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

Transcript

1. 監視SaaSの運用における Observability改善の歩み id:taxintt / @taxin_tt 2025/01/26 SRE Kaigi 1
2. 自己紹介 • 西川 拓志 ◦ id: taxintt / @taxin_tt • 株式会社はてな • Mackerel開発チーム SRE 2
4. 本講演のモチベーションと概要 4 • Observability(o11y)はサービス運用に関わる エンジニアが一度は向き合ったことがある課題 ◦ とtaxinは考えている • SRE Kaigiでの対話・交流において参加者に身近な話題を セッションのテーマにしたい → Observability改善の歩み・学びについて話します
5. 前提 5 • “監視SaaSの運用におけるObservability改善” とある通り、Mackerelのサービス基盤の話をします ◦ ※Mackerelユーザーの事例の話ではありません • Mackerelはサービス基盤の監視にMackerel自身を 利用しています
6. アジェンダ 6 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ
7. アジェンダ 7 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ
8. 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." ◦ システムの外部出力からシステムの内側で何が起きている のかを推測できるかを示す尺度
9. 9 CNCF Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#observability-signals
10. Observabilityとは? 10 o11yにおいて向き合う対象(w/ラムズフェルドの4象限) Known-knowns (意識し理解していること) Known-Unknown s (理解しているけど 意識していないこと) Unknowns-known s (意識してるけど 理解していないこと) Unknown-Unknowns (意識もしてないし 理解もしていないこと) システム監視 未知のシステム故障 への対応 テスト、アラート 直感による問題特定
11. アジェンダ 11 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ
12. Observability改善の歩み 12 1)標準的なメトリクスの利用 • メトリクスの取得が容易なものから利用していく ◦ 例) CPU使用率などのcompute resourceのメトリクス • 󰢃 o11yの観点では十分ではない ◦ システムの内側で何が起きているかを十分には推測できない
13. Observability改善の歩み 13 例)Mackerelへのデータ投稿 • 「Public Cloudのデータ(メトリクス)が投稿されて いない」は内部的には何を表すか? ◦ データ取得のジョブが投入されていない ◦ データの取得処理に失敗した ▪ API throttling、認証情報の不備(※)、障害 etc… ◦ データの取得処理後にデータの保存に失敗した
14. Observability改善の歩み 14 例)Mackerelへのデータ投稿 • 標準的なメトリクスでは内部の挙動は十分にはわからない ◦ ジョブが何件投入されて、何件成功しているかを知りたい ◦ 考えられる要因を場当たり的に見ていくのは大変 • システムの内部状態を表現するテレメトリーを生成する 必要がある ◦ →計装(Instrumentation)
15. Observability改善の歩み 15 2)サービスの状態を表すメトリクスの実装 • ログをメトリクスに変換して投稿 ◦ HTTP status codeを見てジョブの処理開始・成功の 状態にマッピングしてログとして出力 ◦ ログを収集してメトリクスに変換して投稿する Lambda(cloudwatch-logs-aggregator)を利用
16. Observability改善の歩み 16 2)サービスの状態を表すメトリクスの実装 • 👍 メトリクスが表現する状態の解像度が上がる ◦ ログは情報の解像度は高いが、全体傾向はわからない ◦ メトリクスは全体傾向はわかるが、情報としての 解像度はメトリクスの定義に依存する →ログとメトリクスの良いところを組み合わせる
17. 17 CNCF Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#observability-signals
18. Observability改善の歩み 18 2)サービスの状態を表すメトリクスの実装 • 👍 内部的な挙動の異常に気づきやすい ◦ ログ(イベント)をメトリクスに集約することで アラーティングによる検知が容易にできる ◦ “メトリクス取得のジョブが投入されてない”の粒度で アラートが発報されるので状況把握が楽
19. Observability改善の歩み 19 2)サービスの状態を表すメトリクスの実装 • (+)複数のツールを実装してカバー対象を広げる ◦ ログ→メトリクスへの変換 ◦ RDS,S3(Athena)にクエリを投げてメトリクスを生成 ◦ ダミーのメトリクスを投稿・取得してdurationなどを e2eで計測する etc…
20. 20 Known-knowns (意識し理解していること) Known-Unknown s (理解しているけど 意識していないこと) Unknown-Unknowns (意識もしてないし 理解もしていないこと) 未知のシステム故障 への対応 テスト、アラート 直感による問題特定 Unknowns-known s (意識してるけど 理解していないこと) システム監視
21. Observability改善の歩み 21 2)サービスの状態を表すメトリクスの実装 • 󰢃 未知の未知(Unknowns-unknowns)に弱い ◦ ログ変換の場合は、観測したい対象の特定→イベントを ログに出力する→ログを集計してメトリクスに変換 ▪ 既知の未知(Unknowns-knowns) ◦ 「対象を認知できてない」場合はログにはしづらいし、 闇雲にログに出力するのもコストがかかる
22. Observability改善の歩み 22 例)データ投稿・取得処理の遅延 • OpenTelemetryのメトリクスの保存・取得処理が詰まる ◦ 複数のシステムが連携して処理しているので ボトルネックの特定、原因調査が大変 ◦ ボトルネック箇所・原因の特定はスムーズに行いたい
23. Observability改善の歩み 23 3)トレースの活用 • OpenTelemetryの計装ライブラリでトレースを計装 ◦ Mackerel本体はScalaベースなので、 opentelemetry-javaagentを使って自動計装 ◦ Goベースのサブシステムはデータストアとやりとりする 処理を中心に手動計装 ◦ ステージング環境でトレースを確認しつつ、必要に 応じてサンプリング設定をして本番導入
24. Observability改善の歩み 24 3)トレースの活用 • 👍 異なるテレメトリー間の相関から洞察を得る ◦ 例)トレース内のスパンから時間がかかる処理の特定 →関連するテレメトリーを見つつ原因を分析する ◦ 前述の事象はラベル情報を保存するDBへの読み書きが ボトルネックになっていた ◦ ドリルダウン的なアプローチができるようになった ことで未知の事象にも向き合いやすくなった
25. 25 CNCF Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#observability-signals
26. Observability改善の歩み まとめ 26 • 標準的なメトリクスの利用 • サービスの状態を表すメトリクスの実装 ◦ 単一の情報に対して解像度を上げる(A→A’) ◦ メトリクス、ログの特性を活用し解像度を上げて アラーティングに繋げる(検知の改善) • トレースの活用 ◦ 複数の情報を組み合わせて洞察を得る(A+B→C) ◦ テレメトリー間の相関を活用したドリルダウン(調査の改善)
27. アジェンダ 27 1. Observabilityとは? 2. MackerelにおけるObservability改善の歩み 3. Observabilityの改善において向き合っている課題 4. まとめ
28. (1) テレメトリーの優先度 28 テレメトリーの優先度はどう決める? • 🧐o11yの改善のために、詳細なテレメトリーを網羅的に 計装し続けるのは大変 ◦ 時間もコストもかかる ◦ テレメトリーの計装自体が目的ではない • 一定の基準で優先度を整理して対応したい
29. (1) テレメトリーの優先度 29 テレメトリーの優先度はどう決める? 1. o11y成熟度モデルを使って自分達の現在地を評価する 2. SLI/SLOに関連するテレメトリーを優先度高く計装する
30. 30 AWS オブザーバビリティ成熟度モデル https://aws-observability.github.io/observability-best-practices/ja/guides/observability-maturity-model/
31. (1) テレメトリーの優先度 31 o11y成熟度モデルを使って自分達の現在地を評価する • 組織/プロダクトが今どのような段階なのかを知り、 次の段階とそこに至るまでのギャップを認識したい • ※成熟度モデルに従うだけでは十分ではないはず ◦ 公開されている成熟度モデルの内容は微妙に異なる ◦ 組織/プロダクトの課題と結びつけて考えることが大事
33. (1) テレメトリーの優先度 33 SLI/SLOに関連するテレメトリーを優先度高く計装する • テレメトリーを計装して有用なことをしたい ◦ 有用である=ユーザーのためになる • SLI/SLOに紐づくCUJをユーザーが達成できているか 表現するテレメトリーは必要になる
34. (1) テレメトリーの優先度 34 o11yの改善においては、定期的な分析・評価が重要 • その時の組織/プロダクトが向き合っている課題によって 優先度は変わる • 分析・評価の場としてはPWG、エンジニア会がある ◦ PWG：最近のパフォーマンス状況やインフラ構成の変更を 確認・共有する会 ◦ エンジニア会：プロダクトに関する技術的課題を取り上げ、 議論する会
35. (2) テレメトリーの信頼性 35 テレメトリーの生成・取得に対する信頼性 • 🧐自前のテレメトリーは正しく収集・送信できている? • 例)ログをメトリクスに変換するケース ◦ ログの欠損がメトリクスの数値に波及する ◦ 変換処理の失敗は、メトリクスでの定点観測、アラートの 信頼性にも影響してくる
36. (2) テレメトリーの信頼性 36 テレメトリーの生成・取得に対する信頼性 • 監視系のコンポーネントが処理失敗したら、メトリクス が投稿されなくなるので最低限の監視は必須 ◦ メトリクス投稿用のLambdaに対する監視 ◦ 生成したメトリクス自体の監視 ◦ OpenTelemetry Collectorの監視(New!)
37. (2) テレメトリーの信頼性 37 テレメトリーの生成・取得に対する信頼性 • 計装の観点ではライブラリの仕様にも注意して実装 ◦ zap/FAQ.md at master · uber-go/zap ◦ >Logs are dropped intentionally by zap when sampling is enabled. The production configuration (as returned by NewProductionConfig() enables sampling…
38. まとめ 38 • 検知の改善 ◦ サービスの状態を表すメトリクスの実装とアラーティング • 調査の改善 ◦ 各テレメトリー間の相関を踏まえたドリルダウン的な分析 • テレメトリーの優先度 ◦ o11y成熟度モデル、SLI/SLOを考慮した継続的な優先度評価 • テレメトリーの信頼性 ◦ 監視系のコンポーネント、計装用のライブラリに目を向ける