Azure アプリケーション用の障害モード分析

障害モード分析 (FMA) は、システムで考えられる障害点を特定することによって、システムに回復力を持たせるためのプロセスです。 FMA をアーキテクチャおよび設計フェーズで行って、最初からシステムに障害復旧を組み込むことができるようにする必要があります。

FMA の一般的な実施プロセスを次に示します。

1. システム内のすべてのコンポーネントを明らかにします。 ID プロバイダーやサード パーティーのサービスなど、外部依存関係を含みます。

2. コンポーネントごとに発生する可能性のある障害を特定します。 1 つのコンポーネントに複数の障害モードが存在する場合があります。 たとえば、影響と可能な軽減手順が異なるため、読み取り障害と書き込み障害は別のものとして検討する必要があります。

3. 総合的なリスクに従って、各障害モードを評価します。 次の点を考慮します。

   • 障害の可能性はどれくらいか。 比較的よくあることか。 非常にまれに発生するか。 正確な数値は必要はありません。目的は、優先順位をランク付けすることです。
   • 可用性、データの損失、金銭的コスト、および業務の中断の観点から、アプリケーションに対してどの程度の影響がありますか。

4. 各障害モードについて、アプリケーションがどのように対応および復旧するかを決定します。 コストとアプリケーションの複雑さのトレードオフを検討します。

この記事では、FMA プロセスの出発点として、起こりうる障害モードの一覧とその軽減手順について説明します。 カタログは、テクノロジまたは Azure サービス、およびアプリケーション レベルの設計の一般的なカテゴリで分けられています。 カタログは完全ではありませんが、主要な Azure サービスの多くをカバーしています。

Note

障害はエラーと区別する必要があります。 障害とは、システム内の予期しないイベントであり、これによってシステムが正常に機能し続けることができなくなります。 たとえば、ネットワークのパーティション分割を引き起こすハードウェアの故障は障害です。 通常、障害には、介入や、そのクラスの障害に対する特定の設計が必要になります。 これに対し、エラーは通常の操作で想定される部分であり、直ちに処理され、システムはエラー後も同じ能力で動作し続けます。 たとえば、入力検証中に検出されたエラーは、ビジネス ロジックを通じて処理できます。

App Service

App Service アプリがシャットダウンする。

検出。 考えられる原因:

• 予期されたシャットダウン

  • オペレーターが、たとえば Azure Portal を使用してシャットダウンしました。
  • アプリはアイドル状態だったために、アンロードされました (Always On の設定が無効の場合のみ)。

• 予期されないシャットダウン

  • アプリがクラッシュしました。
  • App Service の VM インスタンスが使用できなくなりました。

Application_End ログは、アプリ ドメインのシャットダウン (ソフト プロセス クラッシュ) をキャッチし、アプリケーション ドメインのシャットダウンをキャッチする唯一の方法です。

復旧:

• シャットダウンが予期されていた場合は、アプリケーションのシャットダウン イベントを使用して正常にシャットダウンします。 たとえば、ASP.NET では、Application_End メソッドを使用します。
• アイドルの間にアプリケーションがアンロードされた場合は、次の要求で自動的に再起動されます。 ただし、"コールド スタート" コストが発生します。
• アイドル状態の間にアプリケーションがアンロードされないようにするには、Web アプリで Always On の設定を有効にします。 Azure App Service での Web アプリの構成に関する記事をご覧ください。
• オペレーターによるアプリのシャットダウンを防ぐには、ReadOnly レベルでリソース ロックを設定します。 Azure Resource Manager でのリソースのロックに関する記事をご覧ください。
• アプリがクラッシュした場合、または App Service の VM が使用できなくなった場合は、App Service がアプリを自動的に再起動します。

診断 アプリケーション ログと Web サーバー ログ。 「 Azure App Service での Web アプリの診断ログの有効化」を参照してください。

特定のユーザーが繰り返し不適切な要求を行ったり、システムを過負荷状態にする。

検出。 ユーザーを認証し、アプリケーション ログにユーザー ID を含めます。

