taxin's notes

雑記

「SREをはじめよう」の読書会を実施した

先日、「SRE をはじめよう」という本を読了しました。gr1m0hさんと一緒に読書会形式で読み進めていたのですが、本の内容・読書会の進め方も全て含めて満足度が高かったので、そのことについてブログを書いてみようと思います。

書籍の翻訳をされた山口さんも、SRE に取り組んでる人で書籍を輪読をしながら感想・意見交換をすることを推奨されていましたが、これを実践した人の体験談としてお読みいただければと思います。

ymotongpoo.hatenablog.com

私が訳者としておすすめしたいのは、読者のみなさんの組織の中でSREに取り組んでいる方々全員で、本書を輪読をしながら感想や意見を交換することです。

「SREをはじめよう」について

「SRE をはじめよう」という本の内容を端的に説明するのであれば、オライリー・ジャパン社のサイトにある下記の文章が適していると思います。「個人としてどのように SRE を始めればいいのか?」「組織としてどのように SRE を始めればいいのか?」という 2 つの主題を軸に、トイル、ポストモーテムなど SRE に関する様々なトピックについてまとめられています。どのようなトピックについてまとめられているかは、下記 HP の目次を参照してください。

www.oreilly.co.jp

本書は、自身もSRE/DevOps/システム管理の分野で40年のキャリアを持つ筆者による、個人がSREになるための、また組織がSREを導入し、発展させるための指針を平易かつコンパクトにまとめた書籍です。 「SREとはどのようなものか」「SREになるには何をすればよいのか」「SREを導入するにはどのように始めればいいのか」「するべきこと、避けるべきこと」といった、SREにまつわるさまざまなトピックを幅広く解説します。

SRE として仕事をする場合、多くのプラクティス・技術に向き合う必要があり、自分個人に閉じるだけでなく個人の動きから組織の活動につなげるようなトピックが多く存在します。そういった中で、SRE の実践に関する全体像が見えず何をどのように始めたらいいかという部分に不安を感じることもあるかと思います。この書籍は、そのような人に SRE の実践のための概要と道筋を提供する書籍だと思います。

読書会の進め方

読書会は KWL チャートを利用して行いました。具体的には、Miro で各章ごとに KWL チャートのボードを作成して、読書 (カードの作成) → ボードに貼られたカードを眺めながら議論という形式で進めました。参加者の負担にならないように事前準備は一切不要としたのですが、その結果として書籍の読了に繋げることができました。

www.lifehacker.jp

KWL チャートは What I Know (K), What I Wonder (W), What I Learned (L) の 3 セクションで構成されていますが、途中から 感想コーナー のセクションを設けるようにしました。KWL にも当てはまらないが共有しておきたい内容を感想として書くことで、「話のネタ」的にそこからカードの内容を拾って会話・議論に繋がった場面が何回もありました。

読書会の時間としては、1 回あたり 2 ~ 2.5 時間程度かかっていました。読書 (カードの作成) もその場で実施するので、どうしても読書会 1 回あたりの所要時間は長くなってしまいます。一方で、それだけの時間をかけても損はないくらいの気づき・学びを本書と読書会での議論を通じて得ることができたと思っています。

読書会に利用した Miro のボードは最終的に下記のようになりました。左から What I Know (K), What I Wonder (W), What I Learned (L), 感想コーナー の順に分かれているのですが、各セクションの内容を連携させながら議論が発展している様子がわかるかと思います。

「SREをはじめよう」を読んだ上での感想

本書で個人的に面白かった章について、2 つほどピックアップしてみます。読書会の中での会話・議論についても軽く触れますが、具体的な内容について全て言及することは難しいので多少ぼやかして書いています。

4章 SREについて語る (SREの提唱)

章のタイトル通り、SRE の提唱というトピックについて語られています。「SRE とは何で、なぜこれが重要なのか」ということを組織に説明するために、効果的な提唱方法やストーリーテリングにおける重要なポイントについて説明しています。SRE は様々なエンジニアリング・運用に関するプラクティスを中心に構成されており、SRE の実践においてはそれらを組織に導入・展開していく必要があります。その際に、SRE の実践を主導する人々はプラクティスの提唱に必然的に向き合うことになるでしょう。逆に、組織において理解を得ることなくプラクティスや各種ツールを導入しても、それらは長続きしない可能性が高いということは直感的に理解できるかと思います。

