たった2ヶ月半でSLOを導入して事業判断に影響を与えた話

SLO SRE Datadog 監視 可視化

こんにちは、広告サービスを担当している飛田です。
今回は "SLO導入で悩んでいる方" に向けて、弊社リワード広告サービスでのSLO策定の取り組みについてお話したいと思います。

そもそもSLOを策定するに至った経緯は二つあります。

  • ユーザへの影響度合いが分かりづらいパフォーマンス問題などの対応が後回しにされがちで、品質改善がなかなか進まない
  • アラート通知があってもユーザに影響があるか即座に判断できず、静観や一部アラートを無視する状況もあり、モニタリングが形骸化しつつある

両方とも共通してユーザに与える影響を正しく把握できていないことが課題のようです。
そこでSLOを策定する過程でオブザーバビリティを高め、モニタリングの最適化とエラーバジェット運用で開発リソース配分の状況改善を図りました。 一挙両得作戦です。

細かな取り組みは順を追って紹介します。

プロジェクト初期

今回はチームでSLO策定に取り組むため、各自思考の方向性がブレないように目的とゴールを定義しました。
目的は経緯で挙げた2点の改善。ゴールは "SLO策定と仮運用の開始", "サービスの信頼性は担保された状態で行動が伴わない過剰なアラートを削減する" となりました。

このプロジェクト初期フェーズでは、チーム内の監視に対する理解と対象サービスのシステム構成や仕様理解の差を埋めることに注力しました。
やったことは簡単でmiro（オンラインホワイトボードサービス）を利用して、システムアーキテクチャの図をベースにサービス仕様やモニタリングの観点を整理し、チームの理解向上に努めました。

特にモニタリングの観点整理では、ユーザが満足するにはシステムはどのような振る舞いが必要か、ユーザ視点に立って議論を交わしました。
最終的に個々のシステムの状態（リソース）ではなく、システム全体として期待した動作を行っているか（ワーク）によりフォーカスすることでユーザへの影響を観測できると結論付け、よりユーザやシステムの境界に近い部分がモニタリングの重要ポイントと位置付けました。

f:id:AdwaysEngineerBlog:20220114125921p:plain ※補足：人型アイコンはサービスの想定ユーザ
※補足：ピンアイコンはモニタリングの重要ポイント

後ほどSLOの合意の話もしますが、このような図があるとステークホルダーに理解してもらいやすいと思うのでおすすめです。

ワークメトリクスからSLI策定

システムアーキテクチャの図をベースにモニタリング観点の整理ができたらSLIの策定に移ります。 この段階で既にざっくりしたSLI候補が見えてきます。

例えばユーザへの広告表示は

  • 広告情報のレスポンスが成功している
  • 十分な速さでレスポンスできている

といった感じです。あとはワークメトリクスをSLIとして設定するぐらいで良いと思います。

f:id:AdwaysEngineerBlog:20220114130048p:plain

SLIが決まったところで既存のモニタリング設定を最適化しました。最適化といっても既存のモニタリングがSLI（ワークメトリクス）と重複するので削除するだけです。SLIの方が抽象度が高いのでモニタリングの設定数は以前より減ることになります。

SLO策定

SLIに対してSLOを策定していきます。 とその前に、SLOにはモニターベースとメトリクスベースの二種類があります。今回細かな説明はしませんが、いくつか特徴がわかってきたので先に紹介します。

モニターベースの特徴

  • エラーバジェットを期間で管理できる
    • ただしアラートのリカバリ時間が最短でも1分であるため、最低1分はエラーバジェットを消費する（Datadogの仕様に依存）
      • SLIによってはdatadog-agentからの1分未満のCustomCheckを使えば回避できるかも（未検証）

メトリクスベースの特徴

  • バーストイベントを検知できる
    • モニターベースはSLIの閾値を越えたかどうかしか判断できないが、メトリクスベースはイベント数の急激な増減を検知できる
  • イベント数が金額などのサービスにおける重要指標に換算できる場合、エラーバジェットが直感的で分かりやすくなる
  • エラーバジェットの増減幅がイベント数の母数に依存する

これら二つの特徴からサービスにおける重要指標（売上など）に換算できるものはメトリクスベースを、それ以外は基本的にモニターベースを採用するようにしています。ただ運用実績がまだないので両方設定して様子を見たりしています。

SLO Targetのベースは暫定で99.9%、TimeWindowは一律30Daysで固定しています。SLO Targetが99.9%なのはバランスが良さそうって理由だけで、全く根拠はありません。感覚です。ステークホルダーや機能の重要性によって個別でSLO Targetを調整することはあります。エラーバジェットを消化しきった際のダウンタイムや損失金額の許容値から逆算してSLO Targetを設定するなどの工夫もしています。SLO Targetの見直しはできるというかするものなので、初めはあまり迷わずサクッと決めるのが良いかと思います。

SLOドキュメント
f:id:AdwaysEngineerBlog:20220114130130p:plain

DatadogのSLOモニタリング
f:id:AdwaysEngineerBlog:20220114130144p:plain

Datadogの分析ダッシュボード
f:id:AdwaysEngineerBlog:20220114130154p:plain エラーバジェットのアラート通知があった場合は速やかにダッシュボードを確認し状況把握と対応判断を行っています。

導入後の結果

経緯であった以下の課題が結果的に良い方向に変化しました。

  • ユーザへの影響度合いが分かりづらいパフォーマンス問題などの対応が後回しにされがちで、品質改善がなかなか進まない
  • アラート通知があってもユーザに影響があるか即座に判断できず、静観や一部アラートを無視する状況もあり、モニタリングが形骸化しつつある

ユーザ体験に目を向けた議論が活発化

今では "パフォーマンスとしては良くないがBotのアクセスはユーザ体験として損なっていないので、BotのリクエストはSLIから除外すべきではないか？" など、ユーザ体験や価値についての議論が度々行われています。最高に楽しい瞬間なのでみなさんも是非味わってみてください！

SLOの運用においては、策定段階で既にエラーバジェットを消費しきっているSLOがいくつかあり、SLIを含めSLO Targetの見直しも行っています。

直近の課題としては "サイトリライアビリティワークブックの5章~低トラフィックのサービスとエラーバジェットによるアラート~" で言及されているように、低トラフィック・低頻度で発生する失敗イベントでエラーバジェットを大きく消費する問題に直面しているため、そちらの改善も検討しています。

SLOを運用し、無駄なアラートを撲滅

SLO導入前後で形骸化したアラートの撲滅が出来ました。導入前にあったアラート全体のうち64%（数にすると約100回/月）あった静観していたアラートがゼロになりました。

またユーザ体験をもとに判断したアラートになるため、事業への影響が即座に判断できるようになり、ビジネス側とのコミニケーションもスムーズになりました。

エラーバジェットを消費したシステム課題に対して、開発案件の優先度に影響した

策定直後からエラーバジェットを消費していたSLOがありました。
プロダクトマネージャーを通してビジネス側と合意し、エラーバジェット回復のための特別チームを発足しました。 期間は約4ヶ月と限定的ですが信頼性回復のための開発リソースを確保出来きとても嬉しかったです。

最後に

SLOを導入することで色々な人から褒められました！
プロダクトマネージャーからは "SLOのおかげで問題の影響具合がわかるようになり、事業判断がスムーズに行えるようになって助かる" と労われました！嬉しい！

f:id:AdwaysEngineerBlog:20220114130211p:plain 所属する組織の定例会でも褒められました！嬉しい！

SLOの取り組みは始まったばかりなので、また知見をためてこの場で報告できればと思います。