「SRE入門：『SLO サービスレベル目標』監修者が解説する実践とメリット」 グーグル合同会社 山口 能迪

タイミー社による事例講演はこちらからご覧ください

●Event report信頼性と品質 / システム運用と管理

「今ならこうする！SLO導入の失敗と4つの教訓」タイミー 岡野 兼也

2023.08.14

約3分

サービスレベル目標（SLO）設定 | 7ステップ

① 組織全体で「信頼性」を基準にしよう

信頼性の高いサービスは、顧客の満足度を向上させ、企業の評判やブランドイメージを築く重要な要素です。どれだけリリースをしても、顧客満足度、つまり信頼性の低いサービスでは意味がありません。サービスの信頼性は特定の部署のみが意識するものではなく、会社全体で意識・共通理解すべき指標なのです。

② 「信頼性」を具現化する

信頼性の定義を見てみましょう。

つまり、サービスやシステムに求められる機能が実行される確率を計測できれば良さそうです。

③ ユーザーに求められている機能を、指標（SLI）にする

指標（SLI）を設定します。指標（SLI）は、ユーザーから求められる機能、ユーザー満足度に相関する指標でなくてはなりません。ユーザーから求められる機能は、サービスの性質によって異なるため、適切に見極めることが必要です。

下記に指標の一例を出してみました。

サービスの性質による典型的な信頼性指標の元データ リクエスト/レスポンス 可用性、レイテンシー、品質 データ処理 カバレッジ、正確性、鮮度、スループット ストレージ スループット、レイテンシー

この指標はあくまで典型例のため、当てはまらないケースもたくさんあります。例えば、CPU・メモリの使用率などのメトリクスを、ユーザー満足度に相関があると思い込み指標にしてしまうパターンです。ユーザー視点で考えると、自分が使ってるブラウザの向こう側にあるサーバーのCPUの使用率がいくら高かろうと関係ないはずです。自分が期待している時間内に期待されたレスポンスが返ってくれば問題ありませんよね。

指標（SLI）は、ユーザー満足度に相関するか？を見極めよう

④ サービスレベル指標（SLI）を計算する

求められる機能を洗い出せたら、次は実行確率を計算しましょう。SLIは、以下の式のように定量的かつ慎重に定義します。

⑤ サービスレベル指標（SLI）を言語化する

冒頭で話したように、サービスの信頼性は特定の部署のみが意識するものではなく、会社全体で共通理解すべき指標です。技術的な知識のない人にも「だいたいこんなことをやっているんだな」と理解してもらうために、言語化しましょう。

⑥ サービスレベル目標（SLO）を設定する

言語化ができたら次はサービスレベル目標（SLO）を設定します。SLOを設定するために、計測期間・確率の目標値を定義しましょう。

⑦ サービスレベル目標（SLO）を言語化する

SLIと同様に、SLOも言語化しておきましょう。

このドキュメントがあれば「いま使っている指標は、本当にユーザーの満足度に相関してるの？」という定期的な議論に役立ちます。

SLOを設定する3つのメリット

① エラーバジェットの理解

SLI・SLOを設定し、エラーバジェットを算出することで、リソースを効率的に配分できます。SLOは、その値を満たしてれば、ユーザーが満足できるという値ともいえます。つまり、その値までは、故意に障害を発生させたとしても、ユーザーは使い続けてくれると仮定できるわけです。先ほどのSLI・SLOの例では、このように設定しました。

可用性が99.9%。つまり 0.1%分のエラーは、ユーザーが許容できる範囲ということになるので、「だったらそのエラー分をさまざまなチャレンジのための予算にしよう」と考えることができます。

エラーバジェットを監視することで、システムの運用にどれくらいの余裕があるかが一目瞭然になってきます。

② バーンレートの解析

さらにもう一歩進んで考えていきます。エラーバジェットは、ユーザーが不満足になるまでの余裕分です。その消費速度を追いかけることで、現在置かれた状況を判断できます。

先程の例で考えてみましょう。

可用性の目標が 過去28日間 の良いレスポンスが99.9%ということは、28日間で 0.1%のエラーを起こす想定です。これがバーンレート1の基準になります。14日間 で 0.1% のエラーが起きると、バーンレート2となります。この基準を使えば業務の優先順位や緊急度を適切に判断することができます。

