YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

「SREの探求」という本が出版されました #seekingsre

はじめに

こんにちは、Cloud Operations担当者です。このたび私が監訳者として関わった「SREの探求―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。

www.oreilly.co.jp

TL;DR

「SREの探求」はGoogle以外の企業でSREの導入がどのように行われているのかを記したエッセイ集です。スタートアップからエンタープライズまで、多くの事例を楽しみながら読める一冊だと思います。ボリュームに圧倒されるかもしれませんが、短編集なのでどの章からでも気軽に読み始められます。ぜひご一読ください。

「SREの探求」のおすすめの読み方

SRE本と同様、非常に分量がある書籍になっていますので圧倒されがちですが、本書は一つの技術に関しての入門やハンズオンを行う類の書籍ではありません。本書の執筆に参加した各社のSREが自らの経験を語ったエッセイ集です。したがって、まずは面白そうだと思う章を読んでみる、というのが良いかと思います。どの章から読んでも構わないと思いますし、読む順番も順不同で構わないと思います。一応、下記にあるように、大まかに4部構成になっていて、各部にある章は関連性が高いものになっているので、読む対象を選ぶときの参考になると思います。

本書を読むに当たって、副読本として同じくオライリーより出版されている「SRE サイトリライアビリティエンジニアリング(以下、SRE本)」が手元にあるとより読みやすいかもしれません。もちろんすでにSRE本を読まれていて内容をある程度把握されている方は必要ないと思いますが、他のSRE関連書籍を読んだことがない、という方は各章に登場するSRE関連用語がわからない可能性があります。Google SREのサイトで原著を無料で閲覧可能になっていますが、日本語の資料があったほうが読みやすいという方はぜひご用意ください。

「SREの探求」はどのような本か

本書はDavid N. Blank-Edelmanが編集し2018年9月に出版された "Seeking SRE" の日本語訳書籍です。

この本は、すでに同じくオライリー・ジャパンより刊行されているSRE本、「サイトリライアビリティワークブック(以下、ワークブック)」「データベースリライアビリティエンジニアリング」に続くSRE関連日本語訳書籍の第4弾となります。

本書は、GoogleだけでなくSREを実践している(しようとしている)多くの企業がその経験を様々な観点から語り、それらを4部に分けて編纂したエッセイ集です。私はこれまで、業務上あるいはコミュニティ関連のイベント等で多くのエンジニアや経営層の皆様と関わる中で、SRE(サイトリライアビリティエンジニアリング)の導入について質問をいただいたときに私が社内のSREの方々から学んだ知見を共有してきました。多くの方々が異口同音にその価値に共感しつつも、その実践となるとハードルがあり、難しいと感じている様子を目にしてきました。

私自身は他社へSREの導入の支援を直接行ったことはない*1ので、実際に各社がどのように導入を行ってきたかは各社の公開情報を断片的に集めてきて学んできました。そうした公開情報はブログ記事であったり、カンファレンスの録画やスライドだったりするのですが、まとまった形で参照できる書籍は本書が出るまでは存在しませんでした。私が2018年にGoogle Cloudのチームへ異動しオブザーバビリティの担当をすることになってからそうした情報を活発に調べるようになったのですが、ちょうど異動した直後に本書が発刊され、これは福音と手に取ったのでした。目次に並ぶ社名を見たあと、実際に各社がSREの導入を試行錯誤した様子を見て、共感をするとともに、苦労が偲ばれました。SREの導入には銀の弾丸は無いと改めて確認するとともに、Google以外でももちろんSREは実践できるのだと、あらためて確信できようになる、そんな一冊でした。

第1部はよく耳にする「SREの導入」についてです。たとえば第6章や第7章ではSoundCloud社がProdEngチームを組織するにいたるまでの経緯、そしてSpotifyでのOps-in-Squadsの内容が詳細に語られていますが、その経験は多くの企業、特にスタートアップ企業に当てはまるのではないかと思います。彼らは専任のSREチームなしでSREを実践してきているわけですが、この例はまさに「SREというタイトルやチームがSREを実践する」ということではなく、会社全体としてその実践を行うことが大事であるということが伺いしれます。また逆に第8章や第10章では大企業でのSREの導入について語られています。これらの章は想像通り鮮やかな解決方法などはありません。特に大企業で発生する組織の問題をどう乗り越えていくのか、という点について生々しい経験を見ることができます。

第2部は「SRE本」や「ワークブック」で触れきれなかったSRE関連の各種手法についての紹介です。カオスエンジニアリング、セキュリティ、データベースリライアビリティなど、「SRE本」「ワークブック」以降に出版された各種書籍につながる内容になっているので、まずはここで概要を抑えてから、必要に応じてそれぞれをテーマとした専門書籍を読むと読みやすいことと思います。*2

第3部はSREにおけるソフトスキルとアーキテクチャーの紹介をしています。個人的には重要なソフトスキルであるドキュメントに関する19章は技術書の中ではなかなか語られないドキュメントの重要性を知れる章です。また23章のアンチパターン集も軽快に読め、気晴らしに読むにはもってこいの章です。

