障害モード分析を実行するためのアーキテクチャ戦略

この 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 演習中に作成するドキュメントは、主に理論的な計画です。 FMA ドキュメントを定期的に見直して更新し、ワークロードの状況に合わせて常に最新の状態に保つようにします。 カオス テストと実際のエクスペリエンスは、時間の経過に伴う分析の改善に役立ちます。

Azure監視

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

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

Azure Network Watcher の 接続モニター と 接続のトラブルシューティング を使用して、デプロイ前にネットワーク接続のシナリオをモデル化して検証します。 これらのツールは、合成テストをシミュレートし、潜在的なルーティング パスのトラブルシューティングを行うことで、ネットワーク アーキテクチャで発生する可能性のある障害モードを予測して文書化するのに役立ちます。 また、 トラフィック分析を使用して仮想ネットワーク フローの履歴ログを分析することで、ブロックされたトラフィックや異常なトラフィックのパターンを特定し、Azure インフラストラクチャ全体で FMA ドキュメントに通知する可能性があります。

例

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

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

関連リンク

• 回復性と依存関係

信頼性チェックリスト

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