リトライ暴走（Retry Storms）からの解放：Uber が採用した「エラー所有権」アプローチ

はじめに

過去、リトライの暴走は業務運営とブランド信頼に多大な影響を与えてきました。従来の手法であるリトライ構成の微調整や予算緩和は手動設定を必要とし、深い依存関係チェーンやファナウトパターンによる影響増幅を可視化できませんでした。

• 根本的な課題: 現在のリトライ挙動が文脈（コンテキスト）に感知していないため、発生タイミングを精密に制御できません。
• 一律的なリスク: エラーと単純な伝播エラーを見分けることが難しく、条件付きではなく一律に適用されるアプローチは、中度〜重度の障害時には逆効果です。
• ドミノ倒しの効果: 単一のサービス障害がトリガーとなり、上流依存サービス間のトラフィックが増幅され、スタック全体のインシデントにエスカレートします。

理論的には「下流のエラーコードを上流へ翻訳」するアプローチもありますが、Uber のような大規模なファナイン/ファナウトや頻繁な変更を伴う環境ではスケーリングしません。そこで開発されたのが**文脈感知型メカニズム「エラー所有権（Error Ownership）」**です。

背景：リトライの指数関数的増幅と解決策

コールチェーンにおけるリクエスト数の増幅

単純なコールチェーンにおいて、サービス D でエラーが発生し、各サービスが 1 回のリトライ構成を持っている場合、エラーは下流へ伝播するごとに指数関数的に増幅します。

ノード	深さ (d)	処理リクエスト数 (無制約の場合)
A	0	$ \eta $
B	1	$ 2 \times \eta $
C	2	$ 4 \times \eta $
D	3	$ 8 \times \eta $ (エラー発生点)
...	...	...

これを単純化すると、ホップごとのリトライ数 $ R $ が一定の場合、処理リクエスト数は $ R^d \times \eta $ で表されます。

リトライ予算（Retry Budgets）の導入

各ホップで同じリトライ予算 $ B $ を設定することで増幅を抑制できます。新しい公式は以下のようになります。

$$ (1+B)^d \times \eta $$

例：リトライ予算を 10% に設定した場合

ノード	深さ (d)	処理リクエスト数
A	0	$ \eta $
B	1	$ 1.1 \times \eta $
C	2	$ 1.21 \times \eta $
D	3	$ 1.33 \times \eta $

このようにして、エラー発生点（ノード D）と上流（A, B）の間のリトライのみを制限すれば、下流サービスを過負荷にさせずに可用性を保証できます。

エラーの所有権（Error Ownership）

エラーは**「コールバック側（callee）」**で発生したことが重要です。

• 症状: サービスが返すアウトバウンドエラー。
• 原因: 下流からのインバウンドエラー。
• 所有権: アウトバウンドで失敗せずともエラーを返した場合、そのサービスはエラーの「所有者」となり、リトライを制御する責任を持ちます。

計算による可用性向上 コールバック側での可用性低下が 10% 以内の場合、たった1 回のリトライでも呼出し側の観測される可用性を 99.9% から 99.9999991% まで引き上げることができます。これは「エラー所有権」の基礎であり、「高エラーレートの間、ランダム化されていないエラーに対して多くのリトライを行うことは利益にならない」という原則となります。

アーキテクチャ：エラー所有権の実装

解決策は**「エラー所有権」**を確立することです。サービス依存関係分析ソリューションを用い、インバウンド失敗とアウトバウンド失敗を相関させてエラー主張の有無を判断します。

エラー所有権付きのリトライ

呼出し側（Caller）は以下のロジックでリトライの是非を決定します。

• 非協力的な環境: 下流サービスに分析ソリューションがない場合やコンテキスト伝播が欠落している場合、エラー主張ヘッダーが欠落することがあります。
• 対応策: 下流からエラー主张が見当たらない最初のノードはエラーを引き下げ（unclaims）ることで、リトライ暴走の影響半径を制限します。

決定マトリクス：コールバックのエラー主張に応じたアクション

