障害モード分析を実行するための推奨事項

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

このガイドでは、ワークロードの障害モード分析 (FMA) を実行するためのベスト プラクティスについて説明します。 FMA は、ワークロード内の潜在的な障害点と関連するフローを特定し、それに応じて軽減策のアクションを計画するプラクティスです。 フローの各ステップで、複数の障害の種類の影響範囲を特定します。これにより、新しいワークロードを設計したり、既存のワークロードをリファクタリングしたりして、障害の広範な影響を最小限に抑えることができます。

FMA の重要な原則は、回復性のレイヤー数をどれだけ適用しても障害は発生するということです。 より複雑な環境では、より多くの種類の障害が発生します。 この現実を踏まえると、FMA によって、ほとんどの種類の障害に耐え、障害が発生した場合に適切に復旧するワークロードを設計することができます。

FMA を完全にスキップしたり、不完全な分析を実行したりすると、ワークロードは、最適でない設計によって予期しない動作や潜在的な停止のリスクにさらされます。

定義

主要な設計戦略

フローを特定するための推奨事項を確認して実装します。 これは、重要度に基づいてユーザーとシステムのフローを特定し、優先順位を付けていることが前提となります。

収集したデータと作業で作成した成果物によって、フロー全体に関わるデータ パスの具体的な説明が得られます。 FMA の作業を成功させるには、成果物の正確性と徹底性が重要です。

重要なフローを決定したら、それに必要なコンポーネントを計画できます。 次に、各フローを段階的に確認して、サード パーティのサービスや潜在的な障害点などの依存関係を特定し、軽減策の戦略を計画します。

ワークロードを分解する

アイデアから設計に移行するときは、ワークロードをサポートするために必要なコンポーネントの種類を特定する必要があります。 ワークロードによって、計画する必要がある必要なコンポーネントが決まります。 通常、イングレス制御、ネットワーク、コンピューティング、データ、ストレージ、サポート サービス (認証、メッセージング、シークレットまたはキー管理など)、エグレス制御を計画する必要があります。 設計作業のこの段階では、導入する具体的なテクノロジがわからない可能性があるため、設計は次の例のようになります。

初期アーキテクチャ設計を作成した後、フローを重ね合わせて、それらのフローで使用される個別のコンポーネントを特定し、フローとそのコンポーネントを説明する一覧またはワークフロー図を作成できます。 コンポーネントの重要度を理解するには、フローに割り当てた重要度の定義を使用します。 コンポーネントの誤動作がフローに及ぼす影響を考慮します。

依存関係を識別する

ワークロードの依存関係を特定して、単一障害点分析を実行します。 ワークロードを分解してフローを重ね合わせることで、ワークロードの内部および外部の依存関係についての分析情報が得られます。

内部依存関係は、ワークロードが機能するために必要なワークロード スコープ内のコンポーネントです。 一般的な内部依存関係には、API、または Azure Key Vault などのシークレット/キー管理ソリューションが含まれます。 これらの依存関係については、可用性 SLA やスケーリング制限などの信頼性データを取り込みます。 外部依存関係は、別のアプリケーションやサード パーティ サービスなど、ワークロードのスコープ外にある必要なコンポーネントです。 一般的な外部依存関係には、Microsoft Entra ID などの認証ソリューションと、Azure ExpressRoute などのクラウド接続ソリューションが含まれます。

ワークロード内の依存関係を特定して文書化し、それらをフロー ドキュメント成果物に含めます。

障害点の評価

ワークロードの重要なフローで、各コンポーネントを検討し、そのコンポーネントとその依存関係が障害モードによってどのような影響を受けるかを判断します。 回復性と復旧を計画するときには、多くの障害モードを考慮する必要があることに注意してください。 どのコンポーネントでも、任意の時点で複数の障害モードの影響を受ける可能性があります。 これらの障害モードには次のようなものがあります。

• リージョンの停止。 Azure リージョン全体が使用できなくなります。

• 可用性ゾーンの停止。 Azure 可用性ゾーンが使用できなくなります。

• サービス停止。 1 つ以上の Azure サービスが使用できなくなります。

• 分散型サービス拒否 (DDoS) またはその他の悪意のある攻撃。

• アプリまたはコンポーネントの構成の誤り。

• オペレーター エラー。

• 計画メンテナンスの停止。

• コンポーネントの過負荷。

分析は常に、分析しようとしているフローのコンテキスト内で行う必要があるため、そのフローのユーザーへの影響と想定される結果を必ず文書化してください。 たとえば、eコマース アプリケーションがあり、顧客のフローを分析している場合、1 つ以上のコンポーネントにおける特定の障害モードの影響により、すべての顧客がチェックアウトを完了できない可能性があります。

各種類の障害モードの発生可能性を考慮してください。 マルチゾーンやマルチリージョンの停止など、発生する可能性は非常に低いものもありますが、冗長性を超えた軽減策の計画を追加することは、リソースと時間の無駄になります。