第4部は見過ごしてはならない文化的な側面です。SREに寄った文章にはなっていますが、SREのみならず組織全般に言えるような文化的側面についての考察が広くカバーされています。心理的安全性やバーンアウト(燃え尽き)、はてはソーシャルアクティビズムとの関連性など、広く「人間の組織活動」における懸念事項などを深く突っ込んでいます。心理的にネガティブになるような事象はできる限り起きてほしくないのは常だと思いますし、なかなかソーシャルアクティビズムについてこの文脈で書かれた文章は少ないと思うので、そうした経験を書籍で知れることは意義があると感じます。重い話もありますが、おすすめです。

読んでいただければわかるとおり、どの章も「正解」というわけではなく、現組織が試行錯誤の末にたどり着いた最適解であるということがわかります。それと同時にどの章においてもSRE本やワークブックで何度も語られているような、ユーザーに対する信頼性を獲得するための手法や組織作りを行うことに尽力していることが読み取れると思います。こうした経験の共有が読者の皆さまのヒントになることを期待してやみません。

謝辞

監訳者まえがきでも触れさせていただきましたが、あらためて編集者のオライリー・ジャパンの高恵子さん、翻訳者の渡邉了介さんに感謝いたします。

高さんには全体の進行をしっかりと管理いただき、また私と渡邉さんのコミュニケーションが円滑になるように様々な配慮をいただきました。本書の翻訳原稿はすべて各章ごとにGoogle Docsでいただき、その上に私が「提案」の形でコメントを追加し、それを渡邉さんに再度確認してもらい、良ければ承認、認識のズレがある場合には追加でコメントをいただくという形のワークフローを用意していただきました。会社で日常的にこの形式でドキュメントのレビューを行っているため、私としては大変進めやすかったです。

翻訳者の渡邉さんにはただただ感謝するばかりです。600ページ超の本、しかもエッセイが中心でコードや図表が少なく、かつ技術要素が多い書籍の翻訳を、入念な下調べとともにすばらしい品質で行っていただきました。おかげで私が監修する際にはどこに着目すればよいかが分かりやすく、私の負担が大きく軽減されました。また英語そのもののニュアンスが読み取りづらかった文章も文化的背景から調べていただいた上でいくつかの訳の候補を提案いただいたりと、多くの配慮をいただきました。結局コロナ禍にあって、プロジェクト進行中は直接お会いすることは叶わず、またスケジュールの都合等でビデオ会議もできなかった中で、これほどまでスムーズに共同作業ができたのは、渡邉さんの柔軟性と配慮のおかげだと思います。またこうした機会がいただけるのであれば、ぜひご一緒させていただきたいです。

読者の感想など

レビューエントリー

(更新予定)私の方で確認次第随時追加していきます

blog.hiroakis.net

note.com

e34.fm #7で取り上げていただきました!1:04:00頃から @deeeet さん、@rrreeeyyy さんの注目の章の紹介があります。

e34.fm

speakerdeck.com

ツイート

その他

良い香りがするそうです。

しない場合もあります

*1:ところで、Google CloudではCREPSOといった組織がSREの導入支援を行っていますので、ご興味あればご連絡ください。

*2:セキュリティに関してはBuilding Secure & Reliable Systemsがありますし、データベースリライアビリティについては先に上げた書籍があります。

Googleに入社して10年が経ちました

はじめに

f:id:ymotongpoo:20210415170610p:plain

こんにちは、Cloud Operations suite担当者です。2021年4月18日でちょうどGoogleに入社して10年が経ちました。自分は転職で入社したときのことは書いておらず、前職を退職したときの記録しか残っていませんでした。いい機会なので記録として10年間を振り返ってみようかなと思いました。自分用の振り返りで特に推敲もしておらず、読みづらいと思いますが、とりあえずそのまま出します。

Google入社のきっかけ

当時はPython関係のコミュニティ活動やアウトプットをしていて、ちょうどそのときにGoogleのPartner Solution Organization(いまの gTech という組織の前身)のTechnical Account Managerという職種で空きがあるので、受けてみませんかとメールが来たのがきっかけでした。当時はGoogleというとソフトウェアエンジニア職くらいしか知らなかったので、受けてみるまでそういう技術営業的な職種があることもしらず、失礼ながらどういう職種か調べもせず面接を受け始めました。面接を進める中で職種について理解が深まり、対顧客の仕事が多くあり、様々に技術的に問題解決や価値提供をできる職種だと知ったので興味が深まり、幸いオファーがいただけたので転職しました。

いま思い返すと当時面接してくれた人や入社当時の同じチームだった方はいまはかなりの人が退職したり他国のオフィスに転籍してしまっていて、本当に時間が経ってしまったのだなあと実感します。

YouTubeのTAM/Developer Advocate

f:id:ymotongpoo:20110607010509j:plain
YouTubeの本社に初めて出張に行ったときに撮った雑な写真

