はじめに
SRE (Service Reliability Engineering) 部の村上です！
前回の記事では、SLO とはなにか、その概要を説明しました。
本記事は、Advertising Flow （以下 A-Flow と呼びます）での SLO の取り組みを紹介します。
SLO の復習と、A-Flow における CUJ と SLI の戦略
SLO に関する取り組みは以下のような流れになるということを前回ご紹介しました。
- ユーザ視点で重要な機能や体験を抽出し、 （CUJ の策定）
- 抽出した機能の信頼性を測定し、（SLI の測定）
- ユーザが満足するラインの目標を設定し、（SLO の策定）
- SLO と実際の信頼性とを対比し、行動を決定する（Error Budget の測定と行動計画）
ですので、まずは CUJ …つまり「ユーザ視点で重要な機能や体験」を見定める必要があります。
これについて、A-Flow の企画担当と開発担当にヒアリングを行い、取りまとめを行った結果、以下のような CUJ が得られました（一部抜粋）。
- 運用者がプロモーションの配信状況を確認する
- 運用者が最新の予算利用率をプロモーションごとに確認をする
- 予算やスケジュールに応じて広告配信の自動停止と自動再開を行う
- 広告媒体へ自動で予算更新を行う
先述の通り、CUJ は「ユーザ視点で重要な機能や体験」から抽出されるべきであるため、一般の web サービスであれば実際の操作フローをなぞるようなものが良さそうです。
そしてこの場合、SLI を測定するためには RUM (Real User Monitoring) や Synthetics Test 等を活用し、例えばレスポンスの成功率や、レスポンス速度等を SLI とすると良さそうです。
一方、A-Flow は、設定に従ってバックグラウンドで動作する Agent のようなものであり、それが動作していることはユーザにとって非常に重要です。
それは、A-Flow が、かつて手動オペレーションで行われていた予算の最適化や自動停止・再開を自動化するという目的で開発されたものであるからです。
そして、こういった CUJ に対してはその動作が適切である件数を SLI とすることにしました。
これはかなり内部監視の延長のようなアプローチかも知れませんが、しかしプロダクトの特性を考えたときに最適な戦略が選択されていると考えています。
SLI の実際
では、実際の SLI の動向を見てみましょう。
ここでは、CUJ「広告媒体へ自動で予算更新を行う」を取り上げます。
まず、この CUJ はバックグラウンド処理にまつわるものなので、その処理状況を確認し動作が妥当であるか否かを判定し結果を json で log 出力するようなスクリプトを実装しました。
log は Datadog に転送され、測定などを行っていきます。
以下は、出力の例です（数値などはすべてダミーです）。
attributes には、測定対象であるプロモーションやキャンペーンなどの情報が入っています。
details は、判定に利用した情報が入っています。details.actual は実際の予算の値や自動で予算更新を行うか否かを判定するのに必要な情報が入っています（長いので隠しています）。details.expect は、予算最適化エンジン Sophia によって最適化された予算金額と、そのロジック元の情報が入っています。
そして、result には判定結果が BOOL値で入っています。 また、判定対象でないケースもあり、その場合は NULL が入ります（NULL の場合 Datadog では表示されません）。
この result の件数を利用して SLI を計算しており、 SLI = {{result が true であった件数}} / ({{result が true であった件数}} + {{result が false であった件数}} )
と定め、計測しています。
そして、実際の測定結果の推移がこちら。
赤い線が立っているのが見えるかと思いますが、実際にインシデントがあったものが確かに観測されているものになります。
SLI の活用と SLO の策定に向けて
この SLI に対して、SLO…つまりウィンドウ期間や閾値をどうするかは 2025年9月現在、絶賛議論中です。
ウィンドウ期間の設定、閾値の設定はだいぶ難しいなと感じています（笑）。
一方で、この SLI を測定し振り返りを行うことで「前々から問題が起きそうと言われていた部分について手を付けたほうがいいよね」という議論が起こり、実際に着手されることが決定しました。
これはプロダクトの信頼性を適正化するにあたって非常に良い流れだったと感じています。
勿論、測定されたSLI に対し SLO として そのウィンドウ期間と閾値とを定め、Error Budget に従いチームの行動計画が立つというのは王道であり、それを目指すべきなのは間違いありません。
一方で、特に SLO の取り組みの初期段階においてその利用方法等を限定する必要はないと私は考えます。
「このプロダクトにおいて何が真に重要な要素であるかの共通認識を生み出せること」
「実際に測定された SLI について定期的に振り返り、何をするべきかがビジネスや開発などの役割を問わずプロダクトに関係する人全員で議論され、アクションが決定・合意されること」
これらがチームを一体化させ、プロダクトの信頼性の適正化に繋がると考えています。
プロダクトの状況に応じてうまく SLO を活用していきましょう！