Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OpenTelemetryの位置づけと高度なオブザーバビリティオペレーション
Search
sumiren
February 25, 2025
2
230
OpenTelemetryの位置づけと高度なオブザーバビリティオペレーション
https://offers-jp.connpass.com/event/342445/
sumiren
February 25, 2025
Tweet
Share
More Decks by sumiren
See All by sumiren
HoneycombとOpenTelemetryでオブザーバビリティに入門してみる
sumiren
2
2k
フロントエンドパフォーマンスの変遷とNext.jsに見る次の時代
sumiren
25
9.1k
クラウドへのOpenTelemetry導入のハマりどころ
sumiren
0
220
React ViteからNext.jsへ切り替えたプロセスとApp Router化のボトルネック | 株式会社ヘンリー
sumiren
3
3.5k
ローコード自動テストを1ヶ月半で導入した話
sumiren
0
780
スタートアップでのmabl導入事例とリーディングテクニック
sumiren
0
290
Next.js 13 Layout / Streaming SSR 仕組み解説
sumiren
3
1.8k
Featured
See All Featured
Speed Design
sergeychernyshev
27
800
Agile that works and the tools we love
rasmusluckow
328
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
Facilitating Awesome Meetings
lara
52
6.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Making Projects Easy
brettharned
116
6k
Optimizing for Happiness
mojombo
376
70k
It's Worth the Effort
3n
184
28k
BBQ
matthewcrist
87
9.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
The Invisible Side of Design
smashingmag
299
50k
Transcript
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
[email protected]
https://x.com/sumiren_t