当記事はみずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画で執筆されたものです。

みずほリサーチ&テクノロジーズ株式会社の舘山と申します。当記事では Cloud Monitoring 指標スコープを活用して複数プロジェクトを横断してリソースの消費状況をモニタリングする事例を紹介します。

はじめに
前提知識
- 割り当てと上限
- VPC ピアリングに関する割り当てと上限
ピアリンググループ単位の割り当てのモニタリング
さいごに

はじめに

まずはじめに、なぜ Cloud Monitoring 指標スコープを用いて VPC ピアリンググループ単位の割り当て消費をモニタリングする必要があるかをご説明します。

複数プロジェクトとオンプレミス環境の接続

マルチテナントのように数多くの Google Cloud のテナントプロジェクトとオンプレミス環境を接続する場合、以下のような VPC ピアリングによるハブアンドスポーク構成が有力な選択肢です。

共有 VPC 構成よりも堅確にテナントネットワーク相互の分離、アクセス制御を実現できる構成です。

個別システムと共通基盤の役割分掌

ここで、テナントプロジェクトの利用者（個別システム）と提供者（共通基盤）の役割分掌に注目します。一般的には

VPC と VPC ピアリング接続の作成
組織内でユニークなプライベート IP アドレス範囲の割り当て

などは個別システムからの申請に基づき共通基盤が実施します。一方で

VM インスタンスの作成
サブネットの作成

などは個別システムに権限移譲したほうが開発速度を加速できるでしょう。

VPC ピアリンググループ単位の制限

ここで 1 点注意が必要なのですが、 VM インスタンスやサブネットを無限に作成できるわけではありません。

本件のようなマルチテナントの場合、中心となるハブプロジェクトから各テナントプロジェクトに VPC ピアリングしているため、VPC ピアリンググループ（中心となる VPC と直接ピアリング接続された VPC の集合）単位の制限に注意が必要です。制限を超過して VM インスタンスやサブネットを作成することはできません。

テナントプロジェクト側は、自 VPC の割り当ては意識できていても、ピアリンググループ単位の割り当ては把握できません。そのような状況で、ある日突然 VM インスタンスやサブネットを作成できなくなると問題です。制限に抵触しないように共通基盤がピアリンググループ単位の利用状況をモニタリングし、必要に応じて割り当て量の増加をリクエストする運用を行います。

共通基盤によるモニタリング

そこで共通基盤は Cloud Monitoring 指標スコープを用いて VPC ピアリンググループ単位の割り当て消費をモニタリングする運用が必要となってくるわけです。

なお、複数プロジェクトのモニタリングについて、指標スコープと従来のワークスペースとの差異については、以下のブログ記事の解説が参考になります。

参考: 複数プロジェクト構成の Cloud Monitoring がより使いやすくなりました

前提知識

割り当てと上限

繰り返しになりますが、Google Cloud の各サービスでは無制限にリソースを作成できるわけではありません。
制限として割り当てと上限があります。両者の違いは以下のようになります。

観点	割り当て	上限
増加の可否	ほとんどの場合、コンソールの割り当て画面から割り当ての増加が可能。	原則不可。例外的にサポートケース起票で上限の引き上げができる項目が存在。
Cloud Monitoringの指標による消費状況の確認	ほとんどの場合、Cloud Monitoringの割り当て指標で、現在の割り当て消費状況を確認可能。コンソールの割り当て画面で、割り当て指標を一括管理可能。	Cloud Monitroingで上限の消費状況を確認できる指標は提供されていない。

なお、クラウドにおけるリソース数などの制限の管理については、AWSのドキュメントになりますが、AWS Well-Architected Framework信頼性の柱の記述が参考になります。

参考: REL 1 サービスクォータと制約はどのように管理しますか?

VPC ピアリングに関する割り当てと上限

「はじめに」でも述べましたが、VPC ピアリンググループ（中心となる VPC と直接ピアリング接続された VPC の集合）単位の VM インスタンス数、サブネット数などには制限があります。

参考: VPC の割り当てと上限のガイド

VM インスタンス数やサブネット数などは割り当てに分類されており、消費状況を確認できます。

