なぜこのテーマを選択したかというと、以前のプロジェクトでの実装でかなり苦労したからです(汗)。

プロジェクトの一環として、インターネットへ公開されていない VM インスタンス(Compute Engine)の稼働監視をする、というタスクありました。

もちろん OSS の死活監視ソフト等で実現は可能だったのですが、今後のソフトウェアメンテナンスや運用面を考慮して、マネージドサービスで完結したかったのです。

まず、VM インスタンスの死活監視を Cloud Monitoring の Uptime メトリクス(compute.googleapis.com/instance/uptime)で試行錯誤したものの、やっぱりうまくいかず。
※ 実際公式ドキュメントにも 「uptime などの指標タイプはモニタリングしないで」と書いてありますしね。。。

そして 、今回ご紹介する「稼働監視アラート」 も試してみたのですが、当時は、内部 IP アドレス向けの監視は「http、https」ポートしか利用できず、監視対象全台に実質 Web サーバの準備が必要でした。

結局のところ、泣く泣く、Cloud Monitoring のカスタムアラートにて死活監視を実装しました。
 

＜ 当時の構成 ＞

ところが、2024/07/01 のアップデートにて、プライベートセグメントでも TCP 監視できるようになったという情報をつかみました。
ということで、最新の構成で検証してみたいと思います。

既に Google Cloud のプロジェクトがある前提で進めます。

構成はこんなイメージを想定しています。

１．API の有効化

プロジェクトで以下の API を有効にします。

• Compute Engine API
• Network Management API
• Service Directory API

２．必要な権限(ロール)の付与

プロジェクトで次のロールが付与されていることを確認します。

• Compute 管理者 (roles/compute.admin)
• Compute ネットワーク管理者 (roles/compute.networkAdmin)
• モニタリング編集者（roles/monitoring.editor)

３．リソースの準備

検証用に、監視対象となる VM インスタンス(Compute Engine)を 1 台 作成しました。
この VM インスタンスには グローバル IP を割り当てず、内部 IP アドレスのみの構成とします。

下準備はここまでです。

通常は便利な構成ウィザードで簡単に作成できますが、今回は構成理解のためにそれぞれのパーツから作ってみようと思います。
必要な手順は下記の４つです。

1. ファイアウォール ルールの作成
2. Service Directory サービスの作成
3. Service Directory エンドポイントの作成
4. 稼働時間チェックの作成

１．ファイアウォール ルールの作成

今回は、内部 IP アドレスしか持たないプライベートセグメント内の VM インスタンスを監視するため、必要な通信を許可します。
下記の設定は検証目的のため VPC ネットワーク全体に適用していますが、実際には適切な範囲での適用を推奨します。

２．Service Directory サービスの作成

Google Cloud コンソールのメニューバーより [ネットワーク サービス] – [Service Directory]を選択します。

上部より「サービスの登録」を選択します。

サービスが作成されたことを確認します。

３．Service Directory エンドポイントの作成

作成したサービスを選択し、「＋ エンドポイントを追加」をクリックします。

エンドポイントが追加されると以下のようになります。



 

４．稼働時間チェックの作成

Google Cloud のメニューバーより [ロギング] – [稼働時間チェック]を選択します。
上部より「＋稼働時間チェックを作成」を選択します。

リクエスト送信元 リージョンを指定する際、最低 ３ リージョンを選択する必要があります。

今回は検証目的のため「TCP 22 番ポート」を監視対象としますが、実際にはセキュリティ面も考慮して別のポートを使った方がよいかもしれません。

① ターゲット

② レスポンスの検証

③ アラートと通知

④ 稼働時間チェックの名称

作成する前に稼働時間チェックのテストをしましょう。
検証が失敗した場合は何かしら設定不備があるので、設定を見直してください。

これで、稼働時間チェックの作成は終了です。
作成後しばらくすると、各リージョンから監視が始まります。



 

５．稼働時間チェックの動作確認

それでは VM インスタンスを停止してみます。
しばらくすると、3 リージョンからアクセスができなくなり、最終的にはメールにて通知が来ることも確認できました。



・ 通知メール

ちなみに、ssh ポートに向けて稼働時間チェックを行うと、Linux系OSでは「/var/log/secure」に下記のようなログが記録されます。
通信の発信元が「35.199.192.0/19」である場合は、稼働時間チェック(厳密には Service Directory からのアクセス)が原因ですので、ご安心いただければと思います。

６．考察

今回は Cloud Logging へログ出力していますので、ログからもトレースしてみます。
VM インスタンス停止後、リクエスト送信元のリージョンから監視通信がタイムアウトし、監視失敗の判定をしていることがわかります。
 
・ 到達可否の推移（1 = 到達、0 = 到達不可）



・ Cloud Logging のログ内容

・ 監視間隔
今回設定では、 5 分間隔の監視でしたので、理論上は最大 10 分未満にてアラート検知がされます。
また、接続失敗の検知は 10 秒間レスポンスがない場合に監視失敗と判断されます。
その後、全チェックポイントでの失敗検知後にアラート判断となるため、若干のタイムラグがあるのかと思います。

・ 構成について
内部 IP アドレス向けの稼働時間チェックはインターネットを経由せず、Google Cloud のグローバルな内部ネットワークを通じて VPC に 接続された Service Directory ＆ エンドポイントへ向けて監視パケットを送信する、というような構成となっていることがわかりました。

１．費用感

内部 IP アドレスの死活監視では、Service Directory を経由するため、若干費用が発生します。
とはいえ、そこまで気にする費用感ではないかなと思われます。

２．使いどころ

監視対象の台数にもよりますが、10 台 ～ 20 台を 5 分間隔で死活監視をする場合を想定すると、それ程の費用負担にはならないかなと思います。
また、Cloud Monitoring では 死活監視だけではなく、メトリクスに応じたパフォーマンス監視等も可能です。
もちろん、OSS の監視ソフトでも同じことができますので、ここは運用者のスキルセットや学習コストに応じて選択いただければと思います。
数台の死活監視のために別途監視サーバを立てて運用していくのはちょっと、という方はぜひマネージドな機能に監視をまかせてみるのもいかがでしょうか。

一度リリースして安定稼働しているとあまり構成を見直すことはあまりないため便利なアップデートに追いつけてませんでしたが、「稼働時間チェック」はこんなに実用的になっていました。

• Google Cloud マネージド機能で内部 IP アドレスの監視が完結できる
• 複数リージョンからの監視で可用性も担保
• ログ管理サービス(Cloud Logging）に統合されているため、運用変更なく容易に監視が可能

 
最後まで読んでいただき、ありがとうございました！
 
 
当社システムサポートは、Google Cloud の導入・移行・運営支援を行っています。
クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします！