Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Observability Technology Selection Tips

Y.Matsuda
February 20, 2025
520

Observability Technology Selection Tips

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

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

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

Y.Matsuda

February 20, 2025
Tweet

Transcript

  1. Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア • 仕事ではRubyを書いています(その前はGolangを3年程) • プライベートではOpenTelemetryにコントリビュートしたり 関連ツールを作ったりしています

    • OpenTelemetryに関連した登壇など ◦ OpenTelemetryでRailsのパフォーマンス分析を始めてみよう Kaigi on Rails 2024 ◦ OpenTelemetryとSaaSの“良いとこ取り”で構築する柔軟なオブ ザーバビリティ基盤 OpenTelemetry Meetup 2024-11 2
  2. オブザーバビリティの定義 8 オブザーバビリティ(可観測性)とは、出力を調べることでシステムの内部状態を測定する能力 です。出力、つまり計測データのみを用いて現在の状態を推定できる場合、システムは「オブ ザーバブル(観測可能)」だと見なされます。 What is Observability? An Introduction

    | Splunk (スライド作成者が翻訳) • 計測データ(テレメトリー) ◦ ログ ◦ メトリクス ◦ トレース パフォーマンス劣化のボトルネックは? 500エラーの原因は? アプリエラーはエンドユーザーにはどう見 えている? コード
  3. モニタリングとの違い:不確実性の高い問題に対するアプローチ • 背景:複雑化するアーキテクチャ ◦ マネージドサービスへの依存(AWS S3, SES, etc.) ◦ マイクロサービスアーキテクチャ

    ◦ サーバーレスデプロイ →(問題の)不確実性の増大 9 アプリ起因かも 外部サービス側の問題でしょ ネットワークが不安定になっ ただけ?
  4. • システムのコンテキストや経験中心の調査からテレメト リー(事実)中心の調査へ モニタリングとの違い:不確実性の高い問題に対するアプローチ 10 分散化したログの調査 コードの調査 ローカルでの再現確認 モニタリング テレメトリーによる分析

    ・遅延箇所の特定(トレース) ・コードレベルのエラー箇所特 定(ログ) など オブザーバビリティ • トライアンドエラーが分析ツール上で完結 • 経験への依存度低下 • 経験豊富なエンジニアへの依存 • 高コストなトライアンドエラー →調査コストの増大
  5. 乱立する仕様(プロトコル) ※トレース関連のみ抜粋 Dapper (Google) 2010 2012 2017 2019 OSS SaaS

    ※現在はServiceNow ※o11y関連のプロダクト開始年 に合わせてマッピング Splunk APM (ソース) Jaeger ソース Grafana Tempo 17 Kaigi on Rails 2024 登壇資料より
  6. OpenTelemetryの登場(2019.5) Dapper (Google) 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow

    ※o11y関連のプロダクト開始年 に合わせてマッピング Splunk APM (ソース) Jaeger ソース Grafana Tempo 20 Kaigi on Rails 2024 登壇資料より
  7. • OpenTracingとOpenCensusを統合 • オブザーバビリティの実現に必要なほぼ(*1) 全てを提供 ◦ トレース、ログ、メトリクス ◦ API仕様(Specification, OTLP)

    ◦ 言語別のSDK、instrumentation library ◦ デモやドキュメント →標準仕様としての存在感 OpenTelemetryの登場(2019.5) (*1)ほぼ・・・閲覧用のUIやストレージなど、バックエンドは今のところ提供していません 21 Kaigi on Rails 2024 登壇資料より
  8. オブザーバビリティベンダー各社の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
  9. オブザーバビリティSaaSの訴求ポイントの変化 26 • これまで ◦ 有用な情報を手軽に送信できる独自SDKを提供 し、それをどう活用できる機能を提供するか • これから ◦

    標準化されたプロトコル(OpenTelemetry)を ベースにそれをどう活用できる機能を提供するか ※実際の市場調査をした訳では無く、あくまでも主観的な感想です
  10. 下記の選択肢から要件やコストをベースに選定する 技術選定のざっくり全体像 30 ベンダー非依存 ベンダー依存 プロトコル OpenTelemetry(OSS) ベンダーの独自形式 バックエンド OSS製品を自前デプロイ

    (Prometheus, Grafana等) ※マネージド版が提供されている 場合もあり オブザーバビリティSaaS (マネージドバックエンド) 作る 買う
  11. 下記の選択肢から要件やコストをベースに選定する 技術選定のざっくり全体像 31 ベンダー非依存 ベンダー依存 プロトコル OpenTelemetry(OSS) ベンダーの独自形式 バックエンド OSS製品を自前デプロイ

    (Prometheus, Grafana等) ※マネージド版が提供されている 場合もあり オブザーバビリティSaaS (マネージドバックエンド) ハイブリッド
  12. 理由2:各ベンダーのOpenTelemetry対応は完全ではない 35 • 対応していない機能(Exemplar、Baggage、Link etc.) • セマンティック規約の差異 ◦ 例:接続先データベース製品名を表す属性 ▪

    OpenTelemetry:db.system.name ▪ 独自プロトコル:database.product_name • 検索粒度やエラー率の集計対象など 要件にマッチするかを慎重に検討する必要がある
  13. • 必須要件だと私が考えていること ◦ ログ、メトリクス、トレースを一元管理できること ▪ ログとメトリクスはCloud Logging、トレースだけ別サービスみたいなの は避けたい(関連付けできないため) ▪ 監査ログとは分けて考える(サンプリングや保存期間)

    • プロダクトや組織固有の要件 ◦ 柔軟なフィルタリング・クエリ機能 ▪ テレメトリー間のジャンプなど ◦ トレンド分析や予測など ◦ ダッシュボードやアラートのカスタマイズ性 技術選定:要件の整理 37
  14. • 計装対象由来の要件(制限事項) ◦ 使用言語 ▪ 例:Ruby+OpenTelemetryの場合メトリクスは別の手段が必 要(Prometheus等) ◦ 実行環境 ▪

    例:App Engineはサイドカーが動かせない ▪ 例:Cloud Runならサイドカーは動かせるが、スケールするとリ ソース効率が悪化する 技術選定:要件の整理 38
  15. • メリットで比較する?→決め手に欠ける 独自計装(SDK)を採用することで 得られるメリット ・充実した計装(最小の導入コスト) ・セマンティクスの一貫性 (例:設定無しでいい感じのダッシュ ボードを閲覧できる) 技術選定:機能と要件の比較(ハイブリッドor買う=プロトコルをどうするか) 41

    SaaS側のOpenTelemetry対応 によってこのメリットは消えるか も?(中長期的な視点) 恐らくこのメリットは覆らなそう OpenTelemetry計装(SDK)を採 用することで得られるメリット ・相互運用性 ・バックエンド移行時のコスト
  16. • 例:「ハイブリッド」を選択 独自計装(SDK)を採用することで 被るデメリット ・異なるバックエンドや計装プロトコ ルとの統合ができなくなる ・バックエンド移行時のコスト増 技術選定:機能と要件の比較(ハイブリッドor買う=プロトコルをどうするか) 44 OpenTelemetry計装(SDK)を採

    用することで被るデメリット ・導入コストが高くなる(カスタムメト リクスの追加、追加の設定など) ・セマンティクスの相違でトレース種別 がGeneralになる < テレメトリーの一元管理ができれば良くて、まずは 知見を色々溜めたい! でもうちはサービスがたくさんあるので独自計装 だと乗り換えが大変そう・・・
  17. • 例:「買う」を選択 独自計装(SDK)を採用することで 被るデメリット ・異なるバックエンドや計装プロトコ ルとの統合ができなくなる ・バックエンド移行時のコスト増 技術選定:機能と要件の比較(ハイブリッドor買う=プロトコルをどうするか) 45 OpenTelemetry計装(SDK)を採

    用することで被るデメリット ・導入コストが高くなる(カスタムメト リクスの追加、追加の設定など) ・セマンティクスの相違でトレース種別 がGeneralになる うちはモジュラーモノリスで計測ポイントが少な いので、もうちょっとOpenTelemetryが成熟し たり、アーキテクチャ戦略が変わるならそのときに また考えるよ >
  18. • 大前提:バックエンドを保守するエンジニアリングリソースが ある ◦ Prometheus, データストア, Grafana etc. ◦ OpenTelemetry

    Collector • 基本はこれまでと同じ考え方(リスク最小化、メリット最大化) ◦ 大規模な分散システムのテレメトリープロトコルの統一 ◦ 高度なサンプリングによるコスト最適化 具体的な事例:デンソー工場IoTにおける世界中からのテレメトリー収集の取り組み 技術選定:「作る」を選択するケース 46
  19. 運用し始めてからが本番です! 48 • テレメトリーや運用の検査と適応のループを回す ◦ インシデント発生時のポストモーテム時など • オブザーバビリティに関連した主な計測指標 ◦ MTTD(Mean

    Time to Detect): 障害が始まってからそれが検出 されるまでの時間 ◦ MTTK(Mean Time to Know): 障害が検出されてから根本原因が 特定されるまでの時間 ◦ MTTV(Mean Time to Verify): 修正の実施後に障害の解決が検 証されるまでの時間 参考:MTTR、MTBF、MTTD、MTTF の違いは何ですか | LogicMonitor
  20. SmartHRはどうかな 50 • 伸び代は色々ありそう💪 ◦ テレメトリーが一元管理できていないプロダクトがあ る(=テレメトリーの関連付けが不完全) ◦ 未計装のサービスがある ◦

    スパンが多すぎてノイズが発生している(1トレース数 千スパンとか・・・) ◦ 先述の指標(MTTK等)は測定できていない