③ ポリシーの策定

ここまでエラーバジェットやバーンレートなどを説明してきましたが、すべては信頼性を基準にシステムを開発運用することに端を発しています。シンプルな定義であるにもかかわらず、非常に強力な概念です。

SLOとFour Keysの違いを理解する

Four Keys は、2017年発売の書籍『LeanとDevOpsの科学』で提唱された開発生産性を示す4つの指標（デプロイ頻度・変更リードタイム・変更障害率・サービス復旧時間）です。この4つの指標は、あくまでソフトウェアデリバリーに関係する指標であり、安定時のパフォーマンス（ユーザー満足度）が欠けています。

しかしシステムというのは、ユーザーの信頼性がなければ意味がありません。そこで「組織のパフォーマンス」が再考され、State of DevOps Report (SODR) 2018以降では新たに信頼性（可用性）に関する記載が加わりました。

2018年以降は「信頼性」を指標として計測することが推奨されています。信頼性を優先することで、従来のエラーバジェットの考え方も図のように変化しています。

SLO 関連のおすすめ書籍

概要を理解したい

SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム

サイトリライアビリティワークブック―SREの実践方法

計測基盤を理解したい

オブザーバビリティ・エンジニアリング

SLOを導入する際に必要となる基礎概念、実装、文化を理解したい

SLO サービスレベル目標―SLI、SLO、エラーバジェット導入の実践ガイド

Slidoに届いた視聴者からの4Qs

Q：マイクロサービス × SLO

山口：SLOのユーザーの中には、人間だけでなく、APIを投げるすべてのサービスも含まれます。最もユーザー対応の多いフロントエンドはエンドユーザー視点でのSLOになっていくと思いますが、内部サービスでのSLOの対応は各サービス担当との兼ね合いになると思います。（マイクロサービスなのであれば各サービスに担当がいて、そこにリクエストが来ると思います。）

― バックエンドとしてSLO導入してきた岡野さんですが、もしタイミー社にSREエンジニアが入社してきたら、その方にSLO推進を任せますか？

岡野：タイミーの場合は自分で開発したものは自分で運用するルールになっているので、最終的には開発チームにボールを持たせる前提で、SREの方にはプラットフォームチーム的な考えで動いてもらうのがいいプラクティスなのかなと考えています。

Q：はじめてのSLO導入です。準備期間の目安は？

岡野：開発の合間に進めていたので、一ヶ月ほど準備期間がかかりましたが、専任であればもう少し早められるかもしれません。

山口：まずは何を計測すべきか、何が一番「信頼性」に影響するか、そもそも、これまで何も計測していない状態で過去との比較ができない場合は、まずはSLIを決めて最低4週間ほど計測してみると良いでしょう。

Q：SLIの定め方がかわかりません

― APIやサービスが提供する機能の利用頻度は、利用者によって桁が違うため、なかなかSLIが定まりません。

山口：ユーザー特性が複雑で、それに合わせた要件が求められているということであれば、リクエストに付けているアトリビュートなどで振り分けて、それに対してSLOを設定する方法などが可能かと思います。

岡野：私はとりあえずやってみようと行動するタイプなので、最初はよくあるレイテンシや可用性を計測していました。振り返りながら改善していけば良いのかな。運用しながら悩み続けていく形でも問題ないと思います。

Q：社内から過剰品質を求められます

山口：100%にしなくていいのかみたいな話ですよね。「これまで計測してきましたが、可用性100％を達成することはないですよ」をスタートポイントにしつつ、具体的に工程を伝えてイメージさせると良いと思います。可用性のSLOを99.99%にする場合、1ヶ月で許容されるダウンタイムは5分以下です。

「あなたが今求めてる可用性は、この工程を5分で行うことです。そのうえで、やりますか？やりませんか？」と議論すると、必然的にお金の話になってくると思うので、そこで相手に判断してもらえば良いと思います。

岡野：適切な調整をしたいという話だと思うのですが、私は上げちゃえば良いと思うんですよね。どこかで実現不可能になる。ある程度上げてみて違反する経験を積んでおくのも組織としてはいいプラクティスかなと思います。