こんにちは、AWS Jr. Championsの伊藤です！
概要
re:Invent 2024にて、オブザーバビリティのベストプラクティスというタイトルのチョークトーク(※)に参加してきましたのでその内容についてご紹介します！
(※チョークトーク：スピーカーと少人数の参加者による対話形式)
普段、インフラエンジニアとして、基盤の構築や運用設計まで携わる部分が多く、今日でもホットなワードであるオブザーバビリティに着目しました！
本セッションでは、発表者と聴講者の対話形式のもと、オブザーバビリティと実現するためにはどのようにすればよいか、また継続的改善を進めるには、という話がありました。
オブザーバビリティとは？
オブザーバビリティとは、システムの内部状態を外部から得られるデータや情報（メトリクス、ログ、トレースなど）を通じて理解する能力を指します。モニタリングとは異なり、より広範囲のシステム状態を把握し、問題の特定や将来の予測が可能な点が重要となります。
いきなりですが、6つのベストプラクティス
セッションの序盤でいきなり結論が出ました。
- ビジネスからの逆算
- メトリクス、ログ、トレースの一元化と相関化
- 計測と監視の自動化
- フルスタックでオブザーバビリティの実現
- リアルタイムアラートおよびダッシュボードの実現
- 継続的改善の文化を育む
スポーツベッティングのシステムがあるとする。クライアントサイドでの監視ポイントは？
- ブラウザの種類、ChromeやFirefoxでエラーが多いのかどうかを見る必要性
- クライアントサイドで実行されているJavaScriptコードが原因でブラウザエラーが発生する可能性
- 例えばChromeのアップデートが実行されているために待ち時間が発生することもある
- ベッティングは年齢制限があるためID認証などの機能の必要性
- ユーザが適切に認証されていることの保証
- 非合法な地域については制限をかけその地域からのアクセスがないか
活用できるサービスは、Synthetics Canary、RUMなど
バックエンドでの監視ポイントは？
- バックエンドでは、ログ、メトリクス、トレースを活用して、インフラやアプリケーションの状態を詳細に追跡する
- CloudWatch Logsなどでログ収集をし、フロントエンドーバックエンド間の情報フローを確立
- 「Page Zero Metrics」は最重要のビジネス指標であり、これに基づいてほかのメトリクスを管理する
- 不必要なログやメトリクスは、ストレージや処理コスト削減のため削除する
- ログ・メトリクスの相関性を分析し、不要な部分をクリーンアップするプロセスを定期的に実行する
活用できるサービスは、CloudWatch Logs、X-Rayなど
インフラストラクチャでの監視ポイントは？
- リソースごとのメトリクス
- Insightsの活用（Lambda Insights / Container Insightsなど）（今回の構成だとLambdaやECSが使われている想定のため）
- RDSのデータベースメトリクス
- 複数のAWSアカウント間での監視の際には、集中管理アカウントの利用が推奨されるが、すべてのメトリクスを集める必要はない。ビジネスニーズに応じて必要なものを取得する
活用できるサービスは、各種リソースメトリクス、X-Rayなど
継続的改善を進めるには？
オブザーバビリティは単なる技術的な問題ではなくプロセスと人々が連携することで機能する。
継続的改善を進めるためには、メカニズムとして定期的なフィードバックループを作り、エラー分析や学びを次回に生かすことが重要
AWSでは、運用メトリクスを週次で収集し、問題があればその原因を特定し、修正するためのミーティングを行っている。
これにより、改善点を共有し、次回の運用に活かす文化が育まれている
運用メトリクスは以下の通り
- 定期的なケイデンスサイクル
- インシデント後の分析
- 非難なく5つのなぜなぜ
- エラー訂正
- 学びの共有
まとめ
今回オブザーバビリティのベストプラクティスについて学びました。
まずは、オブザーバビリティとは和訳すると可観測性ということで一言だとわかりにくいものなのですが、システムの内部状態を外部から得られるデータや情報を通じて”理解できる能力”のことと学びしっくり感じました。
メトリクスを取ることが目的ではなく、収集したメトリクスからシステムの状態を把握できることが重要だとわかりました。
また、同様に、メトリクスやアラートを収集したり設定したりするだけではなく、それらが本当に必要なのかを判断し、不要な場合にはクリーンアッププロセスを自動実行することも重要だということは、印象に残っています。
説明を受けるだけだと簡単なように思ってしまいますが、いざ実践しようとなるとビジネスニーズから運用設計に落とし込んで、メトリクス要否の定期実行プロセスを回して、インシデントが起こった際には、定例で原因分析と修正をして・・・などやることが盛りだくさんだと思いました・・・これを実践できているＡＷＳはすごい・・・