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