私は Mackerel というオブザーバビリティプラットフォームの SRE として働いているのですが、先日の Observability Conference Tokyo 2025 の Mackerel ブースで実施したアンケートボードでも、オブザーバビリティツールの組織内への展開・利用促進に課題感を抱える方々が一定数いました。これも、SRE 分野における提唱に関する課題の 1 つかと思います。

mackerel.io

著者は、SRE の提唱においては、複雑で多変量な情報を関連づけるためのストーリーの整理とストーリーを伝える相手について理解することが重要であると語っています。ストーリーを伝える上での課題についてもいくつか語られていますが、「吠えなかった犬」の例え話について 1 つピックアップしてみます。これは、SRE の実践において個人的によく見聞きする課題です。SRE の価値は、「何が起きなかったか」という点に表れるため、障害が起きなかったことやデータ損失が防げたことなど、否定的な事象からストーリーを語るのは容易ではないという課題について取り上げています。この課題に対しては、コントラスト(対比) を意識した上で物事がうまくいっている要因を整理し、それらがなかった場合に物事がより悪化する可能性があるという点について認知させることが重要だと著者は述べています。

この章の読書会では、提唱における課題と実践的なアプローチについて議論しました。例えば、ストーリーを語るタイミングとしていつが適切かであったり、具体的な提唱のアプローチ (e.g. チーム内外で提唱のアプローチを変える、提唱の主体をあえて SRE ではなく別の人にする、ストーリーの整理の段階で組織を巻き込む) について語っていました。また、ストーリーテリングの難易度においては、組織構造など変動要因がいくつか存在し得るという話題もありました。

14章 Dickersonの信頼性の階層構造 (良い出発点)

この章では、SRE を組織に導入する際に、何から手をつけるべきかというトピックについて語られています。このトピックに対する 1 つの答えとして「Dickerson の信頼性の階層構造 (The Dickerson Hierarchy of Reliability)」が取り上げられていました。本書内では、オリジナルの階層構造に少し修正を加えたものが取り上げられています。

sre.google

We’ll use this hierarchy, illustrated in Figure 3-1, to look at the elements that go into making a service reliable, from most basic to most advanced.

この階層モデルは、信頼性の改善に向けた取り組みを監視/オブザーバビリティ・インシデントレスポンス・インシデント後のレビュー・テスト/リリース・キャパシティ/スケール・開発・UX の 7 つのレベルに分類しており、下位の階層から着実に積み上げていくことを推奨しています。最初の階層として監視/オブザーバビリティが取り上げられていますが、この階層は SRE の実践に関する取り組みが短期的・長期的な観点で信頼性にどのような影響を及ぼしているかを定量的に測るために重要な情報源であるとして説明されています。それ以降の階層についても説明されていますが、ここでは割愛します。

この章の読書会では、Dickerson の信頼性の階層構造について議論しました。監視/オブザーバビリティ・インシデントレスポンスといった各階層を構成するトピックは相互に関連しています。そのため、階層のトピックにある程度取り組んで次の階層に進むというものではなく、それぞれのトピックについてある程度満遍なく進めるという意味では螺旋のような 2 次元構造が実態に近いのではないかという議論をしていました。

最後に

「SRE をはじめよう」という本とその読書会についてお話ししました。(SRE を実践している 1 エンジニアとしての観点から) SRE の実践を目指す人にとって、まず最初に読むべき本としてぴったりの書籍だと思います。本記事を通じて興味を持った方は、ぜひ手にとってみてください。

SRE NEXT2025にコアスタッフとして参加しました

07/11 (金) - 07/12 (土) の2日間でSRE NEXT 2025が開催されました。今年もコアスタッフとして運営のお手伝いをさせていただきました。

sre-next.dev

SRE NEXTの運営スタッフとして参加するのは4年連続4回目です。一番最初にSRE NEXTのスタッフとして参加したのが4年前と考えると、感慨深いものがありますね。