復旧:

• Azure API Management を使用して、ユーザーからの要求を調整します。 「Azure API Management を使用した高度な要求スロットル」を参照してください。
• ユーザーをブロックします。

診断 すべての認証要求をログに記録します。

不正な更新プログラムがデプロイされた。

検出。 Azure portal を使用して (「Azure Web アプリのパフォーマンスの監視」を参照してください)、または正常性エンドポイントの監視パターンを実装して、アプリケーションの正常性を監視します。

復旧: 。 複数のデプロイ スロットを使用して、最後の正常な展開にロールバックします。 詳細については、基本的な Web アプリケーションに関するページをご覧ください。

Microsoft Entra ID

OpenID Connect 認証が失敗する。

検出。 次のような障害モードの可能性があります。

1. Microsoft Entra ID が使用できないか、ネットワークの問題があるために到達できません。 認証エンドポイントへのリダイレクトが失敗し、OpenID Connect ミドルウェアが例外をスローします。
2. Microsoft Entra テナントが存在しません。 認証エンドポイントへのリダイレクトから HTTP エラー コードが返り、OpenID Connect ミドルウェアが例外をスローします。
3. ユーザーを認証できません。 検出戦略は必要ありません。Microsoft Entra ID によってログイン エラーが処理されます。

復旧:

1. ミドルウェアからのハンドルされない例外をキャッチします。
2. AuthenticationFailed イベントを処理します。
3. エラー ページにユーザーをリダイレクトします。
4. ユーザーが再試行します。

Azure Search

Azure Search へのデータの書き込みが失敗する。

検出。 Microsoft.Rest.Azure.CloudException エラーをキャッチします。

復旧:

Search .NET SDK では、一時的な障害の後で自動的に再試行が行われます。 クライアント SDK によってスローされた例外は、一時的ではないエラーとして処理する必要があります。

既定の再試行ポリシーは、指数バックオフを使用します。 異なる再試行ポリシーを使用するには、SearchIndexClient クラスまたは SearchServiceClient クラスで SetRetryPolicy を呼び出します。 詳細については、自動再試行に関する記事を参照してください。

診断 検索トラフィックの分析を使用します。

Azure Search からのデータの読み取りが失敗する。

検出。 Microsoft.Rest.Azure.CloudException エラーをキャッチします。

復旧:

Search .NET SDK では、一時的な障害の後で自動的に再試行が行われます。 クライアント SDK によってスローされた例外は、一時的ではないエラーとして処理する必要があります。

既定の再試行ポリシーは、指数バックオフを使用します。 異なる再試行ポリシーを使用するには、SearchIndexClient クラスまたは SearchServiceClient クラスで SetRetryPolicy を呼び出します。 詳細については、自動再試行に関する記事を参照してください。

診断 検索トラフィックの分析を使用します。

Cassandra

ノードに対する読み取りまたは書き込みが失敗する。

検出。 例外をキャッチします。 .NET クライアントの場合は、通常、これは System.Web.HttpException です。 他のクライアントでは、例外の種類が異なる場合があります。 詳細については、「Cassandra error handling done right」(Cassandra のエラー処理) を参照してください。

復旧:

• 各 Cassandra クライアントには、専用の再試行ポリシーと機能があります。 詳細については、「Cassandra error handling done right」(Cassandra のエラー処理) を参照してください。
• データ ノードがフォールト ドメイン間に分散される、ラック対応のデプロイを使用します。
• ローカル クォーラム整合性で複数のリージョンにデプロイします。 一時的ではない障害が発生した場合は、別のリージョンにフェールオーバーします。

診断 アプリケーション ログ

クラウド サービス

Web ロールまたは worker ロールが予期せずシャットダウンされる。

検出。 RoleEnvironment.Stopping イベントが発生します。

復旧。 RoleEntryPoint.OnStop メソッドをオーバーライドして、正常にクリーンアップします。 詳細については、「Azure OnStop イベントを処理する正しい方法」 (ブログ) を参照してください。

Azure Cosmos DB

