OpenTelemetryの位置づけと 高度なオブザーバビリティオペレーション 2025/02/25 sumiren

自己紹介 @sumiren_t ● 社外CTO / 技術顧問 4社様〜 ● 株式会社Reminus（3月登記予定） CEO ● 株式会社ヘンリー SRE

オブザーバビリティに関する実績 ● 事例①：ECサービスにおいてパフォーマンス低下による機会損失の事業課題に対してパ フォーマンス改善ロードマップを策定。また短期では既存ツールを活かして計装を改善し、 N+1の特定とGraphQLオペレーション単位のメトリクスによるトレンド可視化を実現 ● 事例②：アパレル系サービスのWebバックエンドにオブザーバビリティを導入。アウトバウンド リクエスト集計でボトルネック特定を実現し、コスト削減に貢献 ● 事例③：医療会計システムにおいてオブザーバビリティに責任を持ちOpenTelemetryを導 入・運用。10MB以上のレスポンスを行うエンドポイントの発見やトラブルシュートの民主化な ど、開発生産性に貢献

オブザーバビリティにおける OpenTelemetryの位置づけ

オブザーバビリティとはシステムで なにが起きてるか明快にわかる度合い インフラ アプリケーション DB システム ログ メトリクス トレース オブザーバビリティ バックエンド モニタリング

オブザーバビリティは便宜上、対象システム、　テレ メトリの仕様と収集、オブザーバビリティバックエン ドの3つから成ると言える インフラ アプリケーション DB システム ログ メトリクス トレース オブザーバビリティ バックエンド モニタリング 1.対象システム 2.テレメトリの仕様と収集 3. o11yバックエンド

OpenTelemetryはテレメトリの仕様と収集のみ を担当し、テレメトリの利活用には関与しない インフラ アプリケーション DB システム ログ メトリクス トレース オブザーバビリティ バックエンド モニタリング 2.テレメトリの仕様と収集 = 　OpenTelemetryのスコープ

OpenTelemetryのほうが オブザーバビリティが高い などということはない

直接的にオブザーバビリティに寄与するのは オブザーバビリティバックエンドの利活用と選定 インフラ アプリケーション DB システム ログ メトリクス トレース オブザーバビリティ バックエンド モニタリング ツールの利活用と選定が 今日のオブザーバビリティを決める

OpenTelemetryで オブザーバビリティの 開発生産性が高まる 将来のオブザーバビリティが高まる

日々のオブザーバビリティの計装や改善が行いやす く、長期でオブザーバビリティ向上が見込めるのが OpenTelemetryの強み インフラ アプリケーション DB システム ログ メトリクス トレース オブザーバビリティ バックエンド モニタリング 2.テレメトリの仕様と収集 OSS・標準であるため 事例やAIの力が借りやすく 柔軟なカスタマイズも可 複数バックエンドへのシグナル 振り分けや並行運用、移行が容 易に可能。切り戻し可能なため 意思決定速度を向上

高度な オブザーバビリティ オペレーションパターン

OpenTelemeteryを採用して オブザーバビリティを磨いても 利活用しなければ全くの無意味

テレメトリには主に3つのシグナルがあり、これらを活用 していく。シグナル間連携などが一般にはよく謳われる インフラ アプリケーション DB システム ログ メトリクス トレース オブザーバビリティ バックエンド モニタリング リクエストのIDや時間帯で紐 づけ連携させて利用する

sumirenの思想： シグナルの連携以上に、トレースに無限の可能性がある。ト レースに特化してレベル別に5つオペレーションを紹介 インフラ アプリケーション DB システム ログ メトリクス オブザーバビリティ バックエンド モニタリング とにかくトレースを使い倒し てほしい！ ※OpenTelemetryや特定ツールに限った話ではなくオブザーバビリティ一般について議論します トレース

レベル1：パフォーマンスを観測する https://play.honeycomb.io/sandbox/environments/ analyze-debug-tour/result/dMLPJTBMtBz/trace/G Tx1i14vRxR?fields[]=s_name&fields[]=s_serviceN ame&span=8c5ccae7fad3dcd9 いわゆるAPM的な活用。N+1やス ロークエリ、予想に反して長い処理な どをツリーから見つけられる 全体がトレース トレースを構成するノードがスパン