taxintt.hatenablog.com

taxintt.hatenablog.com

taxintt.hatenablog.com

今年は、去年に引き続きRoad To SRE NEXTの運営と当日はTrack Aのチームリーダーを担当していました。

Road to SRE NEXTは2024年に引き続いての実施で、今年は去年以上に日本全国を回りたいねという話をしていました。年明けからスケジュールを引いて、ほぼ月1ペースで地方イベントを実施すると分かった時は「本当にこれやれるのか...?」と思いましたが、7都市で無事開催できました。会場・懇親会スポンサーといった形でサポートいただいた企業の皆様、そして何より参加いただいた皆様のおかげです。この場を借りて、皆様にお礼申し上げます。

目指せ47都道府県制覇!ではないですが、来年は新しい場所でも開催できるといいですね。ここで開催してくれ!みたいなお声があれば、ぜひ #srenextハッシュタグをつけてXでPostしてもらえると参考になると思います。

Road To SRE NEXTの地方イベント、SRE NEXT 2025の両方で共通して「会話」が個人的に強く印象に残っています。今年のテーマは Talk NEXT! でしたが、カンファレンスの廊下・ディスカッションイベント・スポンサーブース・Road toの地方イベント (二次会も含む) で色々な人と話をしました。

blog.sre-next.dev

なぜ会話なのか? 2023年の山口さんによるクロージングキーノートでは「信頼性は会話です」という言葉で締められ、関係者感での対話により信頼性目標が決定し、実現のためのアクションが行われていくということが語られました。 SRE NEXT 2025ではカンファレンス内における会話(Talk)を通して各々次のアクション(NEXT)のためのヒントをより多く得られるような場の提供を試みます。

少人数の対話の中で、自分達が抱えている課題を共有したり、あるいはその逆もありました。対話の中で必ずしも答えや結論が出てくるわけではないですが、他者に説明する過程で自分の頭の中が整理されたり、他者が抱えている課題について対話する中で気づきを得たり、対話そのものにも価値があると特に今年は強く思いました。

そういった実感があったので、ディスカッションイベントや廊下でもっと多くの方と会話したかったなというのが一つ心残りです。これは、「話のネタ」としての課題感・疑問・アイデアを去年より多く持っているということの裏返しかもしれません。

何はともあれ、大きなトラブルもなくSRE NEXT 2025を終えることができて嬉しく思います。次はSRE NEXT 2026でお会いしましょう。

SRE Kaigi 2025で登壇しました

2025年1月26日(日)に開催されたSRE Kaigi 2025に参加していました。

2025.srekaigi.net

最初に、SRE Kaigi 2025運営の皆様ありがとうございました。 カンファレンス初登壇で緊張もありましたが、終わってみると懇親会も含めて総じて楽しく過ごせたかなと思います。

登壇

「監視SaaSの運用におけるObservability改善の歩み」というタイトルで登壇させていただきました。

speakerdeck.com

監視SaaSのサービス基盤におけるO11y改善ということで、多少物珍しい内容だったかなと思います。

Mackerelはメトリクスを中心とした監視機能を提供していて、ドッグフーディングを兼ねてサービス基盤の監視をMackerel自身で行っています。

そのような背景はありつつも、O11yの改善の進め方・学びにおいては事例として共有する価値があると感じたので、今回は改善の過程に焦点を当てて、なるべくMackerelの機能理解に依存しないような形でセッションの構成を考えてみました。

テレメトリーの性質、ラムズフェルドの4象限を用いたO11yの分類という汎化された要素を使って、改善の歩みを整理できたかなと思います。

気になったセッション

登壇の緊張と終わった後の脱力感もあって一部のセッションは見れなかったのですが、都合の良い時間帯のセッションはチェックしていました。

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

セッション自体は見れなかったのですが、資料を見たものもいくつかありました。

speakerdeck.com

speakerdeck.com

speakerdeck.com

