REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する - 信頼性の柱
実装のガイダンス リソース

REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する

ワークロードの状態を継続的にモニタリングすることで、お客様と自動化システムが障害やパフォーマンスの低下の発生を速やかに把握できるようにします。ビジネス価値に基づいて主要業績評価指標 (KPI) をモニタリングします。

復旧および修復メカニズムはすべて、問題を迅速に検出する機能から開始する必要があります。技術的な障害を最初に検出して、解決できるようにするのです。ただし、可用性はワークロードがビジネス価値を提供する能力に基づいているため、これを測定する主要業績評価指標 (KPI) が検出および修正戦略の一部である必要があります。

期待される成果: ワークロードの重要なコンポーネントは個別にモニタリングされ、障害が発生したタイミングと場所で障害を検出してアラートを出します。

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

  • アラームが設定されていないため、停止は通知なしで発生する。

  • アラームは存在しますが、そのしきい値では対応するために十分な時間がない。

  • メトリクスは、目標復旧時間 (RTO) を満たすのに十分な頻度で収集されない。

  • ワークロードの顧客向けインターフェイスのみがアクティブにモニタリングされる。

  • 技術的なメトリクスのみ収集し、ビジネス関数のメトリクスは収集しない。

  • ワークロードのユーザーエクスペリエンスを測定するメトリクスがない。

  • 作成されたモニターが多すぎる。

このベストプラクティスを活用するメリット: すべてのレイヤーで適切なモニタリングを行うことで、検出までの時間を短縮して、復旧時間を短縮できます。

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

実装のガイダンス

モニタリングの対象となるすべてのワークロードを特定します。モニタリングする必要があるワークロードのすべてのコンポーネントを特定したら、次はモニタリングの間隔を決定します。モニタリングの間隔は、障害の検出にかかる時間に基づいた復旧を開始する速さに直接影響します。平均検出時間 (MTTD) は、障害が発生してから修理作業が開始されるまでの時間です。サービスのリストは広範囲かつ完全でなければなりません。

モニタリングは、アプリケーション、プラットフォーム、インフラストラクチャ、ネットワークを含むアプリケーションスタックのすべてのレイヤーを対象とする必要があります。

モニタリング戦略では、 グレー障害の影響を考慮する必要があります。グレー障害の詳細については、Advanced Multi-AZ Resiliance Patterns whitepaper (高度なマルチ AZ 回復性パターンについてのホワイトペーパー) の グレー障害 を参照してください。

実装手順

  • モニタリング間隔は、どの程度迅速に復旧する必要があるかによって異なります。復旧時間は復旧にかかる時間によって決まるため、この時間と目標復旧時間 (RTO) を考慮して、収集の頻度を決定する必要があります。

  • コンポーネントとマネージドサービスの詳細なモニタリングを設定します。

    • EC2 インスタンスの詳細モニタリング と Auto Scaling が必要かどうかを判断します。詳細モニタリングは 1 分間隔メトリクスを提供し、デフォルトのモニタリングは 5 分間隔メトリクスを提供します。

    • EC2 拡張モニタリング が必要かどうかを判断します。拡張モニタリングでは、RDS インスタンスのエージェントを使用して、さまざまなプロセスまたはスレッドに関する有益な情報を取得します。

    • 以下における重要なサーバーレスコンポーネントのモニタリング要件を決定します。 Lambda、 API Gateway、 Amazon EKS、 Amazon ECS、およびすべてのタイプの ロードバランサー。

    • 以下におけるストレージコンポーネントのモニタリング要件を決定します。 Amazon S3、 Amazon FSx、 Amazon EFS、 Amazon EBS。

  • ビジネス主要業績評価指標 (KPI) を測定する カスタムメトリクス を作成します。ワークロードには主要なビジネス機能が実装されており、いつ間接的な問題が発生したのかを特定するのに役立つ KPI として使用される必要があります。

  • ユーザー Canary を使用して、障害に対するユーザーエクスペリエンスをモニタリングします。 合成トランザクションテスト (「Canary テスト」とも呼ばれますが、Canary デプロイとは異なります) は、最も重要なテストプロセスの 1 つです。さまざまなリモートロケーションからワークロードエンドポイントに対してこれらのテストを常に実行します。

  • ユーザーエクスペリエンスを追跡する カスタムメトリクスを 作成します。顧客のエクスペリエンスを測定できる場合は、コンシューマーエクスペリエンスが低下するタイミングを判断できます。

  • アラームを設定 し、ワークロードの一部が正常に動作していないことを検出して、リソースを自動的にスケールするタイミングを示します。アラームをダッシュボードに視覚的に表示したり、Amazon SNS または E メールでアラートを送信したり、Auto Scaling と連携してワークロードリソースをスケールアップ/スケールダウンしたりできます。

  • メトリクスを視覚化する ダッシュボード を作成します。ダッシュボードは、傾向や異常値などの潜在的な問題の指標を視覚的に確認したり、調査対象となり得る問題の存在を示すために使用できます。

  • サービスに 分散型トレースモニタリング を作成します。分散型モニタリングにより、アプリケーションと基盤となるサービスがどのように動作しているかを理解して、パフォーマンスの問題やエラーの根本原因を特定し、トラブルシューティングすることができます。

  • 別のリージョンとアカウントでモニタリングシステム ( CloudWatch または X-Rayを使用) ダッシュボードとデータ収集を作成します。

  • Amazon Health Aware モニタリング を統合することで、パフォーマンスの低下の可能性がある AWS リソースをモニタリングする可視性を得られます。ビジネスに不可欠なワークロードの場合、このソリューションによって、AWS サービスに対するプロアクティブでリアルタイムのアラートへのアクセスが可能になります。

リソース

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

関連するドキュメント:

関連動画:

関連する例:

関連ツール: