こんにちは、muroです。AWS事業本部 サービス開発室でopswitchの開発・運用を担当しています。24/365のサービス運用では、サービスの監視と自動回復の仕組みが欠かせません。opswitchでは長年の運用経験から、これらの仕組みを実装してきましたが、まだまだ改善の余地があると考えています。ちょうどこのテーマのre:Invent 2023 セッション動画を見つけたのでご紹介します。
セッション動画
セッション概要
タイトル
Building observability to increase resiliency
概要
Using observability effectively is essential for proving your resilient system operates the way you planned. Well-applied observability helps you find early signs of problems, before they impact customers, and react quickly to mitigate impact. In this session, learn how you can use observability best practices to improve your resilience posture in AWS. Dive deep into real-world failure modes, and see how you can use the right combination of instrumentation and observability tools to solve them quickly. This session includes a demo of these techniques and practices using AWS services like Amazon CloudWatch and AWS X-Ray.
可観測性を効果的に使用することは、回復力のあるシステムが計画どおりに動作することを証明するために不可欠です。 適切に適用された可観測性は、顧客に影響を与える前に問題の初期の兆候を発見し、影響を軽減するために迅速に対応するのに役立ちます。 このセッションでは、可観測性のベストプラクティスを使用して AWS の復元体制を改善する方法を学びます。 実際の障害モードを深く掘り下げ、インスツルメンテーションと可観測性ツールの適切な組み合わせを使用して障害を迅速に解決する方法を確認します。 このセッションには、Amazon CloudWatch や AWS X-Ray などの AWS のサービスを使用したこれらのテクニックと実践のデモが含まれています。
スピーカー
David Yanacek
レベル
300 上級
利用するAWSサービス
Amazon CloudWatch, AWS X-Ray
セッションの要約
問題を診断する
WEBサービスには様々な問題が発生しますが、その正常性メトリクスは顧客のユースケースごとに個別の次元に分割します。さらに、アラーム疲れを避けるために、Amazon CloudWatchの複合アラーム（composite alarm）を利用します。
次に、問題が起きていることがわかったら、その依存関係を調べる必要があります。AWS X-Rayを利用して、全てのAWSサービス及びアプリケーションをトレースし、サービスマップで依存関係を見つけられるようにします。
さて、大規模分散サービスでは、顧客のユースケースごとに個別の次元に分割するだけでは問題の特定が困難です。各アベイラビリティゾーンやインスタンスごとといったインフラストラクチャ別に正常性メトリクスの次元を分割します。CloudWatch Metrics Insights のクエリを利用して、パフォーマンスが低い箇所を特定します。
続いて変更管理についてです。新しいアプリケーションをデプロイし問題が発生した後、自動でロールバックさせることができれば、問題が起きている時間を短くすることができます。Cloud Formationの自動ロールバックが有効です。またコードリビジョン別にメトリクスを分割してアラームを設定すれば、問題が起きている時間をさらに短縮できるでしょう。
また、事前にメトリクスを設定していないケース、例えばトラフィックが急増したというような場合では、詳細に出力されたアプリケーションログの上位の結果を Contributor Insights で分析し、logs insighs クエリを書いてメトリクスを作成することができます。
隠れた問題を明らかにする
互換性のないコンポーネントを誤ってデプロイしてしまった場合やインフラストラクチャの移行に失敗した場合は、どのような問題がおきるか分かりません。そのような場合に備えて Synthetic Monitoring を利用して実際のエンドユーザーよりも早くサービスの問題を検出することができます。
また、例えば顧客からの入力値に対するバリデーションのバグをリリースしてしまった場合、エラー率の上昇を検知できますが、バグが原因かどうか判別できません。しかし多くの顧客が同時にエラーを起こす場合はバグが原因であると推測できます。Contributor Insights を利用してエラーになったリクエストの割合ではなく、エラーになった顧客の割合をメトリクスとして設定します。
将来の問題を防ぐ
AWSのサービスは高い弾力性を備えています。将来の問題を防ぐために自動スケーリングを設定します。また全てのリソースの使用率（CPU、スレッドプール、クォータ等）にアラームを設定し、キャパシティダッシュボードを作成してモニタリングすることを推奨します。
最後に、AWS Fault Injection Service(AWS FIS)を利用して、本番環境と同様の環境に対して定期的にテストを実施しましょう。そのためにはアラームやダッシュボード定義をコードとして管理しておく必要があります。
セッションを受講してみて
ストーリー仕立てになっており、様々なAWSの監視ツールのユースケースをわずか1時間でキャッチアップできる素晴らしい内容のセッションでした。opswitchでもメトリクス、アラーム、ダッシュボードを利用したり、自動スケーリングや自動フェイルオーバーを設定したりしていますが、各種Insights機能は使いこなせてはいませんでした。また、隠れた問題や将来の問題の備えに関しても有益な示唆を得ることができました。この知見をサービス運用の改善に活かしていこうと思います。
なお、AWSの監視ツールについては、公式のワークショップから学ぶこともできます。こちらもご参考にどうぞ。
3