個人的に一番面白かったのは @nari_exさんの「インシデントキーメトリクスによるインシデント対応の改善」です。指標として馴染みのあるMTTRの問題点を切り口に、データの変動性を抑えて改善箇所を明確にできるTTXメトリクスの紹介と活用について語られていました。

障害対応のプロセスを改善するにあたって「もっと素早く障害復旧できるといいよね」という会話がよくなされると思います。一方で、細かく要素分解をしていくと検知・調査開始・修正など「どこまでの期間を短縮したいか」という切り口があるので、TTXメトリクスの図を共通認識としておくと改善の議論において目線を揃えられそうだなと感じています。

懇親会(二次会)

懇親会や二次会でも色々な方とお話しできてとても楽しかったです。

話した内容で何か一つ抜粋しようかなと思ったので(手前味噌ですが)はてなのSRE標準化委員会の取り組みがあまり知られてなかった割に反応が良かったので紹介しておきます。

hatena.co.jp

はてなの初期は自社toCサービスの一事業だった経緯もあり、インフラやアプリケーション実行基盤は一枚岩で構成されていて、それをメンテナンスする専任のチームを置いていました。その後現在のように事業が多角化していき、すべてのサービスが同じ基盤に乗るのは開発・運用の面でさまざまな不都合があるというわけで、インフラも含めて開発チームがプロダクト全体のオーナーシップを持つように体制を変えていきました。 すると当然ながら、各チームが使う技術やノウハウがばらばらになっていったんですよね。ここで事業をサイロ化させていくことは、はてなの職能組織として本意ではない、ということでチーム横断的に技術を標準化していく取り組みを始めることになりました。

はてなのSRE標準化委員会は、チーム横断的に技術を標準化することを目的とした集まりです。CI/CDの標準化、社内向けのTerraform Modulesの管理やSRE向けのオンボーディングプログラムの作成など色々行なっています。

組織図に現れない「同好会」的な立ち位置だと思いますが、一定のアウトプットが出るように一つのテーマに2,3人のチームで活動しています。組織的な拘束力はないけど社内理解もあるので一定の工数を割けて、半期ごとにアウトプットも継続して出してます みたいなことをお話ししました。

SRE標準化委員会の取り組みとして社外に見えるものは SRE連載 という形で公開しているので、気になった方はぜひご覧ください。

developer.hatenastaff.com

終わりに

今回のSRE Kaigi 2025では、スピーカーとして登壇したこともあり多くの刺激と学びを得ました。今後もイベントに定期的に顔を出していく予定なので、何かしらの形でSREコミュニティに参加・貢献できればと思います。

2024年の振り返り

2024年がもうすぐ終わるので、今年を振り返ってみたいと思います。

去年は家族の体調不良で一人寂しく年末過ごしていたようですが、今年は実家でのんびり健康に過ごしています。

taxintt.hatenablog.com

仕事

今年も監視SaaSであるMackerelのSREとして働いています。SRE座談会とかしたな〜と思っていたのですが去年でした。完全に今年だと思っていたので頭を抱えています。

hatena.co.jp

座談会の中で下記のようなことを言っていましたが、Mackerelというプロダクトとしての各種開発が進む中で「今の」「自分が」何をすべきか考えながら、より良い状態を追求するように試行錯誤していた一年でした。

ひと言でいうと、more betterを追求できるような人ですね。はてなのEmbedded SREの役割やミッションで重要なのは、一定の信頼性のもとで開発速度を最大化すること。そのトレードオフはそのプロダクトや開発チームの状況次第で求められることが変わるので、今はこの動きでいいんだけど、数カ月したらその動きは最適じゃなくなっている可能性もある。

つまり、今の時点でのモアベタ―をどんどん追求していく必要があるんですね。それはチームとしての動きもそうですけど、はてなの技術的な部分でも細部を含めてこだわり抜けるエンジニアであれば、SREとして一緒にプロダクトを良くしていくという観点でも一緒に働きたいなと思います。

来年も引き続きやっていきます。

アウトプット

今年は2つのイベントで登壇しました。

speakerdeck.com

speakerdeck.com

ブログは会社と個人のブログ合わせて4本書いていました。

developer.hatenastaff.com

taxintt.hatenablog.com

