要約

  • Retry-Afterは後続要求まで待つ時間を示すが、復旧時刻を保証しない。
  • 値はHTTP日付または秒数なので、時計と解釈も証拠に含める必要がある。
  • 503や429は観測した応答を説明するだけで、将来の容量や全依存関係の状態は示さない。
  • 再試行指示、最新の稼働状況、実際の結果を結ぶ再試行の判断記録が必要である。

仮に、復旧制御装置がRetry-After: 120付きの503 Service Unavailableを受け取ったとする。全要求を保留し、2分後を緑で表示し、同じ秒に待機列を一斉解放する。新しい要求が一件も成功していないのに、障害は復旧扱いになる。2分後もオリジンは逼迫し、上流依存は停止したままで、同期した再試行が過負荷を延ばす。

ヘッダーは正しかった。復旧という結論だけが作り出された。

RFC 9110の定義は限定的である。Retry-Afterは、ユーザーエージェントが後続要求を行うまでに待つべき時間を示す。503では再試行に適した時刻を提案でき、リダイレクト応答では移動先へ要求する前に待つことが望ましい時間を示せる。どちらもサービス状態の予測ではない。

値にはHTTP日付と非負の秒数がある。日付は時計に依存し、秒数は応答を実際に受信した時刻と、中継、待機列、ローカルタイマーによる経過時間の扱いに依存する。換算後の時刻だけを保存すると元の指示を監査できない。

RFC 9110は503を、過負荷や計画保守による一時的な処理不能としている。サーバーは再試行時刻を提案できるが、その瞬間に制約が必ず消えるとは定めていない。また、過負荷のサーバーが必ず503を返すとも要求していない。利用可能な状態に戻る時期は早まることも遅れることもあり、地域、利用者の認証・認可条件、別の依存関係によっても変わる。

RFC 6585の429 Too Many RequestsもRetry-Afterを付けられる。ただし、利用者をどう識別し、要求をどう数えるかはサーバーに委ねられる。トークン、アカウント、経路、テナント、エッジごとに制限が異なり得る。適用範囲を失ったタイマーは、次の要求が受け付けられることを証明しない。

再試行の判断記録は、元の要求と応答、観測点、状態、値の生データ、形式、受信時刻、換算時刻、時計、中継による経過時間、適用する制限範囲を保存する。さらにバックオフ方式、ジッター、試行予算、同時実行上限、取消状態、送信時刻を記録する。

要求を再送する直前には、対象操作に関係する稼働状況、処理余力、依存先の状態、認可条件、判断主体を新たに取得する。最後に後続応答と取引結果を保存する。「再試行可能時刻」「稼働確認」「要求受付」「取引完了」は関係するが、同じ事実ではない。

出典

RFC 9110 — HTTP Semantics、RFC 6585 — Additional HTTP Status Codes。