2024年4月25日、春の Observability 祭り 2024 Observability獲得までの旅に参加してきました。発表セッションの中から、2つセッション取り上げてレポートをまとめたいと思います。取り上げた2つのセッションはObservabilityを獲得して成熟していく方針や、ベストプラクティスの紹介をしています。今回は自分自身の実務での取り組みと比較したり、感想をはさみながらまとめたいと思います。
当日の資料はこちらで公開されています。
Observabilityジャーニーの全体像
アマゾン ウェブ サービス ジャパン 合同会社
ソリューションアーキテクト
津郷 光明 氏
Stage1 : 基本的なモニタリング(テレメトリデータの収集)
このステージでは、現状を把握し、改善のための現実的な目標を設定する。 Observabilityに取り組む目的を整理して、必要なテレメトリデータの収集を行う。 最初のステップとして、SLI/SLOの検討・策定を行い、必要なテレメトリデータの収集を進めるとよい。
テレメトリは、顧客体験の向上につながるように、レスポンスタイム、リクエスト成功率、エラー率など、ユーザーに近いテレメトリデータを取得するとよい。Synthetic MonitoringやReal User Monitoringを実施することを推奨。
Maturity Modelの資料には、最初のステージで以下のように取り組むとよいと書かれている。
(組織内の各チームは)取得したデータを使用して自分たちが必要としているものを最適化しようとします。また、別のチームから取得したデータは形式が異なる可能性があるため、チーム間でデータを共有できません。
重要なワークロードを特定する計画を立て、オブザーバビリティの統一ソリューションを目指し、メトリクスとログを定義することが、このレベルの重要な側面です。(「Maturity Model」より抜粋)
感想 : 実務でもObservabilityに取り組む最初のステップとして、メトリクスの選定から取り組み始めたことを思い出しました。システム上で取得でき、ユーザーの体験に近い意味のあるメトリクスを選び、SLI/SLOを決めるところから始め、それがステージ1に該当すると思いました。
Stage2 : 中級レベルのモニタリング(テレメトリの分析とインサイト)
このステージでは、テレメトリデータを収集するプロセスを明確に定義。分析や問題のデバッグに多くの時間を費やすことがある。次のステージに進むためには、ポリシーを決め実践する。実行可能なKPI(重要業績評価指標)を定めるとよい。
システムアーキテクチャの設計を定期的にレビューし、インパクトやダウンタイムを減らし、アラートを削減するためのポリシーやプラクティスを導入する。
アクション可能なKPIを定義し、アラート結果に価値のあるコンテキストを追加、重要度/緊急度で分類し、エンジニアがより速く問題を解決できるように異なるツールとチームに送信することでアラート疲労を防ぐ。(「Maturity Model」より抜粋)
感想 : このステージ2の話を聞いて、アラートレベルをCriticalかWarningかInformationであるかを定義し、閾値のチューニング、通知先グループを決める業務経験を思い出しました。
Stage3 : 高度なオブザーバビリティ(相関関係と異常検知)
このステージでは、他の重要なシステムを統合。AI/MLツールを使用して運用を自動化する。
適切なチームは、問題を解決する修正を提供することで、すぐに修正措置を講じることができます。このシナリオでは、MTTR は非常に小さく、サービスレベル目標 (SLO) はグリーンであり、エラーバジェットを通じたバーンレートは許容できるものです。
(次のステージに進むには)過去に収集されたデータを使用してトレーニングされたモデルに基づいて、シグナルを自動的に相関付け、根本原因を特定し、解決計画を作成する人工知能 for IT 運用(AIOps) を利用できます。(「Maturity Model」より抜粋)
AIOpsを行うAWSサービスも紹介された。(以下の画像の赤枠で表示
Stage4 : 予測的オブザーバビリティ(自動かつ予想的な根本原因の特定)
最後のステージでは、AI/MLによる根本原因の特定や、自動復旧に向けた仕組み作りを目指す。
ここでは、オブザーバビリティデータは問題が発生した「後」にのみ使用されるのではなく、問題が発生する「前」のリアルタイムでもデータを活用します。 適切にトレーニングされたモデルを使用することで、問題の特定が予測的に行われ、解決がより簡単に達成されます。
収集したシグナルを分析することで、モニタリングシステムは問題の洞察を自動的に提供し、問題を解決するための解決策を提示できます。(「Maturity Model」より抜粋)
感想 : ステージ3,4は以前の実務では取り組めなかったステージです。このステージまで進めるのはハードルが高そうです。(セッションの中で、ステージ4まで取り組めている顧客は多くないという話もありました。)
AWS Observability ベストプラクティス
アマゾン ウェブ サービス ジャパン 合同会社
テクニカルアカウントマネージャ
日平 大樹 氏
AWS で Observability を実装する上でのベストプラクティスガイドである AWS Observability Best Practicesを紹介。5つのベストプラクティスの概要と、カテゴリ別の概要を紹介。
ベストプラクティスガイドはGitHubで公開されていて、アマゾン ウェブ サービス ジャパン 合同会社の社員で運用されている。ガイドの内容に貢献したり、コミュニティから提案を求めたりしたい場合は、GitHubのDiscussionsを利用する。
ログ
メトリクス
トレース
イベント
アラーム
感想 : 自分自身の経験と比較すると、以下のような活動が当てはまると思いました。
ログ : apacheのログからレスポンスタイムを取得して、メトリクスデータとして閾値を設定することは経験があったことを思い出しました。ログのパターンを定義して、ログを読み取るパースの設定や、監視文字列の抽出も行ったことがありました。
メトリクス : アラートを通知するための、異常検知のアルゴリズム利用は課題として取り組むことはできていませんでした。一定期間チューニングの期間を設けて、期間中の振る舞いから閾値を設定する方法でチューニングを行ったことはありました。
トレース : アプリケーションにトレース用のエージェントをインストールし、トレースデータを取得したことがありました。検証環境、本番環境のように環境を分けて集計することが必須であったため、環境のラベル付けが重要でした。
アラート : ダウンタイムの設定や、アラートレベルの設定、通知先グループの設定などを定義したことがありました。
感想 : 今後監視する対象のシステムに合わせて必要に応じて参照したいと思います。
今回は6つのセッションの中から2つのセッションを取り上げて参加レポートにまとめました。今回取り上げなかった4つのセッションでは、Observabilityに関するAmazon CloudWatch関連サービスの紹介、AWS X-Ray、Amazon DevOps Guruの紹介がありました。また、Amazon CloudWatch Syntheticsの実演を交えた紹介もあり、Observabilityを獲得するための第一歩になると説明がありました。Observabilityの最新アップデート情報の紹介もありました。
参加者からAL/MLの可能性について質問があり、「AI/MLは人のサポートツールの位置づけで、発砲まではよいが自動復旧は難しい。」「生成AIによる予測ができる日が来るまでに今できることとしてはデータをためておくことが大事。」という回答があり、会場内でのAI/MLへの関心の高さを感じました。
Maturity Modelやベストプラクティスでは、Observabilityに取り組むときの目指すべき状態やロードマップ が示され、有効なAWSサービスの紹介もありました。当日の発表内容も後日資料が公開され、このレポートも資料を見返しながらまとめています。
以前携わった実務では、AWS上のシステムに対してDatadogを利用してObservabilityの確保を進めていましたが、今回のセッションではAWS上の多くのサービスでも実現できることを知ることができました。Maturity Modelやベストプラクティスの話を以前の業務経験と比較すると、メトリクスの選定やアラート集約など、取り組めていた点もあれば、AI/MLを利用した予測など、取り組めていない点もあり、当時の活動の成熟度や課題も見つかりました。今後、監視や運用の設計に携わる機会があれば、セッションを思い出して業務を行おうと思います。