トレーニング
ラーニング パス
ソリューション アーキテクト: Microsoft Power Platform のソリューションを設計する - Training
ソリューション アーキテクトがソリューションを設計する方法について説明します。
サーキット ブレーカー パターンは、アプリケーションがリモート サービスまたはリソースに接続したときに、回復にさまざまな時間がかかる可能性がある障害を処理するのに役立ちます。 サーキット ブレーカーは、障害が検出された後、障害のあるサービスへのアクセスを一時的にブロックします。 このアクションにより、システムが効果的に回復できるように、試行が繰り返し失敗するのを防ぐことができます。 このパターンにより、アプリケーションの安定性と回復性が向上します。
分散環境では、一時的な障害が原因でリモート リソースとサービスの呼び出しが失敗する可能性があります。 一時的な障害には、オーバーコミットまたは一時的に使用できないリソース、低速なネットワーク接続、タイムアウトなどがあります。 通常、これらの障害は短時間で修正されます。 これらの障害を管理するには、再試行パターンなどの戦略を使用するようにクラウド アプリケーションを設計する必要があります。
予期しないイベントにより、修正に時間がかかるエラーが発生する可能性があります。 これらの障害は、部分的な接続の損失から完全なサービス障害までの重大度の範囲で発生する可能性があります。 このような状況では、成功する可能性が低い操作をアプリケーションが継続的に再試行しないようにする必要があります。 代わりに、アプリケーションは失敗した操作をすばやく認識し、それに応じてエラーを処理する必要があります。
サービスがビジー状態の場合、システムの一部で障害が発生すると、連鎖的な障害が発生する可能性があります。 たとえば、サービスを呼び出してタイムアウトを実装する操作を構成できます。サービスがこの期間内に応答しなかった場合、操作はエラー メッセージで応答します。
ただし、この戦略では、タイムアウト期間が経過するまで、同じ操作に対する同時要求をブロックできます。 これらのブロックされた要求は、メモリ、スレッド、データベース接続などの重要なシステム リソースを保持する可能性があります。 この問題はリソースを使い果たす可能性があり、同じリソースを使用する必要があるシステムの他の関係のない部分が失敗する可能性があります。
このような状況では、操作はすぐに失敗し、成功する可能性がある場合にのみサービスの呼び出しを試みる必要があります。 この問題を解決するには、短いタイムアウトを設定します。ただし、ほとんどの場合、操作が成功するのに十分な時間がタイムアウトであることを確認します。
サーキット ブレーカー パターンは、失敗する可能性のある操作をアプリケーションが繰り返し実行することを防ぐのに役立ちます。 このパターンにより、障害が修正されるのを待たずに、または障害が永続的であると判断する際に CPU サイクルを無駄にすることなく、アプリケーションの実行を継続できます。 サーキット ブレーカー パターンを使用すると、アプリケーションで障害が解決されたタイミングを検出することもできます。 エラーが解決された場合、アプリケーションはもう一度操作の呼び出しを試みることができます。
注意
サーキット ブレーカー パターンは、再試行パターンとは異なる目的を果たします。 再試行パターンを使用すると、アプリケーションは最終的に成功することを期待して操作を再試行できます。 サーキット ブレーカー パターンを使用すると、アプリケーションが失敗する可能性のある操作を実行できなくなります。 アプリケーションは、サーキット ブレーカーによって操作を呼び出す再試行パターンを使用することで、これら 2 つのパターンを組み合わせることができます。 ただし、再試行ロジックは、サーキット ブレーカーが返す例外に対して機密性が高く、サーキット ブレーカーが障害が一時的ではないことを示す場合は再試行を停止する必要があります。
サーキットブレーカーは、失敗する恐れのある操作の代行役として機能します。 プロキシは、最近のエラーの数を監視し、この情報を使用して、操作の続行を許可するか、すぐに例外を返すかを決定する必要があります。
プロキシは、次の状態を含むステート マシンとして実装できます。 これらの状態は、電気回路遮断器の機能を模倣します。
終了: アプリケーションからの要求が操作にルーティングされます。 プロキシは、最近のエラーの数を保持します。 操作の呼び出しが失敗した場合、プロキシはこのカウントをインクリメントします。 最近のエラーの数が特定の期間内に指定されたしきい値を超えた場合、プロキシは Open 状態になり、タイムアウト タイマーが開始されます。 タイマーの有効期限が切れると、プロキシは Half-Open 状態になります。
注意
タイムアウト中に、システムはエラーの原因となった問題を解決してから、アプリケーションが操作を再試行できるようにします。
開く: アプリケーションからの要求はすぐに失敗し、アプリケーションに例外が返されます。
Half-Open: アプリケーションからの要求の数に制限があり、操作のパススルーと呼び出しが許可されます。 これらの要求が成功した場合、サーキット ブレーカーは、障害の原因となった障害が修正され、サーキット ブレーカーが Closed 状態に切り替わると見なします。 エラー カウンターがリセットされます。 要求が失敗した場合、サーキット ブレーカーは障害がまだ存在すると見なされるため、オープン 状態に戻ります。 システムが障害から回復できるように、タイムアウト タイマーを再起動します。
注意
ハーフオープン 状態は、復旧サービスが突然要求であふれないようにするのに役立ちます。 サービスが復旧すると、復旧が完了するまで、限られた量の要求をサポートできる場合があります。 ただし、復旧の進行中は、大量の作業が発生すると、サービスがタイムアウトしたり、再び失敗したりする可能性があります。
次の図は、各状態のカウンター操作を示しています。
Closed 状態のエラー カウンターは時間ベースです。 定期的な間隔で自動的にリセットされます。 この設計は、サーキットブレーカーが偶発的に障害が発生した場合に、オープン 状態に入らないようにする手助けをします。 エラーしきい値は、指定した間隔で指定した数のエラーが発生した場合にのみ、オープン 状態をトリガーします。
Half-Open 状態の成功カウンターには、操作の呼び出しが成功した回数が記録されます。 サーキット ブレーカーは、指定された数の連続した操作の呼び出しが成功した後、Closed 状態に戻ります。 呼び出しが失敗した場合、サーキット ブレーカーはすぐに Open 状態になり、成功カウンターは次に Half-Open 状態に入るとリセットされます。
注意
システム回復は、障害が発生したコンポーネントの復元や再起動、ネットワーク接続の修復などの外部操作に基づいています。
サーキット ブレーカー パターンにより、エラーからのシステムの復旧中の安定性が保たれ、パフォーマンスに対する影響が最小限に抑えられます。 システムの応答時間を維持するのに役立ちます。 このパターンでは、操作がタイムアウトするのを待つ、または戻らないのを待つのではなく、失敗する可能性が高い操作の要求が迅速に拒否されます。 サーキット ブレーカーが状態を変更するたびにイベントを発生させる場合、この情報は、保護されたシステム コンポーネントの正常性を監視したり、サーキット ブレーカーが Open 状態に切り替えたときに管理者に警告したりするのに役立ちます。
このパターンは、さまざまな種類の障害に合わせてカスタマイズおよび調整できます。 たとえば、サーキット ブレーカーにタイムアウト タイマーを増やすことができます。 サーキット ブレーカーは、最初に数秒間、オープン 状態にすることができます。 エラーが解決しない場合は、タイムアウトを数分に増やし、それに応じて調整します。 場合によっては、エラーを返して例外を発生させる代わりに、オープン 状態は、アプリケーションにとって意味のある既定値を返すことができます。
注意
従来、サーキット ブレーカーは、障害数やタイムアウト期間など、構成済みのしきい値に依存していました。 このアプローチにより、決定論的ですが、場合によっては最適でない動作が発生しました。
AI と機械学習を使用するアダプティブ手法では、リアルタイムのトラフィック パターン、異常、および過去の障害率に基づいてしきい値を動的に調整できます。 このアプローチにより、回復性と効率が向上します。
このパターンを実装するときは、次の要因を考慮してください。
例外処理: サーキット ブレーカーを介して操作を呼び出すアプリケーションは、操作が使用できない場合に例外を処理できる必要があります。 例外管理は、アプリケーションに基づいています。 たとえば、アプリケーションの機能が一時的に低下したり、別の操作を呼び出して同じタスクを実行したり、同じデータを取得したり、ユーザーに例外を報告して後でもう一度やり直すように依頼したりする場合があります。
例外の種類: 要求エラーの理由は重大度によって異なる場合があります。 たとえば、リモート サービスがクラッシュし、復旧に数分かかる場合や、オーバーロードされたサービスによってタイムアウトが発生するため、要求が失敗する可能性があります。サーキット ブレーカーは、発生する例外の種類を調べて、これらの例外の性質に基づいて戦略を調整できる場合があります。 たとえば、使用できないサービスによって発生したエラーの数と比較して、サーキット ブレーカーを Open 状態にトリガーするには、より多くのタイムアウト例外が必要になる場合があります。
監視: サーキット ブレーカーは、失敗した要求と成功した要求の両方を明確に監視し、運用チームがシステムの正常性を評価できるようにする必要があります。 分散トレースを使用して、サービス間でエンドツーエンドの可視性を実現します。
回復性: サーキット ブレーカーは、保護する操作の、可能性の高い復旧パターンに一致するよう構成してください。 たとえば、サーキット ブレーカーが長期間 オープン 状態のままである場合、障害の理由が解決された場合でも例外が発生する可能性があります。 同様に、サーキット ブレーカーは、オープン 状態から Half-Open 状態にすばやく切り替わると、アプリケーションの応答時間が変動し、応答時間が短縮される可能性があります。
失敗した操作のテスト: タイマーを使用して ハーフオープン 状態に切り替えるタイミングを決定するのではなく、オープン 状態で、サーキット ブレーカーはリモート サービスまたはリソースに定期的に ping を実行して、使用可能かどうかを判断できます。 この ping は、以前に失敗した操作の呼び出しを試みるか、リモート サービスが提供する特別な正常性チェック操作を使用できます。 詳細については、「正常性エンドポイント監視パターン」を参照してください。
手動オーバーライド: 障害が発生した操作の復旧時間が非常に変動する場合は、管理者がサーキット ブレーカーを閉じて障害カウンターをリセットできるようにする手動リセット オプションを指定する必要があります。 同様に、管理者は、保護された操作が一時的に使用できない場合に、サーキット ブレーカーを Open 状態に強制し、タイムアウト タイマーを再起動できます。
コンカレンシー: アプリケーションの多数の同時実行インスタンスが同じサーキット ブレーカーにアクセスできます。 この実装は、同時要求をブロックしたり、操作へのそれぞれの呼び出しに過剰なオーバーヘッドを加えたりしません。
リソースの区別: 基になる独立したプロバイダーが複数存在する可能性がある場合は、1 種類のリソースに対して単一のサーキット ブレーカーを使用する場合は注意が必要です。 たとえば、複数のシャードを含むデータ ストアでは、1 つのシャードに完全にアクセスでき、別のシャードで一時的な問題が発生する可能性があります。 これらのシナリオのエラー応答がマージされた場合、障害が発生する可能性がある場合でも、アプリケーションが一部のシャードへのアクセスを試みる可能性があります。 また、成功する可能性が高い場合でも、他のシャードへのアクセスがブロックされる可能性があります。
高速なサーキット ブレーキング: エラー応答には、サーキット ブレーカーをすぐにトリップさせ、最短時間トリップしたままのするのに十分な情報が含まれていることがあります。 たとえば、オーバーロードされた共有リソースからのエラー応答は、アプリケーションがすぐに再試行するのではなく、数分後に再試行する必要があることを示している可能性があります。
マルチリージョンデプロイ: 単一リージョンまたはマルチリージョンのデプロイ用にサーキット ブレーカーを設計できます。 マルチリージョンデプロイ用に設計するには、グローバル ロード バランサーまたはカスタムリージョン対応の回線ブレーク戦略を使用して、制御されたフェールオーバー、待機時間の最適化、規制コンプライアンスを確保します。
サービス メッシュ サーキット ブレーカー: アプリケーション 層で、またはクロスカットの抽象化された機能としてサーキット ブレーカーを実装できます。 たとえば、サービス メッシュでは、アプリケーション コードを変更せずに、サイドカーまたはスタンドアロン機能としてサーキット ブレーキングをサポートすることがよくあります。
注意
クライアントを調整している場合はサービスから HTTP 429 (要求が多すぎます) が返され、サービスが利用できない場合は HTTP 503 (サービスが利用できません) が返される可能性があります。 応答には、遅延の予想期間など、他の情報を含めることができます。
失敗した要求の再生: オープン状態では、単にすぐに失敗させるのではなく、サーキット ブレーカーでジャーナルへの各要求の詳細を記録して、リモート リソースやサービスが使用可能になったときにこれらの要求が再生されるように準備することもできます。
外部サービスの不適切なタイムアウト: サーキット ブレーカーは、タイムアウト期間が長い外部サービスの障害からアプリケーションを完全に保護できない可能性があります。 タイムアウトが長すぎる場合、サーキット ブレーカーを実行するスレッドが、操作が失敗したことをサーキット ブレーカーが示す前に、長期間ブロックされる可能性があります。 この間、他の多くのアプリケーション インスタンスも、サーキット ブレーカーを介してサービスを呼び出し、失敗する前に多数のスレッドを関連付けようとすることがあります。
コンピューティングの多様化への適応性: サーキット ブレーカーは、サーバーレスからコンテナー化されたワークロードまで、さまざまなコンピューティング環境を考慮する必要があります。コールド スタートやスケーラビリティなどの要因が障害処理に影響を与えます。 アダプティブ アプローチでは、コンピューティングの種類に基づいて戦略を動的に調整できます。これにより、異種アーキテクチャ全体の回復性を確保できます。
このパターンは次の状況で使用します。
これらの操作が失敗する可能性が高い場合は、過剰なリモート サービス呼び出しまたは共有リソースへのアクセス要求を停止することで、連鎖障害を防ぐ必要があります。
マルチリージョンの回復性を強化するために、リアルタイムの障害信号に基づいてインテリジェントにトラフィックをルーティングする必要があります。
サービス レベルの目標を維持し、待機時間の長いサービスによるパフォーマンスの低下を回避できるように、低速の依存関係から保護する必要があります。
断続的な接続の問題を管理し、分散環境での要求エラーを減らす必要があります。
このパターンは、次の場合に適さない場合があります。
メモリ内データ構造など、アプリケーション内のローカル プライベート リソースへのアクセスを管理する必要があります。 この環境では、サーキット ブレーカーによってシステムにオーバーヘッドが追加されます。
アプリケーションのビジネス ロジックで例外を処理する代わりに使用する必要があります。
既知の再試行アルゴリズムで十分であり、依存関係は再試行メカニズムを処理するように設計されています。 このシナリオでは、アプリケーションのサーキット ブレーカーによって、不要な複雑さがシステムに追加される可能性があります。
サーキット ブレーカーのリセットを待機すると、許容できない遅延が発生する可能性があります。
メッセージ駆動型アーキテクチャまたはイベント駆動型アーキテクチャでは、失敗したメッセージを手動処理または遅延処理のためにデッドレターキューにルーティングすることが多いです。 多くの場合、組み込みの障害分離と再試行メカニズムで十分です。
障害復旧は、グローバル ロード バランサーやサービス メッシュの正常性チェックなど、インフラストラクチャまたはプラットフォーム レベルで管理されます。
ワークロードの設計でサーキット ブレーカー パターンを使用して、Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。
| 柱 | このパターンが柱の目標をサポートする方法 |
|---|---|
| 信頼性設計の決定は、故障に対するワークロードの回復性を高め、障害の発生後にワークロードを完全な機能状態に回復させるために役立ちます。 | このパターンは、依存関係のエラーがオーバーロードされるのを防ぐのに役立ちます。 このパターンを使用して、ワークロードの正常な低下をトリガーします。 自動回復機能を備えたサーキット ブレーカーを組み合わせて、自己保存と自己復旧を実現します。 - RE: 03 障害モード分析 - 一時的な障害 - RE:07 自己保護 |
| パフォーマンス効率 は、スケーリング、データ、およびコードの最適化を通じて、ワークロード の需要を効率的に満たすのに役立ちます。 | このパターンにより、エラー時の再試行アプローチが回避され、依存関係の復旧中にリソースが過剰に使用される可能性があり、復旧を試みる依存関係のパフォーマンスが過負荷になることがあります。 - PE:07 コードとインフラストラクチャ - PE:11 ライブ問題の応答 |
このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。
この例では、Azure Cosmos DB の永続無料階層を使用してクォータオーバーランを防ぐため、サーキットブレーカーパターンを実装します。 このレベルは主に重要でないデータ用であり、1 秒あたりのリソース ユニットの特定のクォータを割り当てる容量計画の下で動作します。 季節的なイベント中に、需要が提供された容量を超える可能性があり、結果として 429 応答が発生する可能性があります。
需要の急増が発生すると、Azure Monitorアラートが動的しきい値を用いて、データベースの容量を増やす必要があることを運用チームと管理チームに予測して通知します。 同時に、過去のエラー パターンを使用して調整されたサーキット ブレーカーが作動し、連鎖的な障害を防止します。 この状態では、アプリケーションは既定の応答またはキャッシュされた応答を返すことによって適切に低下します。 アプリケーションは、システム全体の安定性を維持しながら、特定のデータが一時的に使用できないことをユーザーに通知します。
この戦略により、ビジネスの正当性に合った回復性が強化されます。 ワークロード チームがコストの増加を意図的に管理し、予期せず運用コストを増加させることなくサービス品質を維持できるように、容量の急増を制御します。 需要が収まるか容量の増加が確認されると、サーキット ブレーカーがリセットされ、アプリケーションは技術目標と予算目標の両方に合った完全な機能に戻ります。
このアーキテクチャの Visio ファイル をダウンロードします。
システムは正常に動作し、すべての要求は、
429HTTP 応答を返さずにデータベースに到達します。サーキットブレーカーは閉じたままで、既定の応答やキャッシュされた応答は必要ありません。
サーキット ブレーカーは、最初の
429応答を受信すると、オープン 状態になります。後続の要求は直ちに中断され、デフォルトの応答またはキャッシュされた応答が返され、ユーザーに一時的なサービス低下を通知します。 アプリケーションは、それ以上のオーバーロードから保護されます。
Azure Monitor はログとテレメトリ データを受信し、動的しきい値に対して評価します。 アラート ルールの条件が満たされると、アラートがトリガーされます。
アクション グループは、オーバーロード条件を運用チームに事前に通知します。
ワークロード チームの承認後、運用チームはプロビジョニングされたスループットを増やして、負荷が自然に沈静化した場合に過負荷を軽減したり、スケーリングを遅らせることができます。
定義済みのタイムアウトの後、サーキット ブレーカーは、限られた数の試用版要求を許可する ハーフオープン 状態になります。
これらの試用要求が
429応答を返さずに成功した場合、ブレーカーは Closed 状態にリセットされ、通常の操作はフロー A に復元されます。障害が解決しない場合、ブレーカーは Open 状態 (フロー B) に戻ります。
Azure App Service は、クライアント要求のプライマリ エントリ ポイントとして機能する Web アプリケーションをホストします。 アプリケーション コードは、サーキット ブレーカー ポリシーを適用し、回線が開いているときに既定またはキャッシュされた応答を提供するロジックを実装します。 このアーキテクチャは、ダウンストリーム システムでの過負荷を防ぎ、ピーク時の需要または障害時のユーザー エクスペリエンスを維持するのに役立ちます。
Azure Cosmos DB は、アプリケーションのデータ ストアの 1 つです。 Free レベルを介して重要でないデータを提供します。これは、小規模な運用環境のワークロードに最適です。 サーキット ブレーカー メカニズムは、需要の高い期間中にデータベースへのトラフィックを制限するのに役立ちます。
Azure Monitor は、一元化された監視ソリューションとして機能します。 すべてのアクティビティ ログを集計して、包括的でエンドツーエンドの可観測性を確保します。 Azure Monitor は、App Service からログとテレメトリ データを受信し、集計と分析のために Azure Cosmos DB から主要なメトリック (
429応答の数など) を受け取ります。Azure Monitor アラートは、アラート ルールを動的しきい値と比較して、履歴データに基づいて潜在的な停止を特定します。 定義済みのアラートは、しきい値に違反したときに運用チームに通知します。
場合によっては、ワークロード チームがプロビジョニング済みスループットの増加を承認する場合がありますが、負荷が高すぎないため、運用チームはシステムが単独で復旧できることを予測しています。 このような場合、サーキット ブレーカーのタイムアウトは自然に経過します。 この間に、
429応答が停止した場合、しきい値の計算によって長時間の停止が検出され、学習アルゴリズムから除外されます。 その結果、次に過負荷が発生したときに、しきい値は Azure Cosmos DB のエラー率上昇を待機するため、通知が遅れます。 この調整により、サーキット ブレーカーは即時アラートなしで問題を処理できるため、コストと運用効率が向上します。
Reliable Web App パターン は、クラウドに収束する Web アプリケーションにサーキット ブレーカー パターンを適用します。
再試行パターン では、以前に失敗した操作を透過的に再試行することで、アプリケーションがサービスまたはネットワーク リソースに接続しようとしたときに予想される一時的な障害を処理する方法について説明します。
正常性エンドポイント監視パターン では、サービスが公開するエンドポイントに要求を送信することで、サーキット ブレーカーがサービスの正常性をテストする方法について説明します。 サービスは、その状態を示す情報を返す必要があります。