YAMAGUCHI::weblog

噛み付き地蔵に憧れて、この神の世界にやってきました。マドンナみたいな男の子、コッペです。

OpenTelemetryプロジェクトが日本のコミュニティに注目している話

はじめに

こんにちは、AWSデベロッパーアドボケイトをしているものです。本来であれば昨日投稿されるはずだったOpenTelemetryアドベントカレンダーの24日目の記事です。本当はここにここ1週間くらい完全にAIアシスタントに設計から実装までやらせたデモについて書きたかったんですが、現時点で重大な問題に対応できてない*1ので、かわりにこの記事ではOpenTelemetryプロジェクトが日本のコミュニティに注目しているという話をします。

TL;DR

いままさに日本のユーザーが注目されています。ぜひこれらの投稿にリアクション(フォームへの回答や返信)をください!

www.linkedin.com

www.linkedin.com

なぜ日本なのか

そもそも世界各国ある中で、なぜ日本のコミュニティが注目されているのか、というと単純に日本のコミュニティやユーザーに次のような特徴があるからです。

  • ユーザーの数も多く、その中でアーリーアダプターの数が多い
  • OpenTelemetryやオブザーバビリティに関連するコミュニティが盛んである
  • 技術的なアウトプットが散見される(importされてるパッケージなどを確認すると集計できる)
  • OpenTelemetryプロジェクトのupstreamがあまりコミュニケーションを取れていない

この話は誰から出てきたのかと言えば、『入門OpenTelemetry(原著名: Learning OpenTelemetry)』の共著者の1人で、現在OpenTelemetryのガバナンスコミッティーメンバーであるAustin Parkerと直接話す機会があったからです。

そもそもこの話が出てきたきっかけはこのIssueを見たからでした。

github.com

タイトルを見れば分かる通りわざわざ「Japanese」と明記しています。この話が出たのが実はAustin Parkerが問題を提起したからだというのが、OpenTelemetryのSlackでのやり取りなどで判明し、re:Inventに僕もAustinも参加してたので直接聞いたほうが早いということでディスカッションをしたのでした(たまたまkatzchangも現地にいたので3人で30分くらい話をしました)。

日本の事例をもっと世界に発信してほしい

他にもあります。OpenTelemetryプロジェクトにはEnd User SIGというものがあり、エンドユーザー向けの情報発信やオフィスアワーなどを企画しているのですが、その中で "OTel Me" と "OTel in Practice" という、OpenTelemetryを使ってみての感想を共有したり、事例を紹介するインタビュー形式のビデオポッドキャストシリーズがあります。

www.youtube.com

www.youtube.com

見れば分かる通り、日本はおろかアジアパシフィック領域からの参加者がほぼいません。理由はわかりやすく、数多くあるSIGのミーティングがAPACタイムゾーンで開催されてないからです。

ということでその状況を改善したいと現在End User SIGのコアメンバーが、ドキュメントの日本語化プロジェクトのapproverに連絡してきたのがこのIssueです。

github.com

OpenTelemetryの課題

また上の2つとは別の話としてOpenTelemetry全体の課題として「プロジェクトの安定性」があります。OpenTelemetryはガバナンス上、仕様の策定→参照実装の開発→問題点の共有→問題の改善と修正というプロセスが一般的です。そのため安定性の問題がある場合にも、仕様を策定するところから始めるものもあり、改善までに多少時間がかかります。またベンダーが中心となって開発されていることもあり、専任で担当していた開発者の退職に伴ってその機能の開発が停止することもあります。

OpenTelemetryプロジェクト全体としてIncubatingからGraduatedになるための課題として、この安定性に関する課題があります。その問題を解決するためにも次の取組を行いたいそうです。

  1. 現状のユーザーが抱える課題を認識する
  2. 安定性の問題とオンボーディングの問題を切り分けるために間口を広くユーザーを支援する

これはAustinだけでなく、同じく Learning OpenTelemetry の共著者であり、同じくガバナンスコミッティーのTed Youngも口にしていた課題です(ところでたまたまTedに直接会えたのでこの話をすることができました)。

来年に向けて

間口を広げるための取り組みとしてOpenTelemetryの公式ドキュメントの日本語化プロジェクトが進んでいます。いまや私やkatzchangだけでなく、@msksgmさんや@kohbisさんがガンガンコミットしてくれています(杉本姓の人だけが参加できるわけではないです)。日本語化プロジェクトに参加する人を増やすというのがまず目下の目標です!ぜひ興味がある方は参加してください!お二人がオンボードするに至った経緯は発表資料やブログで公開されています。

speakerdeck.com

fushagoya.com

また上に挙げていたようにOTel MeやOTel in Practiceに参加してくれる方が出てくれる人/企業をいち早く見つけ、収録したいと考えています(どなたかいませんか?)。

さらに2025年にせっかくupstreamの人々との交流が増えたので、このまま日本のコミュニティへの投資を広げてもらえるよう、コミュニケーションを増やしていきたいと思います。

来年こそOpenTelemetry本番導入元年になるよう、これからもコミュニティ活動を続けていければ思います。コミュニティの人間として、みなさんからのOpenTelemetryへのフィードバックをお待ちしています!

*1:S3 Tablesに独自クライアントでデータを突っ込もうと思った場合に、Apache Icebergの仕様にクライアント側が完全に準拠する必要があり、それが思ってた以上に難しかった

CB650Rを買った話

はじめに

この記事は pyspaアドベントカレンダーの17日目の記事で、技術とはまったく関係のない話です。約2年前に普通二輪免許を取り、その直後に大型二輪免許を取得しました。そして今年の4月に大型二輪CB650R を購入したのですが、なぜバイクの免許を取って、なぜCB650Rを買ったのか、という話を書きます。

学生の頃の話

自分の母親が心配性な部分もあり、小さな頃から「バイクは二輪だから転んで危ない。自動車は四輪だから転ばないから安全」という「理屈はわかるが、それなら自転車に乗らせないほうが良いのでは?」という理論で高校のころに原付の免許を取らせてくれませんでした(そもそも通っていた高校では原付の免許取得は特例でないと取得できない校則があったので、手続きが面倒だからだったということもあるとは思う)。

で、時は流れて自分も大学生になり、友人にはちらほらバイクの免許を取り、中型バイクを購入してツーリングで旅行をしたり、夜に友人同士で自由に家を行き来するような人もでてきました。それを見て自分は「うらやましいなー、でもバイク怖いし、維持も金かかるしなあ」と思いながら過ごしていました。また当時は自分も無限の体力があったので、自由に移動する必要があるときは15km以内であれば自転車でどこでも行っていて、「まあこれでいいか」となんとなく自分に言い聞かせていました。東京に住んでいたこともあり、自転車+電車(たまにバス)で十分便利に過ごせていたこともこれに影響しているでしょう。

大学院に入ると、システム開発の仕事で大学院生の割にはバイトというよりはいささか多めの給料をもらえるようになり、生活費を賄いつつスコットのカジュアルなロードバイクを買いました。これでより一層自転車で移動するのが楽になり、どこでも自転車に乗っていました。しかし、研究室の同期や後輩の何人かがSR400やらD-TRACKERやらCB250やらに乗って、いろんなところに自由に行ってるのを見てやはり「バイクいいなー」と思っていました。

その後輩の中でSR400に乗っていた小野くんは、たまにヘルメットを貸してくれて、自分を後ろに乗せて日帰り温泉まで連れてってくれたりして、それが自分にとって初めてのバイクの体験でした。自転車とはまったく違うあの加速や鼓動感、その躍動感は強烈に覚えていて「バイクすごいなー」と感動をしたのを覚えています。SR400は単気筒のバイクなので、余計にそう思ったのかもしれません。

