はじめに

人生初のマットレスに挑戦しようか悩む今日この頃……

初めましての方は初めまして、DX開発事業部の小山です。

今回はGoogle CloudのCloud Monitoringにおける新しい死活監視サービス「合成モニタリング」の仕様とそれに伴う注意点について書きたいと思います。

そもそも合成モニタリングとはどういうサービスなのか

一言で説明するならば「よりユーザーに近い処理ができる能動的(プロアクティブ)な死活監視」が合成モニタリングというサービスです。

従来の死活監視(Google Cloudですと稼働時間チェックがそれに該当します)だと、特定のエンドポイントにアクセスしてレスポンスに200が返ってくるかどうか = システムが健全かどうかを確認するだけのシンプルな動作しかできません。

しかし合成モニタリングは違います。

裏側ではCloud Run functionsが動いており、Node.jsで書かれたスクリプトを実行できます。これにより、「APIを叩いてレスポンスのJSONフォーマットが正しいか検証する」「Puppeteerで実際にブラウザを立ち上げ、ログインからカート決済までのシナリオが正常に完了するかテストする」といった、実際にアプリケーションを利用するユーザーと似たフローを通じてアプリケーションの健全性を監視することが可能となります。

いち早くアプリケーションの障害を検知できるありがたいサービスなのですが……他サービスと同じように閾値設定をしているとアラートが頻発することがあります。

合成モニタリングは一回(のチェック)に六回(Cloud Run functionsが)実行される？

「1分に1回実行するように設定したはずなのに、Cloud Run functionsの実行履歴を見ると1分間に6回も動いている……？」という事象は合成モニタリングを触ったことがある人なら一度は体感していることでしょう。

勿論バグなどではなく、仕様通りの挙動です。

公式ドキュメント(https://docs.cloud.google.com/monitoring/uptime-checks/introduction)には以下のような記述があります。

Cloud Run functions の関数に依存する合成モニターでは、Cloud Run functions の関数がデプロイされるリージョンを指定できます。ただし、関数は稼働時間チェック サーバーでサポートされている任意のリージョンから呼び出すことができます。この動作は構成できません。

つまり、合成モニタリングは1回の実行時に、ランダムに各稼働時間チェック サーバーから関数が呼び出される仕様となっています。

具体的には以下の6つのチェックサーバーから実行されます。

  • アジア太平洋
  • ヨーロッパ
  • 南アメリカ
  • 米国(アイオワ)
  • 米国(オレゴン)
  • 米国(バージニア)

稼働時間チェックであれば、画像のように3リージョンからのみの実行とするように変更することも可能なのですが……

今一度公式ドキュメントの記述を思い出してください。

「この動作は構成できません。」です。

合成モニタリングは実行場所を特定のリージョンに限定・固定することができないのです……

実際に失敗させてみた

論より証拠ということで、実際に合成モニタリングを動かしてみましょう。

1分間隔で実行される合成モニタリングを作成しました(初回はコールドスタートであえて失敗させました)

アラートポリシーは合成モニタリングが5分間に3回以上失敗した時発報するように設定しています。

当然1回だけ失敗なので閾値を超過していることはないはずですが……

閾値を超過していますね……

6回失敗した判定になっています。

このように各稼働時間チェック サーバーから関数が呼び出される仕様上、1回の合成モニタリングの実行時に6回関数が実行されてしまいます。

よって、合成モニタリング関連のアラートを設計する際は閾値は必ずこのことを考慮する必要があります。

上記のアラートポリシーも「合成モニタリングが5分間に3回以上失敗した時発報する」ようにしたいのであれば、閾値を画像のようにしましょう。

これで正しく合成モニタリングが3回以上(= 関数の実行が18回以上)失敗した時に発報するアラートとなります。

おわりに

今回はGoogle CloudのCloud Monitoringにおける新しい死活監視サービス「合成モニタリング」の仕様とそれに伴う注意点について紹介いたしました。

本記事が皆様のお役に立てれば幸いです。
最後までお読みいただきありがとうございます。

参考: 「合成モニタリングの概要」