CREATIVE BLOOM TEXT AdsのSLO策定と活用

Posted on by hiroshikamiya

はじめに

こんにちは！

SRE (Service Reliability Engineering) の神谷です。

この記事では、プロダクト開発センターで開発している CREATIVE BLOOM TEXT Ads のSLO策定について紹介します。

CREATIVE BLOOM TEXT Adsとは

CREATIVE BLOOM TEXT Ads は、検索連動型広告の効率的かつ効果的なPDCAを実現するプロダクトです。

主な機能は次の４つです。

  • 訴求軸⽣成機能
  • 広告⽂⾃動⽣成機能
  • 効果予測機能
  • 組合せ効果予測機能

出典

SLO策定のモチベーション

SLO策定のモチベーションについて説明するため、書籍『SREをはじめよう―個人と組織による信頼性獲得への第一歩』とブログ記事『SLOをもっとカジュアルに活用しよう』から引用します。

サイトリライアビリティエンジニアリングは、組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野である。

出典

SLIとSLOの良いところは一度設定してしまえばわかりやすい、ということです。SLOという共通の用語を用いて、「いまはSLOを満たしてるので、ユーザーが満足してサービスを使えてい（ると思われ）ます。」「いまはSLO違反になってしまったので、ユーザーは不満を感じてい（ると思われ）ます。」という会話が、エンジニア組織だけでなく、会社全体で行えるということです。

SLOを満たさなくなった場合は、開発の方向性としても、信頼性の回復を目指す方向にいったん舵を切ったほうがよいでしょう。しかし、何かしらの事情でそうできないこともあるかもしれません。重要なのは、SLIやSLOを共通の目安として会話のきっかけにすることです。

上の節で書いたように、SLOという目安があることで、そこを割り込むまでは開発組織は積極的に新規リリースを続けられます。さらにSLOを緩く設定すれば、余裕を持った開発ができるというわけです。

出典

このように、SLOは「適切なレベルの信頼性」について関係者の共通認識であり「新規リリースと信頼性の回復のどちらを優先すべきか？」を決めるための指針として活用できます。

  • SLOを満たしていないときは適切なレベルの信頼性が達成できていないため新規リリースより信頼性の回復を優先すべきだと判断できます。
  • SLOが満たされているときは適切なレベルの信頼性が達成できているため新規リリースを信頼性の回復より優先すべきだと判断できます。

SLOを活用することで、次のような問題を解決できます。

  • 信頼性が低すぎてユーザーの不満が溜まっている状況を放置して新規リリースを続けることにより、不満を持ったユーザーが離脱する。
  • 信頼性が十分高くユーザーが満足しているにも関わらず、信頼性の回復に工数を費やし、無駄なコストが発生する。
  • 適切なレベルの信頼性について関係者の共通認識ができておらず「新規リリースと信頼性の回復のどちらを優先すべきか？」を決めるときに対立が発生する。

CREATIVE BLOOM TEXT AdsのSLO活用

CREATIVE BLOOM TEXT Adsでは２週間ごとのスプリントレビューミーティングでSLOを報告し「新規リリースと信頼性の回復のどちらを優先すべきか？」を決めるための指針として活用しています。

エラーバジェットポリシーは次のように定めています。

SLO 運用方針（エラーバジェットポリシー）

  • 内部監視および外形監視の全ての SLO のエラーバジェットが残っていればユーザーは満足している。エラーバジェットを消費するリスクを取って新規機能の開発とリリースができる。
  • どれかひとつでも SLO のエラーバジェットが無くなるとユーザーは満足していない。新規機能開発を中断し信頼性の回復に注力しなければならない。

SLO策定の流れ

ここからはCREATIVE BLOOM TEXT AdsでSLOを活用するために何をしたのか、順番に説明していきます。

  1. プロダクトチームへの参加
  2. SLO策定開始
  3. CUJ決定
  4. SLI計測
  5. SLO決定
  6. エラーバジェット試験運用
  7. エラーバジェット本運用

プロダクトチームへの参加

まずはプロダクトチームに参加しインフラを整備しました。

１つのAWSアカウントに開発・検証・本番環境が混在しており管理が煩雑になっていたため、環境ごとにAWSアカウントを使い分ける運用に変更しました。

またAWSアカウントを移行する際に手作業でAWSリソースを作成するとミスが発生しやすいためTerraformを導入しました。