レベル2：振る舞いを観測する https://play.honeycomb.io/sandbox/environments/ analyze-debug-tour/result/dMLPJTBMtBz/trace/G Tx1i14vRxR?fields[]=s_name&fields[]=s_serviceN ame&span=8d028656dbb20c02 スパンの属性には膨大な情報がある。 エラーとなったリクエストが入った分岐や処 理の詳細を把握するなど、パフォーマンス以 上に振る舞いのトラブルシュートに活用でき る点が重要 ツリーについても、障害などで全体像を ざっと把握したり、エラー時と通常時の処 理の差分確認など振る舞いに関する活用 が可能

レベル3：機能横断的に手動計装して観測を強化する https://play.honeycomb.io/sandbox/environments/ analyze-debug-tour/result/dMLPJTBMtBz/trace/G Tx1i14vRxR?fields[]=s_name&fields[]=s_serviceN ame&span=8c5ccae7fad3dcd9 機能横断的な情報を自前でスパン属性に詰めるこ とで、振る舞いパフォーマンス両方のトラブル シュートに役立つ。以下事例 ・ユーザーIDやテナントID ・ユーザーの権限やフィーチャーフラグ ・フロントやサービスのバージョン ・req/resサイズ ・機微情報をマスキングしたリクエストボディ ・エラー時のレスポンスボディ ・etc…

手動計装では目的がなければスパンを切り直す必要な し。現在のスパンに属性をどんどん付け足していい

レベル4： ドメインロジックを手動計装して観測を”超”強化する 重たいバグはドメインロジックに起因。個別機能の ドメインロジックを計装すればするほど、一撃でト ラブルシュートできる。例えばこの例なら「エラー 時にカート合計金額が高いか」などを知れる リクエストボディやDBから取得したデータ、セッ ションの状態、中間データの状態や分岐のどこに 入ったかなど、どんどん記録する ログよりスパンに記録したほうが得！ https://play.honeycomb.io/sandbox/environments/analyze-de bug-tour/result/dMLPJTBMtBz/trace/GTx1i14vRxR?fields[]=s _name&fields[]=s_serviceName&span=8c5ccae7fad3dcd9

おさらい：ここまでトレースでリクエストをブレークダウン して観測してきた。一方、システム全体の視座では、依然 としてボトムアップ的アプローチである システム ＝リクエスト 結局重たいバグはドメインロジックに起因。 個別機能のドメインロジックを計装すればするほど、一撃でトラブルシュートでき る。例えばこの例なら「エラー時はカート内商品が多い」などを知れる リクエストボディや DBから取得したデータ、セッションの状態、中間データの状態や 分岐のどこに入ったかなど、どんどん記録する。書き込み系のエンドポイント、デー タはフラグや列挙値が最優先 ログを吐くくらいならスパンの属性に記録したほうが得 ● システム全体レベルでは、依然として森ではなく木を見ている状態 ● 「cart_totalが162だから3000msかかってる」を検証するにはトレースを順番に見ていく しかない

スパンをDWHに見立てれば、 システム全体レベルで ブレークダウンできるのでは？

レベル5： トレースをDWHとして扱いシステム全体の傾向を分析する システム全体 ＝リクエスト WHERE route = /cart/checkout GROUP BY cart_total 問題 なし 問題 あり 問題 なし … ● 「合計金額と応答時間に相関性はない」と仮説が検証できる ● 全体の傾向を調べることで仮説を立てることにも使える ● 事前定義不要、探索的でオープンエンドな調査

宣伝

株式会社Reminus オブザーバビリティ支援含む技術支援会社を 立ち上げました ● 「洗練されたSaaSエンジニアリングを事業に実装 する」という共通項で、横断的な技術領域の支援を スタートアップ様に提供 ● オブザーバビリティやフロントアーキなど領域特化 の支援から、社外CTOやVPなど経営・マネジメン ト・何でも屋的な支援まで、幅広いスタートアップ様 を想定 提供サービス お問い合わせ https://reminus.co.jp#contact sumiren@reminus.co.jp https://x.com/sumiren_t