最初に担当した製品はYouTubeでした。日本でもいまでこそYouTuberを見かけない日はないほど世間に認知されていますが、10年前はYouTubeは日本国内においてはコンテンツホルダー企業からはお世辞にも良い印象は持たれていなかったと思います。自分は対企業の担当だったのですが、ビジネス開発担当の方々の地道な努力もあって、自分が入ったときには依然としてYouTubeと距離を取っている企業は多数あったものの、同時に試験的にでも公式チャンネルを運用してくださっているも企業がかなりありました。すでにYouTubeを使ってくださっている企業はより収益を上げられるように、まだYouTubeを使っていない企業には導入した場合のコンテンツ保護や収益化した場合の予測、導入の際にはツールやAPIの支援、といったことを業務としていました。当時のYouTube事情はMCN*1が日本でもでき始めたりみたいな話もあったので、結構面白い時期に近くでビジネスが変わっていく様子を見れた気がします。

こういう仕事はソフトウェアを開発するというよりもうまく既存ツールを組み合わせたり、手動でやっていることをなるべく自動化するというような運用仕事がメインでしたが、BigQueryが市場に出る以前よりDremelを使ってダッシュボードを作ったり、お手製ツールで数十TBの参照映像ファイルをアップロードしたりと割とコードを書いたり運用的な仕事が多かったなと思いました。またJASRACとの包括契約を結んでいたこともあって、JASRACが権利者に利用料を再配布するためのレポートを作る必要が出て、実際にそのプログラムを書いたりもしていました。いまはもっときれいに書き直されているはずです。

2012年くらいからはYouTube Liveというライブ配信基盤も公開され、イベントのライブ配信の技術サポートなども現地に行って行ったりしていました。今もそうですが、日本のインターネット環境は世界で見ても相当高水準だったため、日本でのライブ配信帯域幅が大きく、またGoogle側の基盤も不安定だったため、何度かP0のアラートを現地から飛ばしたことがありました。配信の現場にてコンテンツホルダー側の責任者が横で見ている状況で、夜中に起きてもらったアメリ東海岸のSREに状況を説明しながらロールバックやパッチを当ててもらうのは精神的にきつかったです。ただ一方で、生で坂本龍一細野晴臣石野卓球ピエール瀧などに会えたり、種子島こうのとりの打ち上げを見れたのは役得でした。

当時日本でYouTubeに関する対外的な技術的な担当者が少なかったことから、必然的にその動画処理パイプラインやライブ配信CDNの仕組みを見たりすることも多く、技術的にも刺激が多かったです。ご存知の通りYouTubeは買収企業でバックエンドはもともとPythonとMySQLだったのですが、入社時にも絶賛MySQLからBigTableへの移行をしていたりと、巨大なマイグレーションを見ることができたのは面白かったです。

また権利処理システムやネットワーク帯域の確保に関する契約など、サービスに関わる法律や交渉にも関わることができたのは今思えば楽しかったです。Googleが海底ケーブルを他社と協業で敷設していることは有名ですが、それが日本のIXに接続された後は各Tier1プロバイダー経由で各ユーザーに接続します。YouTubeトラフィックでいえば世界有数のトラフィック量を誇るサービスだった(である)ため、たとえばGoogleイントラネットワーク*2と各プロバイダとの接続をIX経由ではなく、ピアリングすることでコストを削減できたりします。あるいはエッジノード(Google Global Cache)で人気コンテンツがキャッシュされていればトラフィックの縮小につながるわけです。こうした取り組みの現場に少しでも関われたのは大変貴重な経験でした。このあたりの話は次のページが詳しいです。

peering.google.com

その後、2年ほどしてからDeveloper Relationsチームに移り、YouTube APIを使ってシステム自動化やSNSキュレーションを行っている国内外の企業の支援をするのも楽しい仕事でした。

Partner Developer Advocate

Developer Relationsのチームが組織改編で製品別ではなく役割別になり、自分はYouTubeのチームから大手企業や中堅スタートアップがGoogleの各種製品(Chrome/Web、Androidといったクライアントサイド)を使って連携する場合の技術支援や新規技術の普及をするチームに移籍になりました。このチームでは常にgTechなどで手厚くサポートできる体制が整う前の新しい製品や機能を扱い、かつ四半期ごとに注力する技術領域が移り、キャッチアップが大変でした。本社やヨーロッパのチームは人数が多く、英語のままサポートできることが多かったので割と技術領域に対してメンバーが固定されていましたが、APACのチームは割と自分と同じように四半期ごとに担当を移る動き方をしていました。

日本で展開に関わった製品でいうとChromecast、Tango、Android Lollipop〜Pieの各新機能、Google Sign-in、Google Photos、Accelerated Mobile Pages、Eddystone、Progressive Web App、Chrome Custom Tabs、Google Now、Googleアシスタントなどがあります。事例をあげようと思ったら多すぎたので割愛。いくつかリリースアナウンスとかインタビューとかで対外的に出ていた記事を貼っておきます。

関わった製品はうまく行ったものもあれば、途中でプロジェクトが終わってしまったものもあり、この会社の良いところも辛いところもいろいろと見てきました。たとえばGoogle Photosに関しては、当時前身となったGoogle+のフォト機能があり、そのフォト機能との他社サービスとの連携というプロジェクトがいくつか動いていました。Google I/Oの直前にようやく連携が終わり、I/Oが終わったらプレスリリースを打ちましょうということになって、現地でお祝いをするという予定も立てた上で、先方の担当者とともにGoogle I/Oに向かいました。で、キーノートを現地で見ていたら、まさかのGoogle Photosが発表、連携用のソリューションもその瞬間にdeprecatedになるという大変苦々しいことがありました。*3