研究室では小野くんは油圧で人間の手に似せた動作をするロボットハンドの開発をずっとしてたんですが、ひょうきんでいながら真面目でコツコツと作業する彼を見て「本当にすごい根気だなあ」と感心したのを覚えています。小野くんは1学年下だったので、自分がM2のときに就職活動をしていて、結局ホンダに就職していました。最初社名を聞いたときは当時のホンダだったのでロボット部門*1かなと思ったけど、二輪部門と聞いて「まあそりゃあ小野くんだしな」と納得しました。

40歳にして普通二輪免許取得

自分は小野くんの就職活動を見届けた数カ月後に、大学院を修了して就職をしました。その後転職があったり、結婚をしたり、子供が生まれたりといった人生のイベントが数多くあったわけですが、自動車に乗ったり、自家用車を買ったりといったことはあったけれど、「バイクに乗る」という選択肢がまったく思い浮かばず、気がつけば40歳になっていました。

ある日、ふと昔のことを話している最中に、「そういえば大学生の頃、自分はバイクに乗りたいと思っていたんだ」という昔の感情を思い出し、「自分は結局バイクに乗ることがなく人生を終えてしまうのかな」などと考えたら、急にバイクに乗りたい気持ちが昂ってきて、すぐさま教習所に申込みに行きました。新しい家に引っ越すにあたり「原付二種に乗れたら家の周りを移動するのにも便利だしな」とハンターカブを買おうと思っていたことも後押しとなりました。

はじめは「とりあえずハンターカブに乗れればいいか」としか考えてなかったんですが、教習車のCB400 Super Fourに乗っているうちに「中型に乗りたい!」と思うようになってしまいました。免許自体はすんなり取れて、暫くの間はレンタルバイクでいろんなバイクをレンタルして乗っていました。ひとまず「死ぬまでにバイクを運転できるようになる」はクリアできて良かったんですが、一度知ってしまった楽しみは抑えられず、ハンターカブではなく400ccくらいのバイクを所有したくなってしまいました。

大型二輪免許も取得

いざバイクを買おうと思って調べてみると、いま中型で新車のラインナップを見ると欲しいバイクが全然ない!400ccで免許の区切りがある国は少なく、世界的な需要に合わせてバイクメーカー各社がミドルクラス(500cc〜750ccくらい)に力を入れているため、400cc前後に選択肢が全然ない。自分は丸目のネイキッドが欲しいのに、ホンダのGB350は90km/hくらいで謎のリミットがかかって全然高速走行できないし、カワサキZ400はなんか尖ってる、ヤマハMT-03もヘッドライトがシュッとしてる、スズキはそもそも400ccネイキッドを出してない、ということで国内メーカーは全滅でした。外車に乗るか?とも考えて、トライアンフScrambler 400 Xとかもどうかなと思ったんですが、どうせなら制約を取っ払ってしまったほうが良いと思い大型二輪の免許を取ることにして、数カ月後には無事に取得できました。

大型二輪免許を取ると決意し始めた頃から、扱いやすさや自分の性格*2から「乗るならミドルクラスが良いだろう」と勝手に思っていたのと、教習所で慣れ親しんだホンダのCBの4気筒シリーズを踏襲したきれいなエキパイ、その他タンクや丸目ヘッドライトなどの造形からCB650Rがほしいなあと思うようになりました。

こちらの記事より画像引用)

するとおあつらえ向きにCB650RにE-clutchという新しい機構が搭載されるというので、どうせならそれが搭載されているバージョンがいいなあと思うようになりました(実際レンタルバイクに乗っているときに渋滞でクラッチめんどくさいなと思うことがあった)。DCTなどと違ってE-Clutchを切れば普通のMT車として乗れるところに惹かれました。

response.jp

小野くんがE-clutchを開発していた

そういうわけでCB650R E-clutch版に対する購入意欲が湧いていた2024年6月頃だったのですが、調査のためにE-clutch関連の記事を眺めていると、見慣れた顔が出ていて思わず「ええっ!?」と声を上げてしまいました。

www.autoby.jp global.honda

研究室にいた小野くんがE-clutchの主任開発者としてホンダのオウンドメディアやバイク情報サイトでインタビューを受けてました。

読めば、E-clutchの開発に10年もかかったと言うじゃないですか。自分が社会人になってから同じプロダクトに10年も関わり続けたことがなく、業界全体としてもそういった人はごく少数である中、彼は10年間E-clutchの開発を続けて、結果としてホンダの新時代を担う新機構として大々的にリリースされたと。本当にすごいことなので、興奮覚めやらぬうちに小野くんに連絡を取りました。

納期遅延でタイミングを待つことに

やはり新機構なこともあって、なにかしら生産中に問題が発覚したりして当初は2024年6月発売予定だったものが9月に延期され、また生産も追いつかないことから結構納期が遅延していました。自分はつなぎにGB500TTという旧車にすでに乗っていたため、生産体制が戻るまで待てばいいか、と思い結局2025年2月に発注し、2025年4月に無事に納車されました。

それからは趣味のツーリングだけでなく、300km以内くらいの距離に1人でさっと移動する必要があるときにはE-clutchの機能を存分に使いながら長距離移動の足としても活躍してくれています。

(先日のJAWS FESTA in 金沢にもCB650Rで行ってきました)

これから

E-clutch発表当時はCB650R/CBR650Rだけの搭載でしたが、いまやRebel 250とその兄弟車CL250には搭載され、そして先日のEICMAでは更に5車種での搭載が発表されています。その中でXL750 トランザルプにも搭載されるという発表がありました。

バイクを買う計画を立てた当初はトランザルプも買いたいと思っていたのですが、小野くんのためにもE-clutchが付いたバイクが欲しいと思いCB650Rを選択しました。が、今回、トランザルプにも搭載されるということで早くも買い替えの機運が高まっています!小野くんにはこれからも良いバイクを作り続けてもらいたいです!頑張ってください!

(小野くん含めた研究室の後輩と1日中雨の中、朝7時から夜11時までツーリングした日の夕飯。この焼肉屋美味しかった。)

*1:当時は二足歩行ロボットの開発が出来そうな国内の会社ということで専攻からはホンダか豊田中央研究所に行く人が多かった

*2:リッターバイクにいきなり乗るとすぐに死んじゃいそうだから

Go Conference 2025に「参加」してきた #gocon

はじめに

こんにちは、AWSデベロッパーアドボケイトをしているものです。去る2025年9月27日-28日の2日間、東京の住友不動産渋谷タワー(通称: Abema Towers)で開催されたGo Conferenceに、ワークショップとセッションで2日間登壇してきました。もう1週間経ってしまうことに驚きを隠せないでいるのですが、いつまでも余韻に浸るわけにもいかないので、その感想を忘れないうちに書き留めておこうと思います。

speakerdeck.com

speakerdeck.com

Go Conferenceと個人的な関わり

Go Conferenceの立ち上げ

Go Conferenceは今回で開催が19回目、初回開催の2013年4月から12年の長きに渡って開催されています。

gocon.connpass.com

何度か折に触れて紹介されていますが、Go Conferenceはこの開催の前に、お試しイベントで「Go Conference pre 2013 Winter」を企画していて、それが2013年1月に開催されたイベントでした。当時はGoogle App Engine for Goが2011年5月にアナウンスされたあと、GAE上で最も速いランタイムとして注目が増えていき、さらにGo 1.0が前年にリリースされ、Go 1.1がリリースされるかなあとか話しながら、毎日 golang-nuts や golang-dev のメーリングリストを見るというような日々でした。

初回と言えるGo Conference pre 2013 Winterでのワークショップの様子

初回のイベントも盛り上がり、その場にいた何人かと一緒にGoのカンファレンスをやりたいね、という話になりました。そして当時は愛知に住んでいて、地元でGoのイベントを開催していたtenntennが就職に伴い東京に来ると聞いたので、一緒にやりましょうという形で初回の企画を進めました。

