再試行とバックオフポリシー

繰り返し（再試行）は、一時的な障害を生き残るのに役立ちますが、正しく設定されていない場合、トラフィックの雪崩、操作の重複、およびカスケードの低下を引き起こします。信頼できるリトレイポリシーは、常に締め切り/タイムアウトから始まり、idempotencyを考慮し、backoff+jitterを使用します。

1）基本原則

1.最初のタイムアウト/期限、その後、後退。時間制限なしで繰り返すと、失敗が長くなるだけです。
2.Retray-安全な/idempotent操作の場合のみ。安全でないもののために-idempotency-keysとトランザクション保証を通じて。
3.バックオフは必須です。ジッタ付きの指数関数型またはGCRA型で、波を非同期にします。
4.試行回数と予算の合計時間を制限します。ユーザーのSLOを残してはいけません。
5.インフラ信号を尊重します。'429/503'+'再試行'、サーキットブレーカのステータス、キューの制限。

2）タイムアウトと締め切り（締め切りの伝播）

リクエストタイムアウト<SLOサービス、締め切りはチェーン（HTTP ヘッダ/gRPCコンテキスト）を伝播します。
タイムアウト構成：ユーザーの締め切り≤合計（最初の試み+バックオフ+その後）。
読み取り/レコードの異なるタイムアウト：レコードはより短く、より厳密です。ヘッジを許可します。

3） Idempotencyおよび安全な繰り返し

読み取り（GET/idempotent RPC）： '5xx'、 'UNAVAILABLE'、ネットワークタイムアウトで安全に繰り返されます。

• 境界線上で'Idemotency-Key' （HTTP）またはrequest-IDを使用します。サーバーは重複除外する必要があります。
• idempotentハンドラを書く：「upsert」、 「at-lost-once」+compensation （saga）。
• 外部決済-idempotentキーとトランザクションログのみ。

4）バックオフアルゴリズム

指数関数：'base 2^attempt'、' max_backoff'で囲まれています。
Decorated Jitter （full/equal jitter）-クライアントを非同期にする範囲のランダム性。
GCRA/Token-Bucketのような遅延：レート制限と一致します。
境界：'initial_backoff' （50-200 ms読み取り；200-500 msレコード）、'max_backoff' （1-5 s）、 'max_elapsed'（例えば、3-10 s）。

推奨パターンは指数関数バックオフ+フルジッタです。

5）繰り返し/繰り返さない意思決定ポリシー

• ネットワークエラー/タイムアウト、'429'（敬意を表して'Retry-After'）、 "soft' '5xx' （'502/503/504'）、 gRPC 'UNAVAILABLE/DEADLINE_EXCEEDED'。

• '4xx'（一部のシナリオでは'409/429/408'を除く）、ビジネスエラー、'401/403'、検証エラー、明示的な'DoNotRetry'フラグ。

• '409 Conflict'-コンセンサス/ロック後に遅延して繰り返されることがある。
• '404'は永続的に一貫した読み取りのために、小さなバックオフで1〜2回リトレイします。

6）同時キャップと「リトレイストーム」

クライアント/テナント/エンドポイントごとに同時リトレイを制限します。

リクエストごとの試行回数の合計制限（例： 2-3).

入場制御によってホットエンドポイントを遅くして、キューを膨らませないようにします。

7）遮断器および限界との相互作用

CBが開いている場合は、直接リトレイを実行しないでください。フォールバックに移動するか、'半開き'サンプルを待ちます。
'429'-尊重'Retry-After'；そうでない場合は「、ソフト」バックオフを使用してください。
リトレイはひずみを増加させることができます。適応しきい値を適用します（インシデントの'max_attempts'を下げます）。

8）議定書および契約

HTTP （HTTP）

コード：'408/429/5xx'。
ヘッダー：'Retry-After'、ファミリー'RateLimit-'、 'Idempotency-Key'、 'Request-Id'。
クライアントは'X-Request-Timeout'/'Deadline-At'（もしそうなら）を送信しなければなりません。

gRPC

締め切りでコンテキストを使用する。respect 'UNAVAILABLE'、 'DEADLINE_EXCEEDED'、メソッドごとのリトレイポリシー。
idempotent RPCのために、リトレイを含んで下さい；idempotencyをサポートしている場合のみ。

9）キュー、バックグラウンドタスク、統合

少なくとも一度はハンドラ→idempotentアクション、key deduplication。
試行間のバックオフの遅延キュー（たとえば、5s/30s/2m）。
デッドレターキュー（DLQ）は、試行と手動処理の制限があります。
Outbox/CDC-リプレイがトランザクションの整合性を損なわないようにします。