f:id:ymotongpoo:20150525034919j:plain
翌日のキーノートで衝撃の発表をされることを知らずに撮影したGoogle I/O 2015の開催前日の会場の外観

Chromecastの日本展開のときは、元々YouTubeにいたこともあり、割と関わりやすい製品*4だったことも手伝って、非常に楽しいプロジェクトでした。実際いまでも新バージョンが展開され続けている製品ですし、自分も毎日使っている製品なので、その立ち上げ時期に関われたのはとてもいい思い出です。

それぞれの製品を深く見ていくにも一人では限界や得手不得手があるので割とムラはあるけれど、Googleが持っている各種クライアントサイド製品すべてに技術的に関われたのは本当に面白い経験でした。関連してAndroidコミュニティやWebフロントエンドコミュニティ、VR、IoT、SEOやゲーム、はたまたカメラ業界など、多くの業界の方々と関わることができたのは幸いでした。やっていた当時は特に何も考えていなかったけれど、いまクラウドの担当になってから、この辺りの知識を持てていることは自分に取ってアドバンテージに感じています。

Cloud Developer Advocate

Partner Developer Advocateでの仕事も5年ほど続いて、チーム自体には不満はなく(むしろ居心地が良すぎた)担当技術領域も広く見ることができたので大変満足していた一方で、自分の担当がほぼ日本だけだったので、次のキャリアを考えたときにもっと他国とのやり取りが多いチームに移りたいと考えるようになりました。また前職に就職したときもそうでしたが、元々はサーバーサイドに興味があってこの業界で就職したこともあって、クラウドのチームに移りました。ちょうどそのときにポジションに空きが出ていたのはラッキーでした。

自分がクライアント側をずっと見ていた時間の中でサーバーサイドの進歩も非常に多く、特にCNCFを中心としたここ5-6年くらいでの発展は目覚ましいものがあります。いまのチームではオブザーバビリティの領域を担当していますが、Googleの中で発展してきたサイト信頼性エンジニアリングの中で重要な意味合いを持つ技術領域で、かつビジネス的にも繋がりが深い領域なので腰を据えて仕事をできている実感があります。

担当領域が単純な技術の話だけではなく、組織運営や企業経営にも関わるテーマでもあるので、しばらくはこのテーマを元にじっくり取り組んでいきたいと考えています。またコロナ禍以降は海外のお客さんに対してプレゼンやワークショップなどを行ったりする機会も増え、元々目的としていた他国との関わりが多くなりました。得難いポジションだと思うので、まだまだ楽しくやれそうです。

Go

上のような部署の変遷と並行して、Go言語の普及とコミュニティ支援みたいなことも仕事としてやらせてもらったりして大変ありがたかったです。入社した直後は確かバージョンが r57 とかで、バージョン番号が weekly タグから切り替わった直後だった気がします。社内のシステムなんかでもちょくちょくGoが採用され始めて、その様子から「この力の入れようとプロダクトの方向性的にはGoは普及する予感がするぞ」と思って使い始めて、徐々に自分の仕事用のツールもGoに置き換え始めていました。

2012年になっていよいよ1.0がでて、「このビッグウェーブに乗るしかない!!」と思ってGo Conferenceをやりたいと思ったのが2012年末でした。一番最初に開催した幻の初回は20人くらいのこじんまりとした会でした。

f:id:ymotongpoo:20130119144443j:plain
TopGateの会議室で開かれた幻の初回

その3ヶ月後にGo Conferenceとして2013年の春に初開催したのでした。

gocon.connpass.com

@tenntennとはここからずーっと一緒に開催していますが、もう今月末のGo Conference 2021 Springで9年目になるというのが信じられません。始めた当初は世界的にもGoのカンファレンスはほぼなく、日本で数百人規模で開催していると報告するとGoチームも喜んで社内スポンサーとなってくれたのでした。TシャツやGopherのぬいぐるみなどはこのときの支援でもらったものをほそぼそと配布していたのでした。*5

【宣伝】去年はコロナ禍によって開催中止となりましたが、今年は初めてオンライン開催で行います。スポンサーのみなさまのおかげで参加費は無料となっていますので、4月24日にお時間ある方はぜひご参加ください。【宣伝終わり】

gocon.jp

Goの初期から関われて良かったことは、Goチームの人と直接やり取りできたことで、Rob PikeやRuss Cox、Andrew Gerrand、といった方々と直接やり取りできたのは非常に貴重な経験でした。*6

f:id:ymotongpoo:20210409224845j:plain
家宝にしているRenee French直筆のGopherイラスト。Go Conference 2014 AutumnでRob Pikeが東京に来たときに「お礼に」と言ってプレゼントしてくれた

もういまではGoは疑うことなく普及した言語になったわけですが、これからジェネリクスが入ってきたりと新しい局面を迎えようとしています。これからどういった発展をしていくのか、引き続き近くで関わっていきたいと思います。

これから