taxintt.hatenablog.com

taxintt.hatenablog.com

今年は個人の技術系のメモはCosense (旧: Scrapbox) 、プライベートの日記・メモはNotionに集約したのでPublicな場でのアウトプットは多くなかったかなと思います。

一方で、技術系のメモとして使っているCosense (旧: Scrapbox) では今年だけで110ページ程度書いていたので、それを幾分かPublicな場のアウトプットとして展開できればよかったなという反省点はあります。

記事にはできていないですが、ドキュメントツールとしてのCosense (旧: Scrapbox) のおかげで技術メモや物書きのハードルは下がったかなと思います。

taxintt.hatenablog.com

また、Scrapboxというドキュメントツールに出会ったことも一つ大きなイベントかなと思います。特に、技術検証のメモを書く際にはストレス無く内容をまとめられるので、Scrapboxの利用前後で文章を書く頻度は確実に増えました。

技術検証のメモなど小さめなアウトプットの頻度が増えて心理的なハードルが下がったことで、前提となるインプットやアウトカムにも目を向ける機会が増えたことも副次的な効果としてありました。

これまで、Evernote, HackMD, Notion, Obsidianなど色々なメモ用のアプリを使ってきましたが、少しづつ自分の中で納得できる使い分けやツールの活用方法が整理されつつあります。

年内登壇ではなかったのですが、CfPが通ったので、「監視SaaSの運用におけるObservability改善の歩み」というタイトルで来年の1月に SRE Kaigi2025 で喋ってきます。実はカンファレンスでの登壇は初めてなので今から大変緊張していますが、いい発表になるように最大限やっていきます。

2025.srekaigi.net

SRE NEXT

今年もカンファレンスの運営スタッフとして関わらせていただきました。Road To SRE NEXTという新しい取り組みもあり、その中で京都でのイベントの司会 + LTをさせていただきました。東京のイベントとはまた違った空気感の中で良いイベントができたと思います。

来年もRoad To SRE NEXTはありますので、2025年も引き続き関わっていきたいと思います。

blog.sre-next.dev

これが今話題の #〆のラーメンまである倶楽部 ですね。

私生活

今年は色々遊びにも行ったのですが、一番印象に残っているのは2月に行ったイタリア旅行でしょうか。(ベネチアしか行ってないけど)

ずっと写真撮ってましたね。合計300枚くらい写真撮ってました。

ご飯もお酒も美味しく、食べ物に関しては事前にレストランをリサーチしていたおかげも会って一切ハズレを引かなかったです。ベネチアで食べたイカスミパスタは今年食べたものの中でTop3に入るくらい美味しかった。

ベネチアとその周辺の島々を巡っただけでしたが、1週間の旅程で行けなかったエリアもあるので絶対に再訪します。

国内旅行も色々行きましたが、松島 一の坊が今年泊まったホテル・旅館の中でもトップクラスに良かったです。ここでこっそりおすすめしておきます。

www.ichinobo.com

最後に

2024年もお世話になりました。2025年もよろしくお願いします。

Cloud RunのアプリケーションからMackerelにOpenTelemetryのメトリック・トレースを送る

本記事は、Mackerel Advent Calendar 2024 10日目の記事です。

Mackerel開発チーム SREの id:taxintt と申します。

もうすぐ2024年が終わりますね。Mackerel 的にも様々なことがあった一年ですが、その中でも大きな話題としては OpenTelemetry 対応でしょうか。

OpenTelemetry 対応のメトリックについては、2023年9月からベータ版としての提供を始めたラベル付きメトリック機能が2024年11月から正式版としてリリースされました。

mackerel.io

mackerel.io

2024年8月末からは OpenTelemetry のトレースに対応した分散トレーシングサービスとして Vaxila(ヴァキシラ)が利用できるようになりましたね。

mackerel.io

OpenTelemetry の特徴の一つとして特定のベンダーやツールに依存することなく様々な Observability バックエンドと組み合わせて利用できるという点が挙げられています。

opentelemetry.io

Vendor- and tool-agnostic, meaning that it can be used with a broad variety of Observability backends, including open source tools like Jaeger and Prometheus, as well as commercial offerings.