データの読み取りが失敗する。

検出。 System.Net.Http.HttpRequestException または Microsoft.Azure.Documents.DocumentClientException をキャッチします。

復旧:

• SDK によって、失敗した試行が自動的にもう一度実行されます。 再試行回数と最大待機時間を設定するには、ConnectionPolicy.RetryOptions を構成します。 クライアントがスローする例外は、再試行ポリシーを超えているか、一時的なエラーでないかのいずれかです。
• クライアントが Azure Cosmos DB によってスロットルされると、HTTP 429 エラーが返されます。 DocumentClientException で状態コードを確認します。 エラー 429 が繰り返し発生する場合は、コレクションのスループットの値を増やすことを検討してください。
  • MongoDB API を使用している場合は、調整のときに、サービスはエラー コード 16500 を返します。
• 可用性ゾーンをサポートするリージョンを操作する場合は、ゾーン冗長を有効にします。 ゾーン冗長を使用すると、ゾーンが停止した場合に Azure Cosmos DB が自動的にフェールオーバーします。 詳細については、「Azure Cosmos DB を使用して高可用性を実現する」を参照してください。
• マルチリージョン ソリューションを設計している場合は、Azure Cosmos DB データベースを 2 つ以上のリージョンにレプリケートします。 すべてのレプリカは読み取り可能です。 クライアント SDK を使用して、PreferredLocations パラメーターを指定します。 これは、Azure リージョンの順序付きリストです。 すべての読み取りは、リストで最初に利用可能なリージョンに送信されます。 要求が失敗すると、クライアントはリストのリージョンを順番に試します。 詳細については、Azure Cosmos DB for NoSQL でグローバル ディストリビューションを設定する方法に関する記事を参照してください。

診断 クライアント側ですべてのエラーをログに記録します。

データの書き込みが失敗する。

検出。 System.Net.Http.HttpRequestException または Microsoft.Azure.Documents.DocumentClientException をキャッチします。

復旧:

• SDK によって、失敗した試行が自動的にもう一度実行されます。 再試行回数と最大待機時間を設定するには、ConnectionPolicy.RetryOptions を構成します。 クライアントがスローする例外は、再試行ポリシーを超えているか、一時的なエラーでないかのいずれかです。
• クライアントが Azure Cosmos DB によってスロットルされると、HTTP 429 エラーが返されます。 DocumentClientException で状態コードを確認します。 エラー 429 が繰り返し発生する場合は、コレクションのスループットの値を増やすことを検討してください。
• 可用性ゾーンをサポートするリージョンを操作する場合は、ゾーン冗長を有効にします。 ゾーン冗長を使用すると、Azure Cosmos DB は可用性ゾーン間ですべての書き込みを同期的にレプリケートします。 詳細については、「Azure Cosmos DB を使用して高可用性を実現する」を参照してください。
• マルチリージョン ソリューションを設計している場合は、Azure Cosmos DB データベースを 2 つ以上のリージョンにレプリケートします。 プライマリ リージョンが失敗した場合、別のリージョンが書き込みにレベル上げされます。 手動でフェールオーバーをトリガーすることもできます。 SDK が自動的に検出とルーティングを行うので、アプリケーション コードはフェールオーバー後も引き続き動作します。 フェールオーバー期間中は (通常は分単位)、SDK が新しい書き込みリージョンを探しているので、書き込み操作の待機時間が長くなります。 詳細については、Azure Cosmos DB for NoSQL でグローバル ディストリビューションを設定する方法に関する記事を参照してください。
• フォールバックとしては、ドキュメントをバックアップ キューに保存し、後でキューを処理します。

診断 クライアント側ですべてのエラーをログに記録します。

ストレージ

Azure Queue Storage へのメッセージの書き込みが常に失敗する。

検出。 N 回再試行を試みた後も、書き込み操作がまだ失敗します。

復旧:

• ローカル キャッシュにデータを格納しておき、後でサービスが利用可能になったら、ストレージに書き込みを転送します。
• セカンダリ キューを作成し、プライマリ キューが使用できない場合は、そのキューに書き込みます。

