すべてのプロダクト
Search
ドキュメントセンター

Microservices Engine:サーキットブレーカー ルールの設定

最終更新日:Aug 28, 2026

ダウンストリームサービスの応答が遅い、またはエラー率が高い場合、障害が連鎖的に発生し、アプリケーション全体のパフォーマンスが低下する可能性があります。Microservices Engine (MSE) のサーキットブレーカーは、これらのダウンストリームの依存関係を監視し、設定されたしきい値を超えると自動的にリクエストの送信を停止します。クールダウン期間の後、MSE はリクエストを徐々に再び許可することで、回復を試みます。

サーキットブレーカーは、弱い依存関係、つまりアプリケーションが一時的に利用できなくなっても許容できるダウンストリームサービスを対象とします。障害が即座に伝播する必要がある重要な依存関係については、代わりにリトライやフォールバック戦略を使用してください。

仕組み

サーキットブレーカーは、3 つの状態で遷移します。

  1. クローズ (通常運用):すべてのリクエストが通過します。MSE は、設定された時間枠内でメトリクス (スローコール率または異常率) を追跡します。

  2. オープン (遮断):追跡対象のメトリクスが設定されたしきい値を超え、最小リクエスト数を満たすと、MSE は設定された期間、すべてのリクエストをブロックします。ブロックされたリクエストは、タイムアウトを待たずに即座に失敗します。

  3. ハーフオープン (回復試行):サーキットブレーカーの遮断期間が経過すると、MSE はテストとして次のリクエストを通過させます。

    • テストリクエストが成功した場合、サーキットブレーカーは クローズ 状態に戻ります。

    • テストリクエストが失敗した場合、サーキットブレーカーは再び、全期間にわたって オープン 状態になります。

MSE は、単一のテストリクエストに依存せず、複数の段階にわたって許可されるリクエストの割合を徐々に増やす 段階的な回復 もサポートしています。

前提条件

開始する前に、以下をご確認ください:

サーキットブレーカー ルールの作成

  1. MSE コンソールにログインし、上部のナビゲーションバーでリージョンを選択します。

  2. 左側のナビゲーションウィンドウで、マイクロサービス管理センター > アプリケーション管理 を選択します。

  3. [Application list] ページで、対象のアプリケーションをクリックします。次に、以下のいずれかの方法で [Add Circuit Breaking Rule] ダイアログボックスを開きます。

    • 方法 A:左側メニューで [API Details] をクリックします。[WEB service] タブで [Client] タブをクリックします。インターフェイスを選択し、[Circuit Breaking] タブをクリックしてから、[サーキットブレーカー ルールの追加] をクリックします。

    • 方法 B:左側メニューで [Traffic management] をクリックします。[Flow protection] タブをクリックし、次に [サーキットブレーカー ルール] タブをクリックしてから、[サーキットブレーカー ルールの追加] をクリックします。

  4. [Add Circuit Breaking Rule] ダイアログボックスで、以下のパラメーターを設定し、[新規作成] をクリックします。

ルールパラメーター

パラメーター 説明 有効な値
[インターフェイス名] このルールで保護するインターフェイス。 --
[統計期間] メトリクスを計算するための統計ウィンドウの期間。 1 秒~120 分
[最小リクエスト数] サーキットブレーカーが作動する前に、時間枠内で必要とされる最小リクエスト数。実際のリクエスト数がこの値を下回る場合、メトリクスの比率にかかわらずサーキットブレーカーはクローズ状態を維持します。 正の整数
[しきい値タイプ] サーキットブレーカーをトリップさせるかどうかを評価するために使用されるメトリクス。 [スローコール率 (%)]、[異常率 (%)]
[スローコールRT] スローコールを定義する応答時間しきい値 (ミリ秒)。この値より長くかかるリクエストはスローコールとしてカウントされます。[しきい値タイプ][スローコール率 (%)] に設定されている場合にのみ適用されます。 正の整数 (ms)
[遮断率しきい値] サーキットブレーカーをトリガーするパーセンテージのしきい値。スローコール率の場合、これはスローコールのパーセンテージです。異常率の場合、これは異常リクエストのパーセンテージです。 0~100 (%)
[遮断期間 (秒)] サーキットブレーカーがオープン状態を維持する時間。この期間中、保護されたインターフェイスへのすべてのリクエストは失敗します。 正の整数 (秒)
[サーキットブレーカーポリシー] 遮断期間が経過した後の回復戦略。 [単一検出による回復]、[段階的な回復]

注: [統計期間][最小リクエスト数] パラメーターは連携して機能します。たとえば、1 秒のウィンドウと最小リクエスト数 10 を設定すると、トラフィックの少ないインターフェイス (1 秒あたり 10 リクエスト未満) ではサーキットブレーカーが作動しません。トラフィックの少ないインターフェイスには、より長いウィンドウとより低い最小リクエスト数を使用してください。

回復ポリシー

[単一検出による回復]

遮断期間が経過した後、MSE は次のリクエストをテストプローブとして許可します。

  • リクエストが成功した場合 (応答時間がスローコール RT のしきい値未満、またはエラーが発生しない場合) 、サーキットブレーカーはクローズ状態になり、通常のトラフィックが再開されます。

  • リクエストが失敗した場合、サーキットブレーカーは再び全期間にわたってオープン状態になります。

[段階的な回復]

単一のテストリクエストの代わりに、MSE は複数の回復段階にわたってトラフィック率を徐々に増加させます。これにより、回復直後にサーキットブレーカーが再びトリップするリスクが低減されます。

さらに 2 つのパラメーターを設定します。

パラメーター 説明
[回復段階数] トラフィックを 100% に戻すために使用される段階の数。
[ステップごとの最小合格数] MSE が次の段階に進むかどうかを評価する前に、各段階で必要となる最小通過リクエスト数。