同じ組織に10年所属するというのは人生においても最長で、特にDevRelのチームメンバーは同じ所属で一緒に居続けるという意味では自分の親の次に長い付き合いになる人もいます。出入りが多い会社にあって、こういった長い付き合いが出来るのは本当にありがたいことです。また同じチームだけでなく、多くのチームの多くの優秀な方々と仕事でき、誇張でなく毎日新しい発見があります。

この業界は隣の部署に行く感覚で転職をすることもよく見聞きしますが、自分の場合社内で3年〜5年で部署を大きく移ってきたこともあり、いまだに新鮮な気持ちで働けている気がします。本当にあっという間の10年でした。いまのチームにいる限りは少しでも多くの人の問題解決を手助けできるように努めつつ、楽しくやっていこうと思います。*7

参照

*1:Multi Channel Network、YouTuberが所属する芸能事務所。日本ではuuumがそういった形態として見られるが、海外では現在は潮流が変わっている。

*2:イントラと呼ぶにはあまりにも大きすぎますが

*3:Google PhotosをGoogle I/Oで大々的に発表するため、担当チームがリークを恐れて秘密裏に進めていたようだけれども、それにしてもこちらから対外連携の話はしていたわけだし、流石にこれはないよと思った

*4:製品の関わりやすさというのは、単純に技術としてわかりやすいだけでなく、製品コンセプトが市場に受け入れやすかったり、開発チームがやり取りしやすかったり、といろいろな要素がある

*5:いまはもう世界的にも商業的に行っているGopherConをはじめ多くのイベントが開催されているので、こういう雑な支援はもらえない

*6:RobがGoチームを離れた後もシドニーオフィスに行ったときにもRobが声をかけてくれたりして嬉しかった

*7:辞めそうな雰囲気出てるかもしれませんが、いまは特に現職を辞めるつもりはありません!

Ansibleでリモートのインストールスクリプトの実行をcurlを使わずに記述する

TL;DR

ansible.builtin.uri でコンテンツを取ってきて ansible.builtin.shellstdin を使って流し込む

サンプル

たとえばrustupのインストールは公式ドキュメントでは次のようなスクリプトを使っている

rustup.rs

curl -sSf https://sh.rustup.rs | sh -s -- -y

これをこのまま ansible.builtin.shell に記述して実行すると warning が出ます。たとえばこういう具合にすると

- name: Install rustup
  ansible.builtin.shell:
    cmd: curl -sSf https://sh.rustup.rs | sh -s -- -y

実行時にこういうふうにwarningがでます。

TASK [common : Run rustup] **********************************************************************************
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.  If you need to use command
because get_url or uri is insufficient you can add 'warn: false' to this command task or set
'command_warnings=False' in ansible.cfg to get rid of this message.
changed: [dev]

指摘のように ansible.builtin.uriansible.builtin.shellstdin を使えばパイプの部分をそのまま表現できるのでそのように書き換えます。

- name: Fetch rustup
  ansible.builtin.uri:
    url: https://sh.rustup.rs
    return_content: yes
  register: rustup_installer

- name: Run rustup installer
  ansible.builtin.shell:
    cmd: sh -s -- -y
    stdin: "{{ rustup_installer.content }}"

YAMAGUCHI::weblogの2020年を振り返る

はじめに

こんにちは、Cloud Ops担当者です。いよいよ2020年も最後の日ですね。そして本日は私の誕生日でもあります。例のやつを貼りました。よろしくお願いします。

www.amazon.jp

今年は誰にとっても大変な1年でした。自分のためにも振り返りをしようと思います。

関連エントリ

ymotongpooの2020年

去年立てた目標

目標は立てたものの、コロナ禍においてすべての出張(海外カンファレンスでの登壇)がキャンセルになり、かつ生活を継続する方向でいっぱいいっぱいだったので、2020年前半はほぼ何もできませんでした。

  • オブザーバビリティ関連の展開
    • 今年よりも露出を増やしつつ、OpenTelemetryやpprof周りの開発に積極参加
  • 執筆/翻訳をまとめる
    • 複数の書籍関連の話があったにもかかわらず進捗が大変芳しくなく、各所にご迷惑をかけたいので、来年中に終わらせます。
  • FP業の展開
    • 独立系FPとしてより展開していきたいです

オブザーバビリティ領域に関して

OpenTelemetryとpprof

OpenTelemetryのupstreamに提案をしたりしたのだけれども、プロジェクトのファイルやビルドの構成に大幅に手を入れなければならず、またレビュー担当からも割と冷たい反応をされてちょっとやる気が無くなったので、保留してしまった。一応、アイデアだけは普通に残っているので、upstreamではなく自社のレポジトリで仕切り直してやることにしました。大きなプロジェクトはなかなか大変。

イベントに関しては、OpenTelemetryの仕様があと少しで安定版(ver 1.0)が出る予定なので、いままで仕様が変わりすぎて開催するのをためらっていたところもありますが、そろそろ開催できればと思います。

pprofに関しては、OSSそのものよりもプロプライエタリなサービスであるCloud Profilerについての話を重点的にしていました。特にContinuous Profilingの重要性などをお話する機会が多く、カンファレンスや企業向けのワークショップなど、多くの場所でお話させてもらいました。

