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

  • [アーティクル]

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

RE:03 エラー モード分析 (FMA) を使用して、ソリューション コンポーネントの潜在的な障害を特定し、優先順位を付けます。 FMA を実行して、各障害モードのリスクと影響を評価します。 ワークロードの応答と回復方法を決定します。

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

FMA の重要なテネットは、適用する回復性のレイヤー数に関係なく障害が発生するということです。 より複雑な環境では、より多くの種類の障害が発生します。 このような現実を考えると、FMA を使用すると、ほとんどの種類の障害に耐え、障害が発生したときに正常に復旧するようにワークロードを設計できます。

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

定義

期間 定義
障害モード 1 つ以上のワークロード コンポーネントが機能低下したり、使用できない時点まで深刻な影響を受けたりする可能性がある問題の種類。
対応策 問題に対処するために事前または事後対応的に特定したアクティビティ。
検出 インフラストラクチャ、データ、アプリの監視とアラートのプロセスと手順。

主要な設計戦略

前提条件

フローを識別するための推奨事項を確認して実装します。 重要度に基づいてユーザー フローとシステム フローを特定し、優先順位を付けたものと想定されます。

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

FMA アプローチ

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

ワークロードを分解する

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

設計例を示す図。

初期アーキテクチャ設計を作成したら、フローをオーバーレイして、それらのフローで使用される個別のコンポーネントを識別し、フローとそのコンポーネントを記述するリストまたはワークフロー図を作成できます。 コンポーネントの重要度を理解するには、フローに割り当てた重要度定義を使用します。 コンポーネントの誤動作がフローに及ぼす影響を考慮してください。

依存関係を識別する

ワークロードの依存関係を特定して、単一障害点分析を実行します。 ワークロードを分解し、フローをオーバーレイすると、ワークロードの内部および外部にある依存関係に関する分析情報が得られます。

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

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

障害点

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

  • リージョンの停止。 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 は、カオス エンジニアリングを使って、クラウド アプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージド サービスです。

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

例

次の表は、Azure SQL データベースを持つ Azure App Service インスタンスでホストされ、Azure Front Door によって前面に置かれる e コマース Web サイトの FMA の例を示しています。

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

コンポーネント リスク Likelihood 効果/軽減策/メモ Outage
Microsoft Entra ID サービス停止 低 ワークロードの完全停止。 修復する Microsoft に依存しています。 [完全]
Microsoft Entra ID 誤った構成 Medium ユーザーはサインインできません。 ダウンストリーム効果はありません。 ヘルプ デスクは、ID チームに構成の問題を報告します。 なし
Azure Front Door サービス停止 低 外部ユーザーの完全な停止。 修復する Microsoft に依存しています。 外部のみ
Azure Front Door リージョンの停止 非常に低い 最小限の効果。 Azure Front Door はグローバル サービスであるため、グローバル トラフィック ルーティングは、影響を受けないものの Azure リージョンを介してトラフィックを転送します。 なし
Azure Front Door 誤った構成 Medium デプロイ中に構成の誤りをキャッチする必要があります。 構成の更新中にこれらが発生した場合、管理者は変更をロールバックする必要があります。 構成の更新により、外部の短時間の停止が発生します。 外部のみ
Azure Front Door DDoS 攻撃 Medium 中断の可能性があります。 Microsoft は DDoS (L3 および L4) 保護を管理し、Azure Web Application Firewallはほとんどの脅威をブロックします。 L7 攻撃による影響の潜在的なリスク。 部分的な停止の可能性
Azure SQL サービス停止 低 ワークロードの完全停止。 修復する Microsoft に依存しています。 [完全]
Azure SQL リージョンの停止 非常に低い 自動フェールオーバー グループは、セカンダリ リージョンにフェールオーバーします。 フェールオーバー中に障害が発生する可能性があります。 信頼性テスト中に決定される目標復旧時間 (RTO) と目標復旧ポイント (RPO)。 潜在的なフル
Azure SQL 可用性ゾーンの停止 低 効果なし なし
Azure SQL 悪意のある攻撃 (インジェクション) Medium 最小限のリスク。 すべてのAzure SQL インスタンスは、プライベート エンドポイントを介して仮想ネットワークにバインドされ、ネットワーク セキュリティ グループ (NSG) によって仮想ネットワーク内保護がさらに強化されます。 潜在的な低リスク
App Service サービス停止 低 ワークロードの完全停止。 修復する Microsoft に依存しています。 [完全]
App Service リージョンの停止 非常に低い 最小限の効果。 有効なリージョン内のユーザーの待機時間。 Azure Front Door は、影響を受けないもののリージョンにトラフィックを自動的にルーティングします。 なし
App Service 可用性ゾーンの停止 低 影響しません。 アプリ サービスはゾーン冗長としてデプロイされています。 ゾーンの冗長性がないと、効果が生じる可能性があります。 なし
App Service DDoS 攻撃 Medium 最小限の効果。 イングレス トラフィックは、Azure Front Door と Azure Web Application Firewallによって保護されます。 なし

信頼性チェックリスト

推奨事項の完全なセットを参照してください。

信頼性チェックリスト