監視SaaSの運用におけるObservability改善の歩み

by taxin

Slide 1

Slide 1 text

監視SaaSの運用における Observability改善の歩み id:taxintt / @taxin_tt 2025/01/26 SRE Kaigi 1

Slide 2

Slide 2 text

自己紹介 ● 西川拓志 ○ id: taxintt / @taxin_tt ● 株式会社はてな ● Mackerel開発チーム SRE 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

本講演のモチベーションと概要 4 ● Observability(o11y)はサービス運用に関わるエンジニアが一度は向き合ったことがある課題 ○ とtaxinは考えている ● SRE Kaigiでの対話・交流において参加者に身近な話題をセッションのテーマにしたい → Observability改善の歩み・学びについて話します

Slide 5

Slide 5 text

前提 5 ● “監視SaaSの運用におけるObservability改善” とある通り、Mackerelのサービス基盤の話をします ○ ※Mackerelユーザーの事例の話ではありません ● Mackerelはサービス基盤の監視にMackerel自身を利用しています

Slide 6

Slide 6 text

アジェンダ 6 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ

Slide 7

Slide 7 text

アジェンダ 7 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ

Slide 8

Slide 8 text

Observabilityとは? 8 ● cncf/tag-observability ○ > In control theory, "observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs." ○ システムの外部出力からシステムの内側で何が起きているのかを推測できるかを示す尺度

Slide 9

Slide 9 text

9 CNCF Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#observability-signals

Slide 10

Slide 10 text

Observabilityとは? 10 o11yにおいて向き合う対象(w/ラムズフェルドの4象限) Known-knowns (意識し理解していること) Known-Unknown s (理解しているけど意識していないこと) Unknowns-known s (意識してるけど理解していないこと) Unknown-Unknowns (意識もしてないし理解もしていないこと) システム監視未知のシステム故障への対応テスト、アラート直感による問題特定

Slide 11

Slide 11 text

アジェンダ 11 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ

Slide 12

Slide 12 text

Observability改善の歩み 12 1)標準的なメトリクスの利用 ● メトリクスの取得が容易なものから利用していく ○ 例) CPU使用率などのcompute resourceのメトリクス ● 󰢃 o11yの観点では十分ではない ○ システムの内側で何が起きているかを十分には推測できない

Slide 13

Slide 13 text

Observability改善の歩み 13 例)Mackerelへのデータ投稿 ● 「Public Cloudのデータ(メトリクス)が投稿されていない」は内部的には何を表すか? ○ データ取得のジョブが投入されていない ○ データの取得処理に失敗した ■ API throttling、認証情報の不備(※)、障害 etc… ○ データの取得処理後にデータの保存に失敗した

Slide 14

Slide 14 text

Observability改善の歩み 14 例)Mackerelへのデータ投稿 ● 標準的なメトリクスでは内部の挙動は十分にはわからない ○ ジョブが何件投入されて、何件成功しているかを知りたい ○ 考えられる要因を場当たり的に見ていくのは大変 ● システムの内部状態を表現するテレメトリーを生成する必要がある ○ →計装(Instrumentation)

Slide 15

Slide 15 text

Observability改善の歩み 15 2)サービスの状態を表すメトリクスの実装 ● ログをメトリクスに変換して投稿 ○ HTTP status codeを見てジョブの処理開始・成功の状態にマッピングしてログとして出力 ○ ログを収集してメトリクスに変換して投稿する Lambda(cloudwatch-logs-aggregator)を利用

Slide 16

Slide 16 text

Observability改善の歩み 16 2)サービスの状態を表すメトリクスの実装 ● 👍 メトリクスが表現する状態の解像度が上がる ○ ログは情報の解像度は高いが、全体傾向はわからない ○ メトリクスは全体傾向はわかるが、情報としての解像度はメトリクスの定義に依存する →ログとメトリクスの良いところを組み合わせる

Slide 17

Slide 17 text

17 CNCF Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#observability-signals

Slide 18

Slide 18 text

Observability改善の歩み 18 2)サービスの状態を表すメトリクスの実装 ● 👍 内部的な挙動の異常に気づきやすい ○ ログ(イベント)をメトリクスに集約することでアラーティングによる検知が容易にできる ○ “メトリクス取得のジョブが投入されてない”の粒度でアラートが発報されるので状況把握が楽

Slide 19

Slide 19 text

Observability改善の歩み 19 2)サービスの状態を表すメトリクスの実装 ● (+)複数のツールを実装してカバー対象を広げる ○ ログ→メトリクスへの変換 ○ RDS,S3(Athena)にクエリを投げてメトリクスを生成 ○ ダミーのメトリクスを投稿・取得してdurationなどを e2eで計測する etc…

Slide 20

Slide 20 text

20 Known-knowns (意識し理解していること) Known-Unknown s (理解しているけど意識していないこと) Unknown-Unknowns (意識もしてないし理解もしていないこと) 未知のシステム故障への対応テスト、アラート直感による問題特定 Unknowns-known s (意識してるけど理解していないこと) システム監視

Slide 21

Slide 21 text

Observability改善の歩み 21 2)サービスの状態を表すメトリクスの実装 ● 󰢃 未知の未知(Unknowns-unknowns)に弱い ○ ログ変換の場合は、観測したい対象の特定→イベントをログに出力する→ログを集計してメトリクスに変換 ■ 既知の未知(Unknowns-knowns) ○ 「対象を認知できてない」場合はログにはしづらいし、闇雲にログに出力するのもコストがかかる

Slide 22

Slide 22 text