ということで今回は、Google Cloud が提供するマネージド コンピューティング プラットフォームである Cloud Run から Mackerel に対して OpenTelemetry のメトリックとトレースを送ってみようと思います。 Google Cloud での Mackerel の利用事例はあまりインターネットで見ないなと思い、せっかくなので Cloud Run を選択してみました。

サンプルコードも用意したので、宜しければご自身の Google Cloud のプロジェクトでも試してみてください。

サンプルコードの構成について

github.com

アプリケーションは GET /hello のエンドポイントを提供する API server です。OpenTelemetryのメトリックとトレースを送信するための必要最小限のコードとなっています。

今回の記事で利用するサンプルの構成としては、OpenTelemetry のメトリックとトレースを計装したアプリケーションと Opentelemetry Collector を同一の Cloud Run のサービスとしてデプロイしています。

さて、ここからはサンプルコードの中身をみていきましょう。まずは、Opentelemetry Collector の設定ファイルの中身について説明します。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    send_batch_max_size: 200
    send_batch_size: 200
    timeout: 5s

  resourcedetection:
    detectors: [env, gcp]
    timeout: 2s
    override: false

  resource:
    attributes:
    - key: service.instance.id
      from_attribute: faas.id
      action: upsert
    - key: service.name
      value: ${env:K_SERVICE}
      action: insert

exporters:
  otlp/mackerel:
    endpoint: otlp.mackerelio.com:4317
    compression: gzip
    headers:
      Mackerel-Api-Key: ${env:MACKEREL_APIKEY}
  otlphttp/vaxila:
    endpoint: "https://otlp-vaxila.mackerelio.com"
    headers:
      Accept: "*/*"
      "Mackerel-Api-Key": ${env:MACKEREL_APIKEY}


extensions:
  health_check:

service:
  extensions: [health_check]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch, resourcedetection, resource]
      exporters: [otlp/mackerel]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/vaxila]

MackerelにOpenTelemetryのメトリックとトレースを送信する際にはテレメトリーデータの送信先は分ける必要があるので、アプリケーションから OpenTelemetry Collector にテレメトリーデータを送信し、Collector 側で送信先を分けています。

Cloud Run にはサービス側で自動的にセットされる環境変数のセットが存在するため、その中から実行されている Cloud Run サービスの名前である K_SERVICEservice.name のAttributeとしてセットしています。

cloud.google.com

また、resource detection processorを利用して、Google Cloudのmetadata serverからリソース情報を取得してAttributeとして付与するようにしています。

github.com

セットアップ ~ サンプルアプリケーションのデプロイまで

Mackerel (Vaxila) にテレメトリーデータを送信する際に利用されるAPI keyは環境変数としてセットする必要があります。 Secret Manager から API key (mackerel_apikey) を取得して Cloud Run の実行時の環境変数 (MACKEREL_APIKEY) としてセットするように事前に Secret を作成しておきましょう。

mackerel.io

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: ${SERVICE}
...
    spec:
      containers:
      ...
      - image: ${COLLECTOR_IMAGE}
        name: collector
        startupProbe:
          httpGet:
            path: /
            port: 13133
        env:
        - name: "MACKEREL_APIKEY"
          valueFrom:
            secretKeyRef:
              key: "latest"
              name: mackerel_apikey

Cloud Run のアプリケーションのデプロイ処理は全て GitHub Actions で実装されています。README.md に記載していますが、Cloud Run のアプリケーションをデプロイするために幾つか準備する必要があります。

まず、アプリケーションの Docker image を push する Artifact Registry を作成します。

cloud.google.com

次に、Workload Identity Federation を利用して GitHub Actions から Google Cloud へ認証を行うことができるように各種リソースを作成します。 GitHub Actions 側のワークフローファイル内の [GCP_PROJECT_ID], [WORKLOAD_IDENTITY_POOL_ID], [SERVICE_ACCOUNT_EMAIL] といった箇所は修正が必要なので、ご自身の環境を基に設定してください。

cloud.google.com

上記の変更を GitHub の Pull Request として merge すると問題なければ Cloud Run のアプリケーションがデプロイされているはずです。