observe2020.io logmi.jp tech.mfkessai.co.jp

2021年も引き続きCloud Profilerおよびpprofに関してはノウハウなどを共有したり、フィードバックを開発チームと共有したいと思っていますので、興味がある方がいたらぜひ TwitterでDM、もしくは ymotongpoo [at] google.com までご連絡ください。

Go関連

緊急事態宣言もあり、運営の@tenntenn さん、@budougumi0617 さん、@micchiebear さんと話した結果、Go Conferenceは東京では開催しない決定を早々に行いました。一方で仙台は10月に延期、元々はオフライン開催の予定だったものをオンラインとの並行で開催という形になったので、登壇者として参加させてもらいました。


S3-1 Goにおけるfuzzingとproperty based testing

一方でGopherConは完全にオンライン開催になったものの、開催週だけアメリ東海岸時間で生活することが難しかったため、まったくオンタイムでの参加ができずに終わりました。残念です。

来年はGo Conference 2021 Springをオンライン開催することが決定していて、すでにCfPが始まっています。みなさんの応募をお待ちしております。

www.papercall.io

執筆/翻訳

監訳

まだ第1校の監訳を終えたばかりで、発売日の予定も立っていないことから告知がまだできないんですが、書籍の監訳は実は初めてでした。監訳経験者から「翻訳者の方の技量次第で大きく作業量が変わる」と聞いていましたし、実際自分も翻訳をしたことがあるのでその点は感覚としてありました。

いざ監訳を始めてみると、渡された翻訳は大変読みやすく、また技術的にもいろいろ調べていただいている箇所もかなりあり、非常に進めやすかったです。ただ一方で原著の分量が非常に多く(500ページ超)、それもあって監訳作業は丸1年かかる大仕事となりました。いまはコメントをつけた部分を再確認している状況なので、年明けに第2校が終わる目処が立つのではないかと思います。

また別の本の監訳の話もあるので、そちらの原著のレビューをすぐにしなければならないのですが、そちらは予定より遅れていてご迷惑をおかけしております...

執筆/翻訳

こちらは、2020年はまったく進捗がだせず本当に申し訳ない限りです。2021年はいまよりも生活が落ち着いていると思う(期待)ので、少しずつ進めていきたいと思います。

自作キーボード

もう2つのエントリーで書きましたが、今年の7月くらいから自作キーボードを趣味として始めて、趣味が高じて自作キーボード向けパーツショップを開店しました。

ymotongpoo.hatenablog.com ymotongpoo.hatenablog.com

開店したお店はこちら。

kochikeyboard.stores.jp

開店してまだ2ヶ月ですから正直まだまだ赤字ですが、自分も楽しみながら「お店屋さんごっこ」をしています。開店に至るまで、また開店後も多くの方々、特に自作キーボードコミュニティの方々に助けていただいています。コミュニティに貢献できるように、また早くお店屋さんごっこから事業にできるように、引き続き地道に頑張っていきたいと思います。

来年は自分で設計したキーボードを出すぞ。

生活

2月頭に引っ越しをしました。コロナ禍に入る直前だったので、このタイミングで引っ越せて本当に良かったです。

ymotongpoo.hatenablog.com

前の家からはそんなに遠い場所ではないのですが、今の家は仕事部屋をきちんと作れているので、仕事と生活の切り替えがしやすく、精神的な面で本当に良かったと思います。また前の家よりも断熱効果が高い家なので、強い寒波が来ているこの冬も暖房無しでかなりの時間を過ごせていて、とても助かっています。その分、夏は日差しをきちんと防がないととんでもなく暑くなってしまうので大変でした。

元々は結構出張や旅行で外に出ることが多い性分でしたが、それがすべてなくなって結構ストレスが溜まっているのが正直なところです。夏にコテージキャンプをしたのですが、人混みもなく遠いところで自然に触れられて良いリフレッシュになったので、来年はタイミングを見てキャンプなどをできるようにしたいなと考えています。

また、今年の3月までは会社のジムでほぼ毎日何らかのウェイトトレーニングをしていたのですが、オフィスが全面的にクローズして、まったく出入りできなくなってしまい、まったくウェイトトレーニングができない日々が続きました。はじめは家でHIITなどをしていたのですが、やはり趣が異なるため、ついに9月にジムを契約しました。人が少ない夜の時間帯に行くと貸し切りできるような環境は本当にありがたい限りです。

5ヶ月ブランクはあったものの、いまはコロナ禍前よりも強度が高いトレーニングができるようになりました。

出張/旅行

今年の1月に出張と旅行が3回もありました。

  • 1月1週目 シドニー出張
  • 1月3週目 ロンドン(友人の結婚式)
  • 1月5週目-2月1週目 ニューヨーク&サニーベール出張

ニューヨーク出張に行くときに「どうも新型のインフルエンザが流行っているらしい」というような話があって、マスクを2重にして歩いていました。あれがまさかこんなことになるとはまったく思っていなかったので本当に危なかったです。

