Google Cloud
優れた SLO を策定するには : CRE が現場で学んだこと
2017年11月8日
Google Cloud Japan Team
今回は、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
