リクエストの検証と再試行
概要
サーバー API リクエストは、正しく送信された場合でも失敗することがあります。トラフィックの急増、短時間の停止、ネットワークの問題、または上流サービスの遅延などの一時的な問題により、成功レスポンスが妨げられることがあります。これらのエラーは通常短期間で、多くの場合自然に解決します。
このようなエラーで即座に失敗すると信頼性が低下しますが、頻繁に再試行しすぎるとサーバーに過負荷がかかる可能性があります。指数再試行は、再試行の試行を間隔を空けて行い、毎回遅延を増やすことでこれを解決します。これにより、サーバーが回復する時間が確保され、成功の可能性が向上し、より安定して信頼性の高い統合につながります。
指数再試行の実装方法
このセクションでは、指数再試行メカニズムを実装するための期待されるクライアントの動作を定義します。
ステップ 1: 通常どおりリクエストを送信する
- API リクエストを 1 回実行する
- 最初の試行では遅延を適用しない
ステップ 2: 失敗のタイプを評価する
リクエストが失敗した場合、クライアントは以下を判断する必要があります。
- HTTP レスポンスを受信したか？
- 受信した場合、HTTP ステータスコードは何か？
- 受信していない場合、ネットワークまたはトランスポートエラーが発生したか？
この分類により、再試行が許可されるかどうかが決まります。
ステップ 3: エラーが再試行可能かどうかを判断する
以下のすべてが真である場合にのみ再試行します。
- 失敗が 一時的 と見なされる
- 同じリクエストを後で再試行すると成功する可能性がある
- リクエストの再試行が安全である（冪等性があるか、保護されている）
これらの条件のいずれかが偽である場合、再試行ポリシーを試行することなくリクエストは失敗する必要があります。
ステップ 4: 再試行前に指数バックオフを適用する
再試行が許可される場合:
- 再試行する前に待機する
- 試行ごとに待機時間を指数的に増加させる
遅延は以下を満たす必要があります。
- 小さく始める（例: 500ms）
- 段階的に増加させる（例: 各リクエストで 2 倍にする）
- 妥当な最大値で上限を設ける（例: 最大 10 分）
タイムラインの例
| 試行 | 遅延 |
|---|---|
| 1 | 500 ms |
| 2 | 1 s |
| 3 | 2 s |
| 4 | 4 s |
| 5 | 8 s |
ステップ 5: 再試行を制限する
再試行ポリシーには、無限のリクエストを回避してサーバー API に過負荷をかけないように、制限を定義する必要があります。制限に達したら:
- 再試行を停止する
- 呼び出し元にエラーを表面化する
エラーコードと再試行ポリシー
このセクションでは、HTTP リクエストのエラータイプに基づいて、指数再試行をトリガーすべき場合とすべきでない場合を定義します。
| カテゴリ | 指数バックオフによる再試行 |
|---|---|
| ネットワークエラー | ✅ はい |
| 408 Request Timeout | ✅ はい |
| 429 Too Many Requests | ✅ はい |
| 460 Client Timeout | ✅ はい |
| 5xx Server Errors | ✅ はい |
| 1xx Informational Responses | ❌ いいえ |
| 2xx Successful responses | ❌ いいえ |
| 4xx Client Errors (400, 401, 403, 404, 409, 422) | ❌ いいえ |
その他の未定義のエラータイプは、行われるリクエストの成功率を向上させるために個別に特定する必要があります。
API 利用者への最終的な注記
- 再試行ロジックは決定論的で境界が定められている必要があります
- サーバーが提供する再試行のヒントが常に優先されます
- 不正確な再試行は、再試行しない場合よりも有害になる可能性があります
これらのルールに従うことで、サーバー API との予測可能で、安全かつスケーラブルな統合が保証されます。