Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

REL06-BP06 モニタリングの範囲とメトリクスを定期的に確認する - AWS Well-Architected フレームワーク

REL06-BP06 モニタリングの範囲とメトリクスを定期的に確認する

ワークロードモニタリングの実装方法を頻繁に確認し、ワークロードとそのアーキテクチャの進化に合わせて更新します。モニタリングの定期的な監査は、障害インジケータの見逃しや見落としのリスクを低減し、ワークロードが可用性の目標を達成するのに役立ちます。

効果的なモニタリングは主要なビジネスメトリクスに根ざしており、ビジネスの優先順位が変化するにつれて進化します。監視レビュープロセスでは、サービスレベルインジケーター (SLI) を重視し、インフラストラクチャ、アプリケーション、クライアント、ユーザーからのインサイトを取り入れる必要があります。

期待される成果: 効果的なモニタリング戦略があり、重要なイベントや変更の後だけでなく、定期的にレビューおよび更新されます。ワークロードとビジネス要件が進化しても、主要なアプリケーションヘルスインジケータが依然として適切であることを確認します。

一般的なアンチパターン:

  • デフォルトのメトリクスのみを収集している。

  • モニタリング戦略は設定するが、確認することはない。

  • 主要な変更がデプロイされる際に、モニタリングについて話し合わない。

  • 古いメトリクスを信頼して、ワークロードの状態を判断している。

  • 運用チームは、古いメトリクスとしきい値が原因で誤検出アラートの対処に追われている。

  • モニタリングされていないアプリケーションコンポーネントのオブザーバビリティが不足している。

  • モニタリングでは低レベルの技術メトリクスのみに焦点を当て、ビジネスメトリクスを除外している。

このベストプラクティスを活用するメリット: モニタリングを定期的に確認すると、潜在的な問題を予測し、それらを検出できることを確認できます。また、以前のレビューで見逃した可能性のある死角を発見できるため、問題を検出する能力がさらに向上します。

このベストプラクティスを活用しない場合のリスクレベル:

実装のガイダンス

運用準備状況レビュー (ORR) プロセス中にモニタリングメトリクスと範囲を確認します。一貫したスケジュールで定期的な運用準備状況レビューを実行して、現在のワークロードと設定したモニタリングの間にギャップがあるかどうかを評価します。運用パフォーマンスのレビューと知識の共有を定期的に行うことで、運用チームのパフォーマンスを向上させることができます。既存のアラートのしきい値がまだ適切かどうかを検証し、運用チームが誤検出アラートを受信している状況や、モニタリングすべきアプリケーションのモニタリングされていない状況を確認します。

耐障害性分析フレームワークは、プロセスの進行に役立つガイダンスを提供します。フレームワークの焦点は、潜在的な障害モードと、その影響を軽減するために使用できる予防および修正コントロールを特定することです。この知識は、モニタリングとアラートを行う適切なメトリクスとイベントを特定するのに役立ちます。

実装手順

  1. ワークロードダッシュボードの定期的なレビューをスケジュールし、実施します。検査する深度に応じて異なる頻度にすることができます。

  2. メトリクスの傾向を検査します。メトリクス値と履歴値を比較して、調査が必要なものを示唆している可能性がある傾向があるかどうかを確認します。これには、レイテンシーの増加、主要なビジネス機能の減少、失敗レスポンスの増加などがあります。

  3. メトリクスの外れ値や異常を検査します。これは平均または中央値でマスキングできます。時間枠内の最高値と最低値を調べ、通常の境界をはるかに超えている観測結果の原因を調査します。これらの原因を引き続き削除すると、ワークロードパフォーマンスの一貫性の向上に応じて、期待されるメトリクスの境界を絞ることができます。

  4. 行動の急変を探します。メトリクスの数量または方向性の突然の変化は、アプリケーションに変更があったこと、または追跡するためにさらなるメトリクスを追加する必要がある外部要因があることを示唆している可能性があります。

  5. 現在のモニタリング戦略に、引き続きアプリケーションとの関連性があるかどうかを確認します。以前のインシデントの分析 (または耐障害性分析フレームワーク) に基づいて、モニタリングスコープに組み込む必要があるアプリケーションの追加の側面があるかどうかを評価します。

  6. リアルユーザーモニタリング (RUM) メトリクスを確認して、アプリケーション機能のカバレッジにギャップがないかどうかを確認します。

  7. 変更管理プロセスをレビューします。必要に応じて手順を更新し、変更を承認する前に実行する必要があるモニタリング分析ステップを含めます。

  8. 運用準備状況の確認とエラープロセスの修正の一環として、モニタリングレビューを実装します。

リソース

関連するベストプラクティス:

関連ドキュメント:

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.