ニューヨークに行く際にダブルブッキングによって、人生初のファーストクラスへのアップグレードがあり、大変快適な空の旅を過ごしたのですが、あれが最初で最後の良き飛行機の思い出でした...あの出張以降、パスポートは家の引き出しの中で眠ったままです。早くまた海外出張に行けるような日が戻ってくるといいなあ。

来年に向けて

  • オブザーバビリティ関連の展開
    • OpenTelemetryは安定版がでるので、イベントを行っていきたい
    • Collector関連でOSSを出したい
    • Go関連だとPBTの知見をもう少し深めて、オブザーバビリティに絡めていきたい
  • 執筆・翻訳・監訳をすすめる
    • 執筆はラフでもいいので書いてしまおうと思う
    • 翻訳はコツコツ
    • 監訳の原著レビューを早めに終わらせて、早く監訳プロセスに入れるよう企画を通す
  • FP業の展開
    • 今年は一切できなかったので、ファイナンシャル・プランニング関連でなにかしたい
  • 自作キーボード
    • お店の赤字の改善
    • 自分でキーボードの基板を設計する

2020年に買ってよかったもの

はじめに

こんにちは、Cloud Ops担当者です。今年も残すところあと3日となりました。いかがお過ごしでしょうか。

2020年に買ってよかったもの

2020年はみなさんと同様に本当に生活が色々と変わってしまった1年で、特に在宅勤務関連の買い物が多かったように思います。また在宅勤務に関連して自作キーボードを始めて、その組立でいろいろ道具を買ったので、そういった道具も多かったです。

昇降式デスク(スタンディングデスク)

会社のオフィスでは長年昇降式デスクを使っていて、分割キーボードと同様に体への負担を軽減することに大きく貢献してくれていたんですが、常時在宅勤務を行うようになり、それが使えなくなりました。いままではIKEAの安い固定式の机を使ってたんですが、常時在宅勤務になるならやはり昇降式デスクが必要だということで諸々調査してFlexiSpotが良いという結論になり購入しました。

flexispot.jp

自分が買ったのは E6 というセットだったんですが、公式サイトを見るといまは取り扱いがないようで、後継のE7が販売しています。自分の周りでもFlexiSpotを購入する人が多く、おおよそE3を買うかE6を買うかという感じだった気がします。

E3の方は天板が付属しておらず、自分で天板を別途買ってくる必要があるため、天板にこだわりたい人がE3を買っていた印象があります。自分はいち早く昇降式デスクがほしかったことと、力は必要になりますがE6は天板にすでに諸々実装されていて、足をはめるだけでジャストサイズの天板付きの机が組み立てられるため、E6を選びました。昇降式デスクは常時使うというより座ったり立ったりを繰り返すことに意味があるので、メモリ機能がついているE6はボタン1つで立位、座位でのベストな高さに設定できて大満足です。

クッションマット

硬いフローリングに長時間立ったまま仕事をしていると、足が疲れてきます。その足への負荷を軽減してくれるクッションがこういったものです。ステンディングデスクだけではなく、元々立ち仕事をされる方向けに作られているクッションが多くあるので、そういったものを選んで使っています。

自分は上のリンクのものを買いましたが、特に問題なく使えていて、実際立っているときの負担は軽くなったと思います。

USB切替器

在宅中はその時の都合でデスクトップとラップトップを切り替えたりする必要があったので、この滅茶苦茶怪しい謎中華メーカーのUSB切替器を購入して使い始めました。キーボード、マウス、オーディオインターフェース、カメラの4本のUSBケーブルをつなぎ替える必要があったので、この切替器でちょうど用途を満たせました。いままで半年以上使ってますが、特に問題が起きること無く、非常に安定して使えています。

本当はKVMを使ってモニターも同時に切り替えられたほうが良かったかもしれませんが、4K 60fpsに対応しているKVMがほぼ無く、あったとしても高価だったので、モニターの切り替えはモニタ側のリモコンで行っています。

EdgeRouter X

3月前後に多くのIT関係者が在宅勤務を始めて、異口同音に自宅のネットワーク環境について話しているのを見聞きしました。自分も例にもれず、多くのビデオ会議に参加するために自宅のネットワーク環境を改善する必要があり、どうせならネットワーク周りの設定を細かくできるルーターにしようということで、コスパ最強という評判のEdgeRouter Xにしました。

それまではGoogle WiFiで(本当に)無駄にメッシュを組んでいましたが、大元のルーターをEdgeRouter Xに変えて、IPoEを優先するようにし、宅内はギリギリまで有線接続するようにした結果、最大で70Mbps程度だった速度もいまは常時上り下りともに500Mbps程度出るようになっています。

f:id:ymotongpoo:20201228120133p:plain

集合住宅だと利用できる回線契約によってキャップがかかることもありますが、幸いきちんと光回線を引っ張ってこれる物件だったのが幸いでした。

オーディオインターフェースとマイク

今年の3月以降しばらく欠品になっていたオーディオインターフェースとマイクですが、幸いその前に導入できてよかったです。

ベリンガー ダイナミックマイク ボーカル ULTRAVOICE XM8500

ベリンガー ダイナミックマイク ボーカル ULTRAVOICE XM8500

  • 発売日: 2018/09/01
  • メディア: エレクトロニクス

