Observability Technology Selection Tips

Slide 1

Slide 1 text

オブザーバビリティ技術選定の勘所 2025.02.25 Tur. OpenTelemetryって本当に必要？今エンジニアが知っておくべきオブザーバビリティとは@Offers_DeepDive | Connpass @ymtdzzz

Slide 2

Slide 2 text

Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア ● 仕事ではRubyを書いています（その前はGolangを3年程） ● プライベートではOpenTelemetryにコントリビュートしたり関連ツールを作ったりしています ● OpenTelemetryに関連した登壇など ○ OpenTelemetryでRailsのパフォーマンス分析を始めてみよう Kaigi on Rails 2024 ○ OpenTelemetryとSaaSの“良いとこ取り”で構築する柔軟なオブザーバビリティ基盤 OpenTelemetry Meetup 2024-11 2

Slide 3

Slide 3 text

otel-tui（宣伝） 3 ● OpenTelemetry計装のローカル開発向けツール https://github.com/ymtdzzz/otel-tui

Slide 4

Slide 4 text

今日お話すること 4 ● オブザーバビリティとは ● オブザーバビリティを取り巻く環境（令和最新版） ● 技術選定のポイント

Slide 5

Slide 5 text

● 現在の所属会社SmartHRはNewRelicの独自計装を用いてオブザーバビリティ環境を構築しています（OpenTelemetryではない） ● OpenTelemetryをプロダクションで使っていた前職（〜2024/06頃）での経験をベースに、最新事情を盛り込んでお話します注意点 5

Slide 6

Slide 6 text

オブザーバビリティとは

Slide 7

Slide 7 text

オブザーバビリティの定義 7 オブザーバビリティ（可観測性）とは、出力を調べることでシステムの内部状態を測定する能力です。出力、つまり計測データのみを用いて現在の状態を推定できる場合、システムは「オブザーバブル（観測可能）」だと見なされます。 What is Observability? An Introduction | Splunk （スライド作成者が翻訳）

Slide 8

Slide 8 text

オブザーバビリティの定義 8 オブザーバビリティ（可観測性）とは、出力を調べることでシステムの内部状態を測定する能力です。出力、つまり計測データのみを用いて現在の状態を推定できる場合、システムは「オブザーバブル（観測可能）」だと見なされます。 What is Observability? An Introduction | Splunk （スライド作成者が翻訳） ● 計測データ（テレメトリー） ○ ログ ○ メトリクス ○ トレースパフォーマンス劣化のボトルネックは？ 500エラーの原因は？アプリエラーはエンドユーザーにはどう見えている？コード

Slide 9

Slide 9 text

モニタリングとの違い：不確実性の高い問題に対するアプローチ ● 背景：複雑化するアーキテクチャ ○ マネージドサービスへの依存（AWS S3, SES, etc.） ○ マイクロサービスアーキテクチャ ○ サーバーレスデプロイ →（問題の）不確実性の増大 9 アプリ起因かも外部サービス側の問題でしょネットワークが不安定になっただけ？

Slide 10

Slide 10 text

● システムのコンテキストや経験中心の調査からテレメトリー（事実）中心の調査へモニタリングとの違い：不確実性の高い問題に対するアプローチ 10 分散化したログの調査コードの調査ローカルでの再現確認モニタリングテレメトリーによる分析・遅延箇所の特定（トレース）・コードレベルのエラー箇所特定（ログ）　などオブザーバビリティ ● トライアンドエラーが分析ツール上で完結 ● 経験への依存度低下 ● 経験豊富なエンジニアへの依存 ● 高コストなトライアンドエラー →調査コストの増大

Slide 11

Slide 11 text

オブザーバビリティを支えるトレース 11 ● オブザーバビリティの根幹は「テレメトリーの関連付け」メトリクストレースログ（UI上で）自由に行き来できるメトリクスから代表的なトレースを知りたいエラーログからユーザー影響を知りたい

Slide 12

Slide 12 text

オブザーバビリティを支えるトレース 12 ● トレースIDで関連付けるメトリクストレースログ（UI上で）自由に行き来できる TraceID TraceID TraceID トレースのイメージ

Slide 13

Slide 13 text

計装の手段 13 ● 計装：テレメトリーをシステムから出力できるように実装すること ● SDKによる実装やコンポーネントのデプロイが必要になる

Slide 14

Slide 14 text

計装の手段 14 ● テレメトリーのデータフォーマットは様々なので、それぞれが提供するSDKや計装ライブラリを利用する SDKを用いたテレメトリーの送信（計装）

Slide 15

Slide 15 text

選び方については後半で

