エラーバジェット計算機

概要

SLO は比率で表した約束です。これだけの割合のリクエストは成功する、という形の 約束。その有用な裏面が残りの部分、つまりエラーバジェットで、約束を破るまでに 許されている失敗の量を指します。

信頼性をバジェットとして扱うと、議論の質が変わります。「何も壊すな」は エンジニアリングの目標になりません。リスクの値段を無限に設定してしまうので、 結果として何も出荷できなくなります。一方「今月は 43 分の不可用が使えて、うち 12 分を使った」は、計画できる目標です。

この計算機は SLO を 3 つの数字に変換します。割合としてのバジェット、ウィンドウ に対する許容ダウンタイム、そしてリクエスト量を入れた場合にその中へ収まる個別の 失敗件数です。

使い方

1. SLO % に約束する目標値を入力します。
2. Window (days) に測定ウィンドウを日数で設定します。30 が通常のローリング 1 か月、7 はフィードバックを速く回したいとき、90 は四半期のレビューに 合わせる場合です。
3. Requests / window にそのウィンドウのリクエスト量を入れると、失敗件数まで 出ます。ここは任意で、空のままなら割合とダウンタイムだけが出ます。

3 つの数字の読み方

Error budget は単に 100% − SLO です。SLO の隣に並べると自明なほど小さく 見えますが、それが要点です。99.9% と 99.99% の差は、使える量が 10 分の 1 に なるということで、ナインが 1 つ増えるたびに前の 1 つよりはるかに高くつく理由が ここにあります。

Allowed downtime は、そのバジェットをウィンドウに壁時計の時間として当てた ものです。チームの外の人と話すときに最も役に立つ数字で、「月に 43 分ほど」は 「99.9%」が持たない具体性を持ちます。

Allowed failed requests は同じバジェットを量に当てたものです。計画の土台に すべきはこちらで、監視で実際に観測できるもの、つまり 5xx を返した数や レイテンシ閾値を超えたリクエスト数に、そのまま対応します。

時間ベースと件数ベースは同じではない

2 つのインシデントが、時間のバジェットは同じだけ消費して、件数のバジェットは まったく違う量を消費する、ということが起こります。逆も同様です。

深夜 3 時の 5 分間の全面停止は、ダウンタイムを 5 分消費し、リクエストはほとんど 消費しません。1 日続く劣化で 0.5% のリクエストが失敗する状況は、素朴な定義では 「ダウンタイム」をほぼ消費せず、それでいて 1 か月分の件数バジェットを使い切る ことがあります。

利用者が体験するのは後者です。可用性を時間だけで測ると、人を最も苛立たせる種類 の失敗を構造的に数え落とします。部分的な失敗はダウンタイムとして一切記録され ないからです。

通常の解決策は、SLI を「有効なイベントに対する良いイベントの比」、たとえば総 リクエストに対する成功リクエスト、あるいは総リクエストに対する規定時間内に 返ったリクエストとして定義し、時間ベースの数字は説明のためだけに導出することです。

バジェットを実際に消費するもの

よくある誤りは、バジェットをインシデント用の余裕枠と見なすことです。実際には、 リクエストを失敗させるあらゆるものと共有しています。

• デプロイ — すべての層が正しく接続を退避させない限り、問題なく終わった ロールアウトでも接続は切れます。
• 計画メンテナンス — 利用者から見て使えないなら、告知したかどうかに関係なく 数えます。
• 依存先の障害 — 事業者側のインシデントで自分のバジェットが減ります。そこに 投票権はありません。
• ロングテール — 個々のタイムアウト、リトライを使い切った要求、1 台の不調な ノード。どれもインシデントにはならず、確実に積み上がります。

だからこそ、エラーバジェットを 100% 消費する前提で計画したチームは超過します。 インシデントに使えるのはその一部と考え、残りは運用の通常コストのために残して おいてください。

残量ではなく消費ペースで見る

バジェットは残高としてよりも、消費の速さとして見た方が判断に使えます。許容失敗 リクエスト数をウィンドウの長さで割ると、ウィンドウの終わりにちょうど使い切る ペースが出ます。これを監視上の実際の失敗数と比べるのが、リリースを止めるか どうかの判断で最も再現性のある手順です。

たとえば 30 日で 1,000 件が許容なら、1 日あたり約 33 件が均衡点です。ある日に 300 件失敗したなら、その日だけで 9 日分を使ったことになります。残りが 700 件 あるという事実は安心の根拠になりませんが、9 倍の速度で燃えているという事実は 行動を促します。だから多くの組織は残量ではなく、複数の時間窓での消費速度に アラートを設定します。短い窓は急性の障害を、長い窓は慢性の劣化を捕まえます。

使用例

• 99.9% / 30 日 — 約 43 分。ロールバックの遅い不良デプロイが 1 回あるだけで、 1 か月分の大半を使えます。
• 99.95% / 30 日 — 約 22 分。手動のロールバックでは速度が足りなくなり、 自動化が要求される境目です。
• 99.99% / 30 日 — 約 4 分。人が介在せずに作動するマルチリージョンの フェイルオーバーがあって初めて到達できます。
• 99.999% / 30 日 — 約 26 秒。検知だけでこれより長くかかるのが普通なので、 アーキテクチャは障害に反応するのではなく、障害を許容する形でなければなりません。

1 段上がるごとに許される失敗はおよそ 10 分の 1 になり、コストは段違いになります。 SLO はナインの数の見栄えではなく、利用者が実際に必要とする水準から決めてください。 社内のバッチ処理を 99.99% にするのは、誰の利益にもならない支出です。

注意事項

ウィンドウは入力した日数そのままとして扱うので、30 日の「月」は 2,592,000 秒 です。暦の月は最大 3 日ぶれるため、契約と突き合わせるときはここが問題になります。 運用上はローリング 30 日を採るのが一般的で、その方がこの食い違いを回避できます。

失敗リクエスト数は四捨五入ではなく切り捨てです。失敗の端数を使うことはできない からです。計算は有効桁 12 桁に丸めてから切り捨てており、Math.floor を素で 当てたときに 99.9% と 100 万リクエストが 999 件になる桁落ちを避けています。

3 つの入力はいずれも端末の外に出ません。SLO の値は組織の内部事情そのものなので、 送信する理由がありません。

違約金の段階を伴う契約上の可用性を扱うなら、SLA 計算機 を 使ってください。隣の問い、つまりある可用性の約束が何分のダウンタイムを許すかに、 リクエスト量の側面を抜きにして答えます。