10）ヘッジ対リトライ

ヘッジは、テールレイテンシの非常にクリティカルな読み取りに役立ちます。
制限：リクエストのX％以下、開始遅延（p95レイテンシーなど）、敗者のキャンセル。
強力な特権なしにヘッジを適用して操作を記述しないでください。

11）遠隔測定および観測可能性

技術：'tenant_id'、 'endpoint'、 'attempt'、' decision '（retry/skip）、' reason'、'backoff_ms'、 'deadline_ms'、' idempotency_key'。
メトリクス：リトリートのシェア、リトリート後の成功、p95/p99 "end-to-end'、超過期限の数、CBトリガー。
監査ログ：上のN「騒々しい」キー/エンドポイント、429/503との相関。

12）テストおよび混乱

プロファイル："saw" （burst-lull）、 "storm'（マスタータイムアウト）、"sticky"エラー（すべてのNth）、レイテンシテール。
Torus limiter/cache/queue failures、 clock-skew。
合計期間（試行回数+バックオフ）がSLOに収まることを確認します。

13）ポリシー擬似コード

pseudo handle(req, deadline):
attempt = 0 backoff = initial()
while attempt < MAX_ATTEMPTS and now() < deadline:
attempt += 1 with timeout(per_attempt_timeout(deadline, attempt)):
try:
resp = call(req)
if isRetryableStatus(resp): raise Retryable(resp. status)
return resp except Retryable as e:
if circuit. isOpen(dep) or! isIdempotent(req): break sleep(jitter(backoff))
backoff = min(exp(backoff), MAX_BACKOFF)
except NonRetryable:
break return fail_or_fallback(req)

14）コンフィギュレーションテンプレート（例）

yaml retries:
default:
max_attempts: 3 initial_backoff_ms: 150 max_backoff_ms: 2000 strategy: exponential_full_jitter respect_retry_after: true per_attempt_timeout_fraction: 0. 4 # 40% of remaining deadline hedging:
enabled: false read_heavy:
max_attempts: 4 initial_backoff_ms: 80 max_backoff_ms: 1200 hedging:
enabled: true start_after_p95_ms: 300 max_extra_requests_ratio: 0. 05 write_strict:
max_attempts: 2 initial_backoff_ms: 250 max_backoff_ms: 1000 idempotency_required: true

limits:
concurrent_retries_per_tenant: 100 concurrent_retries_per_endpoint: 20

15）売り上げ前のチェックリスト

• 締め切りは通話を通じて伝播する；SLO ≤の合計期間。
• ジッタ付きバックオフアルゴリズム；負荷テストによって検証される変数。
• IDempotence：レコードのキー/ログ/補償。
• リトレイポリシーは、読み取りとレコードで異なります。respect 'Retry-After'。
• リトレイの競争力と試行回数は限られている。
• サーキットブレーカとの統合とレート制限が設定されています。
• テレメトリー：タグ、メトリクス、理由ログ；ダッシュボードp95/p99、リトレイ後の成功のシェア。
• 「嵐」とレイテンシテールのテスト、タスクのDLQ。
• 顧客ドキュメント：コード/タイトル、バックアップおよびキャンセル例。

16）典型的なエラー

タイムアウトや期限のないリプレイは「永遠の期待」です。
ジッタなしの一時停止を修正-同期波とDDoSセルフサボタージュ。
idempotencyなしで安全でないレコードの再送信-重複と非同期。
'Retry-After'とCB信号を無視すると、インシデントがエスカレートします。
キャップと入場管理の欠如によるキューのボトルネック。
理由/解決策の遠隔測定の欠如-「ブラインドフライト」。

17）クイックレシピ

パブリックAPIの読み取り：3つの試み、'initial=100ms'、 'max=1s'、フルジッタ、最大5％のトラフィックのヘッジ。
重要な記録（支払い）：最大試行回数1〜2回、厳密なタイムアウト、必須の「Idempotency-Key」、ヘッジなし。
外部統合：respect '429/Retry-After'、 'max_attempts=3'、 'max_backoff=2-5s'、出力フロー制限。
バックグラウンドタスク：ディレイバックオフ（5s→30s→2m）、 DLQ、 idempotentハンドラ。

結論

良い繰り返しポリシーは、迅速な回復と制御された失敗のバランスです。締め切り、idempotence、ジッタ付き指数関数的バックオフ、競争を制限し、インフラストラクチャ信号を尊重することで、「嵐」からのリトレイがSLOの信頼性と保持を向上させるツールになります。