tl;dr;

connpass APIの仕様変更で地域.rbカレンダーを閉じるつもりでしたが、個人利用申請を行ったので2024年5月23日(木)以降もカレンダーが更新されます

時系列

今年の2月にconnpass APIの無償提供終了が発表

connpassではさらなる価値のあるデータを提供するため、2024年5月23日(木)を以ちまして「イベントサーチAPI」の無料での提供の廃止を決定いたしました。
料金・プラン等につきましては後日改めてご案内いたします。詳しくは以下のお知らせをご覧ください。https://t.co/0IZTzJDOwG
— connpass (@connpass_jp) 2024年2月21日

3月頃にプランが発表されて、料金体系が個人向けじゃなさそうなので地域.rbカレンダーを閉じる（connpassの有料APIに対応しない）ことを決意

2024年5月23日(木)以降より開始予定の「connpass 有料API」の料金・プランページを公開しました。
詳しくは以下のご利用ガイドページをご覧ください。https://t.co/XZVX6kayFB
— connpass (@connpass_jp) 2024年3月11日

この時点では固定IPアドレスも費用かかりそうできっついなあということで閉じる方針は継続。

2024年5月23日(木)以降より開始予定の「connpass 有料API」の料金・プランページを公開しました。
詳しくは以下のご利用ガイドページをご覧ください。https://t.co/XZVX6kayFB
— connpass (@connpass_jp) 2024年3月11日

これを見てRubyKaigi後に機運が高まった。*1（実質KaigiEffect*2）

connpassAPIの有料化につきまして多くのご要望をいただきましたため、2024年5月23日以降も「コミュニティ・個人」に限り利用申請及び審査を行うことを条件に無料でご利用いただけるようになりました。詳細はヘルプページをご確認ください。 https://t.co/SXtHb5Pzw9
— connpass (@connpass_jp) 2024年5月14日

申請した2日後くらいに許諾された！！！

うおおおお！！！！！！
（connpass APIの個人利用申請が通った） pic.twitter.com/86X5FYEngn
— sue445 (@sue445) 2024年5月21日

詳しいログ

github.com

具体的にやったこと

2024年5月23日(木)以降もConnpass APIを使うには固定IPアドレスが必要なので、その対応を行いました。

地域.rbカレンダーのカレンダー生成のエンドポイントはCloud Functionsで動いているため*3、Serverless VPC Access Connectorを利用してCloud Functionからインターネットに出る時にCloud NATを経由して送信元のIPアドレスを固定化しました。

変更前後の構成は下記のような感じです。

Before

After

この図だと端折っていますが、送信元のIPアドレスが本当に固定化されているかの動作確認としてVPC内にVMを立てたりもしています。（Cloud NATはVPCからインターネットに出る時の送信元を全て固定IPアドレスにするので、VPC内にVMを立てても当然同じIPアドレスになる）

Terraform

具体的な方針は下記が参考になりました。

dev.classmethod.jp

これを参考に実装したのが下記のTerraformになります。

# VPC
locals {
  subnet_cidr = "10.128.0.0/20" # 10.128.0.0 - 10.128.15.255

  # Requires /28 for Serverless VPC Access Connector
  # c.f. https://cloud.google.com/vpc/docs/serverless-vpc-access
  vpc_access_connector_cidr = "10.128.16.0/28" # 10.128.16.0 - 10.128.16.15
}

resource "google_compute_network" "main" {
  name                    = "main"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "main" {
  name          = google_compute_network.main.name
  network       = google_compute_network.main.self_link
  ip_cidr_range = local.subnet_cidr
  region        = "asia-northeast1"
}

resource "google_compute_router" "main" {
  name    = google_compute_network.main.name
  region  = google_compute_subnetwork.main.region
  network = google_compute_network.main.self_link
}

resource "google_vpc_access_connector" "main" {
  name          = "main"
  machine_type  = "f1-micro"
  ip_cidr_range = local.vpc_access_connector_cidr
  network       = google_compute_network.main.id

  # NOTE: requires 2+ instances
  min_instances = 2
  max_instances = 3
}

# Cloud NAT
resource "google_compute_router_nat" "main" {
  name   = google_compute_network.main.name
  router = google_compute_router.main.name
  region = google_compute_router.main.region

  nat_ip_allocate_option = "MANUAL_ONLY"
  nat_ips                = [google_compute_address.nat.self_link]

  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

resource "google_compute_address" "nat" {
  name        = "nat"
  region      = google_compute_subnetwork.main.region
  description = "Static Address for Cloud NAT"
}

アプリケーション側（デプロイ時にFunctionをVPC Connectorに紐づける設定）は下記

github.com

ハマったポイント：Terraformでapplyする時だけなぜかエラーになる

具体的には下記のようなエラーです

│ Error: Error waiting to create Connector: Error waiting for Creating Connector: Error code 13, message: An internal error occurred: VPC Access connector failed to get healthy. Please check GCE quotas, logs and org policies and recreate.
│ 
│   with google_vpc_access_connector.main,
│   on vpc.tf line 27, in resource "google_vpc_access_connector" "main":
│   27: resource "google_vpc_access_connector" "main" {

設定自体は問題なさそうだし、なんなら全く同じ設定をコンソールから設定できたので本当に謎でした。（ terraform apply でのみエラーになる）

Terraformで利用しているサービスアカウントに対して service-PROJECT_NUMBER@gcp-sa-vpcaccess.iam.gserviceaccount.com の「サービスアカウントユーザー（ roles/iam.serviceAccountUser ）」*4 のIAMロールが必要なのが原因でした。 *5