はじめに
2024年4月25日、春の Observability 祭り 2024 Observability獲得までの旅に参加してきました。発表セッションの中から、2つセッション取り上げてレポートをまとめたいと思います。取り上げた2つのセッションはObservabilityを獲得して成熟していく方針や、ベストプラクティスの紹介をしています。今回は自分自身の実務での取り組みと比較したり、感想をはさみながらまとめたいと思います。
当日の資料はこちらで公開されています。
セッション1
Observabilityジャーニーの全体像
スピーカー
アマゾン ウェブ サービス ジャパン 合同会社
ソリューションアーキテクト
津郷 光明 氏
セッションレポート
AWS Observability Maturity Modelの概要紹介
- このセッションではAWS Observability Maturity Modelの概要を説明し、以下の画像のように、4つの成熟度のステージとその内容を紹介した。
- AWS Observability Maturity Model(以下 「Maturity Model」と記載)とは、企業が現在の能力を評価し、改善の余地がある分野を特定し、最適なオブザーバビリティを実現するために戦略的に正しいツールとプロセスに投資するための包括的なロードマップを提供する。(Maturity Model より抜粋)
各ステージの紹介
-
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まで取り組めている顧客は多くないという話もありました。)
その他、セッション1のまとめ
- 最初のステップはデータの取得であり、Amazon CloudWatch / AWS X-rayが最初の選択肢になる
- AI/MLを利用して自動化を目指す
- 実装以外にも、ドキュメント作成、プロセス定義、文化の醸成などの取り組みが必要
- 現在の状況を理解し定期的に振り返り、継続的に改善することが大切
セッション2
AWS Observability ベストプラクティス
スピーカー
アマゾン ウェブ サービス ジャパン 合同会社
テクニカルアカウントマネージャ
日平 大樹 氏
セッションレポート
AWS Observabilityベストプラクティスの紹介
AWS で Observability を実装する上でのベストプラクティスガイドである AWS Observability Best Practicesを紹介。5つのベストプラクティスの概要と、カテゴリ別の概要を紹介。
ベストプラクティスガイドはGitHubで公開されていて、アマゾン ウェブ サービス ジャパン 合同会社の社員で運用されている。ガイドの内容に貢献したり、コミュニティから提案を求めたりしたい場合は、GitHubのDiscussionsを利用する。
ベストプラクティスの概要
- 重要なものから監視する
- 重要なトップレベルのKPIを特定し、追跡し測定する自動化された方法を用意する。
- 適切なツールを選択する
- 共通のツールを使用する。車輪の再開発は避ける。異常検知、自動化、機械学習が不可欠。
- すべてのティアからテレメトリを収集する
- ワークロード全体のビューを持つ。コンポーネント間のインテグレーションに焦点を当てる。エンドユーザー体験を忘れない。
- ささいなことにはこだわたない
- アプリケーション規模によってシグナルが多くなり、費用対効果が薄れることがある。重要なものをモニタリングすることから始める。
- Day Oneから取り入れる。
- 開発サイクルの後半ではなく、早い段階でObservabilityを取り入れる。
ベストプラクティスガイドのカテゴリ
- データタイプ
-
ログ
- 構造化ログを利用し、ログレベルを適切に扱う。
- できる限りソース近くでフィルタリングを行い、2重の取り込みは行わない。
- ログからメトリクスデータを収集すること。
- 可能であればstdoutにログを出力すること。
-
メトリクス
- KPIを知り測定し、運用メトリクスと相関付ける。
- 正常な状態がどういう状態か理解する。
- 異常検知アルゴリズムを利用し適切な閾値を計算する。
-
トレース
- サービス間の接続を中央のコレクターにトレースを送信するようにインスツルメンテーションする。インスツルメンテーションは広い意味でコードを利用してアプリケーション内のイベントを測定すること。エージェントやライブラリを使用するとことで自動化が可能。
- トランザクションの時間とレスポンスコードを測定することが重要。
- メタデータ、アノテーション、ラベルを利用する。
-
イベント
- 重要なメトリクスデータとともにイベントを可視化することで、イベントと運用メトリクスを相関付けることが可能
- どのようなアクションをとるべきかを理解する。
- インシデント管理/チケット/ITSMツールと統合し、問題となるパターンを理解する。
-
アラーム
- アクション可能なものに対してアラートする。
- オペレータが絶え間ないアラートに慣れてしまい、突然静かになったときにだけ気づくパターンは危険な運用。
- アラートの集約によりアラーム疲れを緩和する。集約の結果、理解しやすくなり手順書や自動化の作成が容易になる。
- 既存のITSMとサポートプロセスを利用し、トラブルチケットとイシューを作成する。人為的な作業を削減し、プロセスを合理化する。
感想 : 自分自身の経験と比較すると、以下のような活動が当てはまると思いました。
-
ログ : apacheのログからレスポンスタイムを取得して、メトリクスデータとして閾値を設定することは経験があったことを思い出しました。ログのパターンを定義して、ログを読み取るパースの設定や、監視文字列の抽出も行ったことがありました。
-
メトリクス : アラートを通知するための、異常検知のアルゴリズム利用は課題として取り組むことはできていませんでした。一定期間チューニングの期間を設けて、期間中の振る舞いから閾値を設定する方法でチューニングを行ったことはありました。
-
トレース : アプリケーションにトレース用のエージェントをインストールし、トレースデータを取得したことがありました。検証環境、本番環境のように環境を分けて集計することが必須であったため、環境のラベル付けが重要でした。
-
アラート : ダウンタイムの設定や、アラートレベルの設定、通知先グループの設定などを定義したことがありました。
- ソリューションベストプラクティス
- ダッシュボード、データベース、コンテナなどのソリューションごとのベストプラクティスを紹介
- データベース、EC2、ECS、EKS、サーバレスのオブザーバビリティ
- ハイブリッド&マルチクラウド環境のオブザーバビリティなど
- ツール
- オブザーバビリティツールのベストプラクティスについて記載(他のベンダー製品にも適用可能
- レシピ
- Amazon Managed Service for PrometheusやAmazon Managed Grafanaといったマネージドサービス、OpenTelemetryやFluent Bitといったエージェントなど、さまざまなユースケースに対するオブザーバビリティの適用に役立つ、厳選されたガイダンス、ハウツー、その他のリソースへのリンク集
感想 : 今後監視する対象のシステムに合わせて必要に応じて参照したいと思います。
まとめ
今回は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を利用した予測など、取り組めていない点もあり、当時の活動の成熟度や課題も見つかりました。今後、監視や運用の設計に携わる機会があれば、セッションを思い出して業務を行おうと思います。
