次の方法で共有

一時的な故障を処理するための推奨事項

  • [アーティクル]

この Power Platform Well-Architected 信頼性チェックリストのレコメンデーションに適用されます:

RE:05 エラー処理と一時的な故障処理を実装することで、ワークロードの回復力を強化します。 コンポーネントの故障や一時的なエラーを処理する機能をソリューションに組み込みます。

このガイドは、クラウド アプリケーションで一時的な故障を処理するための推奨事項について説明します。 リモート サービスおよびリソースと通信するすべてのアプリケーションは、一時的な故障に敏感でなければなりません。 これは、クラウド上で実行されるアプリケーションに特に当てはまります。クラウドでは、環境の性質とインターネット上の接続により、このタイプの故障がより頻繁に発生する可能性があります。 一時的な故障には、コンポーネントやサービスへのネットワーク接続の一時的な喪失、サービスの一時的な利用不能、サービスがビジー状態のときに発生するタイムアウトなどが含まれます。 これらの故障は多くの場合、自動的に修正されるため、適切な遅延の後にアクションを繰り返すと、成功する可能性が高くなります。

主要な設計戦略

一時的な故障は、あらゆる環境、あらゆるプラットフォームやオペレーティング システム、あらゆる種類のアプリケーションで発生する可能性があります。

課題

予測可能なあらゆる状況下で徹底的にテストされていたとしても、一時的な故障はアプリケーションの可用性の認識に大きな影響を与える可能性があります。 Power Platform ワークロードが確実に動作できるようにするには、次の課題に対応できることを確認する必要があります。

  • アプリケーションは、故障が発生したときにそれを検出し、故障が一時的なものか、長期間続くものか、あるいは致命的な故障であるかを判断できる必要があります。 故障が発生した場合、リソースが異なれば異なる応答が返される可能性が高く、これらの応答は操作のコンテキストによっても異なる場合があります。 たとえば、アプリケーションがカスタム コネクタからデータを取得しているときのエラーに対する応答は、アプリケーションがクラウド フローを実行して応答を待機しているときの応答とは異なる場合があります。

  • アプリケーションは、故障が一時的である可能性が高いと判断した場合、操作を再試行できる必要があります。

  • アプリケーションは再試行に適切な戦略を使用する必要があります。 この戦略では、アプリケーションが再試行する回数、各試行間の遅延、試行が失敗した後に実行するアクションを指定します。 適切な試行回数と各試行間の遅延を判断することは、多くの場合困難です。 戦略は、リソースの種類、リソースとアプリケーションの現在の動作条件に応じて異なります。

一般的なガイドライン

次のガイドラインは、アプリケーションに適した一時的な故障処理メカニズムを設計するのに役立ちます。

再試行メカニズムが組み込まれているかどうかを確認する

接続しているサービスによっては、一時的な故障処理メカニズムがすでに提供されている場合があります。 使用される再試行ポリシーは通常、対象サービスの性質と要件に合わせて調整されます。 あるいは、サービスのRESTインターフェイスは、再試行が適切かどうか、次の再試行までの待機時間を判断するのに役立つ情報を返す場合があります。

別の再試行動作をより適切にする特定の十分に理解された要件がある場合を除き、組み込みの再試行メカニズムが利用可能な場合はそれを使用する必要があります。

操作が再試行に適しているかどうかを判断する

故障が一時的である場合 (通常はエラーの性質によって示されます)、および再試行時に操作が成功する可能性が少なくともいくらかある場合にのみ、再試行操作を実行します。 Microsoft Dataverse 内の存在しない行の更新やユーザーに権限のない行の更新、存在しない API エンドポイント の呼び出しなど、無効な操作を試みる操作を再試行しても意味がありません。

再試行を実行する場合は、その効果を完全に判断でき、条件がよく理解されて検証できる場合にのみ実行してください。 管理外のリソースやサービスから返されるエラーは時間の経過とともに変化する可能性があるため、一時的な故障検出ロジックの再検討が必要になる場合があることに注意してください。

アプリケーションから呼び出される個々のコンポーネントまたはサービスを開発するときは、失敗した操作を再試行する必要があるかどうかをクライアントが判断するのに役立つエラー コードとメッセージを必ず返すようにしてください。 たとえば、isTransient 値を返すなどして、クライアントが操作を再試行する必要があるかどうかを示すことを検討してください。 Web サービスを構築する場合は、サービス コントラクト内で定義されているカスタム エラーを返すことを検討してください。