❯ gcloud run services describe --region asia-northeast1  opentelemetry-mackerel-playgrounds
✔ Service otel-metrics-and-traces-playgrounds in region asia-northeast1
 
URL:     https://opentelemetry-mackerel-playgrounds-203216207119.asia-northeast1.run.app
Ingress: all
Traffic:
  100% LATEST (currently opentelemetry-mackerel-playgrounds-00001-flg)
 
Last updated on 2024-12-05T11:41:08.334760Z by [SERVICE_ACCOUNT_NAME]:
  Revision opentelemetry-mackerel-playgrounds-00001-flg
  Container app
    Image:           asia-northeast1-docker.pkg.dev/[GCP_PROJECT_ID]/opentelemetry-mackerel-playgrounds/app:1e4671022d99e65542b663aae063f4d7540c2ce0
    Port:            8080
    Memory:          512Mi
    CPU:             1000m
    Env vars:
      ENV_PORT       8080
    Startup Probe:
      TCP every 240s
      Port:          8080
      Initial delay: 0s
      Timeout:       240s
      Failure threshold: 1
      Type:          Default
    Container Dependencies: collector
  Container collector
    Image:           asia-northeast1-docker.pkg.dev/[GCP_PROJECT_ID]/opentelemetry-mackerel-playgrounds/collector:1e4671022d99e65542b663aae063f4d7540c2ce0
    Memory:          256Mi
    CPU:             1000m
    Secrets:
      MACKEREL_APIKEY mackerel_apikey:latest
    Startup Probe:
      HTTP every 10s
      Path:          /
      Initial delay: 0s
      Timeout:       1s
      Failure threshold: 3
  Service account:   203216207119-compute@developer.gserviceaccount.com
  Concurrency:       80
  Max Instances:     50
  Timeout:           300s

先述の通り、本記事のサンプルアプリケーションは GET /hello のエンドポイントを提供しているので、/helloAPIにアクセスしてみましょう。

SERVICE_URL=$(gcloud run services describe --region asia-northeast1  opentelemetry-mackerel-playgrounds --format=json | jq -r '.status.url')
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" $SERVICE_URL/hello
Hello, World!% 

サンプルアプリケーションが提供している API にアクセスできたので、Mackerel で送信されたラベル付きメトリックを確認してみましょう。

ラベル付きメトリックを確認する時にはメトリックエクスプローラーを利用することをお勧めします。メトリックエクスプローラーって何? という方はこちらの記事もどうぞ。

mackerel.io

次に Vaxila で送信されたトレースを見てみましょう。 サンプルコードのデフォルトの状態であればサービス名として sample-app を指定すれば送信されているトレースを確認できるはずです。

最後に

簡単ではありましたが、Cloud Run のサンプルアプリケーションを利用して OpenTelemetry のメトリック・トレースを送信し、Mackerel (Vaxila) 上でそれらを確認していきました。 このようなサンプルアプリケーションを利用して、テレメトリーデータを送信し、Mackerel の OpenTelemetry 対応機能に触れてもらえればと思います。

SRE NEXT2024に運営スタッフとして参加しました

08/04 (土) - 08/05 (日) の二日間でSRE NEXT 2024が開催されました。今年もコアスタッフとしてカンファレンス運営のお手伝いをさせていただきました。

sre-next.dev

SRE NEXTの運営スタッフとして参加するのは3年連続3回目です。

taxintt.hatenablog.com

taxintt.hatenablog.com

今回はRoad To SRE NEXTの運営チームとカンファレンス当日は配信管理のチームを担当していました。2023年のSRE NEXTでオフライン開催での運営に携わりましたが、今年も熱量を感じるカンファレンスでした。

オフラインイベントでの運営は今回が初めてだったので、会場でカンファレンスの熱量やお祭り感を実際に感じることができ、個人的に印象に残ったカンファレンスでした。

Track Bの配信管理を担当させていただきましたが、Track Bのスタッフの皆さんに本当に助けられたので、進行面では去年より余裕を持って進行できたかなと思います。