コールバックのエラー主張	呼出し側がリトライすべきか？	呼出し側から伝播されたエラー主張	アクション
いいえ	はい	N/A	NA
はい	はい	欠落している	引き下げる (Unclaim)
はい	はい	主張されている	引き下げる (Unclaim)
はい	いいえ	主張されていない	リトライ

• 図 5 のシナリオ: エッジ A->B および B->C が fail-close（閉鎖型）の場合、ノード C で内部エラーが発生し主張された場合、ノード B は C をリトライすべきですが、失敗した場合はノード A に対して「主張されていない」というヘッダーで返す必要があります。これにより、ノード A は B のエラーを無視します。

サービス依存関係分析の重要性

下流呼び出しが失敗した場合と内部サーバーエラーが発生した場合が混在するシナリオ（図 7 のように両方が fail-open の場合）においても、サービス依存関係分析ソリューションはエラーを最初に下流に帰属させるように設計されています。

• 正当なリトライ機会の逸失: サービス依存関係分析なしの場合、内部サーバーエラーであっても誤って引き下げられ、正当なリトライ機会を失う可能性があります。
• 統計的裏付け: 6 ヶ月のデータ分析により、偶発的な失敗（両方が同時に失敗する確率）は約 2% です。最も最悪のケースでも、サービス依存関係分析ソリューションは fail-close の状況でインバウンド失敗とアウトバウンド失敗が相関している場合のみエラーを引き下げることができます。

「少なくとも一度のリトライ保証」

多くのサービスは fail-close アウトバウンドへのリトライが設定されていません。これを補完するために、下流からのエラーに対して**「リトライ基準を満たしたか」**を信号化するフラグを導入します。

1. リトライミドルウェア: 下流のエラーを検知し、基準を満たしているかを計算・伝達。
2. サービス依存関係分析ソリューション: このシグナルを活用し、インバウンドで fail-close 下流から返されたエラーを所有すべきかを決定。

これにより、コールチェーン上の少なくとも 1 つのサービスにリトライが構成されていれば、「少なくとも一度」の行動が可能となり、全体的な可用性低下を解消します（図 12）。

コンテキストドロップ処理

サービス内のコンテキストが破損した場合でも、エラー所有権は再試行可能なエラーを左側へシフトさせます。

• 問題: コンテキストが壊れていると相関ができず、ノード C が D をリトライし続ける一方で、ノード B も C をリトライしようとします。
• 解決: リトライ失敗時には「主張されていない」ヘッダーを付与することで、上流のノード A は B への再試行を行わないように制御されます。
• 効果: これにより、最悪の場合に発生するリクエスト数を最大で32 倍削減できます。

本番環境における成果：Uber の事例

エラー所有権は現在、Uber のサービスメッシュ全体で実装・運用されています。これはユーザー面向きの API リクエストパスと深い依存関係チェーン全体で動作します。

2025 年 11 月 18 日のインシデント

Core Entity サービス（コールチェーン深さ 5 レベル）の基盤インフラトラブルにより高エラーレートが発生しました。単純なリトライ予算ではトラフィックが 46% から 135% に増大し、障害回復が遅延しましたが、エラー所有権が自動的に爆発半径（blast radius）を抑制しました。

抑制された影響:

• 即時の停止: 劣化したサービスへの直近の呼出し側からの追加リトライ試行が停止されました（一部で最大 20 万件のリクエスト阻止）。
• 上流への波及防止: ルートノードで集計した結果、驚くべき950 万回の虚偽のリクエストを止めることができました。

結論：劇的な改善と定量的効果

このアプローチは、劣化イベント中の総リクエスト量を劇的に削減しました。

メトリクス改善（エラー所有権启用後）

• 最大リトライ暴走半径: 3まで低下（以前は 25）。
• 平均値: 2まで低下（以前は 20）。

エラーを真正な解決責任者（サービス所有者）に限定することで、指数関数的なファナウトを防ぎました。これは単一ポイントの劣化によるカスケード障害からインフラを守りました。

謝辞

• カバー写真は OpenAI の ChatGPT で生成されています。外部資産は使用されていません。
• Uber Engineering の最新情報については、LinkedIn をフォローしてください。