【参加レポ】Ovserbavility Conference Tokyo 2025
はじめに
エンジニアの方もエンジニアではない方も、こんにちは。金融業界で SRE としてGoogle CloudのプロジェクトにJoinしているエンジニア (@teratech__)です。
Observability Conference Tokyo 2025に参加しました。
(遅れましたが)自身の備忘も兼ねて聴講したセッションをいくつか紹介します。
なお、内容の中にワタシ自身の考えも含まれており、発表者の方の意図とは異なる場合があるのでご注意ください。(違うぞ！という意見も募集しておりますので、是非コメントください！)
セッション一覧
- 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ
- 現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ
- ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化するABEMAにおけるトレースサンプリングの実践的事例
- オブザーバビリティ成熟度モデルの企画から社内導入まで：複数サービスでの評価を通じた組織変革の軌跡
可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ
セッション概要 (公式ページより)
「本番環境のオブザーバビリティは大事」。誰もがそう言います。でも、日々の開発で「なんでこれ動かないんだ…」と途方に暮れた経験はありませんか？私たちは、開発環境こそオブザーバビリティ導入の第一歩だと信じ、私の所属するLayerXのAI・LLM事業部でその実践に挑んできました。
本セッションでは、オブザーバビリティがなかったことで起きた苦労したことや、そしてそれを乗り越えるために開発環境にオブザーバビリティを導入したことで、いかに開発が楽になったかをお伝えします。さらに、その小さな改善が最終的にサービスの品質向上にどう繋がったのか、具体的な事例を交えてお話しします。
開発の契機と目的感
状況としてはADR / Design Docは作成されていたが、実行されていなかった。
なぜ？→ 他の優先タスクがあった。
契機は機能追加とアーキテクチャの大刷新。
→ 開発上の問題を解決することの優先度が上がったから。
→ やっぱ目に見える課題があって、解決するとどの程度、開発に寄与できるかを明示する必要はどこにでもありそう。
発表者の方も言っていたが、O11yが必ずしも解決策になるということはなく、今回は課題を解決する最善策がO11yであった。
→ O11yを導入することが目的になっていると良くない。O11yは手段であって、目的ではないことを念頭に置く必要はある。
開発環境のオブザーバビリティ環境を整備することの意義
「開発環境のオブザーバビリティで優先するならトレース」これはとても同感。
自分は開発していなくて、トラブルシューティングの協力を依頼されたときにとても思った。
何なら、トレースが見れている場合はトラブルシューティングの依頼すらする必要もなく、開発者のみで解決できそう。
開発ライフサイクルでのオブザーバビリティ環境
オブザーバビリティ駆動開発 ( What Observability-Driven Development Is Not ) という概念はとても興味深かった。
追加開発時にスパンを一緒に作成するフローにしていれば、スパンの新規追加忘れもなくなり、開発速度も向上しつつ、信頼性向上にも繋がる (コストとのトレードオフではあるが、必要コストとして見なせる)
「上記の情報を個人の環境だけで見れる状態にせずチームメンバー全体で見れることによって情報共有コストの低減も期待できる」これは絶対にそうで、トラシューの際に一番重要な情報は、「現在どんな状況で何ができてて何ができていないか」であると思っている。
トレースを共有することで、この情報を一発 (一発ではなくともかなり解像度の高い状態) で共有することができる。
リモートでのトラシューあるあるだが、画面を見せて一緒にトラシューをすることが多いが、これはかなり参加者全員の時間を費やすものでもあるので、これをかなり削減できるのは良さそう。
感想
- O11yと言うと、「監視関連の話でしょ」となりがちだが、本セクションでは開発生産性みたいな切り口でのO11yだったのでとても新鮮で興味深かった。
- 開発環境にトレースを導入することで開発生産性が向上するのはとても同意する一方、コストとのトレードオフになるので、これの価値をビジネス側にどうやって説明するかを考える必要はありそうだなと感じた。
- と書いていたが、回答はこれに尽きる気がする。
発表スライドより抜粋 - 総じてトレース関連は理解が難しい、ので開発者向けにドキュメントを整備することは必須になりそう。
現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ
セッション概要 (公式ページより)
現代の複雑なシステム環境において、オブザーバビリティは信頼性を高める重要な要素として位置付けられています。しかし現場では、アプリケーションの計測導入に伴うコード改修や環境依存性が大きな障壁となり、アプリケーションに対するオブザーバビリティの獲得を困難にしてきました。様々な経緯を経て稼働するシステム環境へオブザーバビリティを導入するには、従来とは異なるアプローチが必要です。
本セッションでは、この課題を解決する一助となる「計装注入（Instrumentation Injection）」を取り上げます。「計装注入」の主要なアプローチを、OpenTelemetry Operator, OpenTelemetry Injector の仕組みを通して解説し、アプリケーションコードの改修を伴わずに自動計測を実現する原理を明らかにします。さらに、従来の手法との比較から見える導入上の利点と制約を整理し、実環境での適用性とユースケースを検討します。
オブザーバビリティは分散システムだけのものなのか？
発表スライドより抜粋
- スライドの通り、分散システムだろうが、レガシーシステムだろうがオブザーバビリティは監視手法としてとても有効であり、オブザーバビリティは分散システムだけのものではない。
- 一方でオブザーバビリティを導入するステップや大変さは全然異なる。(後述される)
- 共通する壁は以下。
- 「複数の環境を同時に」「コードの変更を伴わず」言語による設定の違いを意識せずに広く設定を適用したい。
- → 「計装注入」というアプローチ。
- 共通する壁は以下。
- 塩漬けされたレガシーシステムなどは前セクションみたいに、システムの処理内容を可視化するだけでもとても有効と言えそう。
「計装注入」と「自動計装」
- 「自動計装」
- テレメトリーシグナルを取得するために、アプリケーションコードに変更を加えず、言語特有の機能で関数をラップして、SDKの実装を施す計装方式。
- アプリケーションコード自体に変更は加えることはないが、アプリケーションコード上での実装は必要になる。
- Datadog Tracerとかのトレーサーはセットアップ手順を見るとたしかに、アプリケーションコードとは言わないがDocerfileやJavaの起動オプションに何かしらの追加が必要ではある。Datadog Javaアプリケーションのトレース
- そして、この自動計装は言語ごとに計装方法は異なる。(Golangはこれ Datadog Tracing Go Application
- 「計装注入」
- 言語ごとに異なる自動計装の仕組みを自動的に注入するために、コンテナ・プロセス単位でシステム機能を利用する計装方式。
- コンテナ・プロセス単位に実装すればOKなので、中身のアプリケーションコードは気にせず計装できる。
- インフラ側設定を導入するだけで、自動的に計装が完了する仕組みになっている。\
OpenTelemetryを利用した「計装注入」
「計装注入」は分散システムはもちろん、レガシーシステムにも有用な手段となっている。
- OpenTelemetry Operator
- OTel のKubernetes Operator 実装
- Operatorが自動計装ツールをPodに組み込む設定を入れることで、各言語の自動計装が実現できる。
- SideCarとしてPodに導入することができ、SideCarが自動でスパン情報をOTel Collectorに送信する。
- 計装・転送を自動ですべてやってくれる。
- OpenTelemetry Injector
- OTelのLinux共有ライブラリ実装
- プロセス起動時の動的リンカーで共有ライブラリをプリロードして、各言語の自動計装が実現できる。
「計装注入」は銀の弾丸となるのか？
感想
- より簡単にトレースを計装できるようになり、「とりあえず導入してみる」というアプローチがより選択できるようになった。
- 一方、計装注入後にカスタマイズしたくなった際に、「計装注入」と「主導計装」を併用できたりするのかは未知数であると感じた。
- 運用の話をすると、K8sの計装注入は新たにOperatorを浮かべるので、障害点を増やすことにもなるし、運用コストも増えるっちゃ増える。
- ので、ここのトレードオフではありそう。
ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化するABEMAにおけるトレースサンプリングの実践的事例
セッション概要 (公式ページより)
多くのマイクロサービスで構成され、膨大なトラフィックを高速化つ安定的に処理する動画配信サービス ABEMA において、オブザーバビリティや分散トレースは必要不可欠です。
一方で、オブザーバビリティにおいて課題となるのはコストです。テレメトリーのデータ量は、ツールを長く効率化に使う上で考慮すべきコストの一つであり、保存すべきトレースの取捨選択が必要になります。関心のあるトレースは実は全てではないことが多く、エラーリクエストや高レイテンシーのものとなる傾向にあります。そこで必要なのがトレースサンプリング戦略です。
本セッションでは、ピーク時165万スパン/秒を超えるABEMAにおけるトレースサンプリングの実践的事例を紹介します。OpenTelemetryとDatadogを用いた分散トレース基盤の上で、OTel Collectorを用いたテールサンプリングや、DatadogのリテンションフィルターやアダプティブサンプリングといったSaaSならではの機能を駆使し、どのように価値あるシグナルを残しつつ、オブザバビリティーコストを最適化しているのか、その具体的な設計や工夫に迫ります。
トレースのデータ量とコスト
トレースにおけるデータ量はコストとなる (当たり前だが)。そのため、不要なトレースは保存しないほうが得策となる。
確かに以下のようなトレースは不要になっている可能性が高い。
- 大量の平凡なリクエスト
- 大量のBotによるリクエスト
- 大量のヘルスチェックリクエスト
Datadogでもトレースの保持ポリシーについて、ベストプラクティスが書かれているドキュメントがある。
Datadog Datadogの保持ポリシーを理解し、トレースデータを効率的に保持する(発表内スライドで紹介)
発表内スライドから抜粋
分散システムの場合1リクエストで複数のサービスを経由することが多いためリクエスト数 ≠ スパン数ではある。
リクエスト数が多い → もちろんスパン数も多くなる → データ量も増加する → コストが増加する。
そのため、トレースデータの取捨選択 (トレースサンプリング戦略) が重要になる。
トレースパイプラインの概念は覚えておきたい。
発表内スライドから抜粋
*その他のDatadogにおけるトレースサンプリング機能は発表スライドで紹介されています。
オブザーバビリティと損益分岐点
WAUを見ると、年々ユーザー数は増加していき、システム内のサービスも増加している。
以下のスライドを見ると、年々サービスが増加していきシステムが複雑化し、全体を把握するのはもちろん、個別具体な処理の流れですら把握し理解するのにとても時間がかかりそう。
発表内スライドから抜粋
アプリケーションの複雑性が増していく中で、各シグナル (ログ・メトリクス・トレース) の紐づけや情報集約をすることで、障害対応への障壁を低くしたい。
ということで、Datadogを導入した。
ただ、DatadogはもちろんSaaSであるので従量課金制である。
スパン量が莫大な量になるため、このままだとコスト的に破綻する。
「トレースデータは全部見る必要はない (し現実的に見ることはできない)」これは非常に同感した。
これを念頭に置いて、トレースコストを向き合う必要がある。
ただ、そもそも開発者がコスト意識を持っていないと、向き合うことすらしないので、前提となるコスト意識をもたせることがとても重要で最も難しい。
(特に自社開発ではない場合やプロジェクト全体のコスト構造が歪だと、なおのこを難しい。)
「オブザーバビリティ」にも損益分岐点がある、ということに気付かされた。
コストをかければオブザーバビリティが向上はしていくが、ある一定の分岐点を超えるとコストを費やしても、オブザーバビリティは向上しなくなる。
だから、「良い感じに必要なデータだけを、安く見たい」のだと。
ABEMA TVにおけるトレースサンプリング戦略
計装において、共通ライブラリをSRE + Backendでメンテナンスしているのも良い。SREっぽくて憧れる。
感想
- もちろん、データ量を削減することは良いことではあるが、障害対応ができなくなってしまうのでは元も子もない。
- 「障害対応できるデータ量」と「コスト」を天秤にかけるためには、基準を設けビジネス側と合意する必要がありそう。
- 一方、SLI/SLO計測のためには、平凡なリクエストは必要になってしまいそうなので、ビジネス側との合意を取るのは慎重にいきたさもある。
- ABEMA TVでは、テイルベースサンプリングをOpenTelemetry Collectorで実装しているので、このコンポーネントのリソース状況は気になる。
- あまりにリクエスト量が多い、機能についてはヘッドベースサンプリングを考えるのもありか。
オブザーバビリティ成熟度モデルの企画から社内導入まで：複数サービスでの評価を通じた組織変革の軌跡
セッション概要 (公式ページより)
SRE部主導で独自のオブザーバビリティ成熟度モデルを企画・策定し、複数サービスにわたる実際の評価・改善を推進した取り組みを紹介します。書籍『オブザーバビリティ・エンジニアリング』とCMMIを基に6つの評価項目（データ収集と可視化、システムの信頼性管理、開発・運用プロセスの整備と最適化、アラート最適化と障害対応、ユーザー行動の理解と最適化、継続的な改善と最適化）を定義し、5段階の成熟度レベルで組織全体を評価しました。アンケート形式での現状把握から、レベル別改善アクションプランの策定まで、実践的なフレームワークを構築しました。理論と実践を結びつけた組織的なオブザーバビリティ向上の取り組みと、その実践から得た知見をお話しし、明日から実践できる第一歩を提供します。
感想
- レベル定義が細かく設定されているため、より実態に即したレベルを定義できるのはとても良いと思った。
- 改善ポイントについても具体化されていたので、各チームが改善方法に困ることはなさそう。
- この改善ポイントを提示できるまで、当該チームの内部をどこまで理解しているのか知りたい。
- 自プロジェクトでも成熟度チェックを実施しているが、改善ポイントをより具体的に提示するにはチームを深く理解する必要があると痛感している。
- レポート作成、データ分析など、成熟度をチェックすることが目的とならずに、チェック後にどういった世界を目指すのかを適切に考えていて素晴らしいと思った。
- 実施して終了ではなく、継続して実施できる施策を。
- 継続するためには施策の価値を証明し続ける必要があり、価値の証明にはレポート作成やデータ分析は必要な作業。
- 本当に全チームがすべての項目においてレベル5を目指すべきなのか？
- チームによっては「このレベルで十分だね」となる項目もあったりすると思うので、グラーデーション的に目標レベルを設定するとSREも開発チームもWin-Winになりそう。
- 最終的に成熟度チェックを実施し、改善をし、開発チームが幸せになれることが最も重要ではある。(自戒の意味でSREの自己満足にならないように気をつけねば、という思い)
Conference全体の感想
- いろいろな方のお話を聞けてとても楽しく、学びになりました。
- 今回、本記事で掲載しているセッション以外も聴講させていただきました。
- お話してくださった方々ありがとうございました！
- もちろん、運営してくださった方々もありがとうございました！
- 自プロジェクトと比較しながら聞けたので、この内容を自プロジェクトに還元したい。
- ランチで出た弁当が笠原さんの「賛否両論」の弁当でうますぎた。
- ノンストップの時にしょっちゅう料理コーナー見てたので感涙。
「賛否両論」の弁当
- ノンストップの時にしょっちゅう料理コーナー見てたので感涙。
Discussion