🔔

Cloud Monitoring で Cloud Run のインスタンス数がしきい値を超えたときにSlackへアラートを通知する

waddy_u2022/09/29に公開

アプリケーションを動作させる環境として、Cloud Run は有力な選択肢のひとつです。コンテナベースで高速にスケールしてくれる点がとくにうれしいですね。このモチベーションで採用することも多いのではないでしょうか。私もそのひとりです。

https://cloud.google.com/run/docs/resource-model?hl=ja#container-instances

最大インスタンス数を多めに設定しておくと安心

高速スケールに魅力を感じるということは、バーストが起きうるワークロードを運用していると察します。バースト時でも可能な限りレスポンスを返したいとき、Cloud Run の最大インスタンス数を100,200,もしくはそれ以上、多めに設定しておくこともありそうです。多めに設定しておくと、不意のバーストに対してリクエストがドロップ(=Cloud Run が429 Too many requestを吐く)される確率を下げられます。もちろん、Cloud Run 上のアプリが呼ぶDBやAPIもバーストに対する解答を持ち合わせておかねばなりませんが、ここでは Cloud Run のみに注目します。

とはいえ、大量に立ち上がったままは不安

瞬間的なバーストに対してインスタンス数を確保し、スケールしてもらうことはありがたいですが、これが1時間、2時間つづくと不安になってきます。そこで、インスタンス数が増えたときにアラートを通知するよう設定します。通知を受け取った後は、さまざまなアクションが想定できますが、まずは通知を考えます。

Cloud Monitoring のアラート機能を使う

Cloud Monitoring のアラートは、Google Cloud から得られるさまざまなメトリクスをもとに通知を送る機能です。アラートを設定するには、以下の要素について項目を埋めます。

  • 元にするメトリクス
  • トリガー(しきい値など)
  • 通知する先のチャネルと通知内容

これらのひとまとまりを アラートポリシー といいます。

「Cloud Run のインスタンス数が50を超えたらSlackへ通知する」ポリシーを作成してみます。

メトリクスの設定

Cloud Monitoring の画面でアラート設定から CREATE POLICY をえらびます。

その後、 Cloud Run Revision > Container > Instance Count とします。

詳細な条件を設定できます。Cloud Run の場合、

  • サービス名
  • Condition: Active

を指定するのがいいと思います。データの設定は、

  • ローリングウィンドウ: 5分
  • ローリングウィンドウ関数: max

としました。5分ごとにインスタンス数が短い期間でもしきい値を超えていたら通知されます。

トリガーの設定

左ペインから「トリガー」を選びます。しきい値を50に設定しました。

Slack通知チャネルを作成する

左ペインから「通知と名前」を選びます。チャネルを選ぶときに「通知チャンネルを管理」が選べるため、そこから飛んでSlack通知を作成してください。作成したチャネルを作成し、通知内容とポリシー名を作成して完了させます。

通知が飛んでくることを確認

最初だけしきい値を低めに設定しておいて、たしかに通知が飛んでくることを確認するとよいと思います。設定したポリシーにあてはまると下図のような通知が飛んできます。

通知を受け取ったそのあと

通知を受け取った後のアクションはいくつか考えられます。

攻撃性のチェック

一番気になるのは、DDoSなどの攻撃を受けていないかどうかです。たとえばですが、リクエストログから攻撃性を判定し、怪しいリクエスト元を Cloud Armor でブロックするという手もあります。詳しくは以下の記事を参照ください。

https://zenn.dev/team_zenn/articles/cloud-armor-add-rule

コンテンツが盛り上がる要因を観測

インスンタンス数が増えているということはアクセス数が増えている可能性があり、そのポジティブな理由のひとつにサイト内のコンテンツが盛り上がっているというのもあります。どんなときに Cloud Run のインスタンス数が増えるか知見が蓄積され、サービスにおける「バーストが起きた事例」として施策やマーケティングにフィードバックできるかもしれません。

アーキテクチャを再考する材料

これもすこし違う切り口ですが、たとえば、しきい値を超えたときに周辺のメトリクスがどうなるかを調べるきっかけになります。たとえば、

  • レイテンシに影響が出始めている
  • DBサーバーなどのCPU利用率が高い
  • リクエスト数はそんなに多くないのに、CPU利用率が高い

こういった予兆を発見できるかもしれません。DBサーバーのスペックアップや、アプリ内で負荷の高い処理がないかを探すといった次の策につながります。

おわりに

あまり通知が多すぎても精神衛生によくないので、しきい値は調整したいところですが、インスタンス数の増加はアプリケーション全体のヘルスチェックとして活用できます。Cloud Run がいい感じでやってくれる部分だからこそ、人間の目は「他に影響は出ていないか」「攻撃性はないか」といったプラスアルファに使いたいですね。

参考

https://cloud.google.com/run/docs/monitoring?hl=ja

https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja

Zenn Tech Blog

Zenn開発チームのテックブログです。Zennの開発・運用にまつわる技術的な知見を投稿します。主な技術スタックは React / Next.js / TypeScript / Ruby on Rails / Google Cloud などです。

Discussion

ログインするとコメントできます