Slide 16

Slide 16 text

オブザーバビリティを取り巻く環境（令和最新版）

Slide 17

Slide 17 text

乱立する仕様（プロトコル） ※トレース関連のみ抜粋 Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年に合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 17 Kaigi on Rails 2024 登壇資料より

Slide 18

Slide 18 text

これまで：オブザーバビリティ、買うか作るか？ 18 買う作る計装計装 SaaS SaaS OSS OSS

Slide 19

Slide 19 text

これまで：オブザーバビリティ、買うか作るか？ 19 買う作る計装計装 SaaS SaaS OSS OSS ベンダーロックイン人手や時間が必要

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

● OpenTracingとOpenCensusを統合 ● オブザーバビリティの実現に必要なほぼ(*1) 全てを提供 ○ トレース、ログ、メトリクス ○ API仕様（Specification, OTLP） ○ 言語別のSDK、instrumentation library ○ デモやドキュメント →標準仕様としての存在感 OpenTelemetryの登場（2019.5） (*1)ほぼ･･･閲覧用のUIやストレージなど、バックエンドは今のところ提供していません 21 Kaigi on Rails 2024 登壇資料より

Slide 22

Slide 22 text

オブザーバビリティベンダー各社の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

Slide 23

Slide 23 text

● Collectorにより異なるプロトコル間で相互運用可能となる ● バックエンドやプロトコル移行のための並行稼働環境構築にも利用可能 OpenTelemetry Collectorによる相互運用性の向上 23 出典：Collector | OpenTelemetry

Slide 24

Slide 24 text

オブザーバビリティの新たな選択肢 24 買う作る計装計装 SaaS SaaS OSS OSS

Slide 25

Slide 25 text

オブザーバビリティの新たな選択肢 25 買う作る計装計装 SaaS SaaS OSS OSS ハイブリッド計装 OSS SaaS

Slide 26

Slide 26 text

オブザーバビリティSaaSの訴求ポイントの変化 26 ● これまで ○ 有用な情報を手軽に送信できる独自SDKを提供し、それをどう活用できる機能を提供するか ● これから ○ 標準化されたプロトコル（OpenTelemetry）をベースにそれをどう活用できる機能を提供するか ※実際の市場調査をした訳では無く、あくまでも主観的な感想です

Slide 27

Slide 27 text

技術選定のポイント

Slide 28

Slide 28 text

プロトコルとバックエンドをそれぞれ選ぶ必要がある 28 SaaS or OSS SaaS or OSS 計装（プロトコル）バックエンド

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

ハイブリッドを選んでおけばOK？

Slide 33

Slide 33 text

ハイブリッドを選んでおけばOK？ →そうとは限らない

Slide 34

Slide 34 text

理由1：OpenTelemetryの成熟度は言語による ● Java・・・テレメトリーすべて安定 ● Ruby・・・トレース以外は開発中 ○ 例：メトリクスは別の方法（Prometheusなど）を使わないと 34

Slide 35

Slide 35 text

理由2：各ベンダーのOpenTelemetry対応は完全ではない 35 ● 対応していない機能（Exemplar、Baggage、Link etc.） ● セマンティック規約の差異 ○ 例：接続先データベース製品名を表す属性 ■ OpenTelemetry：db.system.name ■ 独自プロトコル：database.product_name ● 検索粒度やエラー率の集計対象など要件にマッチするかを慎重に検討する必要がある

Slide 36

Slide 36 text

まずは要件の整理

Slide 37

Slide 37 text

● 必須要件だと私が考えていること ○ ログ、メトリクス、トレースを一元管理できること ■ ログとメトリクスはCloud Logging、トレースだけ別サービスみたいなのは避けたい（関連付けできないため） ■ 監査ログとは分けて考える（サンプリングや保存期間） ● プロダクトや組織固有の要件 ○ 柔軟なフィルタリング・クエリ機能 ■ テレメトリー間のジャンプなど ○ トレンド分析や予測など ○ ダッシュボードやアラートのカスタマイズ性技術選定：要件の整理 37

Slide 38

Slide 38 text

● 計装対象由来の要件（制限事項） ○ 使用言語 ■ 例：Ruby＋OpenTelemetryの場合メトリクスは別の手段が必要（Prometheus等） ○ 実行環境 ■ 例：App Engineはサイドカーが動かせない ■ 例：Cloud Runならサイドカーは動かせるが、スケールするとリソース効率が悪化する技術選定：要件の整理 38

Slide 39

Slide 39 text

機能と要件の比較

Slide 40

Slide 40 text