この当時はちょうどPython 2系から3系への移行期(Language Moratoriumが終了する間近)でした。個人的にPythonicさをPythonよりも体現していると感じたGoに魅力を感じ、この言語が広く普及してほしいという思いもあり、カンファレンスを開催することにしたわけですが、当時はGoなんて本番環境で使ってる会社はほぼなく、登壇できるほど使っている人もいなかったので、毎回運営で登壇者を探してきては一本釣りで登壇依頼をする、というような状態でした。

当時はカンファレンスと言ってもまだ100人程度のイベントで、スポンサーも会場スポンサーを募るくらいの小規模なものでしたが、一方で新しい言語にありがちな多くの新規アップデートにより、セッション登壇を行う人間にとっては話題に事欠かない時期で、半年に1回開催していました。

そのうち、Goも普及してきて、Go 1.4がリリースされる頃になるとアーリーアダプターが言語の習得しやすさ、ビルドやデプロイの容易さ、実行時の安定性や速度などから利用者が増え、本番環境や当時からすると次世代のOSSでの利用も増えてきました*1。この頃になるといよいよconnpassでの参加登録も毎回抽選、参加者規模も200人を超えるようになってきました。

そして忘れもしない2014年11月のGo Conference 2014 autumnでは、Go言語の生みの親であり、当時のリードであったRob Pikeが登壇してくれることになりました。また最初期のGoの普及活動をしてくださっていた*2鵜飼さんも一緒に登壇してくれることとなり、非常に充実した会となりました。その辺の詳細は当時の記事に譲りますが、Robがイベント後の懇親会にも参加してくれて、青物横丁の普通の居酒屋の座敷で、雑にピッチャーから注がれるビールを飲みながら、 @jxck_ さんの質問に対してPCを奪って「こうやって書くんだよ」ってライブコーディング始めたりする、和やかで温かい会でした。

ymotongpoo.hatenablog.com

最後は青物横丁のコインパーキングで余ったTシャツのじゃんけん大会が開催さてたのも良い思い出です。

2次回後に青物横丁のコインパーキングで大人が数十人集まってじゃんけん大会

Go Conferenceの拡大

初期のGo Conferenceでは、Rob Pike以外にも、Andrew Gerrand、Brad Fitzpatrick、Francesc Campoyなど、当時のGoチームの面々が登壇しに来てくれました。半年に一回の開催だったので、Go teamにかなりの頻度で連絡しまくっていて、来てくれるだけでなく、ノベルティの手配なんかも協力してくれました。来てくれるのは嬉しいと思っていた反面、自分が主催するイベントに呼ぶのは当時の立場でいうと職権乱用にも近い状況だったので、流石にまずいなあと思い、この頃にtenntennに主催を引き継いでもらうことにしました。

またこの頃から規模が拡大し始めて、初めて会場スポンサー以外にもスポンサーをしていただいたり、墨田区の公共施設を借りて初めての有償開催(一般参加 500円)をしてみたりと、さまざまな試みが行われました。徐々に、運営に協力してくれる人が増えていき、ありがたいと思う反面、私とtenntennが常に心がけていたのは「スタッフが疲弊して次回の開催が行われなくならないよう、継続性を大事にしよう」ということでした。

回を重ねる中では、運営が本当に数人しかおらず、私一人でCfPからプロポーザルの選考の段取り、タイムテーブルなどをすべて決めつつスポンサーのやり取りを並行してすべて行わなければいけない場面などもありましたが、なんとかやりきって半年ごとの開催を継続していました。

しかし規模が大きくなるにつれて、少人数運営での半年ごとの開催には無理があるということになり、年次開催に切り替わりました。またありがたいことに多くの企業からスポンサーに関してのお問い合わせをいただき、現物支給でのスポンサー枠に限界が来ていたので、スポンサー費用を管理する一般社団法人であるGophers Japanを立ち上げることとなりました。

コロナ禍とGo Conferenceの継承

しばらくGophers JapanとGo Conferenceの運営の中心メンバーが同じ状況が続いていて、安定して年次開催が行われ、新型コロナ禍においてもオンライン開催で続けてこれました。新型コロナが5類感染症へと分類が変更となり、また世の中がオフライン開催へと移行し始めたときにも、Go Conferenceは保守的に2023年までオンライン開催を継続していました。しかしいよいよオフラインへ回帰していいのではないか、という段になったときに、新しい方に運営を引き継いでもらおうということになって、sivchariさんに引き継いでもらうことになりました。そしてGophers Japanのメンバーは一歩引いて、予算管理やGo Conference以外のGoコミュニティに関する支援などを行う活動にシフトしていきました。

歴代Go Conference主催者での記念写真

Go Conferenceは過去回とは一線を画すクオリティのイベントになっていて、運営内の各チームのみなさんも大変なこともありつつも、無事に開催を終えられたのは本当に嬉しい限りでした。

Go Conference 2025の感想

前置きが長くなりました。

今年は自分は去年よりもさらに一歩引いて、Gophers Japanとしての判断が必要なとき以外は意見することなく、運営のみなさんの応援だけしていました(裏ではGophers Japanとして予算や規約周りの稟議などをしていましたが、運営メンバーに関わることはほぼありませんでした)。プロポーザルの審査にも一切関わらず、純粋にCfPに応募しました。そして、たまたま運よくワークショップとセッションの両方で採択された*3ため、2日間ほぼ純粋に登壇者として参加させてもらいました*4。初めての2日間開催のGo Conferenceは、初めて一参加者の目線で見ることができ、本当に新鮮で楽しいものでした。

クロージングでのsivchariさんとmomiさん

今年は準備期間の途中でsivchariさんに代わってmomiさんが運営のリードをしていたのですが、金沢に住んでいる学生のmomiさんが素晴らしい統率力で運営を引っ張っていました。運営者Slackでしか拝見してなかったので、ぜひ現地でお会いしたいなとずっと思っていたのですが、初めて現地でお会いしてあらためてすごい方だなと感じ、運営にもこうした若い新しい方が入ってくれたことを本当にありがたく思うばかりでした。sivchariさんとmomiさんのお二人がクロージングで次回以降のGo Conferenceに向けての意気込みを話していたとき、上に書いてきたようなこれまでの思い出が一気に押し寄せてきて、胸がいっぱいになってしまいました。

2日目撤収後に行われた有志での打ち上げで、さまざまな地域から運営に参加してくださった学生のみなさんが「Go Conferenceまた運営として関わりたいし、自分の地方のGoコミュニティを盛り上げたい」と言っていたのは、これまた胸が熱くなるものがありました*5

最初は自分が好きで始めたものが、最初にたまたま同じようにコミュニティを作っていこうという気持ちを持った人と出会えて、たまたまGoという言語が普及したことに伴ってコミュニティが大きくなって、そしていまあらためてその場を参加者として見ることができるというのは、人生でもそうそうない幸せな経験でした。

おわりに

すでに来年のGo Conferenceの企画が動いているようです。このカンファレンスがこれからもGopherの楽しい集いの場であり続けるよう、心から願っています。

*1:たとえばPrometheusが2012年11月、Dockerがリリースされたのが2013年3月です

*2:Google社内ではGo Readability Approverとして社員のGo言語の習得の支援もしている

*3:元々Go Conferenceではセッションはセッション応募者は伏せて審査してるので、フェアな審査です。昨年は私はプロポーザル落ちました。

*4:もちろん人手が必要な場面や撤収ではスタッフとして働きました

*5:初回のGo Conference開催のときに小学校2年生だったと聞いて衝撃を受けました

『入門OpenTelemetry』という本が出版されました #learning_otel

はじめに

