次の方法で共有

故障モード解析を実行するためのレコメンデーション

  • [アーティクル]

この Power Platform Well-Architected Reliabilityチェックリストの推奨事項に適用されます:

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

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

FMA の重要な信条は、回復力を何層にも適用しても故障は発生するということです。 環境が複雑になればなるほど、より多くの種類の故障が発生する可能性が高くなります。 この現実を踏まえて、FMA を使用すると、ほとんどの種類の故障に耐え、故障が発生したときに正常に回復するようにワークロードを設計できます。

FMA を完全にスキップしたり、不完全な分析を実行したりすると、ワークロードが予期せぬ動作を起こしたり、次善の設計によって停止する可能性が発生したりする危険があります。

定義

任期 Definition
失敗モード 1 つ以上のワークロード コンポーネントが低下したり、使用できなくなるほど深刻な影響を受ける可能性がある問題の一種。
軽減策 問題に積極的または事後的に対処するために特定したアクティビティ。
検出 データとアプリの監視とアラートのプロセスと手順。

主要な設計戦略

FMA のコンテキストでは、前提条件を理解することが重要です。 まず、フローを特定するための推奨事項を検討して実装し、重要度に基づいて優先順位を付けます。 データ アーティファクトは、これらのフロー内のデータ パスを記述する上で重要な役割を果たします。 FMA アプローチを詳しく検討する際には、重要なフローのコンポーネントの計画、依存関係 (内部と外部の両方) の特定、軽減戦略の考案に重点を置きます。

前提条件

フローを識別および評価するためのレコメンデーション を確認して実装します。 重要度に基づいてユーザー フローとシステム フローを特定し、優先順位を付けていることを前提としています。

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

FMA アプローチ

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

ワークロードの分解

アイデア出しから設計に移行する際には、ワークロードをサポートするために必要なコンポーネントの種類を特定する必要があります。 ワークロードによって、計画する必要がある必要なコンポーネントが決まります。

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

依存関係の特定

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

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

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

故障箇所

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

  • リージョンの停止: Power Platform 全体または Azure リージョンが利用できません
  • サービスの停止: 1 つ以上の Power Platform または Azure サービスが利用できません
  • 分散型サービス拒否 (DDoS) またはその他の悪意のある攻撃
  • アプリまたはコンポーネントの構成ミス
  • オペレーター エラー
  • 計画メンテナンスの稼働停止
  • コンポーネントのオーバーロード

それぞれのタイプの故障モードの可能性を考慮してください。 マルチゾーンまたはマルチリージョンの停止など、発生する可能性が非常に低いものもあり、冗長性を超えた緩和計画を追加することは、リソースと時間の有効な使い方とは言えません。

軽減策

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

復元力を高めるということは、アプリケーションの設計が耐久性のベスト プラクティスに従っていることを保証することを意味します。たとえば、モノリシック アプリケーションを分離されたアプリとマイクロサービスに分割し、再試行ポリシーなどのプラットフォームが提供する復元性構成を使用します。 詳細については、冗長性に関する推奨事項 および 自己保存に関する推奨事項 を参照してください。

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

依存関係に関する緩和策を計画することも必要です。 強力な依存関係は、アプリケーションの機能と可用性において重要な役割を果たします。 欠品または故障した場合、重大な影響が出る可能性があります。 弱い依存関係がない場合、特定の機能にのみ影響し、全体的な可用性には影響しない可能性があります。 この区別は、サービスとその依存関係間の高可用性関係を維持するためのコストを反映しています。 依存関係を強いか弱いかに分類すると、アプリケーションに不可欠なコンポーネントを識別しやすくなります。

アプリケーションに、それなしでは動作できない強力な依存関係がある場合、これらの依存関係の可用性と回復のターゲットは、アプリケーション自体のターゲットと一致する必要があります。 アプリケーションのライフサイクルがその依存関係のライフサイクルと密接に結びついている場合、特に新しいリリースの場合、アプリケーションの運用の機敏性が制限される可能性があります。

検出

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

結果

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

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

ドキュメントの開始点として 例の表 を参照してください。

