【参加レポ 🔭】Observability Conference Tokyo 2025

primeNumber という会社で SRE をやっている @z63d_ です。
Observability Conference Tokyo 2025 に参加してきました。
個人的に面白かったセッションを3つ紹介します。

セッション

オブザーバビリティが育む開発者のシステム理解と好奇心

https://speakerdeck.com/maruloop/observability-for-the-system-understanding-and-curious-by-developers

LINEヤフー maru さんによるセッション

O11y ツールの日常的な利用

LINE のシステムでは O11y 周りを一通り整備しているそうですが、使うのはリリース時や問題発生時だけで日常的には使われていなかったそうです。O11y ツールは DevOps の中の主に Ops サイクルで拡充されるので、Dev サイクルを担う開発者はシステム理解が進まず、馴染みのないものとなってしまい利用されなくなるという課題があったためだとお話しされていました（たしかに）。そこで O11y ツールを Dev サイクルでカジュアルに使ってもらえるように preview 環境や負荷試験を整備したそうです。開発環境での O11y ツール整備が日常的な利用につながるという観点では考えたことがなかったので、良い気づきになりました。
ちなみに Observability文化はなぜ根付かないのか 〜よくある失敗とその回避策〜 こちらのセッションでも似たことが話されていました。

監視対象ではなく目的に基づくダッシュボード

続いて、Ops サイクルでの観測の日常化に関する話です。監視対象に基づくダッシュボードは問題発生時に仮説を持ってダッシュボードを見ないと問題を発見しづらいという課題があったそうです。そこでオペレーションに紐づくダッシュボードを整備したそうです（紹介されていたのはリリース時に見るもの）。
弊社では SRE チームの朝会の時に毎日ダッシュボードを確認しており日常的に見てはいますが、オペレーション時に見るダッシュボードは参考にしたいと思いました。リリースダッシュボードがあれば変化や異常などに迅速に気付けそうです。開発者もリリース時にダッシュボード見てくれればチーム全体の観測の日常化を図れそうです。

ユーザー体験に近いメトリクス収集

この取り組みではユーザーのキャッシュ利用状況を収集したことで、ユーザーが非常に高いキャッシュヒット率を持っていることが分かったそうです。ユーザー体験に近いメトリクス収集により、正常とは何かをについて考えることができたとおっしゃっていました（エラーが起きていてもユーザーがキャッシュを用いてサービスを利用できていれば正常では？など）。

現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ

https://speakerdeck.com/aoto/beyond-the-field-barriers-instrumentation-injection-and-the-future-of-observability

Datadog 木村さんによるセッション

計装注入

オブザーバビリティを導入するにあたるアプローチ「計装注入」についてのセッションです。手動計装・自動計装はよく聞く言葉なのですが、これに加えて計装注入というものをこのセッションでは定義していました。それぞれのアプローチの違いは以下です

• 手動計装
  • アプリケーションコードへの変更を行い SDK の実装を施す手法
• 自動計装
  • アプリケーションコードへの変更を行わずに言語特有の機能で SDK の実装を施す手法
• 計装注入
  • コンテナ・プロセスの機能を利用して言語を意識することなく計装する手法

実現方法

• OpenTelemetry Operator
  • 各言語の自動計装を担う
  • Admission Controller の Mutating Admission Webhook を利用して動的に Pod に変更（init container の追加など）を加える
• OpenTelemetry Injector
  • 自動計装を動的に読み込む Linux ライブラリ
  • 元々 C言語の実装だったそうですが、libc への依存への課題などを理由に Zig言語のものに置き換わったそうです。

計装注入は機能や言語など様々な制限があるとのことでしたが、技術的にはとても面白そうでした。OpenTelemetry Injector の仕組みはかなり低レイヤの話が出てきて、その場では理解しきれなかったので、今度手元で動かしつつゆっくり見てみたいなという気持ちです。
LD_PRELOAD という仕組みを利用しているそうですが、調べると "trick" というワードが結構出てくるので、どのような仕組みかますます気になります。

ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化する ABEMA におけるトレースサンプリングの実践的事例

AbemaTV 山本さん、Datadog 逆井さんによるセッション
スライドが見当たらなかったので配信中の映像を引用させていただきます。
スライド公開してくださったようです↓

https://speakerdeck.com/tetsuya28/abema-trace-sampling-observability-cost-optimization-f4d43a88-8257-4bc1-be03-5c9b2333c8da

トレースサンプリング

このあたりはなんか聞いたことあるな程度だったのですが、トレースサンプリングには２種類あるそうです。

• ヘッドベースサンプリング
  • トレース全体を検査しない、早い段階で行われる手法
  • 主に確率サンプリングが用いられる（○○%だけサンプリング）
  • ランダムなサンプリングなので必要なトレースもドロップしてしまう
• テイルベースサンプリング
  • トレース内のスパンを元にサンプリングする（エラーを含むもの、特定のタグ属性を持つもの）
  • システムやアプリの変更に追従する必要があり、導入難易度が高い

Datadog の機能

Datadog ではこの2つのサンプリング手法に対す機能が備わっており、これらを活用してデータ保存量の最適化が可能ということです。

• ヘッドベースサンプリング
  • エンドポイントごとにサンプリングレートを設定可能
• テイルベースサンプリング
  • トレース保存の条件を設定すると、Datadog 側でよしなに保存・ドロップをしてくれる

コストとオブザーバビリティのバランスについて

Abema では大量のトレースデータが生成されるため、全てを保存することはコストを考えると非現実的ということでした。トレースデータを全て保存するのは非現実でデータも全て見る必要がないため、必要なデータだけ残してコストも抑えることが必要になってくるというお話しでした。

トレースサンプリング手法

まずはトレースデータを分類（リクエストの種類・失敗が許容されるか など）してサンプリング対象を選定していました。そして、不要なデータのドロップについては前半の逆井さんのパートで説明されていたヘッドベースサンプリング・テイルベースサンプリングを使い分けて行っていました。

システム構成は以下のような感じ↓

アプリ（トレースライブラリ） -> Datadog Agent -> Otel Collector -> バックエンド（Datadog）

• Datadog に送信する前
  • Datadog では取り込みデータ量に応じて課金されるので、その前にドロップする必要がある
  • OpenTelemetry Collector のレイヤでサンプリングルールを設定している
• Datadog に送信した後
  • 不要なデータはドロップしているのでデータを残すことに専念
  • 異常系は全て残して、正常系も一部残す
  • Datadog の機能を使っている

これらの最適化の仕組みによって Span Ingested という指標が 10% 以下になったそうです。

弊社では New Relic を利用しており、ちょうどこの前データ取り込み量に関するお話しを New Relic の担当者の方としたところだったのでタイムリーな話題でした。まずはどういったデータが取り込まれているかといった現状把握から行う必要があるのですが、このセッションは今後とても参考になりそうです。

写真

お話ししてくださった方々ありがとうございました！

https://x.com/z63d_/status/1982631104847937718

https://x.com/yoshifin/status/1982722305991315851