こんにちは、AWSのオブザーバビリティ/SREを得意領域とするデベロッパーアドボケイトです。この度、私が翻訳しました『入門OpenTelemetry―現代的なオブザーバビリティシステムの構築と運用』という書籍がオライリー・ジャパン社より発売されました。印刷版は書店ならびに各社オンラインストアでご購入いただけます。PDFならびにEPUBオライリー・ジャパンEbookストアにてご購入いただけます。

www.oreilly.co.jp

『入門OpenTelemetry』はどんな本か

本書は、OpenTelemetry という、CNCFのIncubatingプロジェクトに関する解説書籍です。OpenTelemetryは非常に活発かつ巨大なプロジェクトで、訳者まえがきにも書きましたが、2019年にプロジェクトが開始したにもかかわらず、いまやCNCF傘下のプロジェクトでKubernetesに次いで2番目に活発なプロジェクトとなっています。(下記のCNCFのdevstats参照)これはもともとCNCF傘下にあったOpenTracingと、同様の目的のプロジェクトで同じようにすでにユーザーがいたOpenCensusが合併して成立したのがOpenTelemetryなので、発足時点ですでに関係者が多数いたのが要因の1つではあるのですが、それにしても発足時からの発展は目覚ましいものがあります。

all.devstats.cncf.io

そんなOpenTelemetryの解説書籍ではあるのですが、本書にはコード(プログラム、設定ファイル)の類はほぼ出現しません。これほど巨大なプロジェクトの入門書でコードがほぼ出現しないというのは、個人的には驚くべきことだと思うのですが、これは著者陣が意図してそうしました。OpenTelemetryが数多あるOSSの中でも規模が非常に大きい上に、扱っているものの概念が浸透していないこと、そして公式ドキュメントやサンプルを充実させていることがその理由です。

したがって、本書は次のような方におすすめな書籍です。

  • OpenTelemetryプロジェクトの全体像や検討事項を把握したい方
  • オブザーバビリティ・エンジニアリング』を読んでオブザーバビリティの実践を開始しようとしたけれど、計装やテレメトリー収集に関する戦略に関しての理解を深めたい方
  • プロジェクトでOpenTelemetryを使うことになったけれど、プロジェクトの背景や思想を先に知りたい方

OpenTelemetryの各言語用ライブラリを用いて計装をしたり、OpenTelemetryコレクターでテレメトリー収集をし、オブザーバビリティ基盤に送信したり、とい各作業はそれぞれが奥深いものです。筆者たちはそれぞれに関する詳細な解説を書くことも可能でしたが、あえてそれらを削ぎ落とし、背景にある思想や概念、設計方針のアドバイスのレベルでの解説にとどめ、詳細な実装はオンラインのコンテンツに譲った結果、本書はA5版で170ページ程度という、非常に読みやすいボリュームとなりました。

これが可能だったのも、OpenTelemetryというプロジェクトがその始めから、仕様をきっちりと決め、実装はそれに従うというガバナンスを整えていたことによります。もしこれが作者が1人のプロジェクトで、思いつきで実装をしたり、機能を追加したり、APIの仕様変更を行うような製品だったら、こうはいかなかったでしょう。大元の仕様や設計がこれから先しばらくも続くことが想定でき、それでいて細かな実装は変更しうる(APIの下位互換性はある)ものとして、最新版のサンプルを参照するほうが良いからこそ、こうした構成の書籍が成立します。

関連図書

オブザーバビリティバックエンドに関する書籍を挙げると、各ベンダーごとの書籍など多くなってしまうので、ここでは数冊にとどめておきます。

「オブザーバビリティ」という概念そのものを理解するのであれば、まず『オブザーバビリティ・エンジニアリング』をおすすめします。本書でより広い概念を理解したうえで、それを実現するための業界標準になりつつあるOpenTelemetryの理解を『入門OpenTelemetry』で深め、さらに細かな実装に関しては公式ドキュメントや他の解説書を読む、という流れができるでしょう。

OpenTelemetryというプロジェクトはあくまでテレメトリーの計装、収集、送信のみを扱うものです。そのため、テレメトリーがオブザーバビリティバックエンドに送信されたあとの処理に関しては関与していません。しかしながら、テレメトリーの属性(ラベル、ディメンションなどさまざまな呼ばれ方をする)はバックエンドに大きな影響を与えます。例としてはOSSのPrometheusの書籍を挙げていますが、これはベンダーツールでも変わりません。オブザーバビリティバックエンドはOpenTelemetryと対になるものなので、そのつなぎ込みに関わる機能やその概念を理解をすることで、より良い設計ができると思います。

謝辞

本書は日本国内でOpenTelemetryプロジェクトに割と初期から関わっている方々から多くのレビューを頂きました。訳者まえがきでも触れていますが、あらためて私が本書の出版に際してレビューに参加いただいた下記の皆様に感謝します(五十音順)。

またオライリー・ジャパン社の瀧澤さんにはこの2年で4冊の翻訳書の編集を担当いただきました。本書の出版でここ5年ほどずっと続いていた、常に原稿が手元にある状態がようやく一段落しました。本当にありがとうございました。いまは少しの開放感に浸っていますが、また別の翻訳プロジェクトでご一緒できる機会があれば、よろしくお願いいたします。

おわりに

OpenTelemetryはまだまだこれから普及していくOSSだと思います。いまやコンテナオーケストレーションといえばKubernetesデファクトになったように、オブザーバビリティといえばまずOpenTelemetryが選択肢に上がるようになってきました。本書はそのような状況にあって、多くの方々がそのプロジェクトと製品の概要を一息に理解するための優れた入門書だと思います。2025年に多くの方がOpenTelemetryに触れられることを期待しています。

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

はじめに

こんにちは、AWSデベロッパーアドボケイトをしているものです。2024年も最終日となりました。私の誕生日でもあります。

www.amazon.jp

過去の年次の振り返りはこちら。

ymotongpooの2024年

去年立てた目標

  • コミュニティ関連
    • OpenTelemetry meetup とかハッカソンとかやっていきたい
    • Go Conference 2024は久々のオフライン開催なので無事に行う
  • 執筆・翻訳・監訳
    • 1冊は翻訳本を出す
    • 同人でもいいので何かしら書き下ろしたい
  • 趣味
    • キャンプでハンモック泊やタープ泊などの軽量キャンプに行く
    • 普通二輪の免許を取得したらツーリングキャンプに行く
    • グリル料理を覚える
  • 語学

コミュニティ関連

OpenTelemetry

opentelemetry.connpass.com

OpenTelemetry meetupは運営スタッフが増えたことや、イベントの間隔も3ヶ月に1回とかなので、2024年もなんだかんだで3回実施できました。これも会場を快く提供してくださる企業のみなさまのおかげです。大変ありがとうございます。このイベントの外でもOpenTelemetryが話題にのぼることがだんだんと増えてきて、OpenTelemetryがかなり普及してきたように感じます。

これまでは初歩的な内容が多かったように思いますが、2025年はより実践的な内容が共有されることが増えるだろうという期待があります。このイベントも継続して楽しくやっていきたいですね。

opentelemetry.io

それと並行して、OpenTelemetryのドキュメント翻訳プロジェクトが立ち上がったので、approverとして関わっています。OSSはドキュメントのあるなしで大きく普及度合いが変わってくると思うので、なるべく多くのコンテンツを翻訳できればと思っています。日本語化に興味がある方はぜひお声がけください。こちらもご参照ください。

ymotongpoo.hatenablog.com

Go Conference 2024とかGoコミュニティとか

Go Conferenceの主催が3代目の @sivchari さんへとバトンタッチし、新たなフェーズに入りました。新型コロナ禍からオンライン開催に移行していましたが、Go Conferenceは今年からまたオフライン開催が復活しました。素晴らしいスタッフの方々のおかげで大きな問題もなく開催されました。

大盛況のスポンサーブースエリア

歴代主催者での記念写真