どうしてもビデオ会議やオンライン登壇が増えたので、そのあたりの環境を改善すべく導入しました。このあたりの設備は完全にオーディオ沼なので、元々はまっている人や、これをきっかけにものすごい設備を作った人も多く見ましたが、自分は拡張性をもたせつつ、コスパ重視の構成をということで友人に相談をしながらこの構成に決めました。

AG-03は本当に便利で、価格もそこまで高くなく、ループバックもボタン一つでできるし、モニター用のインターフェースもわかりやすいので大正解でした。またマイクは良コスパメーカーのベリンガーの定番マイクにしました。SHUREなどのマイクと比べたら音質は落ちるかもしれませんが、歌を歌うわけでもないので、これで十分だと思いました。

マキタのインパクトドライバ

まだコロナ禍に入る前に引っ越しをしたんですが、いまの家に越してきてから真っ先に取り組んだのがディアウォールを使っての壁面収納でした。

ホームセンターでSPF材の2x4と1x6を買って、カットサービスで切ってもらい、それを家に運んだあとにどんどん組み立てました。思ったよりもしっかりしたものができたので大満足です。その際に大いに役立ったのがインパクトドライバーでした。棚の作成においては

  • 棚の木ネジでのガイドの固定
  • 1x6材をダボ継ぎで棚板にするためのダボ穴のくり抜き

などで大いに役立ちました。

また他にも上に挙げた昇降式デスクの組み立てとIKEAの机の解体、各種家具の組み立てなど、ネジや六角ボルトと使った組み立て・解体を行う作業はほぼすべてこれで解決しました。左手を使ったり物理的に手に力が入らない姿勢でも正しく手早く固定・解体できるのはものすごく便利だと買ってみて初めて実感しました。もうこれ無しで家具の組み立て・解体はしたくありません。

電子工作工具関連

「買ったよかったもの」に含めていいかわからないですが、やはり自作キーボードは触れないわけにはいきません。キーボードキットやキースイッチを選んで、レイアウトを自分でカスタマイズしていくと、ただキーボードを使っているだけではなく、自分のものである愛着が湧いてきます。そのあたりの話は次のブログ記事を読んでください。

で、使い始めてよかったキーボードを2つに絞るとCaravelle BLEとCorne Chocolateです。

で、Corne Chocolateの実装、特にSK6812MINIの実装が難易度が高かったので課金アイテムでチートしたりしました。そのへんも含めての便利グッズの紹介です。

エンジニア ハンダ吸取器 SS-02

「自分ははんだ付けが得意だから失敗しないし、部品を間違って取り付けることなんかない」という人は必要のない代物です。しかし私は違います。調子に乗ってたら向きを逆にしてしまったりなど平気であります。その際にスルーホールから突き出たピンにはんだ付けしてあるものなどのはんだを剥がすのにハンダ吸取器が必要になります。

上のハンダ吸取器は「はんだシュッ太郎」と比較した結果、ぱっと使える中で一番吸い取り力があるもので、他のもっと安い吸い取り器もある中で、その効果を考えるとまずおすすめしているものです。

はんだシュッ太郎も使ってたんですが、吸い取るための口が大きすぎるのと、どうしてもPCBと密着して真空を作れないので、空気ばかり吸ってしまうことが多くありました。上のエンジニアのハンダ吸取器は先端がシリコンゴムになっているので、吸い取りたい場所にドンピシャに密着させて吸い取れるため、一吸いで相当きれいに吸い取れるのが気にいっています。

追記: なんか「吸い取り線のが使いやすい」みたいなこと書いてるブコメがあったので補足するけど、当然ハンダ吸い取り線は使ってますよ。ただ吸い取り線だとスルーホールの中まで入ってるハンダは簡単には取れないので。

白光 こて先 2C型 面のみ T18-CF2

白光 こて先 2C型 面のみ T18-CF2

白光 こて先 2C型 面のみ T18-CF2

  • メディア: Tools & Hardware

はんだ付けをうまく行うためには対象に即したこて先を使う必要がありますが、自分が愛用しているのがこの2C型の面のみのものです。カットされて平たくなった面のみにハンダが乗るのが思った以上に使いやすく感じています。

Wowstick

自作キーボードのお店を開いて、半完成品や組み立て代行サービス、さらに試作品の作成など、多くのキーボードの組み立てをするときに手回しの精密ドライバーを使っていたのですが、Self-Made Keyboards in Japanのdiscordでたしか@hsgwさんが「便利だ」と言っていたのを見て購入しました。

買ってみたらたしかに便利!順回し・逆回しも簡単にできるし、ある程度以上のトルクがかかると止まるし、なにより充電ケーブルがUSB-C対応なのがいい!Xiaomiのインパクトドライバーはラッチ機構がなくて、かかるトルクも大きいから、使ってるときに手首を痛めそうになり危険だと思いましたが、こちらは大したトルクが掛かるわけでもないので、ラッチ機構がないのは特に問題に感じませんでした。

見た目もスッキリしていておしゃれだし、地味にねじが散らばらないようにできる磁石マットとか、ちょっとしまっておくケースとか、机に立てておくスタンドとかも便利です。