Observability改善の歩み 22 例)データ投稿・取得処理の遅延 ● OpenTelemetryのメトリクスの保存・取得処理が詰まる ○ 複数のシステムが連携して処理しているのでボトルネックの特定、原因調査が大変 ○ ボトルネック箇所・原因の特定はスムーズに行いたい

Slide 23

Slide 23 text

Observability改善の歩み 23 3)トレースの活用 ● OpenTelemetryの計装ライブラリでトレースを計装 ○ Mackerel本体はScalaベースなので、 opentelemetry-javaagentを使って自動計装 ○ Goベースのサブシステムはデータストアとやりとりする処理を中心に手動計装 ○ ステージング環境でトレースを確認しつつ、必要に応じてサンプリング設定をして本番導入

Slide 24

Slide 24 text

Observability改善の歩み 24 3)トレースの活用 ● 👍 異なるテレメトリー間の相関から洞察を得る ○ 例)トレース内のスパンから時間がかかる処理の特定 →関連するテレメトリーを見つつ原因を分析する ○ 前述の事象はラベル情報を保存するDBへの読み書きがボトルネックになっていた ○ ドリルダウン的なアプローチができるようになったことで未知の事象にも向き合いやすくなった

Slide 25

Slide 25 text

25 CNCF Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#observability-signals

Slide 26

Slide 26 text

Observability改善の歩みまとめ 26 ● 標準的なメトリクスの利用 ● サービスの状態を表すメトリクスの実装 ○ 単一の情報に対して解像度を上げる(A→A’) ○ メトリクス、ログの特性を活用し解像度を上げてアラーティングに繋げる(検知の改善) ● トレースの活用 ○ 複数の情報を組み合わせて洞察を得る(A+B→C) ○ テレメトリー間の相関を活用したドリルダウン(調査の改善)

Slide 27

Slide 27 text

アジェンダ 27 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ

Slide 28

Slide 28 text

(1) テレメトリーの優先度 28 テレメトリーの優先度はどう決める? ● 🧐o11yの改善のために、詳細なテレメトリーを網羅的に計装し続けるのは大変 ○ 時間もコストもかかる ○ テレメトリーの計装自体が目的ではない ● 一定の基準で優先度を整理して対応したい

Slide 29

Slide 29 text

(1) テレメトリーの優先度 29 テレメトリーの優先度はどう決める? 1. o11y成熟度モデルを使って自分達の現在地を評価する 2. SLI/SLOに関連するテレメトリーを優先度高く計装する

Slide 30

Slide 30 text

30 AWS オブザーバビリティ成熟度モデル https://aws-observability.github.io/observability-best-practices/ja/guides/observability-maturity-model/

Slide 31

Slide 31 text

(1) テレメトリーの優先度 31 o11y成熟度モデルを使って自分達の現在地を評価する ● 組織/プロダクトが今どのような段階なのかを知り、次の段階とそこに至るまでのギャップを認識したい ● ※成熟度モデルに従うだけでは十分ではないはず ○ 公開されている成熟度モデルの内容は微妙に異なる ○ 組織/プロダクトの課題と結びつけて考えることが大事

Slide 32

Slide 32 text

Slide 33

Slide 33 text

(1) テレメトリーの優先度 33 SLI/SLOに関連するテレメトリーを優先度高く計装する ● テレメトリーを計装して有用なことをしたい ○ 有用である=ユーザーのためになる ● SLI/SLOに紐づくCUJをユーザーが達成できているか表現するテレメトリーは必要になる

Slide 34

Slide 34 text

(1) テレメトリーの優先度 34 o11yの改善においては、定期的な分析・評価が重要 ● その時の組織/プロダクトが向き合っている課題によって優先度は変わる ● 分析・評価の場としてはPWG、エンジニア会がある ○ PWG：最近のパフォーマンス状況やインフラ構成の変更を確認・共有する会 ○ エンジニア会：プロダクトに関する技術的課題を取り上げ、議論する会

Slide 35

Slide 35 text

(2) テレメトリーの信頼性 35 テレメトリーの生成・取得に対する信頼性 ● 🧐自前のテレメトリーは正しく収集・送信できている? ● 例)ログをメトリクスに変換するケース ○ ログの欠損がメトリクスの数値に波及する ○ 変換処理の失敗は、メトリクスでの定点観測、アラートの信頼性にも影響してくる

Slide 36

Slide 36 text

(2) テレメトリーの信頼性 36 テレメトリーの生成・取得に対する信頼性 ● 監視系のコンポーネントが処理失敗したら、メトリクスが投稿されなくなるので最低限の監視は必須 ○ メトリクス投稿用のLambdaに対する監視 ○ 生成したメトリクス自体の監視 ○ OpenTelemetry Collectorの監視(New!)

Slide 37

Slide 37 text

(2) テレメトリーの信頼性 37 テレメトリーの生成・取得に対する信頼性 ● 計装の観点ではライブラリの仕様にも注意して実装 ○ zap/FAQ.md at master · uber-go/zap ○ >Logs are dropped intentionally by zap when sampling is enabled. The production conﬁguration (as returned by NewProductionConﬁg() enables sampling…

Slide 38

Slide 38 text

まとめ 38 ● 検知の改善 ○ サービスの状態を表すメトリクスの実装とアラーティング ● 調査の改善 ○ 各テレメトリー間の相関を踏まえたドリルダウン的な分析 ● テレメトリーの優先度 ○ o11y成熟度モデル、SLI/SLOを考慮した継続的な優先度評価 ● テレメトリーの信頼性 ○ 監視系のコンポーネント、計装用のライブラリに目を向ける