Splunk Observability Cloud で SLO Management をはじめる

こんにちは。年末進行で、お疲れ気味の方もいらっしゃるのではないでしょうか。

出遅れてしまったのですが、Splunk Advent Calendar 14日目の記事です。

https://qiita.com/advent-calendar/2024/splunk

サービス監視とサービスレベル目標管理

『自社が運用しているサービスが健全な状態か、把握できるようにしたい』
『サービスに対して影響が生じている場合にはすぐに気づいて対処したい』
『サービスに影響が生じ得る傾向を見つけたら、プロアクティブに対処できるようにしたい』

これは、システムに関わる多くの人にとっての関心事でしょう。

一方、従来的な運用のアプローチは、例えば、詳細なアラート設定をさまざまに行うことで障害を見逃さないというアプローチをとることもあったでしょう。この結果として大量のアラートが発生し、本当に気づきたい事象や通知が埋もれてしまうという経験をしている方もいるのではないでしょうか。これによって、サービスの状態を正しく把握できるようになったかと言うと、必ずしもそういう訳ではないはずです。
ボトムアップ的な監視の構成をベースとして、サービス監視を実現していくには一工夫が必要になっていきます。

これに対して、現代的なシステム開発・運用において、サービス信頼性を管理していくために取られるアプローチとして、サービスレベル目標管理（SLO Management）という考え方を取り入れるケースが増えてきています。

• SLI(Service Level Indicator): 現在のサービスレベルを計測できるような指標
• SLO(Service Level Objectives): SLIについて、全体のイベントのうち「良い状態」と判定できる割合がどの程度かを定めた目標値
• エラーバジェット: SLOを下回るまでに発生させてよいエラー状態の残り予算

これらの指標をもとにサービスの現在の信頼性を把握し、品質改善のためのアクションを取るのか、開発をより進めていくのか、といった意思決定に活用していく、というのがサービスレベル目標管理の考え方です。

サービスレベル目標をより良く知るためには、以下が良い教科書になるはずです。是非ご覧ください。
https://www.oreilly.co.jp/books/9784814400348/

Splunk Observability Cloud における SLO Management 機能

Splunk Observability Cloudをオブザーバビリティバックエンドとして利用していただいている場合、簡単にサービスレベル管理をはじめることができます。

まず、"Detectors & SLOs" メニュー内の "Service level objectives" タブを開きます。
新規作成を行う場合には "Create SLO" からやっていきます。

メニューを開くと、上から順に設定を行っていきます。

1. "Choose a service or metric indicating the health of a system"
   • APMでトレースやメトリクスを取得しているサービスのリクエスト成功率やレイテンシをSLIとして設定できます
   • また、任意のメトリクスをSLIとして設定を行うことも可能です
2. "Define your objective and how to measure it"
   • 選択したサービスやメトリクスにサービスレベル目標値と評価期間を設定します
   • SLIの推移や、SLO準拠状況、エラーバジェットやバーンレート（エラーバジェットの消費レート）を確認できるので、適切なSLOになるように調整していきます
3. "Choose when and how to be notified"
   • SLOの準拠状況に応じた通知について設定します
     • "Breach event" - SLI が評価期間における SLO を割り込む状況になった際に通知
     • "Error budget" - エラーバジェット残りが10%になった時点で通知
     • "Burn rate" - バーンレートが一定以上になった際に通知（詳細はこちら）
4. "Name and save"
   • 作成したSLO Management設定に対して名前を付けて保存します

こういった4ステップだけでSLOを作成することができます。

実際にどう使っていくか

上のスクリーンショットの場合、デモ環境の "adservice" というアプリケーションの処理に関わるレイテンシーを評価しています。
過去30日間、500ms以下で処理される割合が90%以上であることを目標値と設定していますが、現状は 88.996% がこの条件を満たしているということで、SLOを割り込んでいるということが分かります。アラート設定も行っているので、通知が飛んできているはずです。
ユーザー体感に影響が生じている可能性があるので、品質改善のためのアクションを取る必要があるかもしれません。逆に、ユーザー体感としてそれほど問題になっていない（例えばクレームが増えていない、売上などに影響が出ていない…）場合は、SLOの設定自体が高すぎるのかもしれません。SLO設定を見直すということも考えられるでしょう。

他の例としては、例えば、Synthetics による外形監視（合成監視）を行っていたとします。
「一度でもテストが失敗したらエラー」となると、ユーザーにとって問題となるような事象が発生していないにもかかわらずアラートが飛んできてしまう可能性があります。
そこで、例えば「過去30日間にわたって、テスト成功率が99%以上であれば品質上問題なし」と捉えることにして、Syntheticsのテスト実行に関わるメトリクスをSLI、Last 30 daysで99%をSLO Targetとして設定するという形です。
これによって、ユーザー影響がありそうな品質低下が発生している場合にのみ通知を受け取るということができるようになるはずです。

SLO管理を通じてユーザー信頼性にフォーカスした運用へ

特にクラウドネイティブなアーキテクチャへの移行が進んでいくにつれ、オブザーバビリティといった考え方への変化が必要となっていきます。これにあわせて、サービスレベルにフォーカスを当てたエンジニアリングを取り入れていくことで、よりスマートに、より効率的に開発や運用を進めていきましょう！