これからはじめる 実践 SRE / SLO の監視をやってみよう
SRE がアツいですね。
昨年は以前に増して SRE 関連のイベントも増え、SRE 人材への注目も更に高まっていると感じた 1 年でした。私も Google Cloud の Customer Engineer として、お客様へ SRE のお話をする機会が増えてきています。
ご存知の通り、SRE は Google から生まれた運用プラクティス、またはそのロール自体を指す言葉です。
詳細は無料で読むことができる書籍を御覧ください。
“Site Reliability Engineering” 及び “The Site Reliability Workbook” （右上の右2つ）は HTML 形式 なので、Google Chrome で右クリックして 翻訳を選択するという簡単な手順で日本語でも読むことができます。（書籍がよい方は日本語版も購入できます。）
今回のテーマは SLO (Service Level Objectives) の監視を取り上げます。SLO は日本語にするとサービスレベル目標といいますが、サービスの信頼性を表す指標の目標値となるものです。
上記の “The Site Reliability Workbook” でも “SLOs are key to making data-driven decisions about reliability, they’re at the core of SRE practices.” と、SLO は SRE のコアとなる要素であると書かれています。
さらに “One could even claim that without SLOs, there is no need for SREs.” つまり SLO がなければ、SRE の必要性はない、とさえ言っており、SLO の重要性を訴えています。
ということで、今日お伝えしたいことはこちらです。
TL; DR
- SLO は SRE のコアとなる要素のひとつ。
- まず 、適切な SLO を見つけて、継続的に育てましょう。
- Google Cloud ではかんたんに SLO 監視をはじめることができます。
今日はこんな簡単な Web システムを題材に考えてみます。ここでは、ある商品を買物できるサイトだと考えましょう。
左端のクライアントから、GKE（Google Kubernetes Engine）にホストされている アプリケーションにアクセスする、というシンプルな構成です。
クライアントと GKE の間には、Google Cloud Load Balancer（GKE の Ingress）が配置されていて、クライアントからのトラフィックが最初に到達する部分になっています。
SLO を決める
それでは、まず SLO をどうやって決めていけばいいでしょうか。
詳細はこちらにありますが、シンプルに書くと次の順番になります。
- CUJ（Critical User Journey / クリティカルユーザージャーニー）を選択する。
- CUJ に対応する SLI（サービスレベル指標）を決める。
- SLI に対応する SLO（サービスレベル目標）を決める。
重要な点として、SRE はユーザーにフォーカスします。
これがシステムの状態を確認する従来の監視と違う部分です。そのため SLI/SLOを定義する前にまず、CUJ を検討します。
CUJ とは、その名が示すとおり、ユーザーにとって重要な体験、期待です。具体的には、商品の一覧を確認できる、商品を検索できる、ほしい商品を購入できる、など複数あると思います。
この体験が満足にできないと、ユーザーが使ってくれなくなる可能性があります。CUJ の定義はビジネスにとって重要ですので、エンジニアだけではなく、ビジネスサイドも参加してもらい慎重に定義し、優先度を含めて検討しましょう。
ここでは CUJ を 「商品の一覧を確認できる」と定めてみます。
続いて、SLI を決めます。
CUJ を仮に 「商品の一覧を確認できる」 と決めましたが、SLI はそれを測るための指標になります。サイトが正常に利用できる可用性、期待通りの時間内に商品一覧が表示できることを測るレイテンシ、商品の一覧が最新になっているかなどの正確性/新鮮さ、などひとつの CUJ についても複数考えられるかなと思います。
その中でも、今回はわかりやすさを考えて SLI に「可用性」 を選択してみましょう。通常は CUJ につき複数選ぶことになるでしょうが、シンプルにひとつだけにします。
これを数値的に計測するための方法（SLI の実装）を検討しますが、今回はシンプルに Google Cloud Load Balancer がクライアントに返却する レスポンスコードを使います。単純にレスポンスコードが 200番台なら “Good” つまり信頼性が保たれている状態だと判断します。
そして最後に、SLO です。
先ほど決めた SLI がどの期間で、どういう値であれば、ユーザーの期待に沿っていると見做すのか、を定義します。
いったんは決めとして 7日間 で 90%以上 成功であれば、ユーザーは満足すると仮定し定義してみました。もちろんこれらは継続的に見直していくべき値で、運用しながら最適な値を探っていきます。
SLO 監視を実装する
SLI、SLO が決まったので、ようやく SLO 監視の実装です。
Google Cloud には Cloud Operations という運用関連のマネージドサービスがあり、SLO の監視機能が用意されています。
Cloud Operations の 一部である、Cloud Monitoring には多くの指標が集約されており、その情報を使って SLO の監視を実現します。
まず、Cloud Monitoring の画面に移動し、”サービス” を選択し、”サービスの概要”に移動します。次に上部の”+ サービスを定義”ボタンをクリックしてください。
Anthos Service Mesh（ASM）、GKE 上の Istio、App Engine を使っている場合は、サービスの指標が自動で検出されます。
ですが、今回は、GKE 上に ASM や Istio などを使わずにアプリケーションを展開しているため、カスタム サービスの定義が必要です。
今回は、”item-list” という名前で、GKE 上に Kubernetes Service を展開していますので、これを選択後 “送信”ボタンを押すと下記の 画面が表示されます。
ここで左下の “SLO を作成” を押します。（すぐに押すと エラーになる場合があるので 1分ほど待ってから押してください。）
SLO の設定のため、まず SLI を設定します。
前述の通り、指標は自動検出されないので “その他”が選択されています。”リクエスト ベース” または “Windows ベースの選択” は指標の集計に関わる部分ですが、わかりやすい “リクエスト ベース” とします。違いについては こちらを御覧ください。
続いて、SLO の詳細の定義に進みます。
GKE の Ingress で構成された Google Cloud Load Balancer の レスポンスコードの割合を SLI に使うと決めたので、
loadbalancing.googleapis.com/https/request_count
を指標（Metrics）とします。似た名前の指標がたくさんあるので注意してください。
そして SLI の 指標で “Good” サービスを定義します。
“Filter” で “Good” の隣の、”フィルタを追加” を押し、”Select a metrics label” から “response_code_class” を選択、”= 200”を選びます。
これで、200 や 201 など 2xx のレスポンスコードを “Good” とみなすことができます。
もうひとつの “Filter” は “Bad” になっていますが、”Total” にしましょう。そうするとこんな感じの画面になるかと思います。
もし Load Balancer が複数ある場合は、フィルタを追加して指標を絞り込んでください。
そして SLO の設定です。
今回は、SLO を評価するコンプライアンス期間を “連続” の “7日”と定めます。目標値は 90% としましょう。
最後に確認です。
最終的に SLO は JSON で定義されますが、これまで画面で操作した結果から JSON が生成され、確認することができます。確認後、”SLO の作成” を押します。
上記は完成した SLO のステータス画面です。SLO を決めると、エラーを許容する量を示す エラーバジェット も自動的に決定されます。まだ”Good” なレスポンスだけでエラーがないため 100% になっていますね。（画像中央）
これで、SLO の作成はいったん完了、実装できました。
SLO アラートを作成する
SLO が危険にさらされたときに、アラートを上げて、オンコールやチケット対応を実施できるようにします。
先程の SLO ステータス画面の右上にある “SLO アラートの作成” を押すと、下記の画面が開きます。
“ルックバック期間” は 指標を遡って評価する期間です。
“バーンレート” は SLO に対して、エラーバジェットを消費する速度です。バーンレートをうまく設定することで、エラーバジェットを大幅に消費したり、枯渇させたりする前に、アラートを上げて対応することができます。詳しくは、こちらの”4: Alert on Burn Rate”をご確認ください。
今回はテストのため、下記のように設定しました。
- ルックバック期間 10分
- バーンレートのしきい値 5
実際の運用ではこの設定は過敏な設定になる可能性があり、対応が不要なタイミングでアラートが発生するかもしれませんので、ご注意ください。特にバーンレートのしきい値や組み合わせは最適な設定を見つけるために試行錯誤が必要かと思います。
あとは、アラートの通知先を Slack やメールなどに設定するだけで完了です。
テストしてみる
では、テストしてみましょう。
いまは 100% “Good” つまりすべて 200 のレスポンスで返ってきています。
まず、すべてを 503 エラーとしてみます。つまり、100% “Bad” です。
（アプリにちょっとした仕掛けをしていて、エラー率を変えています。あくまでテスト用のシナリオを試すためなので、本番用では行わないでください。）
すべて 503 になってます。
アラートの ポリシー詳細を確認するとエラーレートが上がっていますね。
赤い線で示されているバーンレートのしきい値を超えると、アラートが発出され、Slack通知がきました。
このときはインシデント（Incident）が発生した状態となっており、SLO のステータスも赤く変化します。
エラーを修正してこのアラートを回復させると、また緑色に戻って、回復通知も受け取ることができます。
今度は半分だけ、つまり約50%だけ を エラーにしてみたいと思います。
半分 “Good” で、半分は “Bad” なレスポンスです。ログを見ると、半分程度 503 になっていました。
こちらもアラートが発出されますが、エラー 100% の場合と比べて、少し時間がかかります。アラートのポリシーの詳細画面で比較してみましょう。
グラフの前の山がエラー100%、後ろの山がエラー 50% の場合です。わかりにくいですが、それぞれバーンレートのしきい値（赤い線）を超えるのにかかった時間は約 5分と、約10分です。エラー 50% の場合がゆるやかな山になっており、インシデントの発生までちょうど倍くらいの時間がかかっています。
つまりエラーバジェットの消費が、エラー 50% の場合だと 100% の場合とくらべて、遅くなっているということがわかります。
これが Canary リリースなどの効果になります。新機能のデプロイなどエラーが発生する可能性があるリリースを、いきなり全部ではなく、徐々に行うことで、エラーバジェットを大きく消費せずに新しい機能を試すことができます。もちろん Canary を試す際に、少量のエラーの上昇に気付けるようにしておく必要があるかと思います。
まとめ
Cloud Operations をつかうと SLO の監視を簡単に実現できます。
実際の SLI の定義は、Cloud Operations は自動で収集される指標に加えて、カスタムの指標も作成できるので様々な要件に対応できます。
現在 プレビューで利用可能な Google Managed Prometheus や GKE ワークロード指標 と併用すればさらにSLO 運用の幅も広がります。
今回は基礎編でしたが、また機会があれば続編を書いてみたいと思います。SRE の本格導入を検討されている方は、Google Cloud に相談してみてください。