Co-chairの柘植さんもClosing Talkで触れていましたが、Ask The Speaker (ATS) のルームでのディスカッションの盛り上がりが個人的には印象に残っています。

技術カンファレンスに物理参加する理由の一つとして、廊下 (会場) での会話や議論が挙げられることがあります。

一方で、セッション後にスピーカーに話しかけることに心理的なハードルがある (私も尻込みすることがある) 人は一定数いると思うので、ルームという形でATSの場を用意できたのはよかったと思います。参加者的な観点で、カンファレンスの中でInteractivityを実現するという意味では、来年以降もATSの場があるといいなと思います。

Road To SRE NEXTの運営としては京都イベントの主催をしていました。京都では、マネーフォワードさんの素敵なオフィスをお借りしてセッション、LT、飛び込みLTという内容で期待以上の盛り上がりを見せることができました。現地参加いただいた参加者の皆様、何よりスポンサーのマネーフォワード様 そして luccafortさんありがとうございました!

sre-lounge.connpass.com

二次会の鴨川と〆のラーメン最高でしたね。本当に楽しかった。SRE NEXTの懇親会後も〆のラーメン食べてました。Twitter見たら、運営も他の参加者の方も〆でラーメン食べてる人が多くて笑ったのを覚えています。

SRE NEXTはCfP出したのですが落選してしまい、別のネタではありましたが飛び込みLTという形で喋ることができました。

speakerdeck.com

京都でのイベントでお会いした参加者の方とSRE NEXT本番の会場でお会いしたりと地方イベントとの繋がりを感じる機会もあり、こちらも次回以降も継続したいという気持ちがあります。

今は無事にイベントが終了したことに一安心しつつ、年々スピーカーとしてSRE NEXTに参加したいという気持ちが強くなっているので、次回は運営だけでなくスピーカーとしても参加できれば...!というのを考えています。

何はともあれ、2日間ご参加いただきありがとうございました!また来年もSRE NEXT2025でお会いしましょう!

語彙を獲得する、正しくないことに気づく、原典にあたる

近況として、理科系の作文技術を最近少しづつ読み進めています。

www.chuko.co.jp

 

mochikoさんの本など他の参考文献や資料も見ながら、時間をとってテクニカルライティングについての理解を深めています。

techbookfest.org

speakerdeck.com

テクニカルライティングのような文章・ドキュメントをわかりやすく書くための技術について時間をかけて学んだことはほとんどありませんでした。いわゆる「フィーリング」で文章を書いてきて、これではダメだと思う機会が何回かあったので改めて学習する時間をとっています。

 

これまで文章を書く中で、わかりやすくするための自分なりの工夫や意図が伝わり辛くなってしまった失敗パターンには「名前」がついていませんでした。代わりに、こういう書き方をすると伝わりやすいだろう、こういう文章構成だと伝わりづらいという経験則みたいなものがある状態でした。学習の中で、自分が何を目標としてその文章を書くのか,そこで何を主張しようとするのかを熟考し一つの文にまとめて書く「目標規定文」や情報整理の技術について知ると、ぼんやりとした理解・経験則が単語やその定義で明確になり、それを基に自分の理解・経験則が正しいのかを判断できるようになってきます。

 

単語やその定義を頭に入れることで、自分の理解・経験則が正しくないことに気づくことができるわけですが、この構図は様々な分野の学習において当てはまるなと実感しています。これを踏まえて、どうやって語彙を獲得していくかという話に発展するわけですが、原典にあたって語彙を獲得するのが最善なのだろうなと思います。適切に言葉の意味を理解した人が噛み砕いて書いた文章を読むという手もありますが、その文章が「言葉の意味を適切に理解した人が噛み砕いて書いた文章」なのかを見極めることができるかという問題もあるので。また、語彙を獲得するための原典をどのように選ぶかという問題もありますが、この解決策はまだ言語化できていません。

 

私は id:syu-m-5151 さんのブログのファンなのですが、ブログ記事の中身を構成する原典が辿れるようになっているところが最高だなと思っています。

syu-m-5151.hatenablog.com

 

オチはありません。読書する時間を取らないとですね。