SRE活動の一環として、SLI/SLO/SLAを調査する機会があったので、調べた内容を入門記事としてまとめました。
主にこの書籍を読んでおけば良いと思います。
本記事ではエッセンスや注意点に焦点を置いて説明します。
SLI/SLO/SLAとは？
以下が各用語の説明です。
※書籍では「エラーバジェット」という考え方がありますが、本記事のスコープ外として説明は省略します。
SLI（Service Level Indicator）: サービスレベル指標
サービス品質を表す1つのデータ（このデータによって良い悪いが判定可能なものを選定する）。ユーザー体験に直結する指標を選定する。
例）サービスAの処理が1秒以内に正常なレスポンスが返却されること
SLO（Service Level Objective）: サービスレベル目標
SLIをもとにした目標。社内ではこのSLOを守ることを目指す。
例）SLIが「サービスAの処理が1秒以内に正常なレスポンスが返却されること」だった場合に、月間アクセス数の99.9%において、これが実現されていること
SLA（Service Level Agreement）: サービスレベル合意
顧客と契約を結ぶ際に定めるサービス品質やペナルティ。SLIを元にビジネスリスクを考慮して制定されるのが理想的だが、実際には異なる、もしくは相関する指標を用いるケースも多い。
例）SLIが「サービスAの処理が1秒以内に正常なレスポンスが返却されること」だった場合に、月間アクセス数の99%（※SLOよりかなり緩い値）において、これが実現されていること
SLI/SLO/SLAの関係性
似たような単語でわかりづらいですが、以下のような関係性になっています。
策定プロセスの一つの方法としては、順番に策定していく方法があります。
- SLIを決める: 例）サービスAの処理が1秒以内に正常なレスポンスが返却されること
- SLOを決める: 例）SLIについて、月間アクセス数の99.9%が実現されていること
- SLAを決める: 例）SLIについて、月間アクセス数の99%（SLOよりかなり緩い）が実現されていること
しかし、必ずしもこの順番である必要はなく、自社の要件やニーズによってはまずSLAから策定するようなケースもあると思います。
- SLAを決める
- （SLAと関連する形で）SLIを決める
- （SLAと関連する形で）SLOを決める
また、そもそもSLAが不要であれば、SLI/SLOのみを策定するケースもあります。
- SLIを決める
- SLOを決める
SLI/SLO/SLAがあると何が嬉しいの？
策定のプロセスでいろいろなパターンがあること、およびSLAが不要な場合があることについて触れましたが、そもそもなぜSLI/SLO/SLAが必要なのでしょうか？ 必要性が理解できれば不要なケースも理解できます。
SLAの必要性
例えば、以下のような場合にSLAが必要になります。
- 競合優位性に関してプラスの効果が期待できる
- 外部からSLAを求められている（顧客、利用者等）
一言で言うと、SLAは対外向けのものです。
そのため上記のような対外的な要求がない場合、サービス提供の際に必ずSLAが必須という訳では無いです。例えば、toCサービスのGoogle検索などはSLAを提供していません（Google社内ではエンジニアの目標としてSLIやSLOという形で保持していると思いますが、対外的なSLAは無いと思います）
ただし、toBサービスで各顧客企業毎に契約書を交わす際、なんらかの形でSLAを記述することが多いとは思います。具体的に「SLA」と明記していなくても、「サービス継続稼働率は年間で99%にする」などサービス品質を記載し、「その品質を下回った場合には当月の費用を◯%減額する」などペナルティを記載したりすることがあります（SLAだからといって、必ずしもペナルティがあるわけではないです）。
SLOの必要性
SLIやSLOは、プロダクトチームとしてどのサービス指標を重視するか、サービス指標がどれだけ悪くなるとユーザー体験に影響するかを共通理解するために活用します。
一言で言うと、SLI/SLOは社内・チーム内向けのものです。
もしSLIやSLOがないと、
- サービスの安定供給のために、どのサービス指標を監視してよいかわからない
- （なんとなく）レスポンスのレイテンシーやエラー状況を監視しているが、どれだけユーザー体験に影響しているかわからない
- チーム内で合意した指標がないので、ステークホルダーや時と場合によって行き当たりばったりの対応になりやすい
ということが起こり得ます。
例えば、制定しているSLOに対して現状のサービスレベルが下がっている場合にはサービスレベルを上げる活動に注力するべきですし、もし十分なサービスレベルがあるのであれば新機能の開発に注力するなど、プロジェクトとして合理的な判断に役立てることができます。
ただし、PoCやプロトタイプなどの段階のプロダクトでは、SLIやSLO、ましてSLAを策定するのは不要なケースが多いと思います。
SLI/SLO/SLA策定プロジェクトを始める前に
一般的なプロジェクトの進め方として最初に以下のような事柄を決めておくとスムーズだと思います。
- 立ち上げの背景（Background）
- 取り組む課題（Problems）
- 目的（Objectives）
- 成果物（Deliverables）
- ステークホルダー（Stakeholders）
- スコープ（Scope）
- 期間・スケジュール（Schedule）
- リスク（Risk）
特にSLAを策定する際には、プロジェクトの開始時にステークホルダーを洗い出すとスムーズに進行すると思います。
よくある質問
- Q. SLIは指標なので、「○秒以内に返却」といった具体値ではなく、「サービスAの処理のレスポンスタイム」の方が適切なのでは？
- A. わかりづらいところなんですが、SLIは良い悪いを判定できる必要があり「サービスAの処理のレスポンスタイム」単体だとSLIになりえないと考えています。
参考資料
↓ 本記事の内容としては、主にこの資料を読むのが一番わかりやすいです。
↓ 他の補足資料（Googleが作成しているやつ）
- SRE サイトリライアビリティエンジニアリング
- サイトリライアビリティワークブック
↓ 参考SLA
Discussion