今年はついに2013年から参加していたGo Advent Calendarに参加せずに1年が終わりました。今年は転職したこともあり、また別のアプローチでGoのコミュニティへの貢献などを増やしたいと考えています。

執筆・翻訳・監訳

今年は2冊の翻訳書籍を出版できました。これらの書籍はかなり内容的に思い入れのあるものだったので、翻訳に携われて本当に良かったです。

ymotongpoo.hatenablog.com

ymotongpoo.hatenablog.com

書き下ろしの執筆に関してはまったくできませんでした。年初には年後半にできればいいかなと思っていたんですが、まさか思いもよらず転職することになったので、年後半の予定がまったくもって想定していたものと違ってしまいました。

趣味

バイク

去年の振り返りを書いている段階ではまだ普通二輪免許も持ってなかったのですが、その後無事に年明けすぐに普通二輪免許を取得しました。その後、レンタルバイクで友人とツーリングに行って最高だったのと同時に、現状だと400cc付近に良いレンタルバイクの選択肢がなかったことと、排気量制限が鬱陶しくなったので、2月から4月頭にかけて大型二輪の教習にも通い、こちらも無事に免許を取得しました。

というわけで、今年前半は免許の取得からツーリングなどで趣味としてバイクに乗る時間が非常に多くありました。レンタルバイクや友人から次の車種を借りて、さまざまなバイクを試してみました。乗った順に並べるとこんな感じ。

  • Honda GB350
  • Honda 400X
  • Honda GB500TT
  • Ducati Streetfighter V2
  • Ducati Streetfighter V4S
  • Yamaha XSR700
  • Yamaha MT-07
  • Honda CB650R
  • Ducati Streetfighter V4SP
  • Honda CB650R(2回目)
  • Honda XL750 Transalp
  • Honda CBR650R E-clutch

そして友人である先輩が処分するというので、本当に旧車とは思えないくらい乗りやすかったGB500TTを安く譲ってもらいました。まさか初めて持つ125cc以上のバイクが旧車、それも1985年製のものになるとは思いませんでした。500ccということで、新車発売当時に同時に400ccモデル(GB400)も出ていたこともあって、日本国内にほとんど流通していない!しかもかなり古いので純正部品はまず手に入らない、なかなかメンテナンスが難しいバイクではありますが、バイク人生においてビッグシングルのキャブレター車を所有した、というのは良い経験になっていると思います。

譲り受けた時点で、前々オーナーがかなりいじった状態のままでフェンダーレスになっており、ナンバープレートステーとテールランプが単気筒の振動でかなり経年劣化してて、ツーリング中にいきなりもげてレッカーする羽目になったのはいい勉強になりました。(いまは新しいものに付け替えたのでしばらくは大丈夫)

レッカー車を山の中で待っていたとき

また、いまホンダで二輪開発の最前線にいる後輩含めて、研究室の世代が近いOBたちでツーリングに行けたのは楽しかったです。朝7時から夜11時まで、1日中雨の中のツーリングはしんどかったけど、それでもかなり楽しいツーリングでした。普段はソロツーリングが多いけど、気の合う人たちとのマスツーリングは楽しいですね。そんな後輩が開発を主導したE-clutchが搭載されたCB650Rを先日注文もしました。来年春には納車されます。

GB500TTを維持するか、それとも乗り換えるか、駐輪スペースの都合もあるのでめちゃくちゃ悩んでいます...*1

ツーリングキャンプ

たまたま1人で動ける時間があったので、11月半ばに初めてのツーリングキャンプに行ってきました。

初めてのツーリングキャンプなので、遠くを目指さず下道で行ける範囲、かつ積載量を加味してハンターカブでテント泊してきました。ハンターカブの積載力は本当にすごくて、リアキャリアだけで余裕を持ってキャンプ道具が積めてしまいました。真冬に行くとなると更に嵩が増しますが、そうだとしてもこの装備で考えると寝袋が厳冬期用に替わるくらいなので、余裕を持って行けそうです。

リアキャリアにてんこ盛りに載せたらスタンド1つだと転倒しかねない感じになったので、サイドスタンド2個にしたり強化しないといけないなと考えています。

転職

10月末に13年半勤めたGoogleを退職し、11月からAWSに勤務しています。

ymotongpoo.hatenablog.com

ここ何年かは、自分の興味による理由ではなく、他の要因でキャリアが決まってくることが多くなってきて、今回もそういった事情での転職でした。前職と現職で感じたのは、どんなに大きな組織にいても、身近な権限を持った人間の振る舞いが自分の身の回りに大きな影響を及ぼすということです。そういった意味では現職のマネージャーとディレクターには今のところ恵まれています。会社が変わると丸ごと文化も変わる上に、オンボーディングがかなりきっちり組まれているので、来年2月くらいまではそのキャッチアップで結構時間が取られる感じになっていて、少し焦りを感じています。

また新しいコミュニティに入るということで入社前は緊張していましたが、今のところAWS JapanやJAWS-UGのみなさんが温かく迎えてくださって、大変ありがたく感じています。JAWS-UGには、これまで得た知見を共有することでの貢献から始めていければなと思っています。一方で、AWSとしてJAWS-UG以外のコミュニティイベントへの支援もする、というのが今回の転職での私への期待として挙がっていたので、こちらはこちらで去年までと同様に関わっていければと思います。

1つ懸念点としては、日本ではコミュニティイベントが週末に開催されることが多く、家庭の事情を考えるとどうしても選択して参加せざるをえないということです。これから平日開催のイベントが増えることを期待しています。

語学

スペイン語は相変わらずDuolingoを淡々と続けているんだけれども、他の言語はスペイン語を継続するために辞めてしまいました。日常で使う機会がないとモチベーションを維持するのが難しいものです。

スペイン語のほうはなんだかんだで世界中で話者が多いので、使おうと思ったらまだ機会があるので維持できています。先日もre:Inventで南米から来ていた参加者たちとちょっとした会話をする機会がありました。

先日読んだ、尊敬するKazu Languagesさんの著書で書かれていた語学習得法の中で、自分が前から気になっていたPimsleurがおすすめとして書かれていたので、始めようか迷っています。(サービスを始めるとなると1日30分を必ず確保しないといけない)

来年に向けて

  • コミュニティ関連
    • JAWS-UGへの貢献
    • OpenTelemetry meetup の活性化
    • Goコミュニティへの新しい貢献
  • 執筆・翻訳・監訳
    • 書き下ろし
  • 趣味
    • ツーリングキャンプをもっと
    • グリル料理を覚える
  • 語学

*1:GB500TTに興味があるよ、という方はご連絡ください

OpenTelemetryの公式ドキュメント日本語化プロジェクトのメンバーを募集しています

はじめに

こんにちは、AWSデベロッパーアドボケイトをしているものです。この記事はOpenTelemetry Advent Calendar 2024の最終日の記事です。現時点で何日か穴が空いてるので、代打で書きたい方がいたらぜひご参加ください。去年の記事みたいなゴリゴリの内部実装みたいな話を書こうとも思いましたが、OpenTelemetryの盛り上がりを来年以降も継続するためにメンバー募集をしたいと思います。

宣伝

唐突に宣伝ですがOpenTelemetryの概念を理解するための入門書として『入門OpenTelemetry』という書籍が来月末に発売されます。

"Learning OpenTelemetry"の翻訳書です。ぜひ予約してください!

OpenTelemetry公式ドキュメントの翻訳プロジェクト

去年の6月にOpenTelemetryの公式ドキュメントの翻訳プロジェクトが密かに始まり、8月に正式にプロジェクトとして大々的に公開されました。

opentelemetry.io

現在、翻訳が進められている言語として、日本語、中国語(北京語)、スペイン語ポルトガル語、フランス語があります。進捗は言語によってまちまちですが、公式ウェブサイトの画面右上にある言語メニューを選択することで各言語のドキュメントを確認できるようになっています。