適切な再試行回数と間隔を決定する

ユースケースの種類に応じて再試行回数と間隔を最適化します。 十分な回数再試行しないと、アプリケーションは操作を完了できず、失敗する可能性があります。 再試行の回数が多すぎる場合、または再試行の間隔が短すぎる場合、アプリケーションはリソースを長期間保持する可能性があり、アプリケーションの健全性に悪影響を及ぼします。

操作の種類に応じて、時間間隔と再試行回数の値を調整します。 たとえば、操作がユーザー対話の一部である場合、間隔は短く、再試行は数回のみ行う必要があります。 このアプローチを使用すると、ユーザーが応答を待たされることを回避できます。 操作が長時間実行されるワークフローまたは重要なワークフローの一部であり、プロセスのキャンセルと再起動にコストがかかったり、時間がかかったりする場合は、試行間の待機時間を長くして、再試行回数を増やすことが適切です。

再試行間の適切な間隔を決定することは、成功する戦略を設計する上で最も難しい部分であることに留意してください。 一般的な戦略では、次のタイプの再試行間隔が使用されます。

  • 指数関数的な間隔。 アプリケーションは最初の再試行の前に少し待機し、その後の再試行の間隔が指数関数的に長くなります。 たとえば、3 秒後、12 秒後、30 秒後などに操作を再試行する場合があります。

  • 固定間隔。 アプリケーションは、各試行の間に同じ時間待機します。

  • すぐに再試行します。 一時的な故障が短時間で終わる場合があり、アプリケーションが次の要求を送信する間に故障が解消されれば操作が成功する可能性があるため、操作をすぐに再試行することが適切な場合があります。 ただし、即時再試行は 1 回以上実行しないでください。 即時の再試行が失敗した場合は、指数間隔やフォールバック アクションなどの代替戦略に切り替える必要があります。

一般的なガイドラインとして、バックグラウンド操作には指数間隔戦略を使用し、対話型操作には即時または固定間隔の再試行戦略を使用します。 どちらの場合も、すべての再試行の最大遅延が必要なエンドツーエンド遅延要件内に収まるように、遅延と再試行回数を選択する必要があります。

再試行される操作の全体的な最大タイムアウトに寄与するすべての要因の組み合わせを考慮してください。 これらの要因には、失敗した接続が応答を生成するまでにかかる時間、再試行間の遅延、最大再試行回数が含まれます。 これらすべての時間の合計により、全体的な操作時間が長くなる可能性があります。特に、失敗するたびに再試行の間隔が急速に長くなる指数遅延戦略を使用する場合は、その傾向が顕著になります。 プロセスが特定のサービス レベル アグリーメント (SLA) を満たす必要がある場合、すべてのタイムアウトと遅延を含む全体的な操作時間は、SLAで定義された制限内である必要があります。

過度に積極的な再試行戦略を実装しないでください。 これらは、間隔が短すぎるか、再試行が頻繁すぎる戦略です。 対象のリソースまたはサービスに悪影響を及ぼす可能性があります。 これらの戦略により、リソースまたはサービスが過負荷状態から回復できなくなり、リクエストがブロックまたは拒否され続ける可能性があります。 このシナリオでは、リソースまたはサービスに送信されるリクエストがますます増えるという悪循環が発生します。 その結果、回復能力はさらに低下します。

再試行間隔を選択するときは、後続の試行がすぐに開始されないように、操作のタイムアウトを考慮してください (たとえば、タイムアウト期間が再試行間隔とほぼ同じである場合)。

エラーの種類、またはサービスから返されるエラー コードとメッセージを使用して、再試行回数と再試行間隔を最適化します。 たとえば、一部の例外またはエラー コード (HTTP コード 503、サービスが利用できません、応答に Retry-After ヘッダーがあるなど) は、エラーがどのくらい続くかを示したり、サービスが失敗して後続の試行に応答しないことを示す場合があります。

アンチパターンを避ける

