こんにちは。運用開発グループの井内です。私は4月よりサービス開発の部門からサービス運用の部門に異動となりSymphonictブランドで提供されている各種サービスの運用業務に従事しています。
いままでは、サービスの要件（主にSLA）に沿ってシステムを構築することが多かったのですが、サービスを運用側の立場で考えると、SLAに加えてSLOやSLIといった言葉を意識するようになってきました。また昨今のサービスでは当たり前になってきている、DevOpsを実現するためにもSLOが大きなキーになっています。今回の投稿では自身の振り返りも含めSLA/SLO/SLIといった言葉を改めて整理したいと思います。
SLAとSLO
最初にそれぞれの言葉についてまとめていきたいと思います。
- SLA・・・Service Level Agreement（サービスレベル合意）
- サービスの提供者と利用者が、そのサービスが満たすべき品質について合意するための合意・契約
- 主に社外向け（利用者）向け
- 未達の場合のなんらかのペナルティが課せられる（キャッシュバック等）
- 一般的なクラウドサービスでは「可用性」という形で記載されることが多い
- SLO・・・Service Level Objective（サービスレベル目標）
- SLAで取り決めた内容を達成するために、サービス提供者側が設定する目標
- 社内外の関係者向け（ただし社外には公開されないケースが多い）
- 未達でもペナルティは無し（そのためSLAより厳し目に設定されることが多い）
- 必ずしもSLAと同じ指標にはならない。（むしろ別のケースが多い）
ここで重要なのはSLAは契約であって、SLOは目標（指標）だということです。さらに関連する言葉についてまとめていきます。
SLI
- SLI・・・Service Level Indicator（サービスレベル指標）
- SLOで取り決めたパフォーマンスを達成できているかどうかを測定するための指標
- 例 リクエストの応答遅延時間、データ処理のエラー率、ストレージのスループット等
- SLOを定義する際に使用
SLO/SLIを使ったサービス運用
サービスの利用者にはSLAが契約という形で見えておりますが、裏ではSLO/SLIといった指標を持ってサービスの状態を測定し運用します。SLAは一般的には稼働率（インスタンスのアップタイム等）になりがちです。理由は色々あると思いますが、私は以下の要因が大きいと思っています。
- 利用してるクラウドのSLAに引っ張られている（VMインスタンスの稼働率が99.95％等）
- 契約なのであまり複雑な指標が設定しづらい
そのため実際のサービス運用を考えた際に利用者にとってより体感的に重要なのはSLOの場合が多いのではと思います。例えばWeb系システムを利用すると考えたとき、アクセスできないとあれ？ってなることもありますが、そのうち復旧するだろうと軽く流されることもありますがアクセスした際の画面の描画速度等が常に遅いと、このサイトどうなっているのだろうってイライラしますよね？僕だったらします（個人差あります）このとき画面の表示までの応答速度をSLI（指標）として設定し、一定速度の応答を保てることをSLO（目標値）として運用するイメージです。
ちなみに最近のクラウドサービスではクラウドの標準機能としてSLOをモニタリングする機能を有している場合もあります。例えばGoogle CloudですとSLOモニタリングという機能が提供されております。
SLOモニタリング https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring
まとめ
今回はサービス運用に関わるSLA/SLO/SLIという言葉についてまとめてみました。利用者の皆様により快適にサービスを使っていただくために、SLOをしっかりと意識しながらサービス運用をしていきたいと思います。