実際に上のアナウンスが日本語化されたブログ記事がこちらです。

opentelemetry.io

参加方法

私は母国語で公式ドキュメントが読めるというのはユーザーの拡大において非常に大切なことだと思っています。これを実現するには多くの人手が必要なのですが、今のところ日本語化のコントリビュートは4人からのみで、そのうちほとんどが私が翻訳したものになっています。しかし最近転職とかもあったので、私がほぼ稼働できていません!この火を途絶えさせないためにもぜひ参加メンバーを募集したいと思います。

コントリビュートの方法に関してはこのページに書いてあるので、面倒ではあると思いますがまず上から読んでください。(特にTranslation Guideのところが大事です)

opentelemetry.io

サンプルとして、 open-telemetry/opentelemetry.io にある既存の日本語版を見てもらえればと思います。

github.com

pull requestを作っていただけると、 @open-telemetry/docs-ja-approver になっている人々(現状日本語話者は私と @katzchang )がレビューしてからマージという流れになります。

github.com

pull requestがいくつかマージされると、上のGitHub teamに登録される流れとなり、晴れてapproverになれます。

気後れする方へ

とりあえずどんな感じなのか気になっているけどいきなりpull request作るのは気後れしてしまうという方は、ぜひOpenTelemetry翻訳プロジェクト関係者が集まるチャットに参加して気軽に話しかけてみてください!

まず公式はCNCF Slackの #otel-docs-localization チャンネルです。ここでは翻訳プロジェクトに関わっている世界中の主要なメンバーが全員揃っている上に、なんとまだいまは人が少ないので非常にカジュアルに会話できるという、大変オトクなチャンネルになっています。

cloud-native.slack.com

しかし「やり取りを英語でするのはちょっと・・・」という方向けにもおすすめの場所があります。それが古に作った「Observability Japan」という怪しいDiscordサーバーの #otel-docs-ja チャンネルです。

discord.gg

このDiscordサーバーですが、いまは OpenTelemetry meetup の開催直前になるとちょっとだけ盛り上がるだけという、かなり過疎なサーバーですが、質問などがある場合はすぐに反応があります。

このチャンネルは元々はOpenTelemetryの仕様が1.0になる遥か前に勇み足で日本語化を始めた際に、連絡用に作ったチャンネルだったのですが、公式な翻訳プロジェクトの開始に伴い、元々の日本語化プロジェクトのレポジトリはアーカイブとなりました。

github.com

ぜひお気軽にご参加ください!

やらないといけないこと

すでにプロジェクトは始まっているので、淡々と翻訳していくだけなのですが、記事の翻訳をするにともなって、副次的に次のようなことも課題として挙がっています。

  • 訳語の統一、およびそのブレの自動化
  • 言語間で差異が出ている見出しの順序の統一

方針などは議論しながら進めていければ思いますので、興味を持たれた方は上のSlackや、私のTwitter DMなどでご連絡ください。

おわりに

宣伝もしたとおり『入門OpenTelemetry』も出ますし、来年はOpenTelemetryがますます飛躍する年だと思います。ぜひ一緒に盛り上げていきましょう!

それではみなさん良いお年を!

Googleを退職します

こんにちは。Google CloudでオブザーバビリティやSREを担当していたエンジニアです。明日でこう名乗るのは最後になります。明日、2024年10月31日付でGoogleを退職します。

かしこまった挨拶

Googleに入社してから10年目までの話は次の記事で一旦まとめているので、改めて振り返ることはしません。

ymotongpoo.hatenablog.com

上の記事を書いたのは新型コロナ禍真っ只中で、カンファレンスなどもみなオンラインばかりで、人とのつながりがなかなか難しくなったころでした。その後、ワクチン開発や発症後の処置方法の確立、新型コロナウイルスの5類感染症への移行などがあり、オンラインからオフラインへの移行が再び起こりました。Google Cloud Innovatorsも立ち上がり、上記の記事の後の数年はこのコミュニティの活性化を大きな柱として仕事をしていました。

そして、唐突に退職に至ったわけですが、これも仕事が嫌になった、とか、評価が悪かった事による解雇とかいった理由ではなく、諸般の事情(主に家庭)から諸々検討した結果、そうなりました。13年半勤めた会社をこのような形で退職することになるとは思いませんでしたが、逆にこういったことがないとずっとGoogleで働いていたと思います。入社時と比べると企業の大きさは社員数で見ても8倍以上*1、売上高では10倍以上*2となりました*3。在籍中にはCEOが3回変わったことも含め、企業の文化も大いに変わったところもあり、残念ながら多くの良いと思っていた文化が失われました*4。しかし、依然として社員として働きやすい企業であることには変わりません。技術インフラも素晴らしいものが多く、いまのところまだ世界の先端をゆくものも多く見られます。

社内で仕事をご一緒した同僚も素晴らしい方々ばかりでした。職務上、開発、マーケティング、営業、技術営業、法務、PR、コンサル、サポート*5といったさまざまな職種の方々とご一緒する機会が多くあり、さらに自分の場合はそれが複数の製品においてありました。曲が強い人、いつでも穏やかな人、情熱ほとばしる人、信じられないほど思慮深い人など、みなそれぞれに個性的な同僚ばかりでした。振り返ってみると、こういった一人ひとりがGoogleの強さであると、あらためて感じています。国内外問わず同僚という枠を超えて多くの友人ができたことはかけがえのない財産です。

また社外の多くの方にもお世話になりました。YouTubeではコンテンツホルダーのみなさまと、Partner Developer Relationsでは初期採用事例として実装に協力してくださった企業の方々と、Cloud Developer Relationsではさまざまな顧客企業の方々と多くの関わりがありました。多くの場面で実際の利用者の視点からの製品フィードバックをいただき、ときには懇親会でざっくばらんなお話をしたりと、大変親しくさせていただきました。

コミュニティのみなさまにも大変お世話になりました。多くの技術カンファレンスに登壇する機会がありましたが、登壇者として、参加者として、スポンサーとして、多くの方々との関わりがありました。Google関連コミュニティも大変楽しく関わることができました。Google Developer Groupの皆様にはイベントで各地域にお邪魔した際に大変良くしていただきました。Google Developer Expertのみなさまには月例のミーティング、あるいは全然テクノロジーが関係ないBBQといったアクティビティなどで親しくしていただいたとともに、さまざまイベントでのみなさまの登壇やオンラインでの発信からは多くのことを学びました。何気ない会話が私の業務に生かされたこともたくさんありました。Google Cloud Champion InnovatorsのみなさまにはGoogle Cloudの多くのイベントでお世話になりました。これからもCloud Innovatorsの発展を楽しみにしております。

Googleという会社は、ご存知の通り、とんでもなく多角的な事業展開をしている企業です*6

これらすべてを行っている企業は2024年現在、ビッグテック/ハイパースケーラーと呼ばれる企業を含めても他に存在しません。そのような企業で、しかも各ビジネスが成長する中で、それを傍らで見ることが出来たというのは非常に幸運なことだったと感じています。特にGoogleにおいてDeveloper Relationsという部署は、常に各種製品の開発チームと関わりながら、ときには一緒になって開発を行うことができる、稀有な部署でした。(主要なサービスだとGoogleマップ以外には何らかの形で関わった事がある)さまざまなプロジェクトの思い出を数え上げればキリがありません。2013年後半から11年もの間、デベロッパーアドボケイトとしてGoogleで働けたことは私のキャリアにおいて大きな財産です。

退職することにはなりましたが、Googleが提供するサービスや製品が日常生活に欠かせないインフラとなっている今、Googleという会社との関わりが途切れることはありません。1人のユーザーとして、これからもGoogleが素晴らしい製品や技術を提供し続けてくれることを願っています。

