エラー バジェットの使い過ぎが意味するもの : CRE が現場で学んだこと
Google Cloud Japan Team
『CRE が現場で学んだこと』シリーズでは、これまでも Google の CRE（顧客信頼性エンジニアリング）チームによる SLO（サービス レベル目標）の記事を掲載してきました。SLO とは、サービスが満たすべき信頼性の目標をエンドユーザーの視点から定めたものです。
SLO では特定の期間内にどの程度サービスのダウンタイムを許容するかを指定します。たとえば 99.9 % の可用性が求められるサービスの場合、30 日間における許容ダウンタイムは 43 分です。この時間がエラー バジェットとなります。家計の予算と同様に、エラー バジェットは、予算オーバーにならない限り 30 日間に利用してもよいとされるものです。
日々の運用での積み重ねや、大規模障害によってエラー バジェットを使いきってしまった場合、サービスを使用するユーザーは困難な状況に置かれることになるため、何とか対処しなくてはなりません。
では、一体どうすればよいのでしょうか。今回の記事では、エラー バジェットを再調整する必要があるかどうかを判断するときに考慮すべき点について説明します。
何にエラー バジェットを費やしているか
SLO は、対応する SLI（サービス レベル指標）のターゲット値となります。SLI はエンドユーザー エクスペリエンスの重要な部分の測定値です。先ほど例として挙げた、99.9 % の可用性が求められるシステムの SLI は、「すべての 20x および 50x の HTTP レスポンスのうち、成功した HTTP レスポンス（200）の割合」となります。エラー バジェットの使用量は、サービスが SLO のすべてを達成できなかった測定期間の割合で計算します。これは、SLI の粒度や正確さに応じて、1 分ごとや 1 時間ごと、あるいは 1 日ごとに計算することも可能です。日々のエラー バジェットを分析するには、測定期間中に使用したエラー バジェットについて、その主な理由がどこにあるのかを明らかにする必要があります。
- ほとんどのエラーがバイナリ リリースの際に発生している場合は、リリースの頻度を控えたり、エラーを起こりにくくしたり、エラーが発生しても影響があまり出ないようにしたりといった対策が必要です。そうしないと、エラー バジェット内に収めることは難しいでしょう。
- 断続的なアプリケーション障害によってずっと同じようなエラーが発生し、それがエラー バジェットの大半を占めている場合は、アプリケーションに根本的な欠陥があるということです。ログを掘り下げて問題のクエリを探し、エンジニアと協力して根本的原因を特定したうえで、直接対処するか、もしくは次のプロジェクトの計画サイクルで修正しなくてはなりません。
- “configuration pushes” や過度の負荷、“queries-of-death” が原因でサービスの大半が何分間にもわたって停止するような大規模アプリケーション障害が発生し、そこにエラー バジェットの大半が費やされている場合は、効果的な事後分析を実施して根本的原因を突き止め、障害を緩和させるべきでしょう。開発エンジニアの力を借りて、事後分析で優先順位トップとされた事項に対応する必要があります。したがって、機能の開発やリリースはおのずと後回しになります（これについては別の記事で詳しく説明します）。
- クリティカルなバックエンドやコンピューティング プラットフォームのような制御対象以外との依存関係によって多くのエラー バジェットが消費されている場合は、その依存関係を見直すか、プラットフォームのオーナーと直接交渉し、SLI を示したうえで、サービスの信頼性を向上させる方法や予期される障害モードへの耐性を高める方法について話し合ってみましょう。
いずれのケースでも、問題に十分対処できたかどうかを客観的に測定することになります。以前は落ち込んでいた状況で SLI が高い状態を保つことが求められるのです。
シグナルを正しく査定しているか
ほかにも検討すべきことがあります。障害がユーザーの真の悩みを反映しているかどうかです。まとまった量のエラー バジェットを一気に使ってしまうような大規模障害が発生しても、そのことをユーザーはあまり気にしていないと確信が持てる場合は、開発業務やアーキテクチャを変更する必要はないかもしれません。とはいえ、何らかの修正は必要でしょう。新たに SLO の目標レベルを下げるか、ユーザー エクスペリエンスをより反映した別の SLI を検討するべきです。ユーザー エクスペリエンスが低下してもユーザーは耐えられるか
99.9 % の可用性（1 か月あたり 43 分のエラー バジェット）でサービスを提供しようと努めてはいるものの、実際はその範囲内に常に収まらず、毎月 50～60 分のエラー バジェットを費やしているとします。これは実際、どの程度重要なことでしょうか。サイト上での滞在時間や購入率、サポート チケットの発行数、さらには直接測定したユーザーの幸福度など、顧客満足度を測るビジネス インテリジェンスの手段はさまざまです。その統計を SLI と対比させて評価してみましょう。
エラー バジェットが超過した期間とユーザー満足度が下がった時期に関連性はありますか？ 関連性があるとしたら、その相関関数はどうなっていますか？ エラー バジェットが 50 % オーバーしたときの顧客収益が 1 % 減少しているのであれば、目標値達成に向けて可用性を高めようとエンジニアの労力をつぎ込むよりは、SLO を調整して可用性 99.5 % を確保するほうがよいと考えるかもしれません。
ここで重要なのは、SLO の目標値を決める際に使用するデータを入手し、文書化しておくことです。単に「ユーザーが気にしないから」という理由でエラー バジェットを 50 % 増やすような罠に陥ることがないようにしましょう。ユーザーの満足度/支出と、SLO の定義における信頼性との妥協点を明確にする必要があります。SLO の仕様は、単に数字や指標名があればよいというわけではありません。SLO のターゲットを決めるにあたっては、利用したロジックやデータが何なのかも示す必要があるのです。
ユーザー エクスペリエンスが明確でないケース
お客様が常に正しいというのは真実かもしれませんが、もしサービスのユーザーが社内にいる場合はどうでしょうか。一部のケースでは、常にエラー バジェットをオーバーしていても、ソフトウェアを構築しリリースを続けることが会社の利益のためになることもあるでしょう。エラー バジェットを使うことで従業員には迷惑をかけるかもしれませんが、ソフトウェアの新バージョンをリリースできないことのほうがユーザーに不便をかけることになり、企業にとっては大きなコスト増につながるかもしれないのです。これは、ソフトウェアのユーザーが必要だと考えているもの（今回のサービスの例で言えば 99.9 % の可用性目標）と、ソフトウェア開発の予算を握っている幹部がユーザーに我慢を強いるべきだと考えているものとの間にギャップがある場合に起こる可能性があります。
以上で、エラー バジェットが何を伝えたいのかを理解できたのではないでしょうか。この記事のパート 2 では、うまくバランスを保つ方法について考えます。
SRE（サイト信頼性エンジニアリング）についてより詳しく知りたい方は、7 月 に US サンフランシスコで開催される Next '18 にぜひご参加ください。SRE の原則をサービスのデプロイや管理に適用する方法について紹介します。
関連コンテンツ
* この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの（投稿はこちら）の抄訳です。
- By Adrian Hilton, Alec Warner and Alex Bramley