診断 ストレージ メトリックを使用します。

特定のキューからのメッセージをアプリケーションが処理できない。

検出。 アプリケーション固有です。 たとえば、メッセージに無効なデータが含まれる場合や、ビジネス ロジックが何らかの理由で失敗する場合があります。

復旧:

別のキューにメッセージを移動します。 そのキューで別のプロセスを実行してメッセージを調べます。

Azure Service Bus メッセージング キューの使用を検討します。このキューでは、この目的に対して配信不能キューの機能が提供されます。

注意

WebJobs でストレージ キューを使用している場合、WebJobs SDK は組み込みの有害メッセージ処理を提供します。 Web ジョブ SDK を使用して Azure Queue Storage を操作する方法に関する記事をご覧ください。

診断 アプリケーション ログを使用します。

Azure Cache for Redis

キャッシュからの読み取りが失敗する。

検出。 StackExchange.Redis.RedisConnectionException をキャッチします。

復旧:

1. 一時的な障害の場合は再試行します。 Azure Cache for Redis は組み込みの再試行をサポートします。 詳細については、Azure Cache for Redis の再試行ガイドラインに関するページを参照してください。
2. 一時的でない障害はキャッシュ ミスとして処理し、元のデータ ソースにフォールバックします。

診断 Azure Cache for Redis 診断を使用します。

キャッシュへの書き込みが失敗する。

検出。 StackExchange.Redis.RedisConnectionException をキャッチします。

復旧:

1. 一時的な障害の場合は再試行します。 Azure Cache for Redis は組み込みの再試行をサポートします。 詳細については、Azure Cache for Redis の再試行ガイドラインに関するページを参照してください。
2. エラーが一時的でない場合は、それを無視し、他のトランザクションが後でキャッシュに書き込めるようにします。

診断 Azure Cache for Redis 診断を使用します。

SQL Database

プライマリ リージョンのデータベースに接続できない。

検出。 接続が失敗します。

復旧:

• ゾーン冗長を有効にします。 ゾーン冗長を有効にすることにより、Azure SQL Database は、サポートされているリージョン内の複数の Azure 可用性ゾーンにわたって書き込みを自動的にレプリケートします。 詳細については、「ゾーン冗長の可用性」を参照してください。

• geo レプリケーションを有効にします。 マルチリージョン ソリューションを設計している場合は、SQL Database のアクティブ geo レプリケーションを有効にすることを検討してください。

  前提条件:データベースがアクティブ geo レプリケーション用に構成されている必要があります。 Azure SQL Database のアクティブ geo レプリケーションに関する記事をご覧ください。

  • クエリの場合は、セカンダリ レプリカから読み取ります。
  • 挿入と更新の場合は、手動でセカンダリ レプリカにフェールオーバーします。 Azure SQL Database の計画的または非計画的なフェールオーバーの開始に関する記事をご覧ください。

  レプリカは異なる接続文字列を使うので、アプリケーションで接続文字列を更新する必要があります。

クライアントが接続プール内の接続を使い切る。

検出。 System.InvalidOperationException エラーをキャッチします。

復旧:

• 操作を再試行してください。
• 軽減計画としては、ユース ケースごとに接続プールを分離して、1 つのユース ケースがすべての接続を独占できないようにします。
• 最大接続プール数を増やします。

診断 アプリケーション ログ。

データベース接続の制限に達する。

検出。 Azure SQL Database では、同時実行 worker、ログイン、およびセッションの数が制限されています。 制限は、サービス レベルに依存します。 詳細については、Azure SQL Database のリソース制限に関する記事をご覧ください。

これらのエラーを検出するには、System.Data.SqlClient.SqlException をキャッチし、SqlException.Number の値で SQL エラー コードを調べます。 関連するエラー コードの一覧については、SQL Database クライアント アプリケーションの SQL エラー コードのデータベース接続エラーとその他の問題に関する記事をご覧ください。

