Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
エラー バジェットの使い過ぎが意味するもの : CRE が現場で学んだこと
2018年7月18日水曜日
『
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 の原則をサービスのデプロイや管理に適用する方法
について紹介します。
関連コンテンツ
優れた SLO を策定するには : CRE が現場で学んだこと
SLO 違反への対処 : CRE が現場で学んだこと
* この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Adrian Hilton, Alec Warner and Alex Bramley
エスカレーション ポリシーの適用 : CRE が現場で学んだこと
2018年2月26日月曜日
過去の投稿では、
サービス レベル目標（SLO）違反のエスカレーション方法
を示した明確なポリシー文書を作成することの重要性と、Google の SRE チームによる
実際の文書例
について説明しました。このテーマの最終回となる今回は、エスカレーション ポリシーを適用する仮定のシナリオをいくつか用意し、エッジ ケースとして紹介します。
以下に示すシナリオは、すべてスリー ナイン（99.9 %）の可用性の SLO が設定されたサービスのもので、エラー バジェットの半分はバックグラウンドのエラーで消費されることを想定しています。つまり、エラー バジェットは 0.1 % で、0.05 % のエラーで稼働している状態は「正常」となります。
最初に、ポリシーの基準値をおさらいしておきます。
基準値 1 : SLO が影響を受ける可能性があると SRE に通知される。
基準値 2 : SLO を保つには支援が必要だと SRE が判断し、開発者にエスカレーションする。
基準値 3 : 30 日間のエラー バジェットが消費されたものの根本的原因が判明していない。SRE はリリースを停止し、さらなるサポートを開発チームに要請する。
基準値 4 : 90 日間のエラー バジェットが消費されたものの根本的原因が判明していない。SRE は、より多くの開発時間を信頼性向上に充ててもらうよう、幹部にエスカレーションする。
上記を念頭に、SLO 違反を詳しく掘り下げてみましょう。
シナリオ 1 : 短時間だが重大な障害が根本的原因となり、すぐに依存関係の問題が発生した
状況 : 重要な依存関係を誤ってプッシュしてしまい、その依存関係を担当するチームが当該リリースをロールバックする間、サービスの 50 % が 1 時間停止しました。ロールバックが完了するとエラー率は以前のレベルに戻り、チームは根本的原因となる要因を特定して元に戻します。依存関係を担当するチームが事後分析を作成しますが、再発防止に向けてやるべきことについては、一部サービスを担当する SRE が作成に協力します。
エラー バジェット : 可用性がスリー ナインのサービスの場合、今回の障害だけで 30 日間のエラー バジェットのうち 70 % を消費したことになります。7 日間のエラー バジェットは上回っており、バックグラウンドのエラーも考慮すると 30 日間のエラー バジェットも超えたことになります。
エスカレーション : 本番への影響に対処するよう SRE に通知されます（基準値 1）。この一連の問題（設定ミスまたはバイナリ プッシュ）が発生することはまれであるか、問題は適切に収拾したと SRE が判断した場合、サービスは SLO の規定内に戻され、ポリシーとしては他にエスカレーションする必要はないと判断されます。これは意図的なものです。ポリシーでは開発速度をこれ以上ないほど重視しており、単に 30 日間のエラー バジェットを消費したからといってリリースを止めてしまうのはポリシーに反するのです。
問題が何度も再発する場合（たとえば 2 週間連続で発生し、四半期分のエラー バジェットの大半を消費するような場合）や、再発の可能性があるとの判断が下った場合は、基準値 2 または 3 へとエスカレーションします。
シナリオ 2 : 短時間だが重大な障害が発生し、根本的原因がはっきりしない
状況 : 1 時間にわたってサービスが 50 % 停止し、その原因はわかっていません。
エラー バジェット : シナリオ 1 と同様、7 日間および 30 日間のエラー バジェットを超えました。
エスカレーション : 本番環境への影響に対処するよう SRE に通知がなされ（基準値 1）、それを受け取った SRE は迅速に開発チームにエスカレーションします。SRE は、問題をより明確に可視化するために新たな測定基準を要求し、フォールバック アラートをインストールすることもあります。また、SRE とオンコールの開発担当者は翌週に向け、問題の調査を優先します（基準値 2）。
引き続き根本的原因がはっきりしない場合、SRE は障害の 1 週目以降、30 日間の SLO 測定枠が過ぎ去るまで機能リリースを停止します。他のプロジェクトを進めている SRE と開発チーム担当者がさらに招集され、デバッグや障害の再現を試みます。サービスが SLO 規定内に収まるか根本的原因が見つかるまでは、それが彼らの最優先事項となります。
調査が進むと、SRE と開発チームは事態収拾や回避策、多重防御に向けた取り組みを始めす。理想としては、今後同様の障害が発生したとしても、根本的原因を見つけるのが今回ほど難しくなく、今回ほどの影響も出ることはないと SRE が自信を持って言えるようにしておきましょう。そうなれば、根本的原因がまだわかっていなくても、リリースのプッシュ配信を再開できることになります。
シナリオ 3 : 誤った根本的原因により、エラー バジェットが徐々に消費される
状況 : ある特定の時刻 T に、以前のバージョンにはなかったバグが本番環境に入り込み、サービスが 0.15 % のエラーを出すようになりました。数週間経っても、SRE も開発者もその根本的原因がわかりません。さまざまな修正を試みるものの、影響は収まりません。
エラー バジェット : このまま解決しなければ、1 か月の間に 1.5 か月分のエラー バジェットを消費することになります。
エスカレーション : 発生時刻 T から約 5 日後、7 日間のエラー バジェットが消費されたため、オンコールの SRE 担当者にチケットが送信されます。SRE は基準値 2 を発動し、時刻 T から約 7 日後に開発チームへとエスカレーションします。CPU 使用率の増加と関連があることから、SRE とオンコール担当の開発者はエラーの根本的原因がパフォーマンスのデグレードにあると推測します。オンコールの開発者がシンプルな最適化を見つけ出して送信し、時刻 T から 16 日後に通常のリリース手順の一部として本番環境に提供します。その修正で問題が解決されるわけではないのですが、今となっては、影響を受けたサービスに対して日々のコード リリースを 2 週間分ロールバックするのも現実的ではありません。
時刻 T から 20 日後、サービスが 30 日間のエラー バジェットを超えたため、基準値 3 が発動されます。SRE はリリースを停止し、開発者にさらに真摯に対応してもらうべくエスカレーションします。開発チーム側も、開発者 2 人と SRE 1 人による担当グループを設けることに同意します。担当グループは問題の根本的原因を見つけ出して修復することを最優先とします。
コードの変更と不具合との間に適切な関連性を見いだせないため、担当グループは詳細にパフォーマンスを分析し、ボトルネックを順に排除します。修正はすべて現在の本番リリース上で週 1 回のパッチとして集約されます。サービスは顕著に効率化されますが、それでもエラー率は上昇します。
時刻 T から 60 日後、サービスが 90 日間のエラー バジェットを消費し、基準値 4 が発動されます。SRE は幹部にエスカレーションし、信頼性が欠如している状況が継続していることに対して相当な開発作業が必要だと訴えます。開発チームは問題を深く掘り下げ、アーキテクチャに不具合を発見し、最終的にサーバーとクライアント間におけるエッジケース インタラクションの停止機能を再実装します。エラー率は以前の状態に戻り、リリースを再度開始した段階で停止機能をバッチでロールアウトします。
シナリオ 4 : 繰り返し発生する、一時的なサービス レベル指標（SLI）の逸脱
状況 : 日々または週ごとのバイナリ リリースにより、そのつど一時的なエラーが急増しています。
エラー バジェット : エラーが長期的に SLO を脅かすことがない場合、SRE は責任を持ってアラートを適切に調整しておく必要があります。そこで、このシナリオではエラーが急増しても、SLO が数時間にわたって脅かされることはないと仮定します。
エスカレーション : SLO を基にしたアラートによってまず SRE に通知され、ゆっくりとエラー バジェットが消費される場合と同様のエスカレーション手法が採られます。ここでは、リリースとリリースとの間に SLI が正常に戻ったからといって、それで問題が「解決された」と捉えないようにしてください。というのも、サービスを SLO の規定内に収めるための基準はそれより高く設定されているためです。SRE は、エラー バジェットの消費が長くなったり速くなったりしたときにページャーを鳴らすようアラートを調整してもいいですし、継続的に実施しているサービスの信頼性向上に向けた作業の一環として問題を調査してもいいかもしれません。
まとめ
どんなエスカレーション ポリシーにおいても、仮定のシナリオで「軍事演習」を行い、予期しないエッジ ケースがないか、またポリシーの言葉が明確になっているかを確認しておきましょう。ポリシーの下書きをいろんな人に回覧し、そこで上がってきた懸念事項を付録に記載してください。ただし、あるインフレクション ポイント（変曲点）を正当化するためにポリシーそのものを乱さないようにしましょう。提案したポリシーに対して同僚から異論があった場合は、さらに議論を進める心構えでいてください。
ここで紹介したポリシーは単なる一例にすぎません。高い可用性を実現しようとする実際の SRE チームは、大きく異なるエスカレーション ポリシーを作成している可能性が高いことを忘れないでください。
* この投稿は米国時間 2 月 8 日、Site Reliability Engineer の Will Tipton と、Customer Reliability Engineer の Alex Bramley によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Will Tipton, Site Reliability Engineer and Alex Bramley, Customer Reliability Engineer
SLO のエスカレーション ポリシー : CRE が現場で学んだこと
2018年2月6日火曜日
前回のブログ記事
では、信頼性と機能開発の間で生じる技術的な苦労や、サービス レベル目標（SLO）が満たされていないサービスに対して、企業はいつどうやってエンジニアの時間を信頼性向上に費やすよう決断すべきかについてお話ししました。今回は、SLO のエスカレーション ポリシー（一部編集済み）と、それに関連する Google の SRE チームによる論理的根拠を解説し、開発速度の迅速さを保つために SRE と開発の各チームがどこに妥協点を置いているのかを紹介します。
この SRE チームでは、サービス スタックのさまざまな領域に注力する大規模な開発チームと連携しています。そのスタックには、トラフィックの多いサービスが約 10 件、比較的小規模なサービスが 10 数件含まれており、すべて SRE チームがサポートしています。チームは欧州と米国に分かれており、それぞれの地域で日中オンコール担当となるように 12 時間ごとのローテーションを組んでいます。
サポート対象のサービスには、求められるユーザー エクスペリエンスを示すざっくりとしたトップ レベルの SLO と、スタックのコンポーネントにおける可用性の要件を示す詳細な SLO が設定されています。重要なこととして、SRE チームは呼び出しがかかった際に、それぞれの SLO の粒度に応じて開発チームに担当を引き継ぐことが可能であり、SLO に対する「サポートの取り消し」を安価かつ迅速にできるようになっています。
アラートの設定については、サービスが 1 時間の間に 9 時間分のエラー バジェットを消費するとページャーが鳴るようになっています。また、前週に 1 週間分のエラー バジェットを消費した場合はチケットが発行されます。
なお、ここでのエスカレーション ポリシーは単なる一例だという点に留意してください。しかも、もし 99.99 % 以上の可用性を目標としたサービスを SRE チームがサポートしている場合は、あまり良い例ではないと考えられます。この Google チームが担当している業界は非常に競争が激しく動きも速いため、高可用性の維持よりも、機能のイテレーション スピードや市場投入までの時間を重要視しているのです。
エスカレーション ポリシーの目的
エスカレーション ポリシーの詳細に入る前に、以下の点を検討する必要があります。
まず、エスカレーション ポリシーは何かを完全に禁止するためのものではありません。直面した状況に適切に対応するための判断が SRE には求められるため、特定の行動を取るにあたっての妥当な基準値を設定し、想定される対応の幅を縮小して一貫した基準内で対応できるようにすることが、エスカレーション ポリシーの目的となります。ポリシーにはさまざまな基準値が設定されており、その基準値を超えたときは、SLO 違反に対処するべくエンジニアの労力を注ぎ込みます。
また SRE は、インシデントが解決したと宣言する前に、一連の問題を修復するよう注力しなくてはなりません。これは、問題そのものを修復するよりも大変なことです。
たとえば、悪いフラグ フリップによって深刻な障害が発生した場合、フラグ フリップを取り消すだけではサービスを SLO の規定内に戻せません。そこで SRE は、段階的なロールアウトや、プッシュ失敗時の自動ロールバック、フラグとバイナリのバージョンを結びつける設定へのバージョニングなどにより、今後フラグ フリップによって SLO が脅かされることがないようにする必要があります。
後述するエスカレーション ポリシーの 4 つの基準値において、「サービスを SLO の規定内に戻す」ということは、以下のいずれかの状態を指します。
根本的原因を突き止め、関連する一連の問題を修復する
自動修復によって手作業による介入が必要なくなった
一連の問題が、今後その発生頻度や深刻度によって将来的に SLO を脅かす可能性が極めて低い場合は、とりあえず 1 週間待つ
つまり、手作業で修復する計画を立てたとしても、それだけではサービスを SLO の規定内に戻すには不十分なのです。SLO 違反の根本的原因については、今後違反が発生する可能性や自動修復の有無といった面から理解しておかなくてはなりません。
エスカレーション ポリシーの基準値
基準値 1 : SLO が影響を受ける可能性があると SRE に通知される
SRE は、サポート対象の SLO に危機が迫ると通知されるように警戒態勢を維持します。そして通知が来ると、SRE は調査を行って根本的原因を見つけ出し、それに対処するようにします。また、ロード バランサでトラフィックをリダイレクトしたり、バイナリをロールバックしたり、設定をプッシュしたりと、状況緩和に向けた対応を検討します。
SRE のオンコール担当エンジニアは、SLO への影響を開発チームに通知し、必要に応じて開発チームに最新情報を提供するようにしますが、この段階で開発チームが何らかの対策を講じる必要はありません。
基準値 2 : SRE が開発者にエスカレーションする
次の状況に当てはまるかどうかを判断します。
支援がなければサービスの SLO を保つことは困難だと SRE が判断した
求められるユーザー エクスペリエンスを SLO が表していることを、SRE と開発の両チームとも認めている
すべてに当てはまる場合は、次のような対応が考えられます。
SRE と開発チームのオンコール担当者は根本的原因の修復を優先し、バグを日々更新する
SRE が開発チームのリーダーにエスカレーションし、必要に応じて可視化や追加の支援を要請する
既知の問題に対して継続的に呼び出しがかかるのを避けるため、アラートの基準値を緩める一方で、さらなる不具合に対しては引き続き対策を講じる
サービスが SLO の規定内に戻った場合は、次のことが想定されます。
SRE がアラートの変更を元に戻す
SRE が事後報告を作成することもある
求められるユーザー エクスペリエンスを SLO が正確に表していない場合、SRE、開発チーム、プロダクト チームは SLO を変更もしくは撤回することに同意する
基準値 3 : SRE が機能リリースを一時的に停止させ、信頼性向上に努める
次の状況に当てはまるかどうかを判断します。
最低でも 1 週間は以前の基準値を満たしている
サービスはまだ SLO の規定内に戻っていない
30 日分のエラー バジェットを使い切った
すべてに当てはまる場合は、翌週は次のような対応が考えられます。
根本的原因が判明した不具合を対象に、入念にチェックした修正パッチのみを本番環境にプッシュしてみる
SRE が自分の上司や開発チームのマネージャーにエスカレーションし、緊急でない仕事はすべて後回しにして根本的原因を探し出し修復するように開発メンバーに依頼する
日々の更新を “エスカレーション” のメーリング リストとして発信してみる（幹部を含め、さまざまな人員に障害の情報を知らせるため）
サービスが SLO の規定内に戻った場合は、次のことが想定されます。
通常のバイナリ リリースを再開する
SRE が事後報告を作成する
チーム メンバーが再び通常のプロジェクトを優先することも可能になる
基準値 4 : SRE が幹部にエスカレーションする、またはサポートをやめる
次の状況に当てはまるかどうかを判断します。
最低でも 1 週間は以前の基準値を満たしている
サービスはまだ SLO の規定内に戻っていない
90 日分のエラー バジェットを使い切ったか、機能開発を中止して信頼性の回復に努めることを開発チームが拒否している
すべてに当てはまる場合は、次のような対応が考えられます。
問題解決に専念する人員を増やすため、SRE が幹部にエスカレーションする可能性がある
SRE が SLO やサービスのサポートを取りやめ、関連するアラートをリダイレクトしたり停止したりすることもある
エスカレーションとインシデント レスポンス
SRE は最初のレスポンダーです。開発者にエスカレーションする前に、サービスが SLO の規定内に戻るよう手を尽くすことが SRE には求められます。そのため、7 日分のエラー バジェットが消費されたことを示す 1 週間のチケット アラートにかかわらず、SRE チームに SLO 違反が通知されると基準値 1 を適用します。SRE は開発者へのエスカレーションを、通知を受けてから 1 週間以上先に延ばすべきではありませんが、この段階でのエスカレーションが適切かどうかは、SRE が独自に判断してもかまいません。
SRE によるエスカレーションの際は、可用性の目標値が信頼性と開発速度との望ましいバランスを保っていることを開発者に必ず確認するようにしてください。こうすることで開発者は、新機能をロールバックして可用性の目標値を維持するほうがよいのか、それとも一時的に目標値を緩和して新機能をリリースするほうが望ましいのかを検討できます。
短期間に同様の SLO 違反が繰り返し発生した場合は、何度も考える必要はありません。ただ、こうした状況はさらにエスカレーションが必要だという強力なサインでもあります。開発者が以前合意した可用性の目標値を復帰させることに意欲を見せるまで、開発者に再度そのサービスのページャー担当になってもらうよう主張してもかまいません。開発者が一時的にサービスの信頼性を下げ、ビジネスに重要な機能を提供しつつ信頼性回復に取り組みたい場合も、障害の負担を肩代わりすることができます。
リリースの停止
機能リリースの停止が適切な処置である理由は、主に以下の 3 点です。
一般に、安定した状態で最もエラー バジェットが消費されるのはリリースのプッシュ配信時です。すでにエラー バジェットを使い切っている場合、新たなリリース配信をやめてしまえば、安定した状態でのバジェット消費率が下がり、サービスをより迅速に SLO 規定内に戻すことができます。
リリースの停止により、新たなコード内のバグが原因で今後予期しない SLO 違反が発生するリスクを抑えることができます。根本的原因の修復パッチを新リリースに対してロールアウトするのではなく、現在のリリースに適用すべきなのは、これが理由です。
リリースの停止は制裁処置ではないものの、開発チームにとって非常に気になるリリース速度に直接影響を及ぼします。つまり、SLO 違反と開発速度の低下を結びつけることで、SRE と開発チーム双方のインセンティブにつながるのです。SRE はサービスを SLO の規定内に収めることを望みますが、それに対して開発チームは新機能を迅速に構築したいと考えます。この 2 つは同時に実現するか、双方とも実現しないかのどちらかです。
SLO 違反の根本的原因が特定され修復されたら、SRE は機能リリースの停止を早めに解除することを検討すべきです。SLO が 30 日間の枠内における規定を満たし、今後はサービス低下は起こらないとする開発チームを大目に見ることで、より妥当な信頼性と開発速度のバランスが保てるようになります。
これは、サービスが基準を満たす前に、妥当な時間枠内に収まるだろうと想定して今後のエラー バジェットを効果的に「借り」つつ、リリースを解禁するということです。プッシュ関連の障害がなければ、新機能によってユーザーのサービスに対する評価は向上し、SLO 違反で低下した満足度を回復できるはずです。
SLO 違反の発生前にエラー バジェットの消費率が SLO の基準値に近づいている場合、SRE はリリースの再開をやめることも可能です。こうしたケースでは前借りできるバジェットが少なく、今後 SLO 違反が起こる危険性も高くなり、リリースが許可され続けたときはサービスが SLO の規定内に戻るまでの時間も長くなります。
まとめ
本稿で紹介したエスカレーション ポリシーの例が、サービスの信頼性とビジネス優先度の高い開発速度との妥協点を決めるうえでお役に立てば幸いです。開発速度に対する主な譲歩点としては、SLO に違反したからといって SRE はすぐにリリースを停止せず、SRE との合意に従い SLO が規定内に戻る前に再開のメカニズムを提供することです。
このシリーズの最終回では、今回紹介したポリシーの基準値を仮定シナリオに当てはめてみたいと思います。
* この投稿は米国時間 1 月 19 日、Customer Reliability Engineer である Alex Bramley と、Site Reliability Engineer である Will Tipton によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Alex Bramley, Customer Reliability Engineer; Will Tipton, Site Reliability Engineer
SLO 違反への対処 : CRE が現場で学んだこと
2018年1月24日水曜日
サービスの可用性を数値化することの重要性
については、この『
CRE が現場で学んだこと
』シリーズの過去記事で詳しく解説しました。機能開発に注力している開発チームと信頼性に注力している SRE チームとの間で勃発する優先順位に関する戦いを、
サービス レベル目標（SLO）を使って管理する方法
についても、すでに紹介済みです。
SLO がしっかりしていれば
、組織内での摩擦を軽減でき、信頼性を損なうことなく開発スピードを保つことも可能です。しかし、SLO を満たすことができなかった場合はどうすればよいのでしょうか。
今回のブログ記事では、SLO 違反への SRE チームおよび開発チームの対処を示すポリシーの重要性を解説するとともに、ポリシーの構成と内容について提案します。また、Google の SRE チームでの事例とポリシーの施行に至ったシナリオについても、次回以降の記事で検証します。
機能 vs. 信頼性
真空状態の中に
丸い形をした SRE
がいるような理想の世界では、2 つのバイナリ状態の線引きをする役割を SLO が果たします。つまり、エラー バジェットが残っているときに新機能を開発するのか、それともエラー バジェットが残っていないときにサービスの信頼性を改善するのか、という 2 つの線引きです。
真の開発組織であれば、たいていはビジネスの優先順位に従って、この 2 つの領域に対する労力の割き方を変えるものです。SLO の規定内でサービスが稼働していたとしても、積極的に信頼性を向上させることは、障害の将来的なリスクを抑え、効率性を改善し、そしてコスト削減につながります。一方、SLO を満たしていないからといって、すぐに内部での機能開発を完全にやめてしまう組織はほとんどありません。
この領域の主なインフレクション ポイント（変曲点）をポリシーの形で文書化しておくことは、SRE チームと開発チームのパートナーシップにおいて重要なことです。これにより、（すぐにでも起こりうる）SLO 違反の際に自分が何を求められているのかについて、組織全体でだいたい同じ認識を得ることができるはずです。
また、何よりも重要な点として、対応しなかった場合はどんな結果が待ち受けているのかを全員が明確に把握できます。インフレクション ポイントと帰結をどこに持っていくかは、組織や事業の優先度によって異なります。
インフレクション ポイント
誰も責めることのない事後分析
や根本原因の修復を行う文化が組織に根づいている場合、SLO 違反の状態はたいていその事象ごとに異なります。つまり、非公式に言えば「私たちは新たな障害が発生する事業を営んでいる」ということです。
また、違反への対応もそれぞれ異なり、その際に判定を行うのは SRE の仕事となります。ただし、考えられる対応が異なりすぎると結果もばらばらになり、システムを試してみようとする人が出てきたり、開発組織としての疑念が生まれたりします。
エスカレーションのポリシーに関しては、SLO 違反を重要度に応じていくつかのグループに分けておくことをお勧めします。重要度は、時間とともに積み重なっていく影響度によって決まります（つまり、どのくらいの期間にどの程度エラー バジェットを消費したのかということです）。
分類後のグループの境界線は、はっきりと定義しておかなくてはなりません。正当な理由がグループ分けの背景にあると便利ですが、それはメインのポリシーとは別に付録などに記載しておきましょう。ポリシーそのものを明確にするためです。
このグループ分けの境界線と SLO ベースのアラートを、少なくとも一部は結びつけておくとよいでしょう。たとえば、過去 1 時間にエラー バジェット 1 週間分の 10 % を消費するようだったら SRE を呼び出して調査する、といった具合です。
これは、インフレクション ポイントと結果が結びついている 1 つの例です。これにより、非公式に名づけた「誰かを呼び出さなければならないほどエラー バジェットは消費されていない」グループと、「長期的な SLO から外れてしまう前にサービスを今すぐ調査すべき」グループとの線引きができるようになります。次回の記事では、Google の SRE チームのポリシーを紹介しつつ、より具体的な事例を検証します。
SLO 違反がもたらすもの
SLO 違反の行き着く先はポリシーの元となります。これこそが、サービスを SLO の規定内に戻すのに必要な処置を教えてくれるのです。それには根本的原因の解明や、関連する問題の修復、応急軽減処置の自動化、短期的な悪化のリスクを減らすことなどが含まれることになるでしょう。ここでも、あるしきい値に対する結果をどうするかは、ポリシーを定義する組織によって異なります。とはいえ、広範囲ですが当てはまる分野があります。なお、以下のリストはすべてのポリシーで網羅されているわけではありません。
SLO 違反の可能性や実際の違反を通知する
SLO 違反の可能性があったり実際に違反したりしたときに、最も一般的な結果として考えられるのは、監視システムが人間に対して調査や処置が必要だと通知することでしょう。
SRE がサポートしている成熟したサービスの場合、短期間にエラー バジェットが大量に消費されたときにはオンコール担当者のページャーに通知されますし、長い期間にわたってエラー バジェットが上昇しているときはチケットが発行されます。ページャーへの通知と同時にチケットを発行してデバッグの詳細を記録し、深刻な違反をエスカレーションする際は、チケットを情報伝達の場や参照として使うのがよいかもしれません。
また、関連する開発チームにも知らせましょう。このプロセスは手動でもかまいません。SRE チームは違反をフィルターにかけて集約し、意味のあるコンテキストを提供するなど価値を付け加えることも可能です。
ただ理想としては、実際に違反が発生したときには開発チームの上層部の一部にも自動的に通知されるようにしておくべきです（たとえば、どんなチケットでも上層部に CC を入れるなど）。そうすれば上層部はエスカレーションが発生しても驚きませんし、送られてきたチケットに適切な情報が含まれていれば議論に加わることもできます。
開発チームに SLO 違反をエスカレーションする
通知とエスカレーションの主な違いは開発チームに求められる対応です。SLO 違反が深刻な場合、たいていは SRE と開発者が密に協力して根本的原因を突き止め、再発防止策を講じるよう求められます。
エスカレーションは敗北を認めることではありません。SRE としては、開発チームの情報を検討し、解決までの時間が大幅に削減できるとある程度確信した段階で、すぐにエスカレーションするべきです。ただしポリシーには、SLO 違反（またはほぼ違反）が生じたときの猶予時間（エスカレーションせずに粘る時間）の上限を設けておきましょう。
もっとも、エスカレーションしたからといって、違反に対する SRE の仕事が終わったわけではありません。ポリシーにはそれぞれのチームの責任と、原因の調査や修復に費やす開発時間の量の下限を記載しておくべきです。またエスカレーションのレベルとしては、上層部のサポートが必要なレベルから、サービスの信頼性が戻るまで全開発チームの開発時間を使うといったレベルまでを含め、複数記載しておくと便利です。
サービス変更のリスク軽減で、SLO にさらなる影響を与える
エンドユーザーは定義上、SLO を満たしていないサービスには満足しません。そのため、エラー バジェットの消費率を増やすような日々の運用については、減速させるか完全にやめてしまいましょう。これは一般的に、バイナリのリリースや実験の頻度を制限するか、もしくは SLO が再度満たされるまでリリースを完全にやめるという意味です。
これについては、（SRE、開発部門、QA / テスト部門、プロダクト部門、幹部など）関係者全員がポリシーに合意しておくべき部分です。一部の開発チームは、SLO 違反によって開発やリリースのスピードに影響が及ぶことを受け入れがたいと感じるかもしれませんが、リリースをいつどのようにやめるのか、またこのようなことが起こった際にどの程度の人数のエンジニアが信頼回復に向けた仕事に取り組むのかを文書で合意しておくことが主な目的です。
サービスのサポートを取り消す
決められた SLO をどうしても満たすことができず、そのサービスの責任者である開発チームが、信頼性の改善に向けた開発への取り組みに後ろ向きだとしましょう。Google の SRE チームの場合、そうしたケースでは、稼働中のサービスの運用担当から手を引くことができるようになっています。これは、1 回の SLO 違反の結果というよりも、長きにわたって深刻な障害が何度も発生した結果として手を引くということです。
Google ではこれがうまく機能しています。開発の周辺においては、信頼性に対するインセンティブが変わってくるためです。サービスの信頼性を無視する開発チームはその結果を背負うことになる、ということがわかっているのです。
定義上、サービスから SRE のサポートを外すのは最後の手段ですが、そうなる条件を記載しておくことは、口先だけの脅しではなくポリシーとして当然のことです。開発チームがサービスの信頼性なんかどうでもいいと思っているのであれば、SRE が信頼性を気にしなければならない理由はどこにもありません。
まとめ
開発における信頼性と機能の妥協点を考慮し、SLO 違反への対応が信頼性を大きく変えるという事実を検討するにあたって、今回の投稿記事がお役に立てば幸いです。次回の記事では、Google の SRE チームで施行されているエスカレーション ポリシーを示し、同チームのパートナーである開発チームの開発スピードを保てるような選択について紹介します。
* この投稿は米国時間 1 月 3 日、Customer Reliability Engineer である Alex Bramley によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Alex Bramley, Customer Reliability Engineer
優れた SLO を策定するには : CRE が現場で学んだこと
2017年11月8日水曜日
CRE シリーズ
の過去記事『
SLO、SLI、SLA について考える
』では、サービスの信頼性を定義し測定するうえで重要なのはサービス レベル指標（SLI）とサービス レベル目標（SLO）を適切に設定することだと説明しました。SLI と SLO については、
SRE 本
でも 1 つの章を割いて詳しく解説しています。
今回は、SLI のもとで SLO を策定するにあたり、私たち Google が活用しているベスト プラクティスをいくつか紹介します。
SLO の意義
SLO は、企業が達成したいとする目標であり、防御のために起こす行動でもあります。ただし忘れてならないのは、
SLO はサービス レベル契約（SLA）ではない
ということです。ユーザー エクスペリエンスにおいて最も重要な側面を SLO が象徴するようにしなくてはなりません。SLO が満たされるということは、ユーザーにとっても自社にとってもハッピーなことでなくてはならないのです。一方で、システムが SLO を満たさないということは、不満を持つユーザーがいることを意味します。
企業は、システム停止の頻度を減らし、万が一停止したときはその影響を抑えることで、存続が危ぶまれる SLO を保護できるようにしなくてはなりません。その方法には、新バージョンのリリース頻度を減らすことや、機能追加よりも信頼性向上に努めるといったことも含まれます。企業全体にとって SLO は貴重なもので、代償を払っても守るべきものだということを認識する必要があります。
SLO の策定にあたって留意すべき重要な点は以下のとおりです。
SLO は、チームがやるべきことについて意味のある疑念を解決する便利なツールとなります。「この課題には絶対取り組まなくては」ということと、「この課題には取り組まなくていいかもしれない」ということの間に線引きすることこそが目標なのです。したがって、SLO のターゲットを必要以上に高く設定しないようにしましょう。現在たまたまその目標値を満たしているとしても、いったん設定してしまうと今後何か変更する際に柔軟性が損なわれるおそれがあります。たとえば、信頼性を犠牲にしても開発速度を上げるべきかということを考える際に、柔軟性が制限されてしまうのです。
SLO にクエリをグループ分けするときには、特定の製品要素や内部実装の詳細ではなく、ユーザー エクスペリエンスによって分けましょう。たとえば、ユーザーの行動に対する直接的なレスポンスは、バックグラウンドや付随的なレスポンス（サムネイルなど）とは別の SLO にグループ分けすべきです。同様に、（製品を閲覧するというような）「読み込み」の操作は、（精算するという操作のように）頻度は低いものの、より重要な「書き込み」の操作とは別グループに入れるべきです。それぞれの SLO においては、可用性やレイテンシの目標値が異なります。
SLO の範囲と、それがどこまでをカバーするのか（どのクエリ、どのデータ オブジェクトまでをカバーするのか）、さらにはどういった条件で SLO が提供されるのかを明確にしておきましょう。無効なユーザー リクエストをエラーとして数えるのか数えないのか、また、あるクライアントから多数のリクエストを送られるといったスパムに見舞われたらどうするか、ということについても検討してください。
最後に、上記内容とは若干綱引きの状態になってしまいますが、SLO は簡潔かつ明確なものにしておきましょう。SLO では、本当に気になる部分を曖昧にするのではなく、重要でない操作までカバーしないようにするほうがよいのです。規模の小さい SLO で経験を積んでください。まずはリリースして繰り返すのです。
SLO の例
可用性
Google では、「ユーザーはサービスを利用できていますか ?」という質問に答えることができるように、失敗したリクエストと既知のミスのリクエストを数え、その値を割合でレポートする方法を採用しています。（ブラウザの HTTP リクエストからではなく、Load Balancer からのデータのように）制御できる最初のポイントからのエラーを記録します。マイクロサービス間のリクエストに関しては、サーバー サイドではなくクライアント サイドからのデータを記録します。
そうすると、次のような SLO になります。
可用性 :
＜サービス＞は、＜お客様のスコープ＞に対して、＜SLO が定めた期間＞のリクエストのうち、最低でも＜この割合＞で＜正常にレスポンスを返します＞。
以下は具体例です。
可用性 :
Node.js は、ブラウザのページビューに対して、1 か月のリクエストのうち、最低でも 99.95 % の割合で 30 秒以内に 503 以外のレスポンスを返します。
可用性 :
Node.js は、モバイル API の呼び出しに対して、1 か月のリクエストのうち、最低でも 99.9 % の割合で 60 秒以内に 503 以外のレスポンスを返します。
レスポンスに 30 秒以上（モバイル API の場合は 60 秒以上）を要したリクエストについては、サービスがダウンしていた可能性があり、可用性の SLO が満たされなかったことになります。
レイテンシ
レイテンシは、サービスがどの程度のパフォーマンスを発揮したかをユーザーに示す数値です。Google では、しきい値よりも遅かったクエリの数を数え、全クエリの割合としてレポートしています。クライアントに近ければ近いほど正確な数値を測定できるため、ウェブ リクエストを受信する Load Balancer でレイテンシを測定します。マイクロサービス間については、サーバーではなくクライアントから測定しましょう。
レイテンシ :
＜サービス＞は、＜SLO が定めた期間＞のリクエストのうち、最低でも＜この割合＞は＜制限時間＞内にレスポンスを返します。
具体例は次のとおりです。
レイテンシ :
Node.js は、1 か月のリクエストのうち最低でも 50 % は 250 ミリ秒以内にレスポンスを返し、1 か月のリクエストのうち最低でも 99 % は 3000 ミリ秒以内にレスポンスを返します。
パーセンテージの理由
ここでは、レイテンシの SLI をパーセンテージとして示していることに注目してください。「99 番目のパーセンタイル レイテンシ」をミリ秒で表した数値を「3000 ミリ秒未満」とするのではなく、「レイテンシが 3000 ミリ秒未満のリクエストの割合」の目標値を 99 % としているのです。こうすることで SLO の単位と範囲がすべて同じになるため、SLO の一貫性が保たれ、わかりやすくなります。
巨大なデータセットの全体にわたって正確なパーセンタイルを測定するのは大変ですが、しきい値以下のリクエストの数を数えるのは簡単です。しきい値については、（たとえば 50 ミリ秒以下や 250 ミリ秒以下のリクエストの割合など）さまざまな数値を監視したいと思うかもしれませんが、あるしきい値は 99 % を SLO の目標値とし、別のしきい値は 50 % にするといった具合で一般的には十分です。
レイテンシの平均値を目標値とするのはやめましょう。望みどおりの結果はほぼ出ないと思ってください。平均値は異常値を隠してしまうことがありますし、かなり小さい数値はゼロと見分けがつきません。
ユーザーは、全ページのレスポンス時間が 50 ミリ秒と 250 ミリ秒のどちらであっても、おそらくその違いに気づかないので、両方とも良しとするでしょう。ただし、すべてのリクエストが 250 ミリ秒を要しているために平均値が 250 ミリ秒になる場合と、95 % のリクエストは 1 ミリ秒を要し、残り 5 % のリクエストが 5 秒を要しているために平均値が 250 ミリ秒になる場合とでは、大きな違いがあります。
100 % の場合は話が別
目標値 100 % というのは、どの時間幅においても不可能ですし、必要性もないでしょう。SRE は SLO を使って
リスクを容認
します。SLO の目標値の逆はエラー バジェットになるので、SLO の目標値を 100 % とすると、エラー バジェットがまったくないことになってしまいます。
また、SLO はチームの優先順位を決めるツールでもあります。最優先にすべき仕事と、ケース バイ ケースで優先順位を決める仕事とを分けるのです。それぞれの障害をすべて最優先にしてしまうと、SLO としての信頼性がなくなりかねません。
最終的に決める SLO の目標値が何であれ、その議論はとても面白いものになるでしょう。今後のためにも、論理的根拠を基に目標値を設定してください。
SLO のレポート
SLO は四半期ごとにレポートし、四半期の統計に応じてポリシーを決めましょう。特に、担当者をページャーで呼び出す場合のしきい値を決めるようにしてください。短い期間の数値だと、小さな日々の問題ばかりに目が行き、頻度は高くないもののダメージが大きい問題を見落としがちです。ライブでのレポートも、混乱を避けるために四半期レポートと同じ枠組みを使用するようにしてください。発行された四半期レポートはライブ レポートの寸評に過ぎません。
SLO 四半期サマリーの例
以下は、SLO に対するサービスのこれまでの実績を提示する方法です。たとえば、SLO の期間が 1 四半期となっている場合の半期のサービス レポートは次のようになります。
SLO
目標値
第 2 四半期
第 3 四半期
ウェブの可用性
99.95 %
99.92 %
99.96 %
モバイルの可用性
99.9 %
99.91 %
99.97 %
レイテンシ 250 ミリ秒以下
50 %
74 %
70 %
レイテンシ 3000 ミリ秒以下
99 %
99.4 %
98.9 %
エラー バジェットを使用した際のページャーへのアラートやリリースの凍結など、SLO に依存するポリシーについては、時間枠を四半期より短くしてください。たとえば、過去 4 時間に四半期のエラー バジェットを 1 % 以上使った場合はページャーを鳴らすとか、過去 30 日間で四半期のエラー バジェットの 3 分の 1 以上を使った場合はリリースを凍結するといった具合です。
SLI のパフォーマンスの内訳（地域別、区分別、顧客別、特定の RPC 別など）はデバッグやアラートには役に立ちますが、SLO の定義や四半期サマリーにおいては通常はさほど必要はありません。
最後に、特に初期の段階では SLO を共有する相手を意識するようにしてください。SLO は、サービスの期待値を伝えるうえで非常に便利なツールですが、いろんな人に知られてしまうと変更することが難しくなります。
まとめ
SLO は興味深いテーマですが、私たちはしばしば、SLO の論証にあたって使える便利な目安について質問を受けることがあります。
SRE 本
にはそのことについても詳細に書かれていますが、ここで説明した基本的なガイドラインから始めれば、SLO に取り組むにあたって犯しがちな一般的な間違いを避けることができるでしょう。
ここまで読んでいただき、ありがとうございました。この投稿がお役に立てれば幸いです。そして Google 社内でいつも言っているように、クエリがきちんと流れ、SLO が満たされ、ページャーが静かなままでいてくれることを願っています。
* この投稿は米国時間 10 月 23 日、Customer Reliability Engineer である Robert van Gent と Stephen Thorne、および Site Reliability Engineer である Cody Smith によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Robert van Gent and Stephen Thorne, Customer Reliability Engineers and Cody Smith, Site Reliability Engineer
SLO、SLI、SLA について考える : CRE が現場で学んだこと
2017年2月21日火曜日
前回
の『
CRE が現場で学んだこと
』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。
今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。
SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所にあるサービスの第 2 インスタンスを稼働させて負荷を分散するなど、何とか可用性を上げる必要があるかもしれません。
なぜ SLO があるのか
前回お話しした
シェイクスピア サービス
について考えてみます。正式に定義した SLO のもとで同サービスを稼働させるのは厳しすぎるという決断を下したと想定してみましょう。そこで SLO を投げ出し、サービスを「適度に可用性がある」ようにしてみます。
これで物事は簡単になりました。時々システムが 1 時間ダウンしても気にしなくていいからです。実際、新サービスのリリースや停止と再開の際にダウンタイムが発生するのは普通なのですから。
ところが、残念なことにお客様はそれを知りません。以前はちゃんと使えていたシェイクスピア検索が、突然エラーばかり起こすようになったとしか感じないのです。
サポート担当者は優先度の高いチケットを発行し、エラー率を確認して担当者にエスカレーションします。オンコール対応のエンジニアが調査し、それが既知の問題であることを確認したら、お客様に対して「これはよく起こることですので、エスカレーションの必要はありません」と返答します。
SLO がない場合、どの程度のダウンタイムであれば許されるのかを原理に基づいて語ることができないのです。発生した問題がサービスにとって重大かどうかを判断する基準さえ存在せず、「シェイクスピア検索サービスは現在 SLO に沿って運用しています」と言ってエスカレーションを終えることもできません。
Google での同僚である Perry Lorier は決まってこう言います。「SLO がなければ、君たちの仕事はとても大変だ」と。
SLO を決めるとそれがユーザーの期待値に
一般的なパターンとしては、SLO を低く設定してシステムを始動させます。低くすれば簡単に基準を満たせるためです。1 週間 7 日、1 日 24 時間のローテーションなんて組みたくないですし、初期ユーザーは数時間ダウンタイムがあってもさほど気にしません。
そこで、可用性のターゲットを最低 99 %、つまり 1 週間のダウンタイムを 1.68 時間と設定したとしましょう。しかし、実際にはシステムに結構な回復力が備わっており、6 か月間 99.99 % の可用性で稼働し、ダウンタイムは 1 か月に数分でした。
しかし、あるときシステムのどこかで障害が発生し、数時間にわたってシステムがダウンしてしまいました。地獄のような事態です。
お客様はオンコールの担当者に連絡し、何時間もシステムが 500 エラーになると苦情を伝えようとします。しかし、その連絡に気づく人はいません。というのも、オンコール担当者はページャーを机に置いたまま帰宅してしまったからです。SLO の規定によると、サポートは営業時間内のみとなっていました。
問題は、いつでもサービスが利用できる状況にお客様が慣れてしまったことです。お客様は、常にサービスが利用できるという想定のもとで、自社のビジネス システムにサービスを組み入れるようになりました。6 か月間も継続して利用できていた中で、数時間も停止してしまうと、確実に何らかの問題が起こっていることになります。これまで高可用性を保っていたために期待値もそこに合わせられ、問題となってしまったのです。
だからこそ、「SLO は上からのターゲットでもあり、下からのターゲットでもある」という言葉があるのです。もし非常に信頼性の高いシステムを作ろうとは思っていなかったり、高信頼性を約束できなかったりするのであれば、そこまでシステムの信頼性を高くしなくてよいということなのです。
Google では、可用性を過度に高めないようにするため、一部のサービスで定期的にダウンタイムを実施するようにしています。Google の Marc Alvidrez は
SRE 本
の中で、内部ロック システムの Chubby について語っています。
また、テストに利用する内部サービス用テスト フロントエンド サーバーも用意されており、外部からサービスにアクセスできるようになっています。このフロントエンド サーバーは便利ですが、決して本番サービスで使うためのものではありません。サービス レベル契約（SLA）も 1 営業日となっているため、サポート チームが修復にとりかかるまで 48 時間ダウンしていてもいいことになっています。
フロントエンドで使われていた実験サービスは、時が経つと徐々に重要なものとなっていきます。そのため、フロントエンドで数時間のダウンタイムが発生すると大騒ぎになってしまいます。
Google は現在、このフロントエンドに対して四半期ごとに計画的ダウンタイムを実施しています。担当者が警告を送信し、一部のホワイト リストを除きフロントエンドのすべてのサービスをブロックするのです。そして、この状態を数時間続けます。もしくは、ブロックによって大きな問題が発生するまで続けます。問題が発生した場合は、迅速にブロックをリバースすることが可能です。
ダウンタイムの最後に、担当者はフロントエンドを不適切に利用しているサービスのリストを受け取り、より適した場所にサービスを移動することをサービスの担当者と検討します。この計画的ダウンタイムにより、フロントエンドの可用性は適度に低く保たれ、不適切な依存関係を事前に検知して修復できます。
SLA は SLO とは違う
Google では SLA と SLO を区別しています。一般的に SLA は、サービスの利用者に対して一定期間に一定レベルの可用性を約束するもので、その規定が満たされなかった場合は何らかの罰則も存在します。罰則として、お客様がその期間に支払ったサブスクリプション料金を一部返金することになるかもしれませんし、無料でサブスクリプションの期間を追加することになるかもしれません。つまり、SLA を破るとサービス部門が打撃を受けるため、SLA を満たそうと必死になるのです。
上記のことから、また原則可用性は SLO を大きく超えるものであってはならないことから、SLA は通常、SLO より緩めの目標を定めます。目標は可用性の数値で表すこともあります。
たとえば、1 か月の可用性は SLA で 99.9 %、内部的な可用性は SLO で 99.95 %、といった具合です。もしくは、SLO を構成する基準のサブセットのみを SLA として明記することも可能です。
シェイクスピア検索サービスの場合、API として提供することに決め、課金ユーザーは 1 日 100 万回まで検索を送信可能という条件で月額 1 万ドルを支払うとしましょう。
課金することになったため、契約書にはサービスの可用性がどの程度なのか、その契約を違反した場合どうなるかも明記しなくてはなりません。最低 99 % の可用性でサービスを提供するとし、以前お話ししたように成功クエリの定義も示すといった具合です。また、サービスの可用性が 1 か月 99 % 以下になった場合は 2,000 ドルを返金し、80 % 以下になった場合は 5,000 ドルを返金するといったことも明記します。
SLO とは異なる SLA を定めている場合（ほとんどのケースはそうなのですが）、SLA にきちんと準拠しているかを監査担当者が評価することが重要となります。SLA の期間に沿ってシステムの可用性を確認できるようにしておきたいでしょうし、SLA が満たされない危機が迫っていることも簡単に見極めたいと思うはずです。
また、一般的にはログや分析などにより、契約が守られていることを正確に評価する必要もあります。（SLA という形で）課金ユーザーに対して新たな責任を背負うことになったため、課金ユーザーのクエリをその他のクエリとは別に計測する必要も出てきます（ロード シェディングが必要となったときに、無料ユーザーのクエリが落ちてもあまり気にしなくていいかもしれませんが、課金ユーザーからのクエリについては適切に処理できないと大変です）。これが SLA を設定するもう 1 つの利点で、トラフィックの優先順位を決める明確な方法なのです。
SLA を定義する際は、どのクエリを正当なものとして数えるかに細心の注意を払う必要があります。
たとえば、主要ユーザー（サービスのトラフィックの大半を占めている）3 人に対し、1 人につき 1 日 100 万クエリを割り当てたとしましょう。ユーザーの 1 人がモバイル クライアントのバグだらけのバージョンをリリースし、変更を取り消すまで 1 日 200 万クエリを 2 日間発行しました。30 日の間に、うまくレスポンスを返した回数は約 9,000 万回、エラーの回数は 200 万回でした。つまり成功率は 97.8 % です。
このことで、全ユーザーに返金するのはいやだと思ってしまいますよね。2 人のユーザーの場合は全クエリが成功に終わっているし、3,200 万クエリのうち 200 万回のクエリを拒否されたユーザーの場合は自業自得だったわけですから。つまり、SLA を計算するときは「割り当て外」のレスポンス コードをすべて除外するようにしたほうがよいでしょう。
一方、帰宅前に担当者が誤って空の割り当て仕様ファイルをサービスにプッシュしてしまったとします。全ユーザーはデフォルトで 1 日 1,000 クエリを割り当てられています。上位 3 人のユーザーは、翌朝担当者が出社して問題に気づき変更を取り消すまでの 12 時間にわたって、常に「割り当て外」エラーになってしまいました。
この時点で、月間 9,000 万クエリのうち 150 万のクエリが拒否されたことになり、成功率は 98.3 % になっています。これはすべて担当者の責任です。100 % 成功している 8,850 万クエリをカウントするのはポイントがずれていますし、SLA を測定するうえでモラル的な失敗を犯していると言えるでしょう。
まとめ
SLI、SLO、SLA というものは、単に便利な抽象的概念にとどまりません。このような指標なしにはシステムの信頼性や可用性を把握できませんし、システムが役立っているかどうもわかりません。これらの指標を明確に事業目標と結びつけなければ、選択したことが事業を促進するものか邪魔になっているかさえわからないのです。また、お客様に対して誠実な約束をすることもできません。
一からシステムを構築しているのであれば、SLI、SLO、SLA をシステム要件に入れるようにしてください。すでにシステムが稼働しているのに明確な SLI、SLO、SLA を定めていない場合は、これらを定義することが最優先です。
以上のことをまとめると次のようになります。
信頼性のあるサービスを提供したいのであれば、まず「信頼性」を定義してください。実際には、信頼性は可用性を意味することがほとんどです。
サービスの信頼性を把握したいのであれば、成功クエリと失敗クエリの率を測定する必要があります。これが SLI の基となります。
サービスの信頼性が上がれば上がるほど、運用コストも高くなります。何とかやっていける最低レベルの信頼性を定義し、それを SLO としましょう。
SLA がなければ、サービスの信頼性を高めるべきか（コストが増加し開発速度が落ちます）、信頼性をより低くするべきか（開発速度が上がります）、チームも関係者も原理的な判断ができません。
ユーザーに課金するのであれば、SLA が必要となるでしょう。SLA は、SLO より少し緩めに設定しましょう。
SRE（Site Reliability Engineering）担当者として（また DevOps 専門家として）、システムがこうした目標を達成することでどう事業に役立つかを理解し、ハイレベルな目標を脅かすリスクを可能なかぎり管理するよう、責任を持たなくてはなりません。事業目標を無視するようなシステム可用性の基準は、価値のないものよりもひどいと言えます。なぜなら、実際の可用性を曖昧にし、さまざまな危機的状況や間違ったセキュリティの感覚、そして失敗につながるからです。
前回の記事にコメントや質問を送っていただいた皆さんにとって、今回の投稿が役立つものであれば幸いです。今後もフィードバックをお待ちしています。
注 :
Google Cloud Next '17
開催まで 1 か月を切りました。Google Cloud の SVP である Diane Greene や、Google の CEO である Sundar Pichai、その他著名人らによる基調講演やコードラボ、認証プログラム、さらには 200 以上にも上るテクニカル セッションにぜひ
ご登録
ください。ちなみに今回のイベントでは、Google の SRE や開発オペレーションのエキスパートとイベント参加者が交流できるような専用の場を初めて設けています。
* この投稿は米国時間 1 月 31 日、Customer Reliability Engineers である AJ Ross と Adrian Hilton、および Director of Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By AJ Ross and Adrian Hilton, Customer Reliability Engineers, and Dave Rensin, Director of Customer Reliability Engineering
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
#gc_inside
#gc-inside
#GoogleCloudSummit
#GoogleNext18
#GoogleNext19
#inevitableja
Access Management
Access Transparency
Advanced Solutions Lab
AI
AI Hub
AlphaGo
Ansible
Anthos
Anvato
Apache Beam
Apache Maven
Apache Spark
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASL
ASP.NET
ASP.NET Core
Attunity
AutoML Vision
AWS
Big Data
Big Data NoSQL
BigQuery
BigQuery Data Transfer Service
BigQuery GIS
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
bq_sushi
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Armor
Cloud Audit Logging
Cloud AutoML
Cloud Bigtable
Cloud Billing Catalog API
Cloud Billing reports
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Firestore
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud Healthcare API
Cloud HSM
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud Memorystore
Cloud Memorystore for Redis
Cloud monitoring
Cloud NAT
Cloud Natural Language API
Cloud Networking
Cloud OnAir
Cloud OnBoard
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SCC
Cloud SDK
Cloud SDK for Windows
Cloud Security Command Center
Cloud Services Platform
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud Speech-to-Text
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud TPU
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
Cloud VPC
CloudBerry Backup
CloudBerry Lab
CloudConnect
CloudEndure
Cloudflare
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
Coursera
CRE
CSEK
Customer Reliability Engineering
Data Studio
Databases
Dbvisit
DDoS
Debugger
Dedicated Interconnect
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Dialogflow
Disney
DLP API
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Elastifile
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
Forseti Security
G Suite
Gartner
gcloud
GCP
GCP Census
GCP 移行ガイド
GCP 認定資格チャレンジ
GCPUG
GCP導入事例
gcsfuse
GEO
GitHub
GitLab
GKE
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud INSIDE
Google Cloud INSIDE Digital
Google Cloud INSIDE FinTech
Google Cloud Interconnect
Google Cloud Launcher
Google Cloud Logging
Google Cloud Next '18 in Tokyo
Google Cloud Next '19 in Tokyo
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Summit '18
Google Cloud Summit ’18
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google Kubernetes Engine
Google maps
google maps api
Google Maps APIs
Google Maps Platform
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google マップ
Google 公認プロフェッショナル
GoogleNext18
GPU
Gradle
Grafeas
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
INEVITABLE ja night
inevitableja
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Kaggle
Kayenta
Khan Academy
Knative
Komprise
kubefed
Kubeflow Pipelines
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Managed Instance Group Updater
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
Multiplay
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Osaka
Paas
Panda
Particle
Partner Interconnect
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Podcast
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Professional Cloud Network Engineer
Protocol Buffers
Puppet
Pythian
Python
Qwiklabs
Rails
Raspberry Pi
Red Hat
Redis
Regional Managed Instance Groups
Ruby
Rust
SAP
SAP Cloud Platform
SC16
ScaleArc
Secure LDAP
Security & Identity
Sentinel-2
Service Broker
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
Skaffold
SLA
Slack
SLI
SLO
Slurm
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
SSL policies
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver APM
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Velostrata
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VPC Flow Logs
VR
VSS
Waze
Weave Cloud
Web Risk AP
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エラーバジェット
エンティティ
オンライン教育
クラウド アーキテクト
クラウド移行
グローバル ネットワーク
ゲーム
コードラボ
コミュニティ
コンテスト
コンピューティング
サーバーレス
サービス アカウント
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セキュリティ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
デベロッパー
パートナーシップ
ビッグデータ
ファジング
プリエンプティブル GPU
プリエンプティブル VM
フルマネージド
ヘルスケア
ホワイトペーパー
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
金融
継続的デリバリ
月刊ニュース
資格、認定
新機能、アップデート
深層学習
深層強化学習
人気記事ランキング
内部負荷分散
認定試験
認定資格
料金
Archive
2019
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Follow @GoogleCloud_jp