ほとんどの場合、再試行コードの重複したレイヤーを含む実装は避けてください。 特別な要件がない限り、カスケード再試行メカニズムを含む設計や、要求の階層を含む操作の各段階で再試行を実装する設計は避けてください。 このような例外的な状況では、過度の再試行や遅延期間を防ぐポリシーを使用し、その結果を必ず理解してください。 たとえば、あるコンポーネントが別のコンポーネントにリクエストを送信し、そのコンポーネントがターゲット サービスにアクセスするとします。 両方の呼び出しで再試行回数を 3 に設定して実装すると、サービスに対して合計 9 回の再試行が行われます。 多くのサービスとリソースは、組み込みの再試行メカニズムを実装しています。 より高いレベルで再試行を実装する必要がある場合は、これらのメカニズムを無効化または変更する方法を調査する必要があります。

無限の再試行メカニズムを実装しないでください。 そうすると、リソースまたはサービスが過負荷状態から回復できなくなり、スロットリングや接続拒否が長時間続く可能性があります。

即時再試行を複数回実行しないでください。

Azure 上のサービスやリソースにアクセスする場合、特に再試行回数が多い場合は、固定の再試行間隔を使用しないでください。 このシナリオにおける最良のアプローチは、指数関数的な間隔戦略です。

再試行戦略と実装をテストする

再試行戦略は、できるだけ幅広い状況下で徹底的にテストしてください。特に、アプリケーションとそれが使用するターゲット リソースまたはサービスの両方に極端な負荷がかかっている場合は、再試行戦略を完全にテストしてください。 テスト中に動作を確認するには、次のことができます。

  • 一時的および非一時的な故障をサービスに挿入します。 たとえば、無効なリクエストを送信したり、テスト リクエストを検出してさまざまな種類のエラーで応答するコードを追加したりできます。

  • 実際のサービスが返す可能性のあるさまざまなエラーを返すリソースまたはサービスのモックアップを作成します。 再試行戦略が検出するように設計されているすべての種類のエラーをカバーします。

  • 作成してデプロイするカスタム サービスの場合は、サービスを一時的に無効にしたり、過負荷にしたりすることで、一時的なエラーを強制的に発生させます。 (Azure の共有リソースや共有サービスを過負荷にしないでください。)

  • クライアント Webアプリケーションの一時的な故障に対する回復力をテストするときは、ブラウザの開発者ツールまたはテスト フレームワークの モック または ブロック ネットワークリクエストの機能を使用します。

  • 高負荷係数および同時実行テストを実行して、これらの条件下で再試行メカニズムと戦略が正しく機能することを確認します。 これらのテストは、再試行がクライアントの動作に悪影響を及ぼさないこと、またはリクエスト間の相互汚染を引き起こさないことを確認するのにも役立ちます。

再試行ポリシー構成を管理する

再試行ポリシー は、再試行戦略のすべての要素を組み合わせたものです。 これは、故障が一時的なものである可能性が高いかどうかを判断する検出メカニズム、使用する間隔のタイプ (固定または指数など)、実際の間隔値、および再試行回数を定義します。

組み込みまたはデフォルトの再試行戦略を利用しますが、それはシナリオに適切な場合に限ります。 これらの戦略は通常、一般的なものです。 一部のシナリオでは、これらが必要なすべてである場合もありますが、特定の要件を満たすためのすべてのオプションが提供されていないシナリオもあります。 最も適切な値を決定するには、設定がアプリケーションにどのように影響するかを理解するためにテストを実行する必要があります。

一時的および非一時的ま故障をログに記録して追跡する

再試行戦略の一部として、例外処理や再試行のログを記録するその他のインストルメンテーションを含めます。 時折、一時的なエラーと再試行が発生することが予想されますが、問題を示すものではありません。 ただし、再試行の回数が定期的に増加している場合は、故障の原因となる可能性のある問題や、アプリケーションのパフォーマンスと可用性を低下させる可能性のある問題の兆候であることが多いです。

一時的な故障をエラー エントリではなく警告エントリとしてログに記録し、監視システムがそれらをアプリケーション エラーとして検出して誤ったアラートをトリガーしないようにします。

データの分析中に区別できるように、再試行がサービスのスロットリングによって発生したのか、接続の故障などの他の種類の故障によって発生したのかを示す値をログ エントリに保存することを検討してください。 スロットリング エラーの数の増加は、多くの場合、アプリケーションの設計上の欠陥、または環境にプレミアム容量を追加する必要があることを示しています。

失敗の数と率、平均再試行回数、または操作が成功するまでの総経過時間が増加した場合にアラートを生成できるテレメトリおよび監視システムの実装を検討してください。

継続的に失敗するオペレーションを管理する

あらゆる試行で失敗し続ける操作の処理方法を検討します。 このような状況は避けられません。