復旧。 これらのエラーは一時的なものと見なされるので、再試行すると問題が解決する可能性があります。 常にこれらのエラーが発生する場合は、データベースの拡張を検討してください。

診断 - sys.event_log のクエリでは、正常なデータベース接続、接続エラー、デッドロックが返されます。

• 失敗した接続に対する警告ルールを作成します。
• SQL Database 監査を有効にして、失敗したログインを調べます。

Service Bus メッセージング

Service Bus キューからのメッセージの読み取りが失敗する。

検出。 クライアント SDK からの例外をキャッチします。 Service Bus 例外の基底クラスは MessagingException です。 エラーが一時的なものである場合は、IsTransient プロパティが true です。

詳しくは、「Service Bus メッセージングの例外」をご覧ください。

復旧:

1. 一時的な障害の場合は再試行します。 Service Bus の再試行ガイドラインに関する記事をご覧ください。
2. どの受信者にも配信できないメッセージは、"配信不能キュー" に入れられます。 このキューを使用して、受信できなかったメッセージを確認します。 配信不能キューは自動的にクリーンアップされません。 明示的に取得するまで、メッセージは残っています。 「Service Bus の配信不能キューの概要」を参照してください。

Service Bus キューへのメッセージの書き込みが失敗する。

検出。 クライアント SDK からの例外をキャッチします。 Service Bus 例外の基底クラスは MessagingException です。 エラーが一時的なものである場合は、IsTransient プロパティが true です。

詳しくは、「Service Bus メッセージングの例外」をご覧ください。

復旧:

• Service Bus クライアントは、一時的なエラーの後で自動的に再試行します。 既定では、指数バックオフを使用します。 最大再試行回数または最大タイムアウト期間に達した後、クライアントは例外をスローします。 詳細については、Service Bus の再試行ガイドラインに関する記事をご覧ください。

• キューのクォータを超えた場合は、クライアントで QuotaExceededException がスローされます。 例外メッセージを見ると、さらに詳細がわかります。 再試行の前にキューからメッセージをいくつかドレインし、サーキット ブレーカー パターンを使用してクォータを超えている間は再試行を続けないようにすることを検討します。 また、BrokeredMessage.TimeToLive プロパティの設定が高すぎないことを確認します。

• 1 つのリージョン内では、パーティション分割されたキューまたはトピックを使用して回復性を向上させることができます。 パーティション分割されていないキューまたはトピックは 1 つのメッセージング ストアに割り当てられます。 このメッセージング ストアを使用できない場合、そのキューまたはトピックに対するすべての操作が失敗します。 パーティション分割されたキューまたはトピックは、複数のメッセージング ストア間で分割されます。

• ゾーン冗長を使用して、複数の可用性ゾーン間で変更を自動的にレプリケートします。 1 つの可用性ゾーンが失敗した場合、フェールオーバーは自動的に行われます。 詳細については、「Service Bus の障害および災害に対するアプリケーションの保護のベスト プラクティス」を参照してください。

• マルチリージョン ソリューションを設計している場合は、異なるリージョンに 2 つの Service Bus 名前空間を作成し、メッセージをレプリケートします。 アクティブ レプリケーションまたはパッシブ レプリケーションを使用することができます。

  • アクティブ レプリケーション:クライアントによって、両方のキューにすべてのメッセージが送信されます。 受信側は、両方のキューでリッスンします。 メッセージに一意識別子でタグを付け、クライアントが重複したメッセージを破棄できるようにします。
  • パッシブ レプリケーション:クライアントによって、メッセージが 1 つのキューに送信されます。 エラーが発生した場合、クライアントは他のキューにフォールバックします。 受信側は、両方のキューでリッスンします。 この方法では、送信される重複したメッセージの数が減ります。 ただし、それでも受信側は重複したメッセージを処理する必要があります。

  詳細については、GeoReplication サンプルに関するページ、および「Service Bus の障害および災害に対するアプリケーションの保護のベスト プラクティス」を参照してください。

重複メッセージ。

検出。 メッセージの MessageId プロパティと DeliveryCount プロパティを調べます。