例：ピアリンググループあたりのサブネット数の割り当て指標

また VPC 単位の割り当ても存在します。

例：VPCあたりのサブネット数の割り当て指標

ピアリンググループ単位の割り当てのモニタリング

今回は、ハブアンドスポークアーキテクチャを想定し、ハブ VPC を中心としたピアリンググループをモニタリング対象とします。

アプローチ

ピアリンググループ全体の割り当て消費だけでなく、VPC 毎の割り当て消費の内訳もモニタリングできることが望ましいです。

そのため、ピアリンググループ単位の割り当て指標を直接モニタリングするのではなく、VPC 単位の割り当て指標を集計するアプローチを採用します。

また、ピアリンググループを構成する VPC が複数プロジェクトに跨っている場合にも対応する必要があります。

複数プロジェクト横断のモニタリングには、Cloud Monitoring 指標スコープを利用します。

指標スコープの設定

指標スコープの設定方法は、Cloud Monitoring のガイドを参照してください。

参考: 複数の Cloud プロジェクトの指標を表示する

下の画像は、指標スコープの設定後にメトリクスエクスプローラーで、VPC 単位のサブネット数の割り当て指標（compute.googleapis.com/quota/subnet_ranges_per_vpc_network/usage）を参照した例です。

指標スコープ内の全プロジェクトの VPC の指標が参照されます。

ピアリンググループに参加しない VPC がある場合、フィルター条件で当該 VPC を対象から除外します。

更新がない状態で指標は 1 日に 1 回しか書き込まれていなかったため、アライメント期間を 1500m（25 時間）に設定し、期間内に値が複数存在する場合は、最新の値（next older）を採用しています。

なお、グラフで VPC 毎の利用状況を把握するため Aggregator は none を指定しています。

制限事項

Cloud SQL 等の利用時、Google 管理の VPC との VPC ピアリング接続が作成されます。
Google 管理の VPC は利用者のプロジェクトに属さないため、指標スコープを通して集計対象に含めることはできません。

カスタムダッシュボードの作成

Cloud Monitoring ではカスタムダッシュボードを作成できます。

参考: カスタムダッシュボードの作成と管理

ピアリンググループの割り当て管理用のカスタムダッシュボードとして、割り当て毎に下の画像のようなグラフを配置する構成が考えられます。

VPC 毎の内訳と推移のグラフは、前掲のメトリクスエクスプローラのように、VPC 単位の割り当て指標を参照します。

ピアリンググループ単位の現在の割り当てと消費数のスコアカードは、次のアラートポリシーのようにピアリンググループ単位の割り当て指標を直接参照します。

アラートポリシーの作成

Cloud Monitoring ではアラートポリシーを定義して、割り当て消費が閾値を超過した場合にメール通知できます。

アラートポリシーの作成手順については、Cloud Monitoring のガイドを参照してください。

参考: 指標ベースのアラートポリシーを作成する

今回は Terraform でピアリンググループ単位の VM インスタンス数のアラートポリシーを定義してみます。

このユースケースでは、VPC 毎の内訳は不要のため、ピアリンググループ単位の割り当て指標（instances_per_peering_group/usage）を直接参照できます。

指標スコープ内にはスポーク VPC を中心としたピアリンググループの割り当て指標も存在するため、フィルタ条件でハブ VPC を指定します。

resource "google_monitoring_alert_policy" "instance-per-peering-group" {
  display_name = "instance-per-peering-group"
  combiner     = "OR"
  conditions {
    display_name = "VPC Peering - Instances Per Peering Group quota usage"
    condition_threshold {
      filter     = <<EOF
resource.type = "compute.googleapis.com/VpcNetwork" AND 
metric.type = "compute.googleapis.com/quota/instances_per_peering_group/usage" AND  
resource.labels.network_id = ${local.hub-vpc}
EOF
      threshold_value = 10000
      trigger {
          count = 1
      }
      duration   = "0s"
      comparison = "COMPARISON_GT"
      aggregations {
        alignment_period   = "90000s"
        per_series_aligner = "ALIGN_MAX"
      }
    }
  }
  notification_channels = [
    google_monitoring_notification_channel.email.id
  ]
}