Observability Technology Selection Tips

オブザーバビリティ　技術選定の勘所

2025/2/25にconnpass上で開催された「OpenTelemetryって本当に必要？今エンジニアが知っておくべきオブザーバビリティとは」の登壇資料です

https://offers-jp.connpass.com/event/342445/

Transcript

1. オブザーバビリティ 技術選定の勘所 2025.02.25 Tur. OpenTelemetryって本当に必要？今エンジニアが知っておくべきオブザーバビリティとは@Offers_DeepDive | Connpass @ymtdzzz
2. Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア • 仕事ではRubyを書いています（その前はGolangを3年程） • プライベートではOpenTelemetryにコントリビュートしたり 関連ツールを作ったりしています • OpenTelemetryに関連した登壇など ◦ OpenTelemetryでRailsのパフォーマンス分析を始めてみよう Kaigi on Rails 2024 ◦ OpenTelemetryとSaaSの“良いとこ取り”で構築する柔軟なオブ ザーバビリティ基盤 OpenTelemetry Meetup 2024-11 2
3. otel-tui（宣伝） 3 • OpenTelemetry計装のローカル開発向けツール https://github.com/ymtdzzz/otel-tui
4. 今日お話すること 4 • オブザーバビリティとは • オブザーバビリティを取り巻く環境（令和最新版） • 技術選定のポイント
5. • 現在の所属会社SmartHRはNewRelicの独自計装を 用いてオブザーバビリティ環境を構築しています （OpenTelemetryではない） • OpenTelemetryをプロダクションで使っていた前職 （〜2024/06頃）での経験をベースに、最新事情を盛 り込んでお話します 注意点 5
6. オブザーバビリティとは
7. オブザーバビリティの定義 7 オブザーバビリティ（可観測性）とは、出力を調べることでシステムの内部状態を測定する能力 です。出力、つまり計測データのみを用いて現在の状態を推定できる場合、システムは「オブ ザーバブル（観測可能）」だと見なされます。 What is Observability? An Introduction | Splunk （スライド作成者が翻訳）
8. オブザーバビリティの定義 8 オブザーバビリティ（可観測性）とは、出力を調べることでシステムの内部状態を測定する能力 です。出力、つまり計測データのみを用いて現在の状態を推定できる場合、システムは「オブ ザーバブル（観測可能）」だと見なされます。 What is Observability? An Introduction | Splunk （スライド作成者が翻訳） • 計測データ（テレメトリー） ◦ ログ ◦ メトリクス ◦ トレース パフォーマンス劣化のボトルネックは？ 500エラーの原因は？ アプリエラーはエンドユーザーにはどう見 えている？ コード
9. モニタリングとの違い：不確実性の高い問題に対するアプローチ • 背景：複雑化するアーキテクチャ ◦ マネージドサービスへの依存（AWS S3, SES, etc.） ◦ マイクロサービスアーキテクチャ ◦ サーバーレスデプロイ →（問題の）不確実性の増大 9 アプリ起因かも 外部サービス側の問題でしょ ネットワークが不安定になっ ただけ？
10. • システムのコンテキストや経験中心の調査からテレメト リー（事実）中心の調査へ モニタリングとの違い：不確実性の高い問題に対するアプローチ 10 分散化したログの調査 コードの調査 ローカルでの再現確認 モニタリング テレメトリーによる分析 ・遅延箇所の特定（トレース） ・コードレベルのエラー箇所特 定（ログ）　など オブザーバビリティ • トライアンドエラーが分析ツール上で完結 • 経験への依存度低下 • 経験豊富なエンジニアへの依存 • 高コストなトライアンドエラー →調査コストの増大
11. オブザーバビリティを支えるトレース 11 • オブザーバビリティの根幹は「テレメトリーの関連付け」 メトリクス トレース ログ （UI上で）自由に行き来できる メトリクスから代表的 なトレースを知りたい エラーログからユー ザー影響を知りたい
12. オブザーバビリティを支えるトレース 12 • トレースIDで関連付ける メトリクス トレース ログ （UI上で）自由に行き来できる TraceID TraceID TraceID トレースのイメージ
13. 計装の手段 13 • 計装：テレメトリーをシステムから出力できるように実装すること • SDKによる実装やコンポーネントのデプロイが必要になる
14. 計装の手段 14 • テレメトリーのデータフォーマットは様々なので、それぞ れが提供するSDKや計装ライブラリを利用する SDKを用いたテレメトリーの送信 （計装）
15. 選び方については後半で
16. オブザーバビリティを取り巻く環境 （令和最新版）
17. 乱立する仕様（プロトコル） ※トレース関連のみ抜粋 Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年 に合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 17 Kaigi on Rails 2024 登壇資料より
18. これまで：オブザーバビリティ、買うか作るか？ 18 買う 作る 計装 計装 SaaS SaaS OSS OSS
19. これまで：オブザーバビリティ、買うか作るか？ 19 買う 作る 計装 計装 SaaS SaaS OSS OSS ベンダーロックイン 人手や時間が必要
20. OpenTelemetryの登場（2019.5） Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年 に合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 20 Kaigi on Rails 2024 登壇資料より
21. • OpenTracingとOpenCensusを統合 • オブザーバビリティの実現に必要なほぼ(*1) 全てを提供 ◦ トレース、ログ、メトリクス ◦ API仕様（Specification, OTLP） ◦ 言語別のSDK、instrumentation library ◦ デモやドキュメント →標準仕様としての存在感 OpenTelemetryの登場（2019.5） (*1)ほぼ･･･閲覧用のUIやストレージなど、バックエンドは今のところ提供していません 21 Kaigi on Rails 2024 登壇資料より
22. オブザーバビリティベンダー各社のOpenTelemetry対応 22 • 独自プロトコルを有するベンダーもOpenTelemetry に互換性を持たせる動き Send Metrics and Traces From OpenTelemetry Collector to Datadog via Datadog Exporter | Datadog Native support for OpenTelemetry (early access available now!!) | New Relic Documentation
23. • Collectorにより異なるプロトコル間で相互運用可能となる • バックエンドやプロトコル移行のための並行稼働環境構築にも利用可能 OpenTelemetry Collectorによる相互運用性の向上 23 出典：Collector | OpenTelemetry
24. オブザーバビリティの新たな選択肢 24 買う 作る 計装 計装 SaaS SaaS OSS OSS
25. オブザーバビリティの新たな選択肢 25 買う 作る 計装 計装 SaaS SaaS OSS OSS ハイブリッド 計装 OSS SaaS
26. オブザーバビリティSaaSの訴求ポイントの変化 26 • これまで ◦ 有用な情報を手軽に送信できる独自SDKを提供 し、それをどう活用できる機能を提供するか • これから ◦ 標準化されたプロトコル（OpenTelemetry）を ベースにそれをどう活用できる機能を提供するか ※実際の市場調査をした訳では無く、あくまでも主観的な感想です
27. 技術選定のポイント
28. プロトコルとバックエンドをそれぞれ選ぶ必要がある 28 SaaS or OSS SaaS or OSS 計装 （プロトコル） バックエンド
29. 下記の選択肢から要件やコストをベースに選定する 技術選定のざっくり全体像 29 ベンダー非依存 ベンダー依存 プロトコル OpenTelemetry（OSS） ベンダーの独自形式 バックエンド OSS製品を自前デプロイ （Prometheus, Grafana等） ※マネージド版が提供されている 場合もあり オブザーバビリティSaaS （マネージドバックエンド）
30. 下記の選択肢から要件やコストをベースに選定する 技術選定のざっくり全体像 30 ベンダー非依存 ベンダー依存 プロトコル OpenTelemetry（OSS） ベンダーの独自形式 バックエンド OSS製品を自前デプロイ （Prometheus, Grafana等） ※マネージド版が提供されている 場合もあり オブザーバビリティSaaS （マネージドバックエンド） 作る 買う
31. 下記の選択肢から要件やコストをベースに選定する 技術選定のざっくり全体像 31 ベンダー非依存 ベンダー依存 プロトコル OpenTelemetry（OSS） ベンダーの独自形式 バックエンド OSS製品を自前デプロイ （Prometheus, Grafana等） ※マネージド版が提供されている 場合もあり オブザーバビリティSaaS （マネージドバックエンド） ハイブリッド
32. ハイブリッドを選んでおけばOK？
33. ハイブリッドを選んでおけばOK？ →そうとは限らない
34. 理由1：OpenTelemetryの成熟度は言語による • Java・・・テレメトリーすべて安定 • Ruby・・・トレース以外は開発中 ◦ 例：メトリクスは別の方法（Prometheusなど）を使わないと 34
35. 理由2：各ベンダーのOpenTelemetry対応は完全ではない 35 • 対応していない機能（Exemplar、Baggage、Link etc.） • セマンティック規約の差異 ◦ 例：接続先データベース製品名を表す属性 ▪ OpenTelemetry：db.system.name ▪ 独自プロトコル：database.product_name • 検索粒度やエラー率の集計対象など 要件にマッチするかを慎重に検討する必要がある
36. まずは要件の整理
37. • 必須要件だと私が考えていること ◦ ログ、メトリクス、トレースを一元管理できること ▪ ログとメトリクスはCloud Logging、トレースだけ別サービスみたいなの は避けたい（関連付けできないため） ▪ 監査ログとは分けて考える（サンプリングや保存期間） • プロダクトや組織固有の要件 ◦ 柔軟なフィルタリング・クエリ機能 ▪ テレメトリー間のジャンプなど ◦ トレンド分析や予測など ◦ ダッシュボードやアラートのカスタマイズ性 技術選定：要件の整理 37
38. • 計装対象由来の要件（制限事項） ◦ 使用言語 ▪ 例：Ruby＋OpenTelemetryの場合メトリクスは別の手段が必 要（Prometheus等） ◦ 実行環境 ▪ 例：App Engineはサイドカーが動かせない ▪ 例：Cloud Runならサイドカーは動かせるが、スケールするとリ ソース効率が悪化する 技術選定：要件の整理 38
39. 機能と要件の比較
40. • メリットで比較する？ 独自計装（SDK）を採用することで 得られるメリット ・充実した計装（最小の導入コスト） ・セマンティクスの一貫性 （例：設定無しでいい感じのダッシュ ボードを閲覧できる） 技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 40 OpenTelemetry計装（SDK）を採 用することで得られるメリット ・相互運用性 ・バックエンド移行時のコスト
41. • メリットで比較する？→決め手に欠ける 独自計装（SDK）を採用することで 得られるメリット ・充実した計装（最小の導入コスト） ・セマンティクスの一貫性 （例：設定無しでいい感じのダッシュ ボードを閲覧できる） 技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 41 SaaS側のOpenTelemetry対応 によってこのメリットは消えるか も？（中長期的な視点） 恐らくこのメリットは覆らなそう OpenTelemetry計装（SDK）を採 用することで得られるメリット ・相互運用性 ・バックエンド移行時のコスト
42. 独自計装（SDK）を採用することで 得られるメリット ↓ 独自計装（SDK）を採用することで 被るデメリット • デメリット（リスク）の中長期的な許容度で判断してみる 技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 42 OpenTelemetry計装（SDK）を採 用することで得られるメリット ↓ OpenTelemetry計装（SDK）を採 用することで被るデメリット
43. • デメリット（リスク）の中長期的な許容度で判断してみる 独自計装（SDK）を採用することで 被るデメリット ・異なるバックエンドや計装プロトコ ルとの統合ができなくなる ・バックエンド移行時のコスト増 技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 43 OpenTelemetry計装（SDK）を採 用することで被るデメリット ・導入コストが高くなる（カスタムメト リクスの追加、追加の設定など） ・セマンティクスの相違でトレース種別 がGeneralになる 許容できないデメリット（リスク）を見極める
44. • 例：「ハイブリッド」を選択 独自計装（SDK）を採用することで 被るデメリット ・異なるバックエンドや計装プロトコ ルとの統合ができなくなる ・バックエンド移行時のコスト増 技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 44 OpenTelemetry計装（SDK）を採 用することで被るデメリット ・導入コストが高くなる（カスタムメト リクスの追加、追加の設定など） ・セマンティクスの相違でトレース種別 がGeneralになる < テレメトリーの一元管理ができれば良くて、まずは 知見を色々溜めたい！ でもうちはサービスがたくさんあるので独自計装 だと乗り換えが大変そう・・・
45. • 例：「買う」を選択 独自計装（SDK）を採用することで 被るデメリット ・異なるバックエンドや計装プロトコ ルとの統合ができなくなる ・バックエンド移行時のコスト増 技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 45 OpenTelemetry計装（SDK）を採 用することで被るデメリット ・導入コストが高くなる（カスタムメト リクスの追加、追加の設定など） ・セマンティクスの相違でトレース種別 がGeneralになる うちはモジュラーモノリスで計測ポイントが少な いので、もうちょっとOpenTelemetryが成熟し たり、アーキテクチャ戦略が変わるならそのときに また考えるよ >
46. • 大前提：バックエンドを保守するエンジニアリングリソースが ある ◦ Prometheus, データストア, Grafana etc. ◦ OpenTelemetry Collector • 基本はこれまでと同じ考え方（リスク最小化、メリット最大化） ◦ 大規模な分散システムのテレメトリープロトコルの統一 ◦ 高度なサンプリングによるコスト最適化 具体的な事例：デンソー工場IoTにおける世界中からのテレメトリー収集の取り組み 技術選定：「作る」を選択するケース 46
47. 技術選定ができたら？
48. 運用し始めてからが本番です！ 48 • テレメトリーや運用の検査と適応のループを回す ◦ インシデント発生時のポストモーテム時など • オブザーバビリティに関連した主な計測指標 ◦ MTTD（Mean Time to Detect）： 障害が始まってからそれが検出 されるまでの時間 ◦ MTTK（Mean Time to Know）： 障害が検出されてから根本原因が 特定されるまでの時間 ◦ MTTV（Mean Time to Verify）： 修正の実施後に障害の解決が検 証されるまでの時間 参考：MTTR、MTBF、MTTD、MTTF の違いは何ですか | LogicMonitor
49. SmartHRはどうかな 49 • NewRelicによるトレース活用（主にAPM）は一定成果は 出ている👍 出典：文書配付機能で事前に負荷テストをして繁忙期を乗り切った話 出典：GAS × New Relic を駆使して立ち向かうパフォーマンス改善
50. SmartHRはどうかな 50 • 伸び代は色々ありそう💪 ◦ テレメトリーが一元管理できていないプロダクトがあ る（＝テレメトリーの関連付けが不完全） ◦ 未計装のサービスがある ◦ スパンが多すぎてノイズが発生している（1トレース数 千スパンとか・・・） ◦ 先述の指標（MTTK等）は測定できていない
51. そんなSmartHRはエンジニアを募集しています！ 51 エンジニア採用サイト https://hello-world.smarthr.co.jp/ SmartHR Tech Blog https://tech.smarthr.jp/
52. ありがとうございました！