REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)
ワークロードのコンポーネントは、Amazon CloudWatch またはサードパーティー製ツールを使用してモニタリングします。AWS サービスを AWS Health ダッシュボードでモニタリングします。
フロントエンド、ビジネスロジック、ストレージ層など、ワークロードのすべてのコンポーネントをモニタリングする必要があります。主要なメトリクスと、必要に応じてそれをログから抽出する方法を定義し、対応するアラームイベントを起動させるためのしきい値を設定します。メトリクスがワークロードの重要業績評価指標 (KPI) に関連していることを確認し、メトリクスとログを使用して、サービス低下の早期警告サインを識別します。例えば、1 分間に正常に処理されたオーダー数など、ビジネス成果に関するメトリクスは、CPU 使用率などの技術的メトリクスより早く、ワークロード問題を示すことができます。AWS Health ダッシュボードは、AWS リソースの基盤となる AWS のサービスのパフォーマンスと可用性をパーソナライズして表示するために使用します。
クラウドでのモニタリングは新しい機会をもたらします。ほとんどのクラウドプロバイダーは、カスタマイズ可能なフックを開発して、ワークロードの複数のレイヤーをモニタリングする際に役立つインサイトを提供しています。Amazon CloudWatch などの AWS サービスは、統計的な機械学習アルゴリズムを応用して、システムとアプリケーションのメトリクスを継続的に分析し、正常なベースラインを決定し、最小限のユーザー介入で異常を表面化します。異常検出アルゴリズムでは、メトリクスの季節変動とトレンドの変化が考慮されます。
AWS では、豊富なモニタリングおよびログ情報を公開しており、これらを使用して、ワークロード固有のメトリクスと需要変化プロセスを定義し、機械学習の知識に関わらず、機械学習技法を適応させることができます。
さらに、すべての外部エンドポイントをモニタリングし、それらがベースとなる実装から独立していることを確認します。このアクティブモニタリングは、合成トランザクション ( ユーザーカナリアと呼ばれることもありますが、canary デプロイと混同しないでください) で行うことができます。これは、ワークロードのクライアントによって実行されるアクションに相当する多数の一般的タスクを定期的に実行するというものです。これらのタスクは、短期間に保ち、テスト中にワークロードに負荷をかけすぎないようにしてください。Amazon CloudWatch Synthetics を使用すると、 Synthetics Canary を作成して、 エンドポイントと API をモニタリングできます。合成 Canary クライアントノードと AWS X-Ray コンソールを組み合わせて、選択した期間中にエラー、障害、スロットリング率で問題が発生している合成 Canary を特定することもできます。
期待される成果:
ワークロードのすべてのコンポーネントから重要なメトリクスを収集して使用し、ワークロードの信頼性と最適なユーザーエクスペリエンスを確保します。ワークロードがビジネス成果を達成していないことを検出した場合は、障害を迅速に宣言して、インシデントから復旧できます。
一般的なアンチパターン:
-
ワークロードへの外部インターフェイスのみをモニタリングする。
-
ワークロード固有のメトリクスを生成せず、ワークロードが使用している AWS から提供されるメトリクスにのみ依存する。
-
ワークロードの技術的メトリクスを使用するだけで、ワークロードが貢献する非技術的な KPI に関するメトリクスをモニタリングしない。
-
本番トラフィックとシンプルなヘルスチェックに依存して、ワークロード状態をモニタリングし、評価する。
このベストプラクティスを確立するメリット: ワークロードのすべての階層でモニタリングすることで、ワークロードを構成するコンポーネントの問題をより迅速に予測し、解決できます。
このベストプラクティスが確立されていない場合のリスクレベル: 高
実装のガイダンス
-
可能な限りログを有効にします。 ワークロードのすべてのコンポーネントからモニタリングデータを取得する必要があります。S3 Access Logs など、追加のロギングをオンにして、ワークロードがワークロード固有のデータをログに記録できるようにします。Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling、Amazon EMR などのサービスから、CPU、ネットワーク I/O、およびディスク I/O の平均に関するメトリクスを収集します。把握 CloudWatch メトリクスを発行する AWS のサービス で、CloudWatch にメトリクスを発行する AWS のサービスのリストを確認できます。
-
デフォルトのメトリクスをすべてレビューし、データ収集にギャップがないか確認します。 すべてのサービスはデフォルトのメトリクスを生成します。デフォルトのメトリクスを収集することで、ワークロードのコンポーネント間の依存関係と、コンポーネントの信頼性とパフォーマンスがワークロードに及ぼす影響をより深く理解できます。また、独自のメトリクスを 作成して、 AWS CLI または API を使用して CloudWatch に発行することもできます。 *** please leave this segment blank since the source does not make any sense in context ***
-
すべてのメトリクスを評価して、ワークロード内の各 AWS サービスに対してどのメトリクスでアラートを出すかを決定します。 ワークロードの信頼性に大きな影響を持つメトリクスのサブセットを選択することもできます。重要なメトリクスとしきい値に焦点を当てることで、 アラート の数を絞り込み、偽陽性を最小化できます。
-
アラートを定義し、アラートが起動された後のワークロードの復旧プロセスを定義します。 アラートを定義することで、通知とエスカレーションを迅速に行い、インシデントからの復旧に必要なステップに従い、所定の目標復旧時間 (RTO) を満たすことができます。専用のインフラストラクチャで Amazon CloudWatch アラーム を使用すると、定義されたしきい値に基づいて自動ワークフローを起動し、回復手順を開始することができます。
-
合成トランザクションを使用して、ワークロードの状態に関する関連データを収集することを検討しましょう。 合成モニタリングは、顧客と同じルートに従って同じアクションを実行するため、ワークロードに顧客のトラフィックがない場合でも、継続的にカスタマーエクスペリエンスを検証することが可能になります。また、 合成トランザクションを使用することで、顧客より先に問題を発見できます。
リソース
関連するベストプラクティス:
関連するドキュメント:
-
ユーザーガイド:
関連ブログ:
関連する例とワークショップ:
