国内サービスで実現！SREチームによるSLOスモールスタート導入事例

はじめに 

株式会社メンバーズデブオプスリードカンパニーの木内です！

突然ですが、SLO※1の運用はされていますか？
実際にSLOを導入してみて感じたのは、理論の理解よりもその実践の難しさでした。

Googleが提唱した理論をそのまま当てはめるのではなく、自分たちのサービスにとって意味のある形とは何なのかを自分たちで考える必要がありました。

そして、何より困ったのは自分たちと同じようなサービスがSLOを導入した事例が見つからないことでした。

そこで、私たちはSLOを導入した内容を実例としてここでシェアしたいと考えました。
これからSLOを導入したいと考える方の手助けとなれば幸いです。

※1 SLO（Service Level Objective）は、サービスの信頼性を評価するために設定する「具体的な数値目標」のことです。

SLO導入の進め方

SLOの導入は以下のプロセスで実行しました。
SLOの運用はサービス全体で取り組まないと成立しません。よって、実装よりも関係者への説明を重視しました。期間としては他開発と並行しながら3ヶ月程度で完了しました。

1.クリティカルユーザージャーニーとSLIの決定
2.SLOの決定
3.SLO計測のための設計・実装
4.エラーバジェットモニタリングのための設計・実装
5.ステークホルダーに向けてSLO導入の説明を実施
6.開発チーム全体に向けてSLOの導入と運用の説明を実施

最終的なSLOの運用方式

前述のプロセスを経て、最終的に導入したSLOの運用が以下になります。
自分達が運用できる内容を見極めて、スモールスタートでの立ち上げを優先しました。

SLO

・可用性のみ：99.9%（評価方法：30日間のローリング）　

設計のポイント

・レイテンシーなど他のSLOは将来検討するとして見送りました。
・SLAが無かった事もあり、評価方法は採用事例の多い30日間のローリングとしました。
・成功のリクエストはシンプルにHTTPステータス：2xx + 3xxのみにしました。
・集計対象のリクエストもシンプルにHTTPステータス：2xx + 3xx + 5xxのみにしました。

4xx（クライアントエラー）は思い切ってクライアント側の問題として、SLOの計算から除外しました。
この辺りの取り扱いを厳格に設計するよりも、SLOを早く導入する事を優先したためです。

例えば429のステータスはTooManyRequestsを意味するため、失敗のリクエストとも考えられます。一方で、可用性の設計通りにサーバーへのアクセスを遮断できているため、成功のリクエストとしても整理している事例もあるようでした。私たちの場合は、これの検討に労力を割くよりも、SLOの運用を早く始めることに価値を置いて進めました。

SLI

・単一のAPI x3のみ（クリティカルユーザージャーニーに関わるAPIが対象）

設計のポイント

・SLIもシンプルに対象のAPIのエンドポイントのみにしました。
・日常的に異常が起きている依存先サービスとの通信は計測対象外にしています。

正確なユーザー体験が計測できなくなるデメリットがありますが、日常的に異常が起きており、かつ是正される事が望めない依存先サービスについては計測の範囲外にしました。
長期間の是正待ちが見込まれ、SLO導入の目処が立たなくなるとして、やむを得ない判断となりました。

エラーバジェットのモニタリング

・エラーバジェットの残量に閾値を設け、超過時はアラートを通知する。
・アラート通知後はSLO違反の発生前に復旧する。必要であればリリース計画を変更する。
・SLO違反が起きた場合、リリース計画を変更して早期に復旧する。
・開発チーム全体でエラーバジェットの消費傾向を定期的に確認する場を設ける。

設計のポイント

・エラーバジェットのモニタリング方式はバーンレートアラートが定石だと思います。しかし、バーンレートアラートは常に大量のリクエストが有ることが前提のため、私たちのサービスには適さないとして採用を見送りました。
・エラーバジェットの枯渇時でも復旧以外の開発をどの程度止めるかは障害の状況などを総合的に判断する方針にしました。セキュリティへの対応など、現実的にはリリースを延期できない開発が存在するためです。

SLOの導入を成功させる鍵

自分たちのサービスの特性を理解する

当たり前ですが、SLOに関する理論は提唱元のGoogleに最適化された内容に感じました。
具体的には以下のような特徴があるサービス向けだと思います。

・世界中に多くのユーザーが居るサービス
・特定の国の休日や夜間時間帯にトラフィックが大きく左右されない。
・常に膨大なリクエストがある。（SLOの評価期間中に一つのSLIで数百万以上）

実際にSLOを導入するにあたって、自分達のサービスの特性を理解する事が重要でした。
例えば、私たちのサービスの特徴は以下です。
Googleとは大きく異なるため、そのままSRE Workbookの内容を取り入れる事はできず、調整が必要でした。

・日本国内で展開するサービス
・夜間などにトラフィックが大きく減る。
・Googleのような世界的なサービスと比べてリクエストが少ない

この事を事前に理解しておけば、ステークホルダーを交えた検討でもスムーズに進められると思います

スモールスタートで始める

SLOに関しては、緻密に設計するときりが無く、導入が進まないと思います。
また理論を網羅すればするほど、実際に運用するハードルが高くなってしまいます。
そのため、全てを検討しないで運用できる範囲から小さく導入するのが良いと思います。SLOの計測をするだけのようなパターンでも十分意味があるように感じます。

おわりに

SLO導入前の私たちはサービスの信頼性を感覚的にしか評価できませんでしたが、今では信頼性が基準を満たしているかを客観的な指標で判断可能になりました。
ぜひ皆さんのサービスでも導入を進めてみてはいかがでしょうか。