最初の FMA 演習中に作成する文書は、主に理論的な計画になります。 FMA ドキュメントは、ワークロードに合わせて最新の状態に保つために定期的に確認および更新する必要があります。 カオステストと実際の経験は、時間の経過とともに分析を洗練させるのに役立ちます。

例

次の表は、 Power Apps キャンバスアプリで サードパーティ システムと対話するための、APIMでホストされる Microsoft Dataverse バックエンドと API としての経費精算アプリケーションを FMA でホストした例を示しています。

ユーザーフロー: ユーザーのログイン、経費請求の提出、経費レポートとのやり取り

コンポーネント Risk Likelihood 効果/軽減/メモ 停止
Microsoft Entra ID サービスの稼働停止 安 完全なワークロード停止。 修復には Microsoft に依存します。 完全
Microsoft Entra ID 構成ミス ミディアム サインインできないユーザー。 下流への影響はありません。 ヘルプ デスクは構成の問題を ID チームに報告します。 None
Power Apps サービスの稼働停止 安 外部ユーザーに対する完全な停止。 修復には Microsoft に依存します。 完全
Power Apps 地域的な停止 非常に低い 外部ユーザーに対する完全な停止。 修復には Microsoft に依存します。 完全
Power Apps DDoS 攻撃 ミディアム 混乱が生じる可能性。 Microsoft DDoS (L3およびL4) 保護を管理します。 部分的な停止の可能性
Dataverse サービスの稼働停止 安 完全なワークロード停止。 修復には Microsoft に依存します。 完全
Dataverse 地域的な停止 非常に低い 自動フェールオーバー グループはセカンダリ リージョンにフェールオーバーします。 フェイルオーバー中に停止する可能性があります。 信頼性テスト中に決定される回復時間目標 (RTO) と回復ポイント目標 (RPO)。 潜在的なフル
Dataverse 悪意のある攻撃 (インジェクション) ミディアム 最小限のリスク。 潜在的低リスク
API Management サービスの稼働停止 安 外部ユーザーに対する完全な停止。 修復には Microsoft に依存します。 完全
API Management 地域的な停止 非常に低い 外部ユーザーに対する完全な停止。 修復には Microsoft に依存します。 完全
API Management DDoS 攻撃 ミディアム 混乱が生じる可能性。 Microsoft DDoS (L3およびL4) 保護を管理します。 部分的な停止の可能性
Power Platform ソリューション 構成ミス ミディアム 構成ミスは展開中に検出される必要があります。 構成の更新中にこれらが発生した場合、管理者は変更をロールバックする必要があります。 構成の更新により、外部で短時間の停止が発生します。 完全な停止の可能性

Power Platform の促進

Power Platform は、Azure Monitor エコシステムの一部である Application Insights と統合します。 このアプリケーションを使用して、次のことができます。

  • アプリケーションが Dataverse データベースおよびモデル駆動型アプリ内で実行する診断、パフォーマンス、操作に関する Application Insights の Dataverse プラットフォーム によってキャプチャされたテレメトリを受信するようにサブスクライブします。 このテレメトリは、エラーとパフォーマンスに関連する問題の診断とトラブルシューティングに使用できる情報を提供します。

  • キャンバスアプリから Application Insights に接続して、これらの分析を使用して問題を診断し、ユーザーが実際にアプリで何をしているかを把握し、より適切なビジネス上の意思決定を促進し、アプリの品質を向上させることができます。

  • Power Automate テレメトリ を Application Insights へとフローするように構成します。 このテレメトリを、クラウド フローの実行を監視し、クラウド フローの実行失敗に関するアラートを作成できます。

  • Azureで使用するために、 Microsoft Copilot Studio copilot からテレメトリ データをキャプチャします Application Insights。 このテレメトリを使用すると、コパイロットとの間で送受信されるログに記録されたメッセージとイベント、ユーザーの会話中にトリガーされるトピック、トピックから送信できるカスタム テレメトリ イベントを監視できます。

Power Platform リソースは、 Microsoft Purviewコンプライアンス ポータルにアクティビティを記録します。 ほとんどのイベントはアクティビティの 24 時間以内に利用可能になります。 この情報をリアルタイム監視に使用しないでください。 Power Platform でのログ活動についての情報は、次を参照してください。

信頼性チェックリスト

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

信頼性チェックリスト