// シス担のミカタ
API・メッセージング

リトライとバックオフ りとらいとばっくおふ

リトライ指数バックオフ冪等性APIエラー障害復旧レートリミット
リトライとバックオフについて教えて

簡単に言うとこんな感じ！

通信が失敗したときに「もう一回試してみる」のがリトライ、「少し待ってから試す」のがバックオフだよ！混んでいるお店に電話して話し中だったとき、すぐ何度もかけ直すのではなく、少し時間を空けて再度かけるのと同じ感覚なんだ！

リトライとバックオフとは

リトライ（Retry）とは、通信やAPIの呼び出しが一時的なエラーで失敗したときに、処理を再試行する仕組みのことです。ネットワークの瞬断やサーバーの一時的な高負荷など、「すぐに直る可能性が高い失敗」に対して有効な手段で、システムの堅牢性（こわれにくさ）を高める基本テクニックです。

一方、**バックオフ（Backoff）とは、リトライの際に「次に試すまでの待ち時間」を設ける戦略です。特に指数バックオフ（Exponential Backoff）**と呼ばれる手法がよく使われ、再試行のたびに待ち時間を2倍・4倍・8倍…と指数関数的に延ばしていきます。失敗が続いているサーバーにひっきりなしにリクエストを送り続けると、回復の邪魔をしてしまうため、徐々に間隔を空けることで相手の回復を助けるわけです。

実務では「APIの呼び出し失敗時に自動で3回までリトライする。ただし1回目は1秒後、2回目は2秒後、3回目は4秒後に試す」というように、リトライとバックオフをセットで設計します。これはクラウドサービス連携・マイクロサービス・バッチ処理など、あらゆる「外部との通信」が発生する場面で欠かせない設計パターンです。

リトライ・バックオフの仕組みと種類

リトライの基本フロー

リクエスト送信
    ↓
成功？ ─── Yes ──→ 処理完了 ✅
    ↓
    No（エラー）
    ↓
リトライ可能なエラー？ ─── No ──→ エラー終了 ❌（例: 404 Not Found）
    ↓
    Yes（例: 503 Service Unavailable）
    ↓
待機（バックオフ）
    ↓
再試行回数 ≤ 上限？ ─── No ──→ エラー終了 ❌
    ↓
    Yes
    ↓
リクエスト再送信（繰り返し）

バックオフの種類

種類概要特徴
固定バックオフ毎回同じ間隔で待つ（例: 常に2秒後）シンプルだが高負荷時に集中しやすい
指数バックオフ待機時間を2倍ずつ増やす（1秒→2秒→4秒→8秒…）最も広く使われる標準的な手法
ジッター付き指数バックオフ指数バックオフにランダムなゆらぎ（ジッター）を加える複数クライアントの同時集中を防げる
線形バックオフ一定量ずつ増やす（1秒→2秒→3秒→4秒…）指数より緩やかで予測しやすい

サブトピック1: 覚え方

「リトライはもう一回、バックオフは少し引いて待つ」と覚えましょう。英語の “back off” はまさに「一歩引く」という意味。相手が忙しそうなときに少し引いて待つ、という日常の礼儀と同じイメージです。

サブトピック2: ジッターとは

**ジッター（Jitter）とは「ランダムなゆらぎ」のことです。たとえば100台のクライアントが同時に障害を検知して全員が「4秒後にリトライ」すると、4秒後に一斉にリクエストが殺到します。これをサンダーリングハード問題（Thundering Herd）**と呼びます。ジッターを加えると待機時間がバラけるため、リクエストが分散されてサーバーへの集中攻撃を防ぐことができます。

歴史と背景

  • 1980年代: イーサネットの衝突制御方式「CSMA/CD」で指数バックオフが採用される。ネットワーク通信における再送制御の原型
  • 1990年代: TCPの再送タイムアウトにも指数バックオフが組み込まれ、インターネットの基盤技術として定着
  • 2000年代前半: SOAPやWeb API普及とともに、アプリケーション層でのリトライ設計が重要に
  • 2010年代: AWSやGCPなどクラウドAPIが普及し、APIのレートリミット（呼び出し回数制限）への対応としてリトライ＋バックオフが必須の設計パターンとして広く認識される
  • 2015年前後: Googleがクラウドサービスのベストプラクティスとしてジッター付き指数バックオフを公式推奨し、業界標準として定着
  • 2020年代: マイクロサービスアーキテクチャの普及により、サービス間通信の信頼性確保としてリトライポリシーが設計必須要素に

関連する概念・設計との比較

リトライすべきエラーとすべきでないエラー

リトライ設計で重要なのは「このエラーはリトライして意味があるか」の判断です。

HTTPステータスコードエラー種別リトライ推奨理由
408 Request Timeoutタイムアウト✅一時的な遅延の可能性
429 Too Many Requestsレートリミット超過✅時間を空ければ解消
500 Internal Server Errorサーバー内部エラー✅一時的な障害の可能性
502 Bad Gatewayゲートウェイエラー✅上流サーバーの一時障害
503 Service Unavailableサービス一時停止✅メンテナンス中など
400 Bad Requestリクエスト不正❌何度試しても失敗する
401 Unauthorized認証エラー❌認証情報が間違っている
404 Not Foundリソース不在❌存在しないものは何度でも見つからない

冪等性（べきとうせい）との関係

冪等性（Idempotency）とは「同じ操作を何度繰り返しても結果が変わらない性質」のことです。リトライを安全に行うためには、この冪等性が非常に重要です。

冪等性あり（リトライ安全） GET /users/123 → 何度呼んでも同じデータ取得 PUT /users/123 {"name":"田中"} → 何度呼んでも同じ状態に DELETE /users/123 → 削除済みに対しても同じ結果 冪等性なし（リトライ注意） POST /orders → 呼ぶたびに注文が増える！ POST /payments → 呼ぶたびに決済が走る！ 対策: 冪等キー（Idempotency Key） 一意なキーを付与して 重複処理を防ぐ

冪等性のない操作（注文・決済など）をリトライすると、同じ処理が二重・三重に実行される危険があります。これを防ぐために冪等キー（Idempotency Key）という仕組みが使われます。リクエストに一意なIDを付与しておくと、サーバー側が「このIDのリクエストはすでに処理済み」と判断して重複実行を防いでくれます。

サーキットブレーカーとの使い分け

パターン役割使いどころ
リトライ＋バックオフ一時的な失敗から自動回復する短時間で直りそうなエラー
サーキットブレーカー連続失敗時にリクエスト自体を止める障害が長引いている場合に無駄なリトライを防ぐ

2つは組み合わせて使うのが理想です。「まずリトライで自動回復を試み、一定回数を超えたらサーキットブレーカーが働いて呼び出しを遮断する」という設計がクラウドネイティブアプリケーションの標準パターンです。

関連する規格・RFC

規格・RFC番号内容
RFC 9110HTTP Semantics。503レスポンスの Retry-After ヘッダーの定義を含む
RFC 6585429 Too Many Requestsステータスコードの定義
RFC 7807Problem Details for HTTP APIs。エラー応答の標準フォーマット

関連用語