SLOをもっとカジュアルに活用しよう
はじめに
こんにちは。Google Cloudでオブザーバビリティの担当をしているものです。
昨日、シンガポールで開催されたスタートアップ向けのイベントにリモート登壇したのですが、そこでスタートアップでもSLOを活用しましょう、というテーマで話しました。
せっかくなので日本語にしておこうと思い、スライドを抜粋しながら内容の一部を記事にしておこうと思います。発表内容を記事化してるので、文体が少し発表のようになっているのはご容赦ください。
「ユーザーからの信頼性」が大切
まず、スタートアップ、さらにはWebサービスに限らず、あらゆる事業において、顧客に対する信頼は重要です。荷物が全然届かない配送業者は利用したくないですし、接続してもつながらないISPは契約したくありません。飛行機も統計上事故の確率が低いから利用するわけで、自動車並に事故が発生していたら絶対利用しません。日々私たちがさまざまなサービスを利用しているのは「それを使えば何かしら期待したとおりに物事が行われる」という信頼があるからでしょう。ここでいう信頼には、満足も含まれています。両者を含んだ意味を持つ指標を「信頼性」としましょう。
信頼性がないサービスを人に勧められません。そういった観点で、あらゆるシステムにおいて、「信頼性」というのは最も重要な機能の1つと言えると思います。では、この「信頼性」をいかにユーザーを満足させるレベルに保つのでしょうか。
「信頼性」の観測
そもそも「信頼性を保つ」とはどのように実現すればよいのでしょうか。「保つ」ということは、ある一定の水準よりも低くなった場合には、それを改善して元の水準に戻さなければいけないということです。しかし、個々のユーザーがサービスを利用している際の満足度を直接的に知る術は存在しません。各ユーザーがブラウザーやアプリケーションごしにサービスを使っている間に考えていることは、Webサービス提供側にはわかりません。また、仮に分かったとしても、曖昧な表現で「満足している」「少し満足」などと言われたところで、改善のための粒度としては粗すぎます。
しかしピーター・ドラッカーが言ったように「測定できないものは改善できない（If you can't measure it, you can't improve it）」ので、なんとかして「ユーザーの信頼性」を測定しなければいけません。先ほどのように、ユーザーの信頼性を、たとえば5段階評価で操作ごとに取得しても良いですが、粒度が粗い上に、そもそも回答を得られるかが期待できません。UXリサーチのようにお金を払って評価してもらっても良いですが、即時性がありません。コストも掛かります。
そこでかわりにユーザーの信頼性に強く関連しているであろう代替指標を使います。この代替指標を観測することで、ユーザーの信頼性を観測することにします。理想的には以下の図のように、ある指標（黒の実線）があって、その指標があるしきい値（赤の点線）よりも上の値であればユーザーが満足していて、それ以下であればユーザーが不満を覚えている、ということになれば観測しやすいですね。
SLIとSLO
ここでSREの文脈では、このような代替指標のことをサービスレベル指標（Service Level Indicator、SLI）と呼んでいます。上の図で言うところの黒の実線です。そしてしきい値（赤の点線）のことをサービスレベル目標（Service Level Objective、SLO）と呼んでいます。
1つ明確にSREの文脈での表し方として違いがあるとすれば、SLIは単なる指標（例: レイテンシーのミリ秒、エラーの数）ではなく、単位は常に総量に対する良いイベントの百分率で表すようにしているということです。指標をそのまま使うと単位がバラバラだったり、その値域がわからないので、今観測している値が良いのか悪いのかがわかりません。なので、正規化のために百分率で表すということです。
たとえば、Webサービスであれば、ユーザーがあるボタンをクリックして画面が開くまでの時間（レイテンシー）を計測していて、それが500ミリ秒以下になる割合をSLIとします。日本語で表現すると「レイテンシーが500ミリ秒以下となるレスポンスの割合」です。簡単な数式で表現すると次のようになります。
そして、レイテンシーが500ミリ秒以下のレスポンスが全体99%を超えていたら、ユーザーは満足して使い続けてくれるであろう、という予想のもとに、SLOを99%と設定します。このとき「全レスポンス数」を決定するには計測区間が必要になるため、28日間のローリングウィンドウとしましょう。つまりSLOは「レイテンシーが500ミリ秒以下となるレスポンスの割合が28日間のローリングウィンドウで99%」となります[1]。
ここで2つのヒューリスティックな値が出てきました。1つはSLIの設定の際に決めた「500ミリ秒」という値、もう1つはSLOの設定の際に決めた「99%」という値です。500ミリ秒は1回の利用に関する満足度、99％は継続的な利用に関する満足度に影響してきます。これらの値を理論的に導ければよいのですが、2023年現在では特に見つかっていません。過去のレイテンシーのデータと、カスタマーセンターへの問い合わせの数などを照らし合わせて、経験的に推測していくしかありません[2]。
またそもそもSLIのための元の指標としてレイテンシーを選択しましたが、これも自明ではありません。どういった指標を使えばよいのでしょうか。幸いなことに、これは各サービスの種類に応じて、ある程度ユーザーの信頼性の代替指標として代表的なものが定義されていますので、参考にしてください。The Four Golden Signals、USE、REDなどがよく知られていますが、それらも含めてあくまで参考指標であり「これを計測していれば良い」というものではありません。もし自分のサービスで、もっとよくユーザーの信頼性との強い相関がある指標が見つかれば、そちらを使用すべきです。
SLI/SLOを共通の目安として活用する
SLIとSLOの良いところは一度設定してしまえばわかりやすい、ということです。SLOという共通の用語を用いて、「いまはSLOを満たしてるので、ユーザーが満足してサービスを使えてい（ると思われ）ます。」「いまはSLO違反になってしまったので、ユーザーは不満を感じてい（ると思われ）ます。」という会話が、エンジニア組織だけでなく、会社全体で行えるということです。ビジネスKPIなどで、DAUやARPPUなどを追跡していますが、そもそもそういった指標はサービスがユーザーが満足して使える状況に左右されます。ユーザーが満足しているからこそ、利用し続けてくれますし（DAU）、追加でお金も払ってくれ（ARPPU）ます。そういった意味で、SLIとSLOを全組織で目安にして共通言語とすることには大きな意義があると思います。
ここで振り返りたいのは、SLOを満たしていればユーザーは満足しているとみなせる、ということです。裏を返せば、満たさない状況になるまでは、さまざまなリスクを取れる、ということです。ここで、リスクとは無茶なことを指すわけではなく、普通に新機能をリリースすること自体も指します。Googleで発生した障害の70%は、何かしらのシステム変更によるものです。
SLOを満たさなくなった場合は、開発の方向性としても、信頼性の回復を目指す方向にいったん舵を切ったほうがよいでしょう。しかし、何かしらの事情でそうできないこともあるかもしれません。重要なのは、SLIやSLOを共通の目安として会話のきっかけにすることです。
完璧を目指さない
上の節で書いたように、SLOという目安があることで、そこを割り込むまでは開発組織は積極的に新規リリースを続けられます。さらにSLOを緩く設定すれば、余裕を持った開発ができるというわけです。
たとえば、レイテンシーと並んで代表的な代替指標に可用性があります。可用性のSLOを設定する場合、クラウドプラットフォーマーが設定している99.99%のような高い可用性の目標値を設定すると、30日あたりに許容されるダウンタイムは5分以下となってしまいます。これは、障害対応を人間だけで行う場合にはまず対応出来ません。ダウンタイムを検知してから、アラートが飛んで、担当者が調査を始めて、修正を行って、デプロイして、正しく修正されたことが確認されるまで、を5分以下で行うのはまず無理でしょう。
一方で、可用性のSLOを99%とした場合、30日あたりで7.2時間の余裕があります。90%にすれば、10%の余裕がありますから30日あたりで3日です。これだけ余裕があれば計画メンテナンスで1日落とすことも可能です[3]。
ここからわかることはSLOがシステムや開発・運用手法に強く影響を与えるということです。99.99%の場合には、自動ロールバックシステムや、そもそもリクエストを複数系統で処理する冗長化も必要になります。90%の場合には3日あるので、素朴な人間による対応でも十分対応可能でしょう。
ここまでで分かると思いますが、100%を目標値に設定することには意味がないということです。100%に設定したところで、必ず障害は発生しますし、障害が発生した瞬間に100%の目標値は達成されません。実情を無視した目標値を設定するだけで安定したシステム運用がされるのであれば、実情を無視した売上目標を設定するだけで常に事業はうまくいくはずです。システムに関する目標値だけ実情を無視しても成立する道理はありません。100%までは行かなくても、99.9999%のような目標値も同様です。
イテレーションを繰り返す
ここまで読んで「理屈は分かるけれども、SLIやSLOのヒューリスティックな値をどうやって見つけるかわからないし、見つけたとしても合っているかわからない」という感想を持つ方もいると思いますが、そもそもこれらの値を1度に決めることはまずできません。特にスタートアップであればユーザー数が急拡大することもありますし、事業の方向性も大きく変わるかもしれません。
SLIとSLOは議論の出発点です。ビジネスKPIも定期的に見直しを行うように、SLIやSLOを定期的に見直しながら、組織が目指す方向性を加味して、実現可能な目標値を設定してください。もちろん、最初は目標値が決まらないこともあると思いますが、それでも問題ありません。なによりもまず「ユーザーの信頼性」をSLIを使って追跡するだけでも、発見があるはずです。
SREを意識しすぎない
ここまで、SLIとSLOという用語は紹介しましたが、他のSREのプラクティスは紹介していません。また、SREのプラクティスの中で必ず解説されるようなエラーバジェットについても説明しませんでした。しかし、SLIやSLOは、それらが無くても十分に有益であることが理解いただけたのではないかと思います。もちろん、SREを推し進めていけば、SLIとSLOのより発展的な使い方[4]がでてきますが、そのずっと手前であるSLIを設定するだけでも、十分に意味があると思います。まずは既存の監視システムの指標の1つとして加えることから始めてみてください。
「オブザーバビリティ」や「SRE」といった用語がよく聞こえるようになってきて、焦ってしまうかもしれないですが、まずは着実に「ユーザーの信頼性」を計測し、観察して、開発と運用に活かしてください。
（以上、発表の内容終わり）
Discussion