はじめに
クラスメソッドタイランドの清水です。
2024年5月30日にタイ・バンコクで行われた AWS Summit Bangkok の「Better reliability with SLOs」というセッションに参加しました。
SLO とは
Google は SRE の用語を定義するにあたり、システムの可用性を正確な数値目標として設定したいと考えました。この目標をシステムの可用性サービスレベル目標（SLO）と呼びます。
と SRE の基本（2021 年版）: SLI、SLA、SLO の比較 で紹介されています。
このセッションでは、タイトルの通り SLOs(Service Level Objectives) とそれに関連するコンセプトが簡潔に分かりやすくプレゼンされていました。
それでは内容に入りましょう。
セッションの内容
アジェンダ & 導入
まずはアジェンダです。
以下の5つのセクションに分かれています。
次に導入です。
サービスは Product Innovation と Reliability のジレンマにあります。
例えばウェブサービスを変更しようとすると、CPU usage が増えてサービスが落ちてしまうかもしれません。
一方でサービスが落ちないように変更を控えると、イノベーションは起きません。
そこで、このジレンマを解消するために SLOs が使われます。
SLOs は、
- アプリケーションのパフォーマンスの目標を明確に決めるためのフレームワークを提供する
- 一貫したカスタマーエクスペリエンスの提供し、機能開発とアプリケーションの安定性のバランスをとる
ことを助けてくれます。
SLIs, SLOs, SLAs & Defining quality targets
ここから SLIs, SLOs, SLAs についての説明です。
まずは SLIs(Service Level Indicators) です。
SLIs とはサービスのある側面を表す量的な計測だそうです。
例として、
- あるエンドポイントで成功したリクエスト数
- あるエンドポイントで 500ms 以内に処理が完了したリクエストの数
などが挙げられました。
次は SLOs です。
SLOs は SLI に時間の枠を組み合わせたもので、アプリケーションのターゲットとなる指標です。
例として、
- 直近 24時間で、あるエンドポイントへのリクエストのうち 99.95% は成功する
- 直近 30日間で、あるエンドポイントへのリクエストのうち 90% は 500ms 以内に処理が完了する
が挙げられていました。
最後に SLAs(Service Level Agreements) です。
SLAs は、1つ以上の SLOs が満たされている or 満たされていない場合の結果に対する契約です。
例として、以下が挙げられていました。
- ユーザーは1日あたり最大 0.05% のエラーを許容し、0.05% を超えたら rebate（部分的な払い戻し）を受ける
- ユーザーは1ヶ月あたり 10% のリクエストが 500ms より長くかかることを許容し、10% を超えたら超過分の払い戻しを受ける
Error budgets
Error budget についてです。
シンプルに 1-SLO だそうです。
つまり、ある SLO が 99% なら、 Error Budget は 1% になります。
Burn rates
次は Burn rate についてです。
定義がよく分からなかったので Datadog のウェブサイトで調べました。
これは単位のない値だそうで、
length of SLO target (7, 30 or 90 days)/burn rate = time until error budget is fully consumed
と Datadog - Burn Rate Alerts で紹介されていました。
例えば Burn rate が 1 の場合、 Error Budget を SLO で定めた time period でちょうど使い切り、
2の場合 time period の半分の時間で Error Budget を使い切ってしまい、
3の場合 time period の 1/3 の時間で Error Budget を使い切ってしまう、といった解釈ができるそうです。
最後に
アジェンダの最後の Practical example は動画だったので省きますが、Datadog で SLO とその周辺のコンセプトを実装する方法を紹介していました。
SLIs, SLOs, SLAs についてあまり理解していなかったので、今回のセッションは非常に有益でした。
2