● メリットで比較する？独自計装（SDK）を採用することで得られるメリット・充実した計装（最小の導入コスト）・セマンティクスの一貫性（例：設定無しでいい感じのダッシュボードを閲覧できる）技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 40 OpenTelemetry計装（SDK）を採用することで得られるメリット・相互運用性・バックエンド移行時のコスト

Slide 41

Slide 41 text

● メリットで比較する？→決め手に欠ける独自計装（SDK）を採用することで得られるメリット・充実した計装（最小の導入コスト）・セマンティクスの一貫性（例：設定無しでいい感じのダッシュボードを閲覧できる）技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 41 SaaS側のOpenTelemetry対応によってこのメリットは消えるかも？（中長期的な視点）恐らくこのメリットは覆らなそう OpenTelemetry計装（SDK）を採用することで得られるメリット・相互運用性・バックエンド移行時のコスト

Slide 42

Slide 42 text

独自計装（SDK）を採用することで得られるメリット ↓ 独自計装（SDK）を採用することで被るデメリット ● デメリット（リスク）の中長期的な許容度で判断してみる技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 42 OpenTelemetry計装（SDK）を採用することで得られるメリット ↓ OpenTelemetry計装（SDK）を採用することで被るデメリット

Slide 43

Slide 43 text

● デメリット（リスク）の中長期的な許容度で判断してみる独自計装（SDK）を採用することで被るデメリット・異なるバックエンドや計装プロトコルとの統合ができなくなる・バックエンド移行時のコスト増技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 43 OpenTelemetry計装（SDK）を採用することで被るデメリット・導入コストが高くなる（カスタムメトリクスの追加、追加の設定など）・セマンティクスの相違でトレース種別がGeneralになる許容できないデメリット（リスク）を見極める

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

● 例：「買う」を選択独自計装（SDK）を採用することで被るデメリット・異なるバックエンドや計装プロトコルとの統合ができなくなる・バックエンド移行時のコスト増技術選定：機能と要件の比較（ハイブリッドor買う=プロトコルをどうするか） 45 OpenTelemetry計装（SDK）を採用することで被るデメリット・導入コストが高くなる（カスタムメトリクスの追加、追加の設定など）・セマンティクスの相違でトレース種別がGeneralになるうちはモジュラーモノリスで計測ポイントが少ないので、もうちょっとOpenTelemetryが成熟したり、アーキテクチャ戦略が変わるならそのときにまた考えるよ >

Slide 46

Slide 46 text

● 大前提：バックエンドを保守するエンジニアリングリソースがある ○ Prometheus, データストア, Grafana etc. ○ OpenTelemetry Collector ● 基本はこれまでと同じ考え方（リスク最小化、メリット最大化） ○ 大規模な分散システムのテレメトリープロトコルの統一 ○ 高度なサンプリングによるコスト最適化具体的な事例：デンソー工場IoTにおける世界中からのテレメトリー収集の取り組み技術選定：「作る」を選択するケース 46

Slide 47

Slide 47 text

技術選定ができたら？

Slide 48

Slide 48 text

運用し始めてからが本番です！ 48 ● テレメトリーや運用の検査と適応のループを回す ○ インシデント発生時のポストモーテム時など ● オブザーバビリティに関連した主な計測指標 ○ MTTD（Mean Time to Detect）：障害が始まってからそれが検出されるまでの時間 ○ MTTK（Mean Time to Know）：障害が検出されてから根本原因が特定されるまでの時間 ○ MTTV（Mean Time to Verify）：修正の実施後に障害の解決が検証されるまでの時間参考：MTTR、MTBF、MTTD、MTTF の違いは何ですか | LogicMonitor

Slide 49

Slide 49 text

SmartHRはどうかな 49 ● NewRelicによるトレース活用（主にAPM）は一定成果は出ている👍 出典：文書配付機能で事前に負荷テストをして繁忙期を乗り切った話出典：GAS × New Relic を駆使して立ち向かうパフォーマンス改善

Slide 50

Slide 50 text

SmartHRはどうかな 50 ● 伸び代は色々ありそう💪 ○ テレメトリーが一元管理できていないプロダクトがある（＝テレメトリーの関連付けが不完全） ○ 未計装のサービスがある ○ スパンが多すぎてノイズが発生している（1トレース数千スパンとか・・・） ○ 先述の指標（MTTK等）は測定できていない

Slide 51

Slide 51 text

そんなSmartHRはエンジニアを募集しています！ 51 エンジニア採用サイト https://hello-world.smarthr.co.jp/ SmartHR Tech Blog https://tech.smarthr.jp/

Slide 52

Slide 52 text

ありがとうございました！