復旧:

• 可能であれば、メッセージ処理操作をべき等になるように設計します。 できない場合は、既に処理されたメッセージのメッセージ ID を保存しておき、メッセージを処理する前に ID を確認します。

• RequiresDuplicateDetection を true に設定してキューを作成することで、重複の検出を有効にします。 このように設定すると、Service Bus は、前のメッセージと同じ MessageId で送信されたメッセージを自動的に削除します。 次のことを考慮してください。

  • この設定は、重複するメッセージがキューに格納されるのを防ぎます。 受信側が同じメッセージを複数回処理することを防ぐものではありません。
  • 重複データの検出には時間枠があります。 この期間を超えて重複が送信された場合は検出されません。

診断 重複するメッセージを記録します。

アプリケーションでキューからの特定のメッセージを処理できない。

検出。 アプリケーション固有です。 たとえば、メッセージに無効なデータが含まれる場合や、ビジネス ロジックが何らかの理由で失敗する場合があります。

復旧:

2 つの障害モードを考慮する必要があります。

• 受信側が障害を検出します。 この場合、配信不能キューにメッセージを移動します。 後で、別のプロセスを実行して配信不能キューのメッセージを調べます。
• 受信側が、メッセージの処理の途中で失敗します (ハンドルされない例外など)。 このケースを処理するには、PeekLock モードを使用します。 このモードでは、ロックの期限が切れると、他の受信者がメッセージを処理できるようになります。 メッセージが最大配信数または Time-To-Live を超えた場合、メッセージは配信不能キューに自動的に移動されます。

詳しくは、「Service Bus の配信不能キューの概要」をご覧ください。

診断 アプリケーションは、配信不能キューにメッセージを移動したときは常に、アプリケーション ログにイベントを書き込みます。

Storage

Azure Storage へのデータの書き込みが失敗する

検出。 クライアントは、書き込み時にエラーを受け取ります。

復旧:

1. 操作を再試行し、一時的な障害から復旧します。 クライアント SDK の再試行ポリシーによって、これを自動的に処理されます。

2. ストレージに対する過剰な負荷を回避するため、サーキット ブレーカー パターンを実装します。

3. N 回再試行が失敗した場合は、正常なフォールバックを実行します。 次に例を示します。

   • ローカル キャッシュにデータを格納しておき、後でサービスが利用可能になったら、ストレージに書き込みを転送します。
   • 書き込みアクションがトランザクション スコープであった場合は、トランザクションを補正します。

診断 ストレージ メトリックを使用します。

Azure Storage からのデータの読み取りが失敗する。

検出。 クライアントは、読み取り時にエラーを受け取ります。

復旧:

1. 操作を再試行し、一時的な障害から復旧します。 クライアント SDK の再試行ポリシーによって、これを自動的に処理されます。
2. RA-GRS ストレージでは、プライマリ エンドポイントからの読み取りが失敗した場合、セカンダリ エンドポイントから読み取りを再試行してください。 クライアント SDK はこれを自動的に処理できます。 「Azure Storage のレプリケーション」をご覧ください。
3. 再試行が N 回失敗する場合は、フォールバック アクションを実行して正常にデグレードします。 たとえば、製品の画像をストレージから取得できない場合は、汎用的なプレースホルダー画像を表示します。

診断 ストレージ メトリックを使用します。

仮想マシン

バックエンド VM への接続が失敗する。

検出。 ネットワーク接続エラー。

復旧:

• ロード バランサーの背後の可用性セットに、少なくとも 2 つのバックエンド VM をデプロイします。
• 接続エラーが一時的な場合は、TCP が正常にメッセージの送信を再試行することがあります。
• アプリケーションに再試行ポリシーを実装します。
• 永続的なエラーまたは一時的でないエラーの場合は、サーキット ブレーカー パターンを実装します。
• 呼び出し元の VM がネットワーク送信制限を超えた場合は、送信キューがいっぱいになります。 送信キューが常にいっぱいになっている場合は、スケールアウトを検討してください。

