toB サービスに SLO を導入する上で考えたこと

こんにちは。SRE チームの izzii です。本記事では私にとって弊社での最初の取り組みの一つである SLO の導入について、事例として紹介いたします。 先日、自分の取り組みの答え合わせを目的として、SRE NEXT 2022 に視聴者として参加いたしました。そこで得られた学び気づきも載せていきたいと思います。

SLO 導入の背景

テックタッチでは、昨年の冬に開発チームからの独立という形で、SRE 組織が生まれました。始まりは、組織横断的な技術課題を解決するためのタスクフォースチームに近いものがありました。2022年3月、自分が実質3人目の SRE としてテックタッチに参画しました。そして、より一般的な SRE 組織の運用を取り入れるために、ミッションの舵きりを明確化し、他チームに対して関わり方の変化を宣言しました。

弊 SRE 組織は取り組みの第一歩として、サービスの信頼性を担保するための仕組みである SLO を導入することにしました。 テックタッチという製品に対して、どのように考えて SLO とエラーバジェットポリシーを制定したか、ということを紹介しようと思います。

具体例から知る SLO

まずは SLO を構成する SLI の具体例を見てみましょう。SLI の I は Indicator (指標) の I です。

• 1週間の間で request response の成功率が 99.9% 以上
• 1カ月の間で、時間を5分単位で分割した時に、通信レイテンシの99%タイルが1秒を超えている時間の割合が 99.9 % 以上（ワーストケースでなく 99%タイルを使うことで、外れ値に左右されにくいメトリクスとなります。）

次に SLO の具体例は以下です。

過去7日と30日のデータを元に計算された SLI が 99.9 % という SLO を上回っている例

SLO は、0-100%の範囲に収まりかつ高い方が嬉しいように設計された SLI の目標値です。SLO の O は Objective (目標) の O です。

機能の開発やリリースは SaaS ビジネスのために最も重要な活動でしょう。ただし、アグレッシブな開発やリリースによって、気が付かないうちにプロダクション環境ではサービスの品質が悪化し、信頼性が低下しているかもしれません。上にあげた SLO を常に監視していればそうした品質低下にすぐに気がつけそうな気がしませんか？

SLI、SLO、SLA の違いは以下です。

SLI	Service Level Indicator	サービスの信頼性を表す指標。リクエストの成否、レスポンスタイムやデータベースのスループットなどを数値化したもの。
SLO	Service Level Objective	サービス信頼性の目標値。SLI を用いて定義される。１週間でのリクエスト成功率99.9% など。
SLA	Service Level Agreement	ユーザーとの契約上、サービスが保証しなければいけない値とその約束。SLA を破った場合の営業損失の賠償などを契約に盛り込むことがあります。

エラーバジェットポリシーとは？

エラーバジェットポリシーとは SLO を満たせない場合の開発チームの行動指針です。この行動指針がなければ、SLO を設定してもただ数字を眺めるだけになってしまいます。

Google はポリシーを例示してくれています。 https://sre.google/workbook/error-budget-policy/

SLO 導入の目的

「SLO（数字）とエラーバジェットポリシー（行動指針）をもとに開発することで、一定の信頼性を保ちながらサービスを成長させていくこと」が我々にとっての目的です。