各段階で許可されるトラフィックのパーセンテージは、次のように計算されます。

トラフィック率 = 100% / 回復段階数

たとえば、回復段階が 3 つで、段階ごとに最小 5 リクエストが設定されている場合:

段階 許可されるトラフィック 動作
1 33% MSE はリクエストの 33% を許可します。少なくとも 5 つのリクエストが通過した後、MSE はメトリクスをチェックします。しきい値を下回っている場合は段階 2 に進みます。上回っている場合は、サーキットブレーカーを再度オープン状態にします。
2 67% MSE はリクエストの 67% を許可します。評価は段階 1 と同じです。
3 100% すべてのリクエストが通過します。サーキットブレーカーは完全にクローズ状態になります。

段階内のリクエスト数がステップごとの最小合格数を下回る場合、システムはすべてのリクエストが通過可能になるまで、回復段階を順次進めていきます。

スローコールによるサーキットブレーカー

シナリオ:アプリケーションが、時々応答が遅くなるサードパーティのサービスを呼び出しますが、タイムアウトによってアプリケーションのパフォーマンスが低下します。

設定

パラメーター 理由
[インターフェイス名] test 応答の遅いダウンストリームサービスを呼び出すインターフェイス。
[統計期間] 1 秒 パフォーマンス低下を迅速に検出するため。
[最小リクエスト数] 10 トラフィックの少ないインターフェイスでのトリガーを避けるため。
[しきい値タイプ] [スローコール率 (%)] エラーではなく、応答時間を監視するため。
[スローコールRT] 1000 ms 1 秒を超えるリクエストはスローコールと見なすため。
[遮断率しきい値] 80% リクエストの 80% が低速な場合にトリップするため。
[遮断期間 (秒)] 10 秒 すべてのリクエストを 10 秒間ブロックするため。
[サーキットブレーカーポリシー] [単一検出による回復] 各遮断期間の後に 1 つのリクエストをテストするため。

動作:1 秒以内に 10 件以上のリクエストが到着し、その 80% 以上が 1000 ms より長くかかった場合、サーキットブレーカーがオープン状態になります。次の 10 秒間、test インターフェイスへのすべてのリクエストは失敗します。10 秒後、MSE は 1 つのリクエストを通過させます。それが 1000 ms 未満で完了した場合、サーキットブレーカーはクローズ状態になります。そうでなければ、さらに 10 秒間オープン状態になります。

異常リクエストによるサーキットブレーカー

シナリオ:アプリケーションがサードパーティのサービスからコンテンツを表示します。異常なリクエストが急増すると、表示されるコンテンツの品質が低下し、ユーザーエクスペリエンスを損ないます。

設定

パラメーター 理由
[インターフェイス名] test 異常を返すダウンストリームサービスを呼び出すインターフェイス。
[統計期間] 1 秒 異常なリクエストの急増を迅速に検出するため。
[最小リクエスト数] 10 トラフィックの少ないインターフェイスでのトリガーを避けるため。
[しきい値タイプ] [異常率 (%)] 異常率を監視するため。
[遮断率しきい値] 80% リクエストの 80% が異常な場合にトリップするため。
[遮断期間 (秒)] 10 秒 すべてのリクエストを 10 秒間ブロックするため。
[サーキットブレーカーポリシー] [単一検出による回復] 各遮断期間の後に 1 つのリクエストをテストするため。

動作:1 秒以内に 10 件以上のリクエストが到着し、その 80% 以上が異常であった場合、サーキットブレーカーがオープン状態になります。次の 10 秒間、test インターフェイスへのすべてのリクエストは失敗します。10 秒後、MSE は 1 つのリクエストを通過させます。それが成功した場合、サーキットブレーカーはクローズ状態になります。そうでなければ、さらに 10 秒間オープン状態になります。

ベストプラクティス

適切なしきい値タイプの選択

  • 応答時間の劣化が主な懸念事項である場合 (レイテンシーがユーザーエクスペリエンスに直接影響する同期 API 呼び出しなど) は、スローコール率 を使用します。

  • 信頼性の低いサードパーティサービスへの呼び出しなど、ダウンストリームのエラーが主なリスクである場合は、異常率 を使用します。

適切なウィンドウとしきい値の設定

  • 統計期間:短いウィンドウ (1~10 秒) は問題をより速く検出しますが、トラフィックのバーストに敏感です。長いウィンドウ (1~5 分) は、トラフィックの少ないインターフェイスに対してより安定したメトリクスが得られます。

  • 最小リクエスト数:誤検知を避けるために十分に高く設定します。トラフィックの少ないインターフェイスの場合、通常、1 秒あたり 10 リクエストよりも、より長いウィンドウと組み合わせた 5~10 件の最小リクエスト数の方が信頼性が高くなります。

回復ポリシーの選択

  • 単一検出による回復 は、問題なく回復するサービス、つまり、機能するかしないかがはっきりしているサービスに適しています。

  • 段階的な回復 は、部分的に回復している可能性のあるサービスに対してより安全です。オンラインに戻ったばかりのサービスが、トラフィックの急増によって過負荷になることを防ぎます。

ルールが有効であることの確認

サーキットブレーカールールを保存した後、それが期待どおりに機能していることを確認します。

  1. 左側メニューで [Traffic management] をクリックします。[Flow protection] タブで、[サーキットブレーカー ルール] タブをクリックして、設定されているすべてのルールとそのステータスを表示します。

  2. 保護されたインターフェイスにテストトラフィックを生成し、サーキットブレーカーのメトリクスを監視して、ルールが正しくトリガーされることを確認します。

関連トピック