Uber流：大規模サービスで「リトライストーム」を回避する技術的アプローチ

Uberのような巨大な分散システムにおいて、障害発生時に大量のリクエストが押し寄せる「リトライストーム（再試行の嵐）」は、サービス全体をダウンさせかねない深刻な脅威です。この記事では、Uberがどのようにして効率的な再試行戦略を構築し、システムの堅牢性を維持しているか、そのエンジニアリング手法を解説します。

この分野での他の戦略があればぜひ聞いてみたい。以前、何も考えずに至る所でリトライを許可するという安易な方法をとったら、リトライストームに巻き込まれたよ。次に同じ問題に直面した時は、逆に一番上の階層のサービスだけでリトライを許可するという安易なやり方を試したんだけど、今度は失敗するたびに膨大な量の作業をやり直す羽目になった。複雑になりすぎず、いい感じの折衷案ってないかな？

この記事でロードシェディングに触れられていないのが怪しいな。それを呼び出し側の指数バックオフと組み合わせれば、かなり堅牢なスタート地点になるはずだよ。