13年半、ありがとうございました。

とりとめのない雑記

訪問したオフィスとか

訪れたオフィスの一覧を思い出して書いてみたけど、結構いろいろなところに行かせてもらった。ロンドンとニューヨークのオフィスが好きだった。パリ、シアトル、チューリッヒは結局行くきっかけがなかったのが残念だった。また新しい本社ビルも結局見ることはなかった。

San Brunoのオフィスは買収したYouTubeの本社をそのまま使ってたんだけど、食堂に入ってた会社の質が良くなくて、数多あるオフィスの中でもカフェは特に不人気だった。しかも外に食べに行くにしても歩いていける場所には選択肢が無くて、YouTubeのチームメイトはかなり食事に不満を持っていた。いまは改善されてるらしい。

  • Tokyo (Roppongi, Shibuya)
  • Seoul
  • Taipei
  • Hong Kong
  • Manila
  • Hyderabad
  • Kuala Lumper
  • Singapore (Asia Square, Mapletree)
  • Jakarta
  • Sydney
  • Melbourne
  • London (King's Cross, Victoria)
  • Amsterdam
  • Copenhagen
  • Berlin
  • San Francisco
  • San Bruno
  • Mountain View (Sunnyvale)
  • Los Angeles (Beverly Hills, Playa Vista)
  • Chicago
  • New York

あと自分は正社員の中でいうと勤続年数が全社員の上位6%くらいだったらしい。逆に13年以上在籍してまだ上位に5%以上の長期在籍者がいるというのに驚いた。

大変だったことなど

楽しかったことはたくさんあって書ききれないので、話す機会があればまたそのときに。

YouTube Liveの配信サポート

YouTube Liveがリリースしてまだ間もない頃にLIVE福島の郡山の回を現地で配信サポートしていたら、ユニコーンYouTube Live使ってリモート参加することになった。嫌な予感が的中して、現地で配信担当してた業者が配信をエンコードをモニタリングも兼ねてるノートPCで行い、WiFi経由で、バックアップ回線なし、モニタリングと同系統の回線を使って配信してくれたおかげで映像はカクつきまくって音も飛び飛びで会場はブーイングの嵐。明らかにデータ送信側の問題なのに、受信側のYouTubeのせいにされてめちゃくちゃ腹たった上に技術側の人間が現地に自分しかいないから、どうにかしてくれと言われてめちゃくちゃ困った。

あと視聴者がすごく多くなって急にラストワンマイルでのレイテンシーがひどくなったという報告を受けたので、現地からニューヨークにいたYouTube SREとGoogle Meetで話しながら対応したのはしびれる瞬間だった。

出張中に車上荒らしにあった

本当に面倒だった。

ymotongpoo.hatenablog.com

ymotongpoo.hatenablog.com

Google Now カードの対応

Googleアシスタントの前身となるGoogle Nowという機能があって、その中にサードパーティ企業がAndroidiOS向けのGoogle検索の上部にカードを表示できる機能があったんですが、ある企業が実装がうまくいかないというんでサンプルコードを書いて提供したところ、あろうことかそのコードをそのまま本番稼働させて事故になった。いまはもうサービスごと消えたんで良かった。

チェンナイのホテルで衰弱

このときの出張が、そもそも旅程が強硬だった上に、ハイデラバードまでは同僚と一緒に移動してたのがチェンナイへ行くのは自分ひとりで緊張感が高まっていた。全館カビ臭いホテルに着いてすぐに腹痛と下痢と熱に見舞われ、何も食べられずにベッドでポカリ飲みながら寝てたときは翌日登壇できると思えずしんどかった。翌朝には少し体調が回復したんで、なんとか登壇できて、その後のデリーへの移動もなんとかできたけど、とてもじゃないけど同じような旅程では行けないなと思った。案の定他の同僚も辛かったらしく翌年から旅程が変更になった。

ymotongpoo.hatenablog.com

gdg.community.dev

干し芋

www.amazon.co.jp

次の仕事

11月1日から新しい職場で働きます。

*1:2010年末で24,400人、2023年末で182,502人

*2:2010年度で230億ドル、2023年度で3,060億ドル

*3:この間にアメリカ自体のインフレもあるので単純な比較は出来ませんが

*4:大企業になったので不満がないかといえば嘘になりますが、今回の退職はそれとは関係のない話

*5:Google社外にも伝わる組織名に言い換えています

*6:これ以外にAlphabet傘下の別子会社も含めると自動運転などもある

*7:10億人以上のユーザーのいるサービスが検索、YouTubeGoogleドライブ、GmailGoogleマップGoogle Playストア、Googleフォトと多数ある

『SREをはじめよう』という本が出版されました #becoming_sre

はじめに

こんにちは、Google Cloudのオブザーバビリティ/SRE担当者です。私が翻訳しました『SREをはじめよう―個人と組織による信頼性獲得への第一歩』という書籍がオライリー・ジャパン社より出版されました。書店ならびに各社オンラインストアでご購入いただけます。

www.oreilly.co.jp

『SREをはじめよう』はどんな本か

(2024.10.17 追記: Forkwellさんのイベントで書籍紹介を行いました

www.youtube.com

本書は『SREの探求』のようにGoogle以外の組織を含めた、より一般的な文脈でのSREの実践を、オムニバスなエッセイの形でなく、概論の形で捉えたい人には最適の書籍です。すでに原著の『Becoming SRE』の日本語の感想などもいくつかの記事で見かけていますが、本書はまとめを読んで理解する、という書籍ではなく、本書と対話をするつもりで読み進めながら考えるほうが効果的な書籍だと思いますので、すでにまとめなどを読まれた方もぜひ翻訳版を手にとって一読いただければと思います。

本書は良くも悪くもSREを理解するための書籍です。SREとはなにか、を整理して要点を提示してくれている側面はあるものの、全体としては読者がSREの実践において現時点でどこにいるのか、その認識をより明確にするための補助となる書籍です。したがって、製品の細かな設定やベストプラクティスの構成に関する話ではなく、概念や文化、プラクティスに関する確認を散りばめています。「すでにSREは実践できている」と自認している方々にも、自分たちの立ち位置を確認するために、有用な書籍だと思います。

私が訳者としておすすめしたいのは、読者のみなさんの組織の中でSREに取り組んでいる方々全員で、本書を輪読をしながら感想や意見を交換することです。SREには多くのプラクティスが存在し、そのプラクティスの実践に寄り添うためのさまざまな技術や製品が存在します。(オブザーバビリティ、CI/CD、機能フラグ、ストレージ、コンテナオーケストレーター、IaC、ポリシーマネージャー、etc...)これらを、SREの根幹である「信頼性」を「適切なレベル」で「継続的に」維持するために使うという意識がある場合とそうでない場合とでは、システムに対する見方が大きく異なってきます。

本書の本文中にもあるように、本書はSREの概要に関してGoogleが提唱し続ける価値や実践に寄り添うようにしていますが、一方で多くの著者自身の意見を述べています。脚注のレビュアーのコメントにもぜひ注意を向けてみてください。本書を読み進めながら、「SRE実践の幅」を感じとってもらえれば幸いです。その幅を感じることで、本書以外のSRE関連書籍をあらためて読んだ際に、新たな発見があることと思います。

みなさんの感想をお待ちしています。

こぼれ話

著者 謝辞内の脚注7

今回、本を書くことは容易なことでしたが、世界は大変でした。本当に辛かった。誰にとっても。

この文の最後に脚注7として「原著の執筆は2021年下旬から行われました。」とありますが、これは新型コロナ禍であったことと、議事堂襲撃事件などを含め、アメリカでの治安の急激な悪化が背景にあります。著者がアメリカ在住なので本文でそのような表現になっています。(著者に確認済み)明言をしていないことと、議事堂襲撃事件はアメリカ固有の文脈が強く、日本語訳版において「世界は大変でした。〜誰にとっても。」という内容に即すかが悩ましかったので、新型コロナ禍の部分を強調でいるような含みをもたせるほうが良いと思い、脚注も同様にニュアンスを含めるにとどめました。

序文 アドリエンヌ・リッチの詩

序文冒頭のアドリエンヌ・リッチの詩の引用は最後の最後まで悩まされました。たとえば、3章の脚注10におけるリルケの詩や10章の脚注9にある首楞厳経、あるいはそれこそ他のオライリーやその他の著名な技術書からの抜粋などは、各々の日本語訳版をあたることで表現を揃えられました*1。しかし、このアドリエンヌ・リッチの詩に関しては日本語訳版が見当たらず、自分で翻訳することとなりました。

付録C 第10節

日本語話者、および日本在住の方向けのSRE関連情報を加筆しました。正直この内容は流動的なので掲載するか迷ったのですが、日本のSREコミュニティの発展を願って掲載しました。こういった情報がどんどん増えることを期待しています。

*1:資料の検索にあたっては編集の瀧澤さんのお力添えがなければ何倍もの時間がかかっているところでした。あらためて感謝します。

SRE NEXT 2024で「オブザーバビリティのマクロからミクロまで」というタイトルで発表しました

はじめに

こんにちは、Google CloudでオブザーバビリティやSREのデベロッパーアドボケイトをしているものです。少し時間が経ってしまいましたが、去る8月3-4日に開催された「SRE NEXT 2024」にて、開発フェーズの各段階におけるオブザーバビリティについての発表を行いました。

sre-next.dev

スライドはこちらです。

speakerdeck.com

動画はこちらです。

youtu.be

発表内容のTL;DR

本番環境が持つべきオブザーバビリティ(マクロなオブザーバビリティ)は、事前に拾いきれない不測の事態を発見し対応するためのものであるのに対し、リリース以前のオブザーバビリティ(ミクロなオブザーバビリティ)は、求められたパフォーマンスを提供していることの確認をするためのものです。そのため、それぞれに用いるツールセットや取り組み方には違いが生まれます。

これらを理解するために推薦する書籍として以下の4冊を挙げます。

  • 『SLO サービスレベル目標』
  • 『オブザーバビリティ・エンジニアリング』
  • 『効率的なGo』
  • 『詳解 システムパフォーマンス 第2版』

こうした情報を一貫した日本語で、日本の方に早く広く伝えたいので、翻訳活動を行っています。

『効率的なGo』という本が出版されました #efficient_go

はじめに

こんにちは、Google Cloudのオブザーバビリティ/SRE担当者です。出張中で発売日にきちんとした記事が書けなかったのですが、去る2月24日に私が翻訳しました『効率的なGo―データ指向によるGoアプリケーションの性能最適化』という書籍がオライリー・ジャパン社より出版されました。書店ならびに各社オンラインストアでご購入いただけます。

www.oreilly.co.jp

電子書籍版はオライリー・ジャパンのサイトにPDFおよびEPUBでの提供がありますので、そちらよりご確認ください。

『効率的なGo』をなぜ翻訳しようと思ったのか

私は業務において、SREやオブザーバビリティに関わる各種プラクティスの啓蒙や、それらの各種製品(Google Cloudのプロプライエタリ製品やオープンソースソフトウェア、その他関連製品なんでも)を使った実践などを解説したりしています。ここ数年でのオブザーバビリティに対する注目が高まったこともあり、計装やAPMに関する情報はだいぶ増えてきたように思います。一方で、ボトルネックの究明を行った後の最後の一歩、ボトルネックの改善をどう行うのかについては、アプリケーション開発の文脈に渡されてしまい、あまり一般的な解説が得難い領域でした。

そんな中、『オブザーバビリティ・エンジニアリング』の翻訳の第2校がちょうど終わる頃に、原著 "Effecient Go" の出版が決まり、急いでその内容を確認したところ、まさにその解説が得難い領域をテーマとした書籍であったこと、そして内容もGoに限らない、アプリケーション性能改善一般に触れる書籍であったことから、翻訳の企画をオライリー・ジャパンへと持ち込みました。

ここ最近私が関わったオライリー・ジャパンでの翻訳書籍は、企画が立ち上がった順序で言うと、『SLO サービスレベル目標』『オブザーバビリティ・エンジニアリング』の順だったのですが、ちょうどこの順序でサービス全体のマクロな視点の目標設定から始まり、それを効率よく観察するためのオブザーバビリティの獲得、そして問題がある場合の原因の究明までは理解ができますが、最後の性能改善の部分が足りないとと考えていました。そこにおあつらえ向きに本書が出版され、まさに福音でした。

また本書がGoで解説していたことも大きいです。自分が最も使う頻度が高く、長らく関わっているプログラミング言語なので、『Go言語による並行処理』と同様に、内容の理解は他の言語で解説されたものよりもできるからです。

こういった偶然が重なり、本書を翻訳する機会を得ることとなりました。

「効率的なGo」はどのような本か

本書は次のような読者に有益であると考えています。

  • Goによって開発されたプログラムのパフォーマンスを改善したいと考えているエンジニア
  • 他の言語でのパフォーマンス改善方法を知っているが、Goでの方法を知らないエンジニア
  • パフォーマンス改善一般について理解したい方
  • Goがどのようにリソースを使うか、理解を深めたいエンジニア

本書は書籍タイトルにもあるとおりGo製のプログラムを中心として、そのパフォーマンス改善手法について解説していますが、Goに限らない、プログラムのパフォーマンス改善において汎用的な考え方が紹介されています。

また本書はGoのランタイムからOSまでという、これまであまり解説がまとまった形で得られなかった低レイヤーの解説にもある程度のボリュームが割かれている書籍なので、初級者向けの書籍では刺激が得られないエンジニアにも、非常に興味深い内容になっていると思います。

関連図書

本書の関連図書として私からいくつか挙げてみます。

まず先にも紹介しましたし、本書の訳者まえがきにも書いたのですが、『SLO サービスレベル目標』『オブザーバビリティ・エンジニアリング』は真っ先に挙げたい書籍です。

もちろん自分が翻訳に関わったからでもありますが、先にも紹介した通り、一連のオブザーバビリティの獲得と性能改善というシナリオを大局的に理解するために必要な情報はこの3冊で網羅されています。

そしてプログラムの性能問題の調査に関しては『詳解 システム・パフォーマンス』を外すわけにはいきません。非常に分厚く、また価格も高いので購入がためらわれるかもしれませんが、逆にこの内容の充実ぶりで7000円を切る価格で販売されているというのは破格と言っても過言ではありません。内容も、非常に丁寧に解説されていますし、頭から通して読まなくても、辞書的に使えるところが素晴らしいです。一人一冊とまでは言わないまでも、一社に一冊は備えておくことをおすすめしたいです。

本書にならんでGoの内部挙動を紹介する書籍として紹介したいのは『Goならわかるシステムプログラミング』です。本書より少しだけ上のレイヤーで広くGoのランタイムの解説をしています。システムコールのレベルでGoのランタイムとOSの関係性を知りたい場合にはおすすめの書籍です。

また本書で解説されている内容の中で、GoプログラムとCPUに関する章(第4章)がありますが、そちらに興味を持たれた方は『プログラマーのためのCPU入門 』をおすすめします。より一般的な立場からプログラムとCPUはどう連携して動くのかを深く解説されている書籍です。

おわりに

私は職業柄、システム全体、サービス単体、関数1つと様々なレベルでの性能最適化に関わる話をすることがありますが、一貫して広まってほしいと思っている考え方は「性能を改善するためには計測し目標を立てること」です。本書が、その普及の一助になることを期待しています。