ForHosting KIT · 開発者向けツール

再試行用の指数バックオフスケジュールを計算

この指数バックオフ計算ツールは、4 つの再試行設定から正確な遅延一覧を作成します。最初の再試行までの遅延、増加倍率、遅延の上限、試行回数をご指定ください。入力した時間単位のまま、各再試行前の待機時間を表示します。設定の確認、クライアント動作の文書化、ポリシーの比較、本番導入前に長すぎる復旧時間を見つける用途にお役立ていただけます。

● Beta無料・ブラウザ内で実行

無料で実行 API仕様を見る

ご利用方法ウェブAPIメールTelegramアプリ近日

同じ時間単位で再試行ポリシーを設定します

まず、最初の再試行前に待機する基本遅延をご指定ください。ミリ秒や秒など、設定対象のシステムに合う単位を選び、最大遅延にも同じ単位をお使いください。指数バックオフの計算方法は単位が変わっても同じため、本ツールでは特定の単位を固定していません。倍率は、上限適用前の遅延が増える速さを決めます。2 を指定すると待機時間は順番に 2 倍になり、1 なら一定間隔になります。試行回数は最初の処理を含まず、再試行だけを数えます。たとえば 5 を入力すると、1 から 5 まで番号が付いた 5 件の遅延が返されます。この違いを明確にすると、運用手順書や設定レビューでよく起きる 1 回分の数え違いを防げます。基本遅延は正数、倍率は 1 以上、最大遅延は正数、試行回数は 1 から 1000 までの整数である必要があります。これにより、有効なスケジュールを保ち、出力件数も制限できます。アプリケーションがミリ秒を使う場合は、コピーした結果にも単位を明記し、後から秒と誤解されないようにしてください。

増加方法と最大遅延の上限を確認します

n 回目の再試行について、上限適用前の遅延は、基本遅延に倍率の n マイナス 1 乗を掛けた値です。返される遅延は、その値と最大遅延のうち小さい方になります。たとえば基本値 250、倍率 2、上限 2,000 なら、250、500、1,000、2,000 と増え、それ以降も 2,000 です。上限が基本遅延より小さい場合も、最初から上限が適用されます。基本値が 10 で上限が 3 なら、すべて 3 になります。この動作により厳密な最大値が守られ、通常とは異なる設定も自動で書き換えられず、そのまま確認できます。実装は無制限のべき乗計算に頼らず、反復的に値を進め、上限に達した時点で増加を止めます。そのため、非常に大きな倍率でも JSON 結果に無限値を混入させず、決定的な結果を維持します。このスケジュールにはランダムなジッターを含めていません。テスト、文書、比較に使える基礎的な決定論的ポリシーを示すためです。ジッターは、ご利用のクライアントライブラリの正確な規則に従って別途追加してください。

再試行の集中を避けてスケジュールを適用します

再試行ポリシーを公開する前に、出力を使って時間範囲をご確認ください。短い基本遅延は問題がないように見えても、高い倍率では後半の試行がすぐ上限に達し、全体の復旧時間が大幅に長くなることがあります。各待機時間を、リクエストのタイムアウト、キューの可視性期間、レート制限の解除時刻、利用者が許容できる最大時間と比較してください。本ツールが示すのは再試行前の待機時間です。最初のリクエストの処理時間や、失敗した各試行で実行された作業時間は含みません。完全な最悪時間を見積もる場合は、それらを別途加算してください。分散システムでは、共通障害の後に決定的なスケジュールを使うと、多数のクライアントが同時に再試行する場合があります。本番クライアントでは、計算結果を上限または中心値として維持しつつ、負荷を分散するために範囲を限定したランダムジッターを加える方法が一般的です。この機能はリクエストを実行せず、待機せず、外部サービスへ接続せず、エラーが再試行可能かどうかも判断しません。ネットワークや保存状態を使わず、算術的なスケジュールだけを計算します。ブラウザーでは無料で、API 自動化はリクエストごとに $0.002 です。

活用例

SDK の再試行設定を確認します

クライアント設定を承認する前に、提案されたパラメーターを具体的な待機時間へ変換できます。

障害復旧時間を文書化します

べき乗を手計算せずに、試行ごとの正確なスケジュールを運用手順書へ記載できます。

設定生成ツールをテストします

生成された再試行ポリシーを、上限付きの決定的なスケジュールと自動的に比較できます。

よくある質問

どの時間単位を使用しますか？

一貫していれば任意の単位をご利用いただけます。base_delay がミリ秒なら、返される遅延と max_delay もミリ秒です。

試行回数に最初のリクエストは含まれますか？

含まれません。最初のリクエスト後の再試行数であり、スケジュールには指定数と同じ件数が含まれます。

最初の再試行にも上限が適用されますか？

はい。最初を含むすべての遅延に上限が適用されるため、max_delay は base_delay より小さくても構いません。

結果にはランダムジッターが含まれますか？

含まれません。決定論的な指数スケジュールを計算します。ジッターはクライアントの規則に従って別途適用してください。

上限に達した後はどうなりますか？

指定されたスケジュールでは、その再試行以降の遅延がすべて max_delay のままになります。

開発者向け — APIアクセス

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

エンドポイント

POSThttps://api.kit.forhosting.com/dev2/retry-backoff-schedule

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

お使いのスタックから呼び出す

curl -X POST https://api.kit.forhosting.com/dev2/retry-backoff-schedule \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}'

const res = await fetch("https://api.kit.forhosting.com/dev2/retry-backoff-schedule", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "base_delay": 250,
    "multiplier": 2,
    "max_delay": 8000,
    "attempts": 6
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev2/retry-backoff-schedule",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "base_delay": 250,
    "multiplier": 2,
    "max_delay": 8000,
    "attempts": 6
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/retry-backoff-schedule", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/retry-backoff-schedule", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

リクエスト例

{
  "base_delay": 250,
  "multiplier": 2,
  "max_delay": 8000,
  "attempts": 6
}

レスポンス例

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.retry_backoff_schedule",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

料金

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

制限

max_attempts 1000

エラー

HTTP	コード	意味
`401`	`unauthorized`	APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
`402`	`insufficient_balance`	残高が不足しています。チャージ後に再度お試しください。
`404`	`unknown_type`	指定されたタスクタイプは存在しません。タイプ名を確認してください。
`429`	`rate_limited`	リクエストが多すぎます。しばらく待ってから再度お試しください。

KITの完全なドキュメントを見る →