SRE NEXT 2022
Visional 國井さんの発表より
(https://sre-next.dev/2022/schedule#sp04)

一般的に使われている（と考えられる）信頼性の定義は以下です。

[システムが]求められる機能を、定められた条件の下で、定められた期間にわたり、
障害を起こすことなく実行する確率

(Oco12:P. O'Connor and A. Kleyner, 「Practical Reliability Engineering」, 5th
edition: Wiley, 2012.)

Visional さんの紹介で見て、改めて発見しました。
組織をエンジニアリングするということが語られる良い発表でした。

SLO を設定して運用するということは、SLO を監視しながら、エラーバジェットポリシーに従って、品質改善のための施策を開発ライフサイクルに差し込むことです。ステークスホルダーと合意された数字と行動指針をもとに開発を進めることで、一定の信頼性を保ちながらサービスを成長させていくために SLO を設計します。

SLO の定義で考えたこと

テックタッチでは以下の方針を取りました。

• ユーザー体験を反映する SLI を利用すること
• シンプルであること
• バックエンドで計測すること

ユーザー体験を反映するSLIを利用すること

導入の目的でも語りましたが、SLO という数字をもとに開発計画に差し込みが発生します。つまり、品質改善と機能開発を天秤にかけることになります。SLO は、機能開発と天秤にかけられる値でなければ継続的な運用が難しいと考えました。 （サービスレベルの定義から自明だと思われる方がいらっしゃるかも知れませんが、「なぜ」を掘らないと陳腐化しそうだったため。）

merpay さんの事例
(https://www.youtube.com/watch?v=EPABCe90AaI&t=1384s)

共通の SLI/SLO をマイクロサービス横断的に生成した事例が公開されています。
設定しても運用に乗らなかったという失敗込みの話なので非常に学びがあります。

シンプルであること

細かい条件を使ったメトリクスは、背後の実装や仕様変更の都度基準が変わってしまい、継続的な計測には不向きだと考えたからです。

バックエンドで計測すること

これは実装コストの問題です。ユーザーに近い場所で観測した値の方が、基本的にはユーザー体験の表現としてより相応しくなり、納得感のある数字目標が立てやすくなると考えています。（数値の要因分解は難しくなりますが。）SLO の効果が優れていれば、コストをかける判断をしたいと思います。

SRE NEXT 2022
Tapple 永野さんの発表より
(https://sre-next.dev/2022/schedule#jp47)

Tapple さんではより正確なビジネス判断のために、
SLI の観測機構をモバイル（よりユーザーに近いところ）に移したそうです。

テックタッチでは下記のような SLI を設計しました。 ちなみに目標値である SLO は、非公開とします。

ユーザー種別	SLI	体験
エディター	エディター関連のリクエスト成功率	いつでも正しく
エディター	エディター関連のレイテンシ	いつでもサクッと
プレイヤー	プレイヤー関連のリクエスト成功率	いつでも正しく
プレイヤー	プレイヤー関連のレイテンシ	いつでもサクッと
エディター	プレイヤーの利用履歴収集リクエスト成功率	いつでも正しく

テックタッチはブラウザで動くサービスに操作動線やマニュアルなどを自由に付加できるサービスです。 ユーザーが大きくエディターとプレイヤーの２種類に分類されます。

エディターとは対象システムの上に操作動線やマニュアル（ガイド）などを作成する人です。社内システムのガイド作成者であれば人事部の方であったり、SaaS の場合はカスタマーサクセス担当の方であったります。

プレイヤーとは、対象のシステムの利用者であり、エディターの作成したガイドを実際に使う人です。

上記テーブルの一番最後の SLO は、若干分かりづらいので補足します。テックタッチは、利用状況からガイドの効果を測定することができます。もしもデータ収集が失敗すると、エディターが間違った情報を受け取ることになります。なのでエディターの体験を計測するためにプレイヤー関連のメトリクスを用いています。

逆に無視したプラクティス

すでに自覚している無視したプラクティスも載せます。

• クリティカルユーザージャーニー（CUJ）から設計する
• メトリクスの S/N 比を考慮する

クリティカルユーザージャーニー（CUJ）から設計する

一般に1チームで追いかけるのに相応しい SLO の数が3から5程度と言われている中で、ユーザー行動を分割して多くの SLO がある状況が好ましいと思えませんでした。またクリティカルなユーザー体験だけに絞るよりは、全体から怪しい事象を探索しようと考えました。

メトリクスの S/N 比を考慮する

S/N 比とは Noise に対する Signal の強度のことです。実際にユーザー体験の分割が大まかなせいで、特にレイテンシー系の SLI は S/N 比が低いと考えています。

しかし、分解能の低さによる S/N 比の低下の要因を分解すると

• API 毎の実装のバラツキ
• API 毎の品質のバラツキ

であると考えられ、後者の影響が無視できない現段階の我々にとっては大事ではないと判断しました。

SRE NEXT 2022
Google 山口さんの発表より
(https://sre-next.dev/2022/schedule#jp49)

Art of SLOs （https://sre.google/resources/practices-and-processes/art-of-slos/）
ではクリティカルユーザージャーニー（CUJ）から SLO を構築していくプラクティスが紹介されています。

エラーバジェットポリシーの定義で考えたこと

エラーバジェットポリシーは、信頼性の低下がサービスに与える影響から考えて設計するのが良いかと思います。サービスと顧客の性質に左右されることでしょう。

SRE NEXT 2022
Tapple 永野さんの発表より
(https://sre-next.dev/2022/schedule#jp47)

Tapple さんはレイテンシをコントロールできるデバッグツールを用意して、
SLOの設定値をユーザー体験として納得がいくものに調整しているそうです。

テックタッチのサービスページの導入事例（URL）を見ることから分かるように、エンタープライズ案件での引き合いが比較的多いサービスです。

BtoB のサービス開発に携わった経験があれば想像に難くないかと思いますが、特定の機能を導入の前提とされる案件がそれなりにあります。つまり機能開発が売上に強く影響します。

現段階では罰則の強すぎないポリシーが良いだろうと考えました。

テックタッチでは、以下のようなポリシーを運用していく予定です。

（表現を改変しています）
ある定例で確認し、1 month エラーバジェットを使い切っていた場合
    - それが特定の障害が原因だと考えられ、その原因の対処が済んでいる場合は無視しても良いこととします。
        - それがペネトレーションテストといった検証行為が原因だと考えられる場合は、無視しても良いこととします。
    - 上記以外の場合、SREと開発チームで改善タスクを作成し、優先課題として開発チームとSREが取り組みます。

「ある定例」を審判のタイミングとして改善施策の実施判定することにします。直前にはエンジニアが祈りを捧げるようになるかもしれません。

最後に

本記事が、SLO 導入時の考え方の参考になれば幸いです。

テックタッチは今後数年で大きく成長すると確信しているので、そうなった時に、今この時に蒔いたタネがサービスのスケールを支えてくれるのではないかと考えています。

導入にあたって、教科書的な SLO のあり方や他社事例、テックタッチのサービスと顧客の性質に則って考えましたが、いつかは多少の破綻があろうと考えています。

例えば、エラーバジェットポリシーの曖昧性が高いせいで、時間が経つにつれて楽な解釈に傾く心配をしています。

SRE NEXT 2022
Eureka 山本さんの発表より
（https://sre-next.dev/2022/schedule#sp13)

SLO ではクリティカル課題が掘れなかったため陳腐化してしまったことが紹介されていました。

半年から1年後を目安に、今回の施策の振り返りを実施したいと考えています。

参考

https://newrelic.com/jp/blog/best-practices/best-practices-for-setting-slos-and-slis-for-modern-complex-systems https://www.youtube.com/watch?v=EPABCe90AaI&t=1384s https://sre.google/workbook/error-budget-policy/ https://sre.google/resources/practices-and-processes/art-of-slos/ https://docs.google.com/presentation/d/e/2PACX-1vQuZan2U2cI-S0XTv6awv-52xyvR5opN2Y17eyTU4HlCBt3lrpqFxh7eQqk4cj8Bdqrf5aluKsbRF5C/pub?start=false&loop=false&delayms=3000&slide=id.g48a57ebc11_0_0 https://speakerdeck.com/kazumanagano/yoriuxnijin-islislofalseyun-yong-niyoruke-yong-xing-falsezai-she-ji