今年2022年1月に こちらのブログを書いたところ、多くの方に読んでいただきました
本記事はその続編となります
こちらは Google Cloud Japan Advent Calendar 2022（今から始めるGoogle Cloud） の21日目の記事です
SRE と SLO について
SRE と SLO、及び SLO の重要性については、前回のブログでかんたんに説明しています
事前に一読頂けると理解の助けになるかと思います
SLI を作成するメトリクスソースの選択肢
SLO モニタリングに使うメトリクス（日本語では指標）は、Cloud Monitoring に集約されたメトリクスからつくることができます
つまり メトリクスを Cloud Monitoring から見える形にすれば、それをSLI として設定し、SLO モニタリングに活用できると理解していいでしょう
（なお以前のブログでは、SLO のマネージド監視機能を単に「SLO の監視機能」と呼んでいましたが、今回はドキュメントに合わせて「SLO モニタリング」と呼びます）
Cloud Monitoring には、各種 Google Cloud のリソースから自動的にメトリクスが集約されますが、自分でカスタマイズしたメトリクスを追加することも可能です
カスタムメトリクスを収集する代表的な方法としては、以下があげられます
（ほかにも OpenCensus を使う方法などがあります）
Google Cloud Managed Service for Prometheus（GMP）
今回は 3つ目の Google Cloud Managed Service for Prometheus（GMP）をとりあげます
Prometheus とは、Google 社内の監視システムとして使われている Borgmon を参考に、Sound Cloud のエンジニアが開発したオープンソースの監視運用ソフトウェアです
その柔軟性から、Kubernetes などの監視に多く使われています
ただ Prometheus を使って大規模にスケールするシステムを監視対象とするには、Prometheus 自体のスケールや運用が課題でした
そこで Prometheus のマネージドサービスである GMP の登場です
Google Cloud Managed Service for Prometheus（以下、GMP）は Monarch という新しいアーキテクチャをベースに、よりシンプルに、よりスケールできる Prometheus のマネージドサービス として、今年 3月に GA しています
GMP と Cloud Monitoring の統合
GA したばかりの GMP ですが、Cloud Monitoring との統合が急速に進んでいます
現在は Cloud Monitoring のメトリクスも、GMP で収集したメトリクスも、意識せずにどちらのコンソールからもシームレスにクエリ、参照することができます（指標のマッピング）
GMP のアーキテクチャ
さらに最近のアップデートでは PromQL という Prometheus 標準のクエリー言語で、両方のメトリクスをクエリーできるようになりました
これは個人的にも嬉しいアップデートで PromQL に慣れている方は、従来使われていた独自のクエリ言語（MQL）を覚える必要がないため、学習コストを大きく減らすことができます
以下は PromQL を使って GKE クラスタより、"any-method-api" という名前のコンテナの CPU 利用時間の1分間の変化率を取得したものです
PromQL ではこのように簡潔に、複雑な条件のクエリを実現します
rate(kubernetes_io:container_cpu_core_usage_time{container_name="any-method-api"}[1m])
この PromQL は、いわゆる SRE 本でも SLI の計算や SLO の評価などにたくさん登場しているので、馴染みがある方もいるでしょう
え、書くの難しそう・・・と思った方、安心してください、今回 PromQL は直接の出番はナシです :)
なお Prometheus のエコシステムでは、監視のアラート管理のために Alertmanager というコンポーネントを利用しますが、GMP の場合は Cloud Monitoring のメトリクスと同様に SLO モニタリングからアラートを扱うことができますので、Alertmanager を準備、運用する必要がありません
これも大きなメリットのひとつです
デモアプリケーションの準備
さっそく、GMP で収集したメトリクスで SLO モニタリングをやってみます
今回は実際にお試しいただける手順を用意しているので、ハンズオンが可能です
このようなかんたんなアーキテクチャを想像してください（前回と同じ図なのですが、実際は Cloud SQL はありません）
用意した簡易なソースはこちらに置いていますので、試す場合はお手元に clone しておきましょう
何もしないデモ用の API アプリケーション（名前は any-method-api）ですが、運用状況のシミュレートのため、任意の割合でアプリケーションに遅延やエラーを入れることができるようにしています
なお今回はアプリケーションに Go のフレームワーク Gin を使っていますので、Gin 用の Prometheus exporter を追加しています
これと同様に多くのミドルウェアやフレームワークには、Prometheus exporter が準備されていて、追加して設定をするだけで用意された様々なメトリクスを Prometheus に公開することができます
また多くの exporter ではアプリケーション内で取得した値を使用して、カスタムメトリクスを作成することも可能です
ハンズオンの開始
ここから、具体的に手を動かしてみます
- 必要サービスと GKE の準備
GKE は、GMP を有効にして作成します（なお、既存のクラスタでも有効化できます）
各種サービスの有効化
gcloud services enable container.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com
gmp-test という GKE クラスタをデプロイしています
gcloud container clusters create gmp-test --zone=asia-northeast1-a --enable-managed-prometheus
コマンドがエラーなく完了すると、GKE 操作のための情報（credential、context など）が自動でセットされます
すぐに kubectl で、gmp-test を操作することが可能です
- コンテナのイメージを配置する Artifact Registry を用意します
gcloud artifacts repositories create my-app --location=asia-northeast1 --repository-format=docker --quiet
- アプリケーションのデプロイ
作業をかんたんにするため Makefile をつかっていますが、内容は Cloud Build によるコンテナのビルド、kubectl による Deployment と Service のデプロイです
※ これ以降のコマンドは、clone したディレクトリの中で実施してください
make build-app
make deploy-app
Service に IPアドレスが割り当てられるまで、1分ほど待ちましょう
以下のコマンドで割り当て状況が確認ができます
kubectl get services
- GMP の収集対象とするため、PodMonitoring リソースをデプロイします
この PodMonitoring リソースの中で、どの Pod のメトリクスを対象にするか指定しています
kubectl apply -f podmonitoring.yaml
- 連続的にアプリケーションにアクセスする負荷クライアントをデプロイします
IP=$(kubectl get service any-method-api -o json | jq .status.loadBalancer.ingress[0].ip -r)
export IP=$IP
make build-loading-client
make deploy-loading-client
- Cloud Logging などのログを見て、ちゃんとアプリケーションが動作して、負荷クライアントからアクセスがきていることを確認しましょう
コマンドで確認する場合は kubectl logs を使うほかに、stern なども便利です
stern --tail 10 any-method-api
以降、少しメトリクスが蓄積されたほうがわかりやすいので、5分ほど待ちましょう
GMP と Cloud Monitoring の連携を確認
上記のように、Metrics explorer の PromQL タブを押し、以下を入力、クエリーを実行します
up
エラーが出ずに一直線のグラフが表示されていたら、いったんは収集されていると見てよいでしょう
（ほかに GMP を有効にした GKE クラスタがある場合はそのメトリクスが出ている可能性もあるので、ご注意ください）
SLO モニタリングを設定
アプリケーションが準備できたので、SLO モニタリング の設定です
ここからの設定は前回とほぼ同じなので簡略化しますが、ウィンドウベースのメトリクスなど少しだけ異なる設定を入れてみます
- Cloud Monitoring の左のメニューから、「サービス」を選択、「サービスを定義」を押します
「サービス any-method-api」 を選択して送信、そして次の画面では、SLO の作成を押します
- 今回は、ウィンドウベース（Windows-based）を選択します
ウィンドウや時間幅を表す概念が複数でてきますので、混乱しないようにご注意ください
ここでいうウィンドウは、定義した時間範囲のことで、この中でよいイベントであるべき割合などを指定します（詳細はこちら）
- SLI の定義では、GMP が収集したメトリクスを選ぶことができます
今回は、common_handler_latency_hist というカスタムメトリクスを作成しているので、こちらを選んでみたいと思います（リクエストのハンドラーを処理する時間を簡易に計測したヒストグラムです）
フォームに一部の文字列を入れると、候補としてでてきますので、ちゃんとメトリクスが取れていることがわかりますね
-
ここではよいイベントとする定義を決めていきます
画面のように、1分間のウィンドウで 500ms 以下の値が 90% の場合、よいイベントとしています -
SLO の設定
SLO 期間はテストのため、ローリングウィンドウで1日としています
パフォーマンスの目標は、指定した期間で 80% よいイベントであれば、達成とします
そのまま作成すると、以下のようにエラーバジェット 100% のステータスとなります
- SLO アラートの設定
こちらも前回同様、アラートが出やすくするため、テスト用の設定を入れています
通知先は、メールや Slack など選択できますので任意のものを選んでください
設定は以上です
遅延を入れてみる
それでは、なんらかの理由でパフォーマンスが落ちたイメージをシミュレーションしたいので、わざと遅延を入れてみます
遅延の割合は おおよそ 50%（2分の1） にしています
export RAND_DIV=2 MODE=sleep
make deploy-app
Pod を再起動します
kubectl rollout restart deployment any-method-api
エラーバジェットが消費され、しばらく待つと バーンレートの設定によりインシデントが発生します
サービスの画面で確認する インシデント発生の様子
アラートの画面
アラート通知先として設定していた Slack にも無事通知が飛んできました
回復させる
不具合が解消した場合のシミュレーションをする場合は、環境変数をリセットして、Pod を再起動してください
export RAND_DIV= MODE=
make deploy-app
kubectl rollout restart deployment any-method-api
しばらく待つと、サービス、またはアラートの画面で、回復した様子が確認できます
ハンズオンによる動作確認は以上です
（作成した GKE クラスタが不要な場合は、余分な費用が発生しないよう削除しましょう）
GMP のメトリクスを使って、SLO モニタリングが実現できました
メトリクスの収集の部分を除いては、ほぼ前回と変わらない操作体験になります
おわりに
入門向けのカレンダーにもかかわらず前提知識を必要とする内容のため、少し込み入った内容になったかもしれません
ちょっと難しかったな、という方には 2022年11月22日に実施した Innovator Hive Japan やってみよう 実践 SRE ~ Google Cloud Managed Service for Prometheus と Cloud Monitoring で SLO 監視 ~ をご覧ください
私の同僚の Yoshi さんと Momoi さんが GMP によるアプリケーションの SLO 監視に楽しくトライしています
紹介してきたように GMP と Cloud Monitoring の統合が進み、 SLO の監視の際に適切なSLI が選択しやすくなってきています
特に、すでに GKE とPrometheus を利用しているワークロードはシンプルにGMP を利用開始できます
Prometheus の運用負荷を下げ、マネージドな SLO モニタリングの恩恵を受けることができるので、ぜひ使ってみてください
Discussion