AWSアカウントの移行が完了し、開発の利便性が増すことで、プロダクトチームとの信頼関係を築くことができました。

SLO策定開始

前述のSLO策定のモチベーションをプロダクトチームメンバーに説明しSLO策定を開始しました。

SLOは適切なレベルの信頼性について関係者の共通認識なので関係者の協力が不可欠です。

CUJ決定

CREATIVE BLOOM TEXT Adsの主な機能４つのうち後者の３つをCUJとして定めました。

  • 訴求軸⽣成機能
  • 広告⽂⾃動⽣成機能（CUJ）
  • 効果予測機能（CUJ）
  • 組合せ効果予測機能（CUJ）

CUJを決定したとき訴求軸⽣成機能は開発中だったのでCUJには含めませんでしたが、今後CUJに含めるつもりです。

SLI計測

CUJごとにステータスとレイテンシをSLIとして定めました。

監視の方法は内部監視と外形監視の２種類を併用しました。

内部監視について、既存のログではステータスとレイテンシを計測できなかったため、開発メンバーに依頼してログ出力を追加していただきました。このように監視のために開発メンバーの協力が必要になることが多いです。日頃から信頼関係を築いておいて良かったと思いました。

外形監視はDatadog Synthetics のブラウザテストを採用しました。

SLO決定

SLOは高すぎても低すぎても良くありません。ユーザーが満足するギリギリのラインをプロダクトチームと相談し80%に決めました。

SLO は、ギリギリ達成 できればサービスの典型的なお客様が満足するような、性能や可用性のレベルにすべき

「SLO を満たしている」 ⇒ 「お客様は満足している」

「お客様が不満になる」 ⇒ 「SLO を満たしていない」

出典

SLOというと90%や99%などを想起する方も多いでしょう。80%という値は低すぎると思われるかもしれませんが、リクエスト件数が少ない場合を考慮しました。

  • 9件のリクエストのうち1件が失敗しただけなら、開発リソースを全て信頼性の回復に費やすほどではないので90%は高すぎる。
  • 9件のリクエストのうち4件が失敗したら、開発リソースを全て信頼性の回復に費やすべきだから50%は低すぎる。
  • 9件のリクエストのうち1件の失敗なら許容できるので80%が丁度良い。
総リクエスト数許容されるエラー数(SLO=50%)許容されるエラー数(SLO=80%)許容されるエラー数(SLO=90%)許容されるエラー数(SLO=99%)
100050020010010
1005020101
105210
94100

エラーバジェット試験運用

DatadogでSLOのダッシュボードを作成しエラーバジェットを可視化しました。

組合せ効果予測機能のSLOが満たされていないことがわかったので、開発メンバーに依頼してパフォーマンス改善をしていただきました。

試験運用の中で「新規リリースと信頼性の回復のどちらを優先すべきか？」を決めるための指針としてSLOを活用する練習ができました。

エラーバジェット本運用

パフォーマンス改善によってSLOが満たされるようになったので、エラーバジェットの本運用を開始しました。「CREATIVE BLOOM TEXT AdsのSLO活用」で述べたようにスプリントレビューで「新規リリースと信頼性の回復のどちらを優先すべきか？」を決めるための指針としてSLOを活用しています。実際、本運用後にSLO違反になり、信頼性の回復を最優先で対応していただいた結果エラーバジェットが回復しSLOを満たすようになったことがあります。SLOを活用し優先度を決めることで、適切な信頼性を達成できずユーザーが不満を感じている状態を早期に解決できました。

おわりに

書籍『SREをはじめよう―個人と組織による信頼性獲得への第一歩』のイベントにおける訳者の山口氏への質疑応答から引用・抜粋します。

質問

SREは他の職種と違ってここが面白いと思うポイントはありますか？

回答

  • 「信頼性を適切に持続的に維持できるようにしましょう」というのがポイントです。
  • 「適切」「持続的」はビジネス視点が入っており、ただ技術をやるだけではありません。
  • 一方で、いざ技術をやるときはすごく深掘りをします。
  • これらを横断的にできるのがSREを実践するエンジニアの醍醐味です。

CREATIVE BLOOM TEXT AdsのSLO策定と活用でSREの醍醐味を楽しむことができました。

適切なレベルの信頼性としてCUJやSLOを決定するためにビジネス的な視点を持ちつつ、SLI測定のためにログやDatadogなど監視の技術を深掘りしました。

これらのトピックについても、今後ブログで詳しく取り上げていきたいと思います。