再試行戦略では、操作を再試行する最大回数を定義しますが、アプリケーションが同じ再試行回数で操作を繰り返すことを防ぐことはできません。 たとえば、アプリケーションでフォームを送信すると、フローがトリガーされる可能性があります。 再試行戦略は接続タイムアウトを検出し、それを一時的な故障とみなす場合があります。 フローは指定された回数だけ操作を再試行し、その後中止します。 ただし、同じユーザーまたは新しいユーザーがフォームを再度送信しようとすると、操作は再試行されますが、引き続き失敗する可能性があります。

アプリケーションは、断続的に、またリクエスト間の長い間隔で定期的にサービスをテストし、サービスが利用可能になったかどうかを検出できます。 適切な間隔は、操作の重要性やサービスの性質などの要因によって異なります。 数分から数時間かかる場合があります。 テストが成功すると、アプリケーションは通常の操作を再開し、新しく回復したサービスにリクエストを渡すことができます。

それまでの間、サービスがすぐに利用可能になることを期待して、いくつかの代替操作を実行できる場合があります。 たとえば、サービスへのリクエストをキューまたは データ ストア に保存し、後で再試行することが適切な場合があります。 または、アプリケーションが利用できないことを示すメッセージをユーザーに返す必要がある場合もあります。

その他の考慮事項

ポリシーの再試行回数と再試行間隔の値を決定するときは、サービスまたはリソースに対する操作が長時間実行操作の一部であるか、複数ステップの操作の一部であるかを考慮してください。 1 つの操作手順が失敗した場合に、すでに成功している他のすべての操作手順を補償することは困難または高価になる可能性があります。 この場合、その戦略が希少なリソースを保持またはロックすることによって他の操作をブロックしない限り、長い間隔と多数の再試行が許容される可能性があります。

同じ操作を再試行するとデータの不整合が生じる可能性があるかどうかを検討してください。 複数ステップのプロセスの一部が繰り返され、操作が冪等でない場合、不整合が発生する可能性があります。 たとえば、Microsoft Dataverse にレコードを挿入する操作が繰り返されると、テーブル内の値が不正になる可能性があります。 または、ユーザーに通知を送信する操作を繰り返すと、重複したメッセージが受信される可能性があります。

再試行される操作の範囲を考慮してください。 たとえば、複数の操作を含むレベルで再試行コードを実装し、1 つが失敗した場合にすべてを再試行する方が簡単な場合があります。 ただし、これを行うと、冪等性の問題や不必要なロールバック操作が発生する可能性があります。

複数の操作を含む再試行スコープを選択する場合は、再試行間隔を決定するとき、操作の経過時間を監視するとき、失敗のアラートを生成する前に、すべての操作の合計待機時間を考慮してください。

Power Platform の促進

次のセクションでは、一時的な故障を管理するために使用できるメカニズムについて説明します。

Power Automate

Power Automate にはアクションが失敗した場合にアクションを再試行する機能が含まれています。 これをアクションごとのレベルで設定します。 Power Automate プロジェクトにおけるリスクの軽減とエラー処理の計画. Power Automate はカスタム エラーとデータを呼び出し元のアプリまたはフローに返すアクションも提供します。

一部の一時フローは、スループットとリクエストの制限によって発生する可能性があります。 自動化、スケジュール、即時フローの 限界 そして リクエストの制限と割り当て に関して学習します。

スコープと run-after 設定を使用して、クラウドフローでエラーと例外の処理を構成します。

Power Apps

Power Apps キャンバスアプリは、接続状態を確認し、これにより、アプリがオフラインの場合に異なる動作が可能になります。 オフライン対応キャンバス アプリを開発する方法について学習します。

また,、キャンバス アプリで、 Error、IfError、IsError、IsBlankOrError 関数を使用 して、エラーが発生した場合に次に何を実行するかを決定します。

Power Apps での一時的な故障処理の詳細について :

Azure とカスタム コネクタ

ワークロードが Azure サービスに接続する場合、Azure Well-Architected Framework を使用して一時的な故障を処理する方法を学びます。

エラーに対するカスタムコネクタの応答を管理するには、コーディング標準 に従います。

Application Insights

Application Insights 統合を使って、Power Automate と Power Apps でエラーを記録します:

参照

Dynamics 365 SaaS アプリの事業継続とディザスター リカバリー

信頼性チェックリスト

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

信頼性チェックリスト