大規模投票サービス「WINTICKET」だからこそ SRE の重要性を改めて感じた話
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、WINTICKET に Embedded SRE として参加し、そこで得られたメリットを紹介します。
SRE x 売上顧客生涯価値（LTV）の向上システムの信頼性による顧客満足度向上SRE と売上との相関WINTICKET で得られた SRE メリットビジネスとの連携のしやすさ潜在的に悪化するサービス品質を可視化できるWINTICKET サービス紹介自己紹介Embedded SRE目的別部署に SRE をやっていくためにSRE とモニタリング個人的なモニタリング・アラートツールアラートの整備アラートシステムの統一化Grafana の勉強会を実施Toil の削減コスト削減コミュニケーションWINTICKET のシステム構成監視周りのアーキテクチャBeforeAfterSLI/SLO の実装CUJSLI/SLO の洗い出しSLO の追加と実装SLI は品質が良いものをSLI に利用するメトリクス可用性とレイテンシ SLOどっちが良いかTarget Windowエラーバジェットエラーバジェットの運用エラーバジェットの計算方法エラーバジェットバーンレートfast burn rateslow burn rateレイテンシは slow のみ、可用性は性質により変える深夜になるバーンレートアラートより精度のあるバーンレートが欲しい場合エラーバジェットが枯渇したときSLI/SLO の浸透可視化する内容勉強会の実施隔週でチーム全員で SLO をレビューするWINTICKET でやっているレビューのやり方実際にサービス品質は日々悪化していくなぜここまで SLI/SLO を浸透できたかさいごに: SLI/SLO の今後と理想ビジネスへの浸透の必要性と SLO を改善した人が称賛させる文化雑談 Embedded SRE? Enabling SRE?
SRE x 売上
SRE を知らない方に、SRE をやることで得られるメリットを最初に紹介します。
SRE の導入は、売上の向上に直接的かつ間接的に貢献します。具体的には、以下のような形で売上に好影響をもたらします。
顧客生涯価値（LTV）の向上
SRE は、サービスの安定性を高めることで、顧客の満足度を促進します。特にSaaSのようなサブスクリプション型サービスでは、LTV（顧客生涯価値）を大きく改善できます。
システムの信頼性による顧客満足度向上
安定したシステム運用は、顧客の信頼を獲得し、長期的な売上増加につながります。特に、以下の要素が売上に影響します：
- サービスのダウンタイム削減
- システムの応答性能向上
- エラー率の低減
- コスト削減による収益性の改善
SRE は単なるシステム運用の手法ではなく、直接的・間接的に企業の売上向上に貢献する戦略的アプローチです。
偶然この記事を目にしてしまったビジネスロールの方は、SRE を導入しようとしているエンジニアが居たら寄り添ってあげてください。
SRE と売上との相関
SRE をやる上でその効果を定量的な数値（売上）で相関を取りたいと思う方は多いかと思います。私もそう思いましたが中々に難しく挫折しちゃいました。
具体的には
「売上が多い = サーバー負荷が高い = SLO が悪化」という相関もあるためです。
海外では SRE が売上に貢献しているという論文があります。
この論文と同じことを行って解析するのはかなりハードルが高いと思います。
では何をモチベーションに SRE をやっていくかというと、
「目に見えて悪化していくサービス品質を前もって対処できる」です。
目に見えて悪化していくサービス品質が見えてくるとなんだかモチベーションが湧きますね。
WINTICKET で得られた SRE メリット
最初に WINTICKET の現段階で SRE をやってよかったことをご紹介します。
ビジネスとの連携のしやすさ
何か外部で障害が起きたときに WINTICKET に影響があるかどうか、即座に共有したい場合、SLI/SLO がとても有用です。
潜在的に悪化するサービス品質を可視化できる
エラーバジェットバーンレートのアラートが発生し、メトリクスを見てみるとサービス品質が徐々に悪化し、エラーバジェットが急速に消費されている状態になっていました。
WINTICKET に限らず、こういった潜在的なサービス品質の悪化を見ることができるのは SLI/SLO をやらなければ気付けないものであり、SRE をやるメリットの1つとも言えると思います。
WINTICKET サービス紹介
WINTICKET は公営競技である競輪・オートレースのインターネット投票サービスとして、2019年にリリースされました。サービスの特徴としては、レース映像を視聴しながらの投票体験や、AI予想・EXデータなど WINTICKET オリジナルの豊富なデータベースを備えている点が挙げられます。
また、ABEMAの競輪・オートレースチャンネルと連動した機能も提供しております。WINTICKETはリリースから約2年で競輪投票サービスとして No.1 となり、現在も成長を続けているサービスです。
自己紹介
なぜここで自己紹介をしたかというと私は WINTICKET に所属していません。
今回のアドベントカレンダーでは SRG として、別チームの WINTICKET に Embedded SRE をやっているのでそれをご紹介したいと思います。
Embedded SRE
Site Reliability Engineer が開発組織内で SRE（Site Reliability Engineering）の文化と知識を浸透させ、開発者自身が SRE プラクティスを実践できるようにするための活動(Enabling SRE)です。
私は SRG チームなので、Embedded SRE という形です。
Enabling SRE という言葉もありますが、ほぼ同義なのかなと思います。
（ちなみに海外だと Enabling SRE というワードで検索してもヒットしませんでした）
目的
- プロダクト開発チームにSREの文化と知識を広める（文化醸成）
- 開発者が自主的に SRE プラクティスを実践できるようにサポートする（文化醸成）
- サービスの信頼性を向上させる（SRE）
Enabling SRE の最終的な目標は、各プロダクトチーム内に自律的に SRE を実践できるメンバーを育成することです。
別部署に SRE をやっていくために
SRE として参加したら、いきなり SRE の話をするのではなくサービス側のチームから自身への信頼度を獲得するために色々なことを行いました。
加えてサービス側が SRE のメリットを享受する前に疲れてしまう可能性があるため、先に自身の信頼性を貯蓄しておくことで、これをいくらか軽減するのが目的です。
新しいチームに参加したらやることはモニタリング・アラートの整備、Toil の削減、そしてコミュニケーションです。
SRE とモニタリング
最初にモニタリング・アラートの整備をやる理由には SRE と関係性があります。
エラーバジェットが枯渇したときに適切なモニタリング環境がないと調査のしようがありません。
よく見るピラミッド図で、Monitoring が土台になっている理由がそれです。
個人的なモニタリング・アラートツール
WINTICKET では Google Managed Prometheus, Grafana を利用していますが、個人的には Datadog のほうがやりやすかったです。
WINTICKET に参加する前はドットマネーというサービスで Datadog を利用しており、グラフィカルな UI と豊富な SLI の定義方法（ログベース、レイテンシと可用性を同一に扱う SLI）は Cloud Monitoring にはない機能です。
実戦投入はしていませんが、OSS である SigNoz, 小規模、もしくは SaaS でよければ Grafana Cloud も扱いやすい印象でした。
記事で SRE 視点では使えないと記載していますが、最近のアップデートで PromQL にあるような Range Vector Selectors に対応したので SRE 用途でも利用できるかと思います。
アラートの整備
当初、アラート環境は整備されていましたが、いくつかの課題がありました。アラートツールが Cloud Monitoring と Self-hosted Alertmanager の2つに分かれており、同じアラートが両方に定義されていたり、不必要なアラートが含まれていたりしました。この状態ではアラートのメンテナンスが不十分で、障害検知の効果が落ちていました。
そこで下記の2点について取り組みました。
- アラートシステムの統一
- アラートツールを、すでに可視化ツールとして使用していた Grafana に統一
- チームとのアラート定義の見直し
- すべてのアラートをリストアップし、チームメンバーと共にアラートの必要性と重要度をすり合わせ
これらの取り組みにより、アラートの構造がシンプルかつ効果的になり、監視業務が改善されました。
アラートシステムの統一化
せっかく Grafana を利用しているのでアラートシステムも Grafana へ統一することにしました。
Cloud Monitoring のアラートシステムの柔軟性は Grafana に劣ります。
移行対象のアラートは400件近くあり、取捨選択をしながら移行をしました。
SLI/SLO で補えるアラートルールの削除、オンコール対象のアラートを減らしたり…
Grafana はラベルによるアラートルール（Notification Policy）が直感的で、オンコール対象にしたいアラートのみラベルをつけることで簡単に実現できます。
上記に加え、4つのメリットを得ることができました。
- WINTICKET では AWS も利用しているため Grafana による監視が容易に行えるようになった
- Alertmanager(GKE) を Port Forwarding でいちいち張らなくてよくなった
- クライアントチームのアラートも Grafana で管理できるようになった
- アラートの通知内容に柔軟性が生まれた
Grafana の勉強会を実施
この勉強会の目的は、チーム内へ Grafana に関する知識を提供すること、チーム内で Terraform から簡単にアラートを追加できるようになることです。
といいつつ、裏目的では SRE として自身のチーム内での知名度向上だったりもあります。
Toil の削減
Toil の削減は信頼度を獲得するために手っ取り早い方法です。
例えば、
- 全くメンテナンスされていない IaC
- 長時間かかるデプロイフロー
です。
Toil 削減はサービスのインフラ構成、デプロイフローなどを把握することができるので Toil が見つかればラッキー、見つからなくても構成を把握できたりするのでやって損なしです。
コスト削減
コスト削減も信頼度を獲得するためには手っ取り早いと思います。
Toil 削減より優れている点は、場合によってはより簡単で、コスト削減はビジネスチームにも嬉しい話なので、より効果的です。
コミュニケーション
毎日行われるサーバーチームの夕会や、定例などに参加したり飲み会に参加したり…などなど
小さいけどチリツモです。
WINTICKET のシステム構成
概要ですが、これが WINTICKET のシステム構成図です。
（実際はマルチリージョン化されていたり、かなり大規模です）
監視周りのアーキテクチャ
監視周りのアーキテクチャは Grafana に統一したため、Alertmanager が消え、よりシンプルになりました。
Before
After
SLI/SLO の実装
実際に SLI/SLO を実装するタイミングでは、チームの中から SLI/SLO に興味のあるエンジニアと一緒に進めていきます。
一人で進めても良いですがチームの事情をよく知る人が隣にいるといくらかスムーズに進めることができるので可能であればチームと一緒が良いかと思います。
スムーズに進むだけでなく、そのメンバーの SLI/SLO に対する知識が蓄えられていくので、チーム全体に浸透させていくフェーズでもより効果が発揮されます。
CUJ
WINTICKET ではすでにアプリで SLI/SLO の運用をしていたため、それをサーバー側にも反映させました。
CUJ を詳しく知りたい方はこちらの記事をご覧ください。
SLI/SLO の洗い出し
CUJ が決まったら、SLI を洗い出していきます。
以下のようなスプレッドシートで、現状のレイテンシやエラー率をまとめて、それぞれ整理していきます。
こういった場面のとき、チームの方がいるとスムーズです。
SLO の追加と実装
洗い出しが終わったら実際に SLO の実装をしていきます。
Cloud Monitoring の SLO 機能を使いつつ、SLO ダッシュボードは Grafana で運用します。
先に紹介しておくと、Cloud Monitoring のダッシュボードでは1サービスで 100件の SLO しか表示できない（実際には 100件以上登録できます）ため、Grafana で SLO を可視化しています。
サーバーのメトリクスも Grafana で可視化しているのでツールの行き来がなく楽です。
SLI は品質が良いものを
サービスを運営していると、クローラーや悪意のあるユーザーなどがアクセスするかと思います。
そのようなリクエストを前もって弾くことでより品質の高い SLO を計測することができます。
WINTICKET では、Cloud Armor を活用して不正なリクエストがマイクロサービスに到達しないようにさまざまな対策を行っています。
具体的には、レートリミットや Google Cloud Armor の事前構成 WAF ルールの利用によって悪意ある不正なリクエストを検出しこれも速やかに拒否します。これにより、適切ではないリクエストを弾くことで、システムの健全性を保ちながら、さらなる SLI/SLO の信頼性向上を図っています。
SLI に利用するメトリクス
WINTICKET で SLI として利用しているメトリクスは下記です。
- マイクロサービスが出力している Prometheus メトリクス
- Cloud Monitoring が収集している GCP メトリクス
可用性とレイテンシ SLO
WINTICKET の SLI/SLO ではレイテンシと可用性を独立した SLO として設定しています。
世間的にはこれが一般的だと”個人的”に思っていますが、レイテンシと可用性を合成して1つの SLO として計測することもできます。
実際、前述した WINTICKET の前に参加したドットマネーでは合成した SLO を利用しています。
Cloud Monitoring の SLO では、Datadog のように複数の指標を組み合わせることができません。
どっちが良いか
サービスの特性も加味するべきだと思いますが、基本的には別々のほうが楽だったりします。
一緒の場合：管理が簡単
別々の場合：調査する際、可用性とレイテンシが別々なので調査が簡単
別々の場合はそれだけで管理する SLO が増えるわけですが、粒度が低いので SLO をレビューする際にはかなり楽です。
Target Window
Target Window は定例の頻度や、開発サイクルによって決定します。
WINTICKET 自体のデプロイ周期は1週間に約1回ですが、Target Window は30日に設定し、チーム全体で行う SLO レビュー会を2週間に1回という頻度で行っています。
理想を言えばサービスのデプロイが毎週水曜日であれば、SLO に関する定例は毎週木曜日に設定し Target Window を1週間にすることで機能リリースによる SLO の変化やエラーバジェットについて話し合いをすることができます。
しかし、高頻度なレビューでは SLO の効果を実感してもらえる可能性が低いため、あえて長めのスパンにして潜在的なデグレーションを見つけ、SLO をやってよかったと思ってもらえるようにしています。
そして、次項で説明するエラーバジェットがなくなった際の動き方を考えると Target Window を1週間に設定するのは結構厳しいものがあるんじゃないかなとも思ってます。
エラーバジェット
エラーバジェットは、SLO から導き出される許容できる信頼性の損失量です。
サーバーは DB の高負荷などで一時的に SLO 違反をするものです。
その違反した SLO をどれだけ許容できるかというイメージです。
エラーバジェットの運用
エラーバジェットが消費されていないことが称賛されるかもしれませんが言い換えると
「デプロイ回数が少ないのか」「技術的挑戦を行ってないのか」と見方を変えることできます。
エラーバジェットは Target SLO に対して割り当てられた「技術的挑戦」への予算でもあります。
エラーバジェットが余っている状態は SLO を厳しくするなどして Target Window に対してちょうど 0% になるようにしましょう。
エラーバジェットの計算方法
エラーバジェットは、SLOの目標値から算出されます。
例えば、SLO が99.9%の場合、エラーバジェットは0.1%となります。
Target Window 30days（43,200分）の場合、エラーバジェットは 43.2分のダウンタイムに相当します。
具体的な計算例：SLOが99.9%の場合
- SLO: 0.999
- Target Window: 30日 (43,200分)
=(1−0.999)×43,200=0.001×43,200=43.2
エラーバジェットバーンレート
バーンレートとは、Google の造語で、SLO の目標長に対してエラーバジェットがどの程度速く消費されるかを示す単位なしの値です。たとえば、30 日間を目標とする場合、バーンレートが 1 であれば、1 の割合が一定であれば、エラー予算がちょうど 30 日で完全に消費されることを意味します。消費率 2 とは、一定であれば 15 日、消費率 3とは 10 日でエラーバジェットが枯渇することを意味します。
バーンレートについては Datadog のドキュメントが分かりやすいです。
WINTICKET では1つの SLO に対して5分と1時間の time window でバーンレートに対してアラートを設定しています。
それぞれ fast burn rate, slow burn rate と以後呼びます。
fast burn rate
目的として、リリース後に発火した場合、その変更されたコードによってサービスの品質が低下していることを検知するために利用しています。
まだ WINTICKET 内のフローには定義されていませんが、カナリアリリース後の切り戻し判断基準としても使えるようにしたいと思っています。
slow burn rate
fast burn rate のような急激な障害ではなく、システムの慢性的なサービス品質の悪化を示す重要な警告信号となります。
即時の対応が不必要ですが、継続的に意識すべき指標です。
レイテンシは slow のみ、可用性は性質により変える
可用性の SLO に対するバーンレートアラートでは前述した fast, slow でアラートを設定していますが、レイテンシに関しては slow のみを設定しています。
レイテンシに fast burn rate を適用しない理由の1つに、アラートノイズになりやすい問題があります。
計測するエンドポイントが外部 API に依存している場合、その外部 API のレイテンシに引っ張られてしまうためレイテンシには fast burn rate を適用していません。
slow でも十分な結果が得られます。
逆に可用性では、fast, slow それぞれの特徴を享受するために設定しています。
深夜になるバーンレートアラート
短い time window で、シンプルなバーンレートアラートは深夜などのリクエストが少ないタイミングでよく発生します。
例えば、システムが 1時間に 10リクエストを受け取る場合、1つの失敗したリクエストは1時間当たり 10%のエラー率になります。99.9％の SLO の場合、このリクエストは 1,000倍のバーンレートになり、30日間のエラー予算の 13.9％を消費するため、即座にアラートが発火します。
WINTICKET ではバーンレートの閾値を 3 ないしは、20 にすることでこれをいくらか軽減しています。
これでリクエストが少ない時間帯でも、エラーとなるリクエストの影響度を緩和させる方法です。
ちょっと非実現的な気もしますが、面白いと思います。
他にも色んなアプローチが紹介されているのでご覧ください。
より精度のあるバーンレートが欲しい場合
複数の windows と、複数のバーンレートを組み合わせることで誤検知を無くすことができます。
この例では、5分と1時間の両方で 14.4 のバーンレート（14.4: 消費されるエラーバジェットは 2%）になったとき発火するアラートです。
Alerting on SLOs からの引用
こうすることで即時性というメリットは無くなりますが、すぐに回復するノイジーなものを省いたサービス品質悪化を示す本質的なアラートを構成できます。
エラーバジェットが枯渇したとき
前回 Embedded SRE として参加していたドットマネーでは事業責任者と話し合い、「本番障害への対応、信頼性回復のための改修、外部会社が関係する機能のリリースを除く場合、エラーバジェットが枯渇した際には機能のリリースを禁止する」と合意することができました。
WINTICKET ではエラーバジェットがなくなると、その原因が外部起因のものかどうかを判断し、そうでなければエラーバジェットを復活させるためにタスクを切り、メンバーをアサインするというサーバーチーム内の独自文化を形成しています。
SLI/SLO の浸透
さて、実際に SLI/SLO をコード化、可視化するところまできました。
各コンポーネントごとに Grafana ダッシュボードを作成しています。
可視化する内容
可視化する目的はなんでしょうか？
SLO をレビューするときに必要になる項目は下記の通りです。
- エラーバジェット
- 現状の SLO
しかし、これだけでは不十分です。
エラーバジェットが枯渇したり、深堀りするには詳細な情報が必要です。
- エラーバジェットの Time Series グラフ
- SLI の Time Series グラフ
- 該当 SLI の Time Series レイテンシグラフ（レイテンシ）
- 該当 SLI の Time Series レスポンスコード（可用性）
これを同じダッシュボード内に展開することで、レビューする際に以下のメリットを享受することができます。
- いつから悪化、改善したのか判断できる
- リリースと被るのであればそれが原因
- 外部サービスの障害
- 継続的に悪化しているか判断できる
- 悪化した SLO は対策をして改善傾向にあるか判断できる
- 他に問題はなく、設定した SLI/SLO が厳しいため調整の判断ができる
勉強会の実施
チーム全体で勉強会を実施します。
目的は SLI/SLO を少しでも理解してもらうためにですが、1回限りの勉強会をやって理解できるはずがないです。
私も理解できなかったので、「こういうことをやります！」「こういうメリットがあります！」みたいなのを共有し、いわば決起会的なノリでやりました。
隔週でチーム全員で SLO をレビューする
チーム全員で、SLO をレビューする目的は下記の通りです。
- チーム全員で取り組むことで SLI/SLO の文化を形成する
- （実際にサービス品質が悪化したら）SLI/SLO のメリットを感じてもらい、モチベーションの継続をしてもらう
WINTICKET でやっているレビューのやり方
WINTICKET ではこの記事を執筆時 103個の SLO があります。
これを全てレビューするにはかなり疲弊してしまいます。
そこでレビューは「エラーバジェットが枯渇した SLO のみ + 前回レビュー時枯渇したエラーバジェットの SLO はどうなったか」を見ています。
こうすることで最初はシンプルな形で、疲弊しない運用できます。
最終的にはエラーバジェット枯渇時の動き方をビジネスロールと同意をし、エラーバジェットが枯渇したタイミングでサーバーチームの誰かがエラーバジェットを復活させるような動きが行われている状態を目指しています。
エラーバジェットが全く消費されない SLO はどうすると良いでしょうか？
WINTICKET では3ヶ月もしくは6ヶ月に1回、エラーバジェットが 100% 前後で推移しているものを洗い出し、SLI や SLO を厳しくしてエラーバジェットが有り余る状態を阻止しています。
WINTICKET のタスク管理は Wrike を利用しているので、SLO の振り返りでも Wrike を利用しています。
できるだけツールを増やさず、メンバーが疲れない運用を意識しています。
実際のレビューの流れは下記の通りです。
- ファシリテーターをランダムに決める
- 各カテゴリごとにチームを作成する
- チームはアサインされたカテゴリのSLO を Grafana から確認する
- エラーバジェットが枯渇したものを Wrike に起こす
- 対応可否の判断
- 外部API の障害の場合は、対応不要としています。
- Wrike にすでに起票されている SLO（エラーバジェットは枯渇状態）がどうなった確認
- コメントをして、エラーバジェット欄を更新
実際にサービス品質は日々悪化していく
先に紹介したようにサービスの品質は日々悪化しています。
例えば、増えていく DB レコード数によりレイテンシの悪化があります。
または新規施策でテーブルを追加したけど、インデックスの不備など。
最初は問題がなくてもレコード数が増加すればその影響は露骨に出てきます。
なぜここまで SLI/SLO を浸透できたか
現状の WINTICKET の浸透具合を俯瞰して見ると、SLI/SLO を推し進めたメンバー以外が、バーンレートのアラート、SLO ダッシュボードから悪化した原因を探し始めたり、サーバーチームが自主的にSLI/SLOの運用を行ったりしているように思います。
現に、最初のレビュー会のファシリテーターは私がやっていましたが、現在ではサーバーチームの誰かがやっている状態です。
加えて WINTICKET の開発責任者 @akihisasen が、SLI/SLO に最初から興味を持っており、そのメリットを知っていたこと、推し進める際に動きやすい形を作ってくれたのも大きかったかと思います。
さいごに: SLI/SLO の今後と理想
現在、SLI/SLOはサーバーチーム内での共通言語にとどまっており、本来の目的である「ビジネスとの共通言語」の実現には至っていません。
SRE チームの今後やることは、ビジネスロールへ浸透させることです。そのためには、以下のアプローチを行う予定です。
- 網羅性の改善
- あらたな SLO の追加
- SLO の信頼度を向上（SLI の調整など）
- ビジネスチームの誰かをサーバーチームの SLO レビュー会に参加してもらう
またビジネスの人が見ても分かりやすいように、現状の SLO が見れるビジネス用ダッシュボードも作成しています。
これらを活用し、徐々に浸透を図っていきます。
ビジネスへの浸透の必要性と SLO を改善した人が称賛させる文化
サービス品質を改善した人はエンジニアからだけではなく、プロダクトに関する全員から称賛、評価されるべきだと思っています。
しかし現在の WINTICKET ではビジネスサイドと合意をしていません。
まずはサーバーチーム全体で SLO の運用、浸透を行いつつ、SLO の信頼度や網羅性を向上させている最中です。
雑談 Embedded SRE? Enabling SRE?
最近よく Enabling SRE というワードを耳にするようになり、調べてみましたが海外だと全く見ませんでした。
「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」という書籍に Enabling という記述があるようです。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
