Uberが「リトライストーム」を防ぐ仕組み
How Uber Protects Against Retry Storms
Uberは、リトライがエラーの発生源を区別せず一律に適用されることで、障害を増幅させる問題に取り組んでいる。共有インフラにコンテキスト認識型のエラー所有権メカニズムを導入し、下流のエラーを伝播しただけのサービスはリトライを抑制。リトライバジェットと組み合わせ、単一障害がスタック全体に波及するのを防ぐ。
リトライ動作は今日、コンテキストを認識していない。リトライの回数は制御できても、いつ発生するかを正確に制御することはできない。
HNでの議論
47- prologic
つまり、実質的にA → B → C → Dという流れでDが失敗している場合、CはDをリトライするかもしれないが、BとAはチェーン全体をリトライすることを控えるように促される。
これはかなり巧妙だ。SREやSLOに触発されたであろう「Error Budget」の概念もとても気に入っている :)
- Scoundreller
一方でGoogleは「お待ちください、ページをリロードしないでください」という壁をずっと出してくるので、私はできるだけ素早くctrl-rを押している。それとも、それが人間のテストと反応なのか？
- maxchisto
記事で言及されていないload sheddingが気になる。呼び出し側でexp backoffと組み合わせれば、かなり堅牢な出発点になるだろう。
- aftbit
この分野での他の戦略について聞いてみたい。私はどこでもリトライを許可するというナイーブなことをやって、リトライストームに陥ったことがある。次に同じ問題に直面したとき、最上位のサービスからのみリトライを許可するという別のナイーブなことを試したが、失敗するたびに膨大な作業をやり直すことになった。複雑さをあまり増やさない、良い中間策は何だろうか？
- UltraSane
これはFibre Channelのフロー制御メカニズムを再発明しようとしているように感じる。