クラウド要求の再試行の構成

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：2分

    • クラウド要求の再試行の構成では、ディスカバリー中にクラウドプロバイダーによって要求が抑制されると、要求を再試行するカスタマイズ可能な方法を提供します。ディスカバリーとサービスマッピングパターン には、AWS および Azure の再試行構成が含まれています。含まれている構成をカスタマイズしたり、独自の構成を作成したりできます。

    ディスカバリーアドミンとクラウドアドミンは、次の場所で要求の再試行構成にアクセスできます。 All (すべて) > Discovery > クラウド要求の再試行の構成. プロバイダーごとに 1 つの構成を作成できます。

    再試行フレームワークでは、要求が抑制されると、プロバイダーに定義された再試行構成を使用して、最終的な応答を ApiCommand クラスに返す前に、再試行を処理します。
    • AwsApiCommand
    • AzureApiCommand

    再試行構成は、MID サーバー プロパティ、mid.cloud.discovery.retry.configuration を介して MID サーバー と同期されます。

    次の再試行戦略があります。
    • 指数バックオフ
    • 応答ヘッダーバックオフ
    • カスタムバックオフ

    指数バックオフ

    次の構成例の場合：
    設定 値
    最大再試行回数 3
    応答コード 429
    ベース遅延 (ミリ秒) 1000
    最大遅延 (ミリ秒) 10000
    追加の遅延ウィンドウ (ミリ秒) 1500
    指数バックオフ再試行戦略は次のように機能します。
    • 1 回目の再試行：バックオフ乗数は 0 〜 1 の間でランダムに選択されます。最大遅延値は 400 ミリ秒 (400 * 1) です。
    • 2 回目の再試行：バックオフ乗数は 0 〜 3 の間でランダムに選択されます。最大遅延値は 1200 ミリ秒 (400 * 3) です。
    • 3 回目の再試行：バックオフ乗数は 0 〜 7 の間でランダムに選択されます。最大遅延値は 2800 ミリ秒 (400 * 7) です。

    後続の再試行で、遅延が 10000 (最大遅延) を超えると、10000 が初期遅延として使用されます。

    初期遅延が生成されると、遅延にジッターが追加されます。ジッターウィンドウは、 [追加の遅延ウィンドウ (ミリ秒)] フィールドで定義されます。0 〜 1500 のランダムな値が選択され、初期遅延に追加されます。

    初期遅延が 500 の場合、最終遅延 (ジッターあり) は 500 ～ 2000 ミリ秒の値になります。

    応答ヘッダーバックオフ

    次の構成例の場合：
    設定 値
    最大再試行回数 3
    応答コード 429
    応答ヘッダー 再試行後
    応答ヘッダー遅延単位 秒
    追加の遅延ウィンドウ (ミリ秒) 1500
    応答ヘッダーバックオフ戦略は次のように機能します。
    • サーバー応答からヘッダー Retry-After の値をフェッチします。
    • Retry-After を 1000 で乗算してミリ秒に変換します。

    初期遅延が生成されると、遅延にジッターが追加されます。ジッターウィンドウは、 [追加の遅延ウィンドウ (ミリ秒)] フィールドで定義されます。0 〜 1500 のランダムな値が選択され、初期遅延に追加されます。

    初期遅延が 2000 の場合、最終遅延 (ジッターあり) は 2000 ～ 3500 ミリ秒の値になります。

    カスタムバックオフ

    カスタムバックオフの再試行戦略では、[最大再試行回数] と [応答コード] を定義し、独自の [MID スクリプトインクルード] を作成して、getDelay() 関数を使用して要求を再試行する方法を定義します。詳細については、「スクリプトインクルード」を参照してください。