対応策

軽減策の戦略は、回復性の強化と、パフォーマンスの低下に備えた設計という 2 つの大きなカテゴリに分類されます。

回復性を強化するには、インフラストラクチャ、データ、ネットワークなどのコンポーネントに冗長性を追加することや、モノリシック アプリケーションを分離されたアプリやマイクロサービスに分割するなど、持続性のためのベスト プラクティスに従ってアプリケーション設計を行うことが含まれます。 詳細については、冗長に関する推奨事項および自己保存に関する推奨事項に関するページを参照してください。

パフォーマンスの低下に備えて設計するには、フローの 1 つ以上のコンポーネントを無効にする可能性があるが、そのフローを完全には無効にしない、潜在的な障害点を特定します。 エンド ツー エンド フローの機能を維持するには、1 つ以上の手順を他のコンポーネントに再ルーティングするか、障害の発生したコンポーネントが機能を実行することを受け入れ、その機能がユーザー エクスペリエンスで使用できなくなるようにする必要がある場合があります。 eコマース アプリケーションの例に戻ると、マイクロサービスなどのコンポーネントに障害が発生すると、レコメンデーション エンジンが使用できなくなる可能性がありますが、顧客は引き続き製品を検索してトランザクションを完了できます。

依存関係に関する軽減策を計画する必要もあります。 強い依存関係は、アプリケーションの機能と可用性において重要な役割を果たします。 もしそれらが存在しなかったり、誤動作が発生したりした場合、重大な影響が出る可能性があります。 弱い依存関係が存在しない場合は、特定の機能にのみ影響し、全体的な可用性には影響しないこともあります。 この違いは、サービスとその依存関係の間の高可用性の関係を維持するためのコストを反映しています。 依存関係を「強い」か「弱い」として分類すると、アプリケーションにとってどのコンポーネントが不可欠であるかを特定するのに役立ちます。

アプリケーションに、それがないと動作できない強い依存関係がある場合、これらの依存関係の可用性と回復のターゲットは、アプリケーション自体のターゲットと一致する必要があります。 依存関係を最小限に抑えて、アプリケーションの信頼性を制御します。 詳細については、アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現するに関するページを参照してください。

アプリケーションのライフサイクルがその依存関係のライフサイクルと密接に結び付いている場合、特に新しいリリースでは、アプリケーションの運用の機敏性が制限される可能性があります。

検出

障害検出は、分析で障害点を正しく特定し、軽減戦略を適切に計画するために不可欠です。 このコンテキストでの検出とは、インフラストラクチャ、データ、アプリケーションを監視し、問題が発生したときに警告することを意味します。 可能な限り検出を自動化し、運用プロセスに冗長性を組み込んで、アラートが確実に捕捉され、ビジネス要件を満たすのに十分な速さで対応できるようにします。 詳細については、監視に関する推奨事項に関するページを参照してください。

成果

分析の結果については、調査結果、フロー コンポーネントと軽減策に関して行った決定事項、障害がワークロードに及ぼす影響を効果的に伝える一連のドキュメントを作成します。

分析では、重大度と発生可能性に基づいて特定した障害モードと軽減策の戦略に優先順位を付けます。 この優先順位を使用して、軽減策の戦略の設計に時間、労力、リソースを費やすのに値するほど一般的で深刻な障害モードに重点を置いてドキュメントを作成します。 たとえば、発生または検出が非常にまれないくつかの障害モードが存在する可能性があります。 それらを中心に軽減策の戦略を設計するのはコストに見合うものではありません。

ドキュメントの開始点については、次のサンプル テーブルを参照してください。

初期の FMA 演習では、作成するドキュメントのほとんどは理論的な計画になります。 FMA ドキュメントは定期的に確認して更新し、ワークロードを最新の状態に保つ必要があります。 カオス テストと実際の経験は、時間をかけて分析を洗練させるのに役立ちます。

Azure ファシリテーション

Azure Monitor と Log Analytics を使用して、ワークロードの問題を検出します。 インフラストラクチャ、アプリ、データベースに関連する問題をさらに詳しく調べるには、Application Insights、Container Insights、Network Insights、VM Insights、SQL Insights などのツールを使用します。

Azure Chaos Studio は、カオス エンジニアリングを使って、クラウド アプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージド サービスです。

FMA 原則を一般的な Azure サービスに適用する方法については、「Azure アプリケーション用の障害モード分析」を参照してください。

例

次の表は、Azure SQL データベースを備えた Azure App Service インスタンスでホストされ、Azure Front Door によってアクセスされる eコマース Web サイトの FMA の例を示しています。

ユーザー フロー: ユーザーのサインイン、製品検索、ショッピング カートの操作

関連リンク

• Azure アプリケーション用の障害モード分析
• 回復性と依存関係

信頼性チェックリスト

レコメンデーションの完全なセットを参照してください。