「可用性はスリーナインです」と聞いて、それが月に何分まで止まってよい約束なのか、すぐに答えられるでしょうか。
99.9%と99.99%の差は、数字の上ではわずか0.09ポイント。
ところが止まってよい時間に直すと、ちょうど10分の1まで縮みます。
筆者も SRE を学んでいる途中なので、Google の SRE 本と、Google のエンジニアが ACM Queue に寄せた論文を読みながら、ナインの数字の裏にある運用の差をたどりました。
ナインを「止まってよい時間」に直す
可用性の話は、まず割合を時間に置き換えるところから始めると見通しがよくなります。
Google の SRE 本の付録Availability Tableは、計画停止がない前提で、可用性ごとに許される停止時間を一覧にしたもの。
主な値を抜き出すと、次のとおりです。
可用性 1年あたり 1か月あたり 1日あたり
99% 3.65日 7.2時間 14.4分
99.9% 8.76時間 43.2分 1.44分
99.95% 4.38時間 21.6分 43.2秒
99.99% 52.6分 4.32分 8.64秒
99.999% 5.26分 25.9秒 0.87秒99.9%なら月に43.2分、99.99%なら月に4.32分。
ナインが1つ増えるたびに、許される停止時間は10分の1ずつ減っていく計算になります。
月4.32分に収めるには、検知と復旧を速くするしかない
月4.32分という数字を、障害対応の流れに重ねてみる。
ACM Queue に2017年に掲載されたThe Calculus of Service Availabilityは、可用性を障害の頻度と、1回あたりの長さで決まるものとして扱っています。
式で書くと、MTTF（故障までの平均時間）÷（MTTF＋MTTR（復旧までの平均時間））。
同論文は、サービスの可用性は、障害の発生頻度と検知・復旧にかかる時間で決まる上限を超えられないと書いています。
例として挙げられているのが、20分の全面停止が年に3回起きるケースです。
それだけで年間60分になるので、ほかの期間が完璧でも、年間の停止を53分以内に抑える99.99%には届かないという計算。
人がアラートに気づき、原因を調べて手で切り戻していると、数分はすぐに過ぎてしまうもの。
ナインを1つ増やすことは、人の対応を自動の検知と復旧に置き換えていくこととほぼ同じだと、筆者は読みました。
依存しているサービスの可用性が上限になる
もう1つの落とし穴は、自分たちのコードの外に潜んでいる。
同論文は、サービスは重要な依存先すべてを合わせた可用性を超えられないと述べています。
ここでいう重要な依存先とは、それが故障すると自分のサービスも一緒に故障してしまう相手のこと。
そこで Google 社内では、重要な依存先には自分より1つ多いナインを求める「rule of the extra 9」という経験則を使っているそうです。
99.99%を目指すなら、依存先には99.999%が要るという考え方になります。
依存先のナインが足りないときの手当てとして、同論文はキャッシュでの肩代わり、失敗しても処理を止めないフェイルオープン、エラー時に機能を落として動き続けるグレースフルデグラデーションを挙げていました。
単純な掛け算でも、感覚はつかめます。
依存先がそれぞれ独立に故障すると仮定すると、99.9%の依存先を3つ直列に抱えるだけで、全体は0.999の3乗でおよそ99.7%まで下がる計算です。
時間で測るか、リクエストで測るか
ここまでの表は「サービスが止まっていた時間」を前提にした見方でした。
SRE 本のEmbracing Riskの章は、時間で測る式に加えて、成功したリクエストの割合で測る方法を紹介しています。
世界中に分散したサービスでは、どこかが一部だけ落ちている状態が珍しくなく、「止まっていたかどうか」の二択では実態を表しにくいためです。
同章の例では、1日に250万リクエストを受けるシステムが1日99.99%を目標にするなら、250件までのエラーは許されると数えられます。
この「成功の割合」という見方は、SLI を比率で定義する考え方とそのままつながっている。
ナインを1つ足す前に確かめたいこと
数字を見ていると、つい1つでも多くナインを積みたくなるもの。
ただ SRE 本は、信頼性を一段上げるコストが、その前の一段の100倍になることもあると注意を促しています。
さらに、99%の信頼性のスマートフォンを使っているユーザーには、99.99%と99.999%の違いは分からないという指摘も印象的でした。
利用者とサービスのあいだには、端末や家庭の回線、プロバイダーなど、自分たちでは直せない部分がいくつも挟まっているからです。
目標のナインは、利用者が体感できる範囲と、払えるコストの交点で選ぶもの。
そうして決めた目標の「残り」をどう使うかは、エラーバジェットの記事で扱いました。
最後に
可用性の数字は、割合のままではなく「止まってよい時間」に直して読むと実感がわきます。
99.99%は月4.32分で、その枠に収めるには検知と復旧の自動化、依存先のナイン、測り方の選択がすべてからんでくる。
ナインの数は、運用の設計そのものを映す数字なのだと腑に落ちました。
まずは自分の関わるサービスが、1か月に何分まで止まってよい約束なのかを計算してみるところから。
以上です。
コメントを残す