---
sourceDocument: Xanadu IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-operations-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

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

# クラウド要求の再試行の構成 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：2分

クラウド要求の再試行の構成では、ディスカバリー中にクラウドプロバイダーによって要求が抑制されると、要求を再試行するカスタマイズ可能な方法を提供します。ディスカバリーとサービスマッピングパターン には、AWS および Azure の再試行構成が含まれています。含まれている構成をカスタマイズしたり、独自の構成を作成したりできます。
ディスカバリーアドミニストレーターとクラウドアドミニストレーターは、 すべてディスカバリークラウド要求の再試行の構成. プロバイダーごとに 1 つの構成を作成できます。  
再試行フレームワークでは、要求が抑制されると、プロバイダーに定義された再試行構成を使用して、最終的な応答を ApiCommand クラスに返す前に、再試行を処理します。

* AwsApiCommand
* AzureApiCommand
{#cloud-request-retry-configuration__ul_vnx_nb1_b5b}

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

* 指数バックオフ
* 応答ヘッダーバックオフ
* カスタムバックオフ
{#cloud-request-retry-configuration__ul_ipy_1h1_b5b}

## 指数バックオフ {#cloud-request-retry-configuration__section_lgs_2h1_b5b}

次の構成例の場合：{#cloud-request-retry-configuration__table_chm_xw1_b5b__entry__2}

| 設定 | 値 |
|-|-|
| 最大再試行回数 | 3 |
| 応答コード | 429 |
| ベース遅延 (ミリ秒) | 1000 |
| 最大遅延 (ミリ秒) | 10000 |
| 追加の遅延ウィンドウ (ミリ秒) | 1500 |
[ ]

{#cloud-request-retry-configuration__table_chm_xw1_b5b}  
指数バックオフ再試行戦略は次のように機能します。

* 1 回目の再試行：バックオフ乗数は 0 〜 1 の間でランダムに選択されます。最大遅延値は 400 ミリ秒 (400 \* 1) です。
* 2 回目の再試行：バックオフ乗数は 0 〜 3 の間でランダムに選択されます。最大遅延値は 1200 ミリ秒 (400 \* 3) です。
* 3 回目の再試行：バックオフ乗数は 0 〜 7 の間でランダムに選択されます。最大遅延値は 2800 ミリ秒 (400 \* 7) です。
{#cloud-request-retry-configuration__ul_rwr_fx1_b5b}

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

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

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

## 応答ヘッダーバックオフ {#cloud-request-retry-configuration__section_ffr_2y1_b5b}

次の構成例の場合：{#cloud-request-retry-configuration__table_a4m_gy1_b5b__entry__2}

| 設定 | 値 |
|-|-|
| 最大再試行回数 | 3 |
| 応答コード | 429 |
| 応答ヘッダー | 再試行後 |
| 応答ヘッダー遅延単位 | 秒 |
| 追加の遅延ウィンドウ (ミリ秒) | 1500 |
[ ]

{#cloud-request-retry-configuration__table_a4m_gy1_b5b}  
応答ヘッダーバックオフ戦略は次のように機能します。

* サーバー応答からヘッダー Retry-After の値をフェッチします。
* Retry-After を 1000 で乗算してミリ秒に変換します。
{#cloud-request-retry-configuration__ul_e14_sy1_b5b}

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

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

## カスタムバックオフ {#cloud-request-retry-configuration__section_ipx_byx_f5b}

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