指数バックオフとは？解説

指数バックオフとは、試行間の待機時間が指数関数的に - 通常は2倍ずつ - 増加するリトライ戦略であり、持続的な障害から急速に後退します。

リトライを間隔を空けて行うあらゆる方法の中で、指数バックオフは事態の深刻さに適応するため最も広く使われています。短時間の乱れは短い最初の待機で解消し、深刻な問題ではリトライを素早く大きく引き離して、障害中のシステムを守ります。これは、よく作られたクライアントにおける標準のリトライポリシーです。

計算の仕組み

n回目の試行前の遅延は、基準間隔に増加係数をべき乗したものを掛けた値であり、一般的には基準値かける2のn乗です。したがって待機時間は 1s、2s、4s、8s、16s のようになります。初期のリトライは速く(乱れに有効)、後のリトライは大きく間隔が空き(持続的な問題に有効)、通常は最大待機時間を制限する上限を伴います。

なぜ固定ではなく指数なのか

固定バックオフは毎回同じだけ待つため、素早い乱れには遅すぎるか、実際の障害には速すぎるかのどちらかです。指数バックオフは両方をカバーします - 機敏に始まり、辛抱強くなっていき、ケースごとの調整なしに障害の深刻さに待機時間を自動的に合わせます。

なぜジッターが不可欠なのか

純粋な指数バックオフでも依然として同期します。多数のクライアントが同時に失敗すると、全員が 1s、次に 2s、次に 4s で足並みをそろえてリトライし、サンダリングハードを再現します。ジッター(各遅延をランダム化すること)を加えると同期が崩れ、リトライが分散します。「ジッター付き指数バックオフ」が本番グレードのパターンです。

CIでどこに使われるか

パッケージマネージャー、image pull、クラウドSDK、APIクライアントはいずれも、ネットワークやrate-limitの障害に対して指数バックオフを使います。単発の一時的なregistryエラーがしばしば自動的に回復するのはこのためです - クライアントが静かに後退してリトライし、あなたのjobが気づく前に処理してしまうのです。

Latchkeyの視点

Latchkeyの自己修復型マネージドrunnerが、registryのタイムアウトのような一時的な問題で失敗したjobをリトライする際、妥当なバックオフによってリトライがupstreamに回復する時間を与えます。そのため、一度きりの乱れが、不調なサービスに負荷を積み上げることなく、あなたのbuildを失敗させることはありません。

重要なポイント

指数バックオフは、リトライの遅延を指数関数的に(多くの場合2倍ずつ)増やします。
短時間の乱れには機敏に、実際の障害には辛抱強く対応します。
同期したサンダリングハードのリトライを避けるため、ジッターが不可欠です。
パッケージマネージャーやクラウドSDKにおける標準のリトライポリシーです。