診断 サービスの境界でイベントのログを記録します。

VM インスタンスが使用不可または異常になる。

検出。 VM インスタンスが正常かどうかを通知する Load Balancer 正常性プローブを構成します。 プローブは、重要な機能が正しく応答しているかどうかを確認する必要があります。

復旧。 アプリケーション層ごとに、複数の VM インスタンスを同じ可用性セットに格納し、VM の前にロード バランサーを配置します。 正常性プローブが失敗した場合、Load Balancer は異常なインスタンスへの新しい接続の送信を停止します。

診断 - Load Balancer の ログ分析を使用します。

• すべての正常性監視エンドポイントを監視するように、監視システムを構成します。

オペレーターが誤って VM をシャットダウンした。

検出。 該当なし

復旧。 リソース ロックを ReadOnly レベルに設定します。 Azure Resource Manager でのリソースのロックに関する記事をご覧ください。

診断 Azure アクティビティ ログを使用します。

WebJobs

SCM ホストがアイドル状態のとき、継続的なジョブが実行を停止する。

検出。 WebJob 関数にキャンセル トークンを渡します。 詳細については、グレースフル シャットダウンに関する記事を参照してください。

復旧。 Web アプリで Always On の設定を有効にします。 詳細については、「 Web ジョブでのバックグラウンド タスクの実行」を参照してください。

アプリケーションの設計

アプリケーションが受信要求のスパイクを処理できない。

検出。 アプリケーションによって異なります。 一般的な現象:

• Web サイトが HTTP 5xx エラー コードを返し始めます。
• データベースやストレージなどの依存サービスが、要求の調整を始めます。 サービスに応じて、HTTP 429 (要求数が多すぎる) などの HTTP エラーを探します。
• HTTP キューが長くなりすぎます。

復旧:

• 増加した負荷を処理するためにスケールアウトします。

• エラーを軽減し、障害が連鎖してアプリケーション全体が停止するのを防ぎます。 次のような軽減戦略があります。

  • 調整パターンを実装して、バックエンド システムの過負荷を回避します。
  • キュー ベースの負荷の平準化を使用して、要求をバッファリングし、適切な速度で処理します。
  • 特定のクライアントを優先します。 たとえば、アプリケーションに無料レベルと有料レベルがある場合、無料レベルの顧客を調整し、有料レベルの顧客は調整しないようにします。 「Priority queue pattern (優先キュー パターン)」をご覧ください。

診断 App Service 診断ログを使用します。 Azure Log Analytics、Application Insights、New Relic などのサービスを使用して、診断ログを理解します。

サンプルはこちらから入手できます。 次の例外には Polly が使用されます。

• 429 - 調整
• 408 - タイムアウト
• 401 - 未承認
• 503 または 5xx - サービス利用不可

ワークフローまたは分散トランザクションの操作の 1 つが失敗する。

検出。 N 回再試行した後で、まだ失敗します。

復旧:

• 軽減計画としては、スケジューラー エージェント スーパーバイザー パターンを実装して、ワークフロー全体を管理します。
• タイムアウト時に再試行しないでください。 このエラーの場合、成功する確率は高くありません。
• 後で再試行するため、キューに作業を格納します。

診断 補正アクションなど、(成功と失敗を含む) すべての操作をログに記録します。 相関 ID を使用して、同じトランザクション内のすべての操作を追跡できるようにします。

リモート サービスの呼び出しが失敗する。

検出。 HTTP エラー コード。

復旧:

1. 一時的な障害の場合は再試行します。
2. N 回試みても呼び出しが失敗する場合は、フォールバック アクションを実行します。 (アプリケーション固有。)
3. サーキット ブレーカー パターンを実装し、障害の連鎖を回避します。

診断 リモート呼び出しのすべてのエラーをログに記録します。

次のステップ

Azure Well-Architected Framework の「回復性と依存関係」を参照してください。 障害のリスクを回避するために、システムに障害復旧の機能を備えさせるには、初めからアーキテクチャと設計フェーズの一部に組み込む必要があります。