リトライストームは歴史的にビジネス運用とブランド信頼に影響を与えてきました。リトライ設定のチューニングとリトライバジェットはサービスレベルで意味のある緩和を提供しますが、手動で構成され、深い依存関係チェーンとファンアウトパターンによって引き起こされるクロスサービス増幅への可視性が欠けています。その結果、スタックの深部にある単一のサービス障害によって引き起こされるドミノ効果からインフラストラクチャを保護することが困難になる場合があります。

主な理由は、今日のリトライ動作がコンテキストを認識していないことです。リトライが何回発生するかは制御できますが、いつ発生するかを正確に制御することはできません。これは、サービスによって生成されたエラーと、単にそれを介して伝播されたエラーを確実に区別するという課題に起因します。その結果、リトライは条件付きではなく一律に適用されます。このアプローチは、一時的または低レートの障害には機能します。ただし、中程度または深刻な劣化の間は、逆効果になります。

すでに苦戦しているサービスに対して積極的にリトライすると、負荷が増加し、障害が加速し、上流の依存関係全体でリトライトラフィックが増幅されます。局所的な停止として始まったものが、すぐにスタック全体のインシデントにエスカレートする可能性があります—最終的にはエンドユーザーエクスペリエンスを低下させ、最悪の場合、完全に破壊します。

下流サービスのエラーコードを上流に変換してリトライのコンテキストを提供できると主張する人もいるかもしれません。理論的には可能ですが、このアプローチは、大規模なファンインとファンアウト、進化するコールフロー、頻繁な適応的変更の必要性のため、Uberではスケールしません。したがって、エラーをより効率的に処理するために、共有インフラストラクチャにコンテキスト認識メカニズムを開発しました。このブログではそのメカニズムを説明します。