【入門編】 GCPプライベートGoogleアクセス（Private Google Access）のDNS名前解決とルーティング経路 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！第一線でクラウドインフラを支えるSRE兼、技術メディア「Cloud Deep Dive」主筆の私です。

今日は、Google Cloud（GCP）を触り始めたばかりの方が必ずと言っていいほどぶつかる、そして理解すると「なるほど、クラウドってこうなってるのか！」と膝を打つ、非常に面白いテーマを深掘りしていきましょう。

今回の主役は、「プライベートGoogleアクセス（Private Google Access）」です。

「外部IPアドレスを持っていないVM（仮想マシン）が、どうしてインターネット側にあるはずのGoogle Cloud Storage（GCS）にファイルをアップロードできるの？」という不思議。この裏側にあるパケットの旅路を、郵便配達の流れに例えて、優しく、かつ現場のリアルな視点を交えて紐解いていきます。

—

1. そもそも「プライベート」なVMはなぜ外に出られないのか？

まず、基本をおさらいしましょう。Google Compute Engine（GCE）でVMを作るとき、セキュリティのために「外部IPアドレス（パブリックIP）」を付与しない設定にすることがよくありますよね。これは、家の玄関に鍵をかけるのと同じで、インターネットという「公道」から直接誰かが入ってこれないようにするためです。

しかし、これには困った副作用があります。「自分からも公道に出られない」のです。

通常、GCS（Cloud Storage）やBigQueryといったGoogleの便利なサービスは、インターネット上の「住所（パブリックIP）」を持っています。外部IPを持たないVMからこれらのサービスにアクセスしようとすると、パケット（手紙）を出す先が分からず、あるいは途中のルーターで「君は公道に出る許可を持っていないよ」と追い返されてしまいます。

そこで登場するのが、今回のヒーロー「プライベートGoogleアクセス」です。

—

2. プライベートGoogleアクセスは「秘密の裏口通路」

プライベートGoogleアクセスを一言で言うなら、「公道（インターネット）に出ることなく、Googleのサービスセンターへ直接つながる建物内の専用通路」です。

この機能を使うと、外部IPアドレスを持たないVMであっても、Google Cloudの内部ネットワークを通って、GCSやBigQuery、その他のAPIへ安全にアクセスできるようになります。

なぜこれが嬉しいのか？

  • セキュリティ: 重要なデータをインターネットに一切晒さずに済む。
  • コスト: NATゲートウェイ（Cloud NAT）を経由させずに済むため、通信費を抑えられるケースがある。
  • シンプル: VMに特別なソフトウェアを入れる必要がない。

—

3. パケットはどうやって運ばれる？（DNSとルーティング）

ここからは、実際にパケットがどうやって目的地までたどり着くのか、その仕組みを「郵便配達」に例えて見ていきましょう。ポイントは「宛先（DNS）」と「道案内（ルーティング）」の2つです。

① DNS名前解決：どこの窓口に行けばいい？

例えば、VMの中で gsutil cp コマンドを叩くと、まず storage.googleapis.com という名前の住所を調べます。

通常、これはインターネット上のパブリックIPを返しますが、プライベートGoogleアクセスの世界では、ちょっと特別な「専用窓口」のIPアドレスを教えてもらうように設定します。

  • private.googleapis.com: ほぼすべてのGoogleサービスにアクセスできる窓口（IP: 199.36.153.8/30）
  • restricted.googleapis.com: VPC Service Controlsという、より厳しいセキュリティ制限をかけたサービス専用の窓口（IP: 199.36.153.4/30）

② ルーティング：どの道を通ればいい？

住所がわかったら、次はパケットを送り出します。
VPCネットワーク内には「ルーティングテーブル」という道路標識があります。ここで、「もし宛先が 199.36.153.4（専用窓口）なら、Googleの内部ネットワークへ進め！」という指示が必要になります。

—

4. 実践！プライベートGoogleアクセスを有効にする設定

それでは、実際にインフラを構築する際のコード例や設定を見ていきましょう。一歩ずつ、確実に進めていけば大丈夫ですよ。

Step 1: サブネットの設定（スイッチを入れる）

まずは、VMが所属している「サブネット」に対して、プライベートGoogleアクセスを「オン」にします。これだけで、そのサブネット内のVMはGoogleの内部ネットワークへの入り口を使える権利を得ます。

# gcloudコマンドを使って、特定のサブネットでプライベートGoogleアクセスを有効化する
# --enable-private-ip-google-access フラグが魔法の言葉です！
gcloud compute networks subnets update [サブネット名] \
    --region=[リージョン名] \
    --enable-private-ip-google-access

Step 2: DNSの設定（住所録を書き換える）

次に、VMが *.googleapis.com を呼び出したときに、先ほどの「専用窓口のIP」を指すように、Cloud DNSで設定を行います。

# Terraformでの設定イメージ（Cloud DNSのレスポンスを上書きする）

# googleapis.com という名前のプライベートDNSゾーンを作成
resource "google_dns_managed_zone" "private-googleapis" {
  name        = "private-googleapis-zone"
  dns_name    = "googleapis.com."
  description = "Google APIsへのプライベートアクセスのための設定"
  visibility  = "private"
  
  networks {
    network_url = google_compute_network.my_vpc.id
  }
}

# すべてのAPIアクセスを 199.36.153.8 (private.googleapis.com) へ誘導するCAMEレコード
resource "google_dns_record_set" "cname_record" {
  name         = "*.googleapis.com."
  managed_zone = google_dns_managed_zone.private-googleapis.name
  type         = "CNAME"
  ttl          = 300
  rrdatas      = ["private.googleapis.com."]
}

# private.googleapis.com 自体のIPアドレスを定義（Aレコード）
resource "google_dns_record_set" "a_record" {
  name         = "private.googleapis.com."
  managed_zone = google_dns_managed_zone.private-googleapis.name
  type         = "A"
  ttl          = 300
  rrdatas      = ["199.36.153.8", "199.36.153.9", "199.36.153.10", "199.36.153.11"]
}

Step 3: ルーティングの確認（道路標識を立てる）

最後に、VPCに「デフォルトルート（0.0.0.0/0）」が設定されているか確認します。
「えっ、外部IPがないのにデフォルトルート？」と思うかもしれませんが、Google Cloudの賢いところは、たとえネクストホップがインターネットゲートウェイ（デフォルトゲートウェイ）を向いていても、宛先がGoogle APIの専用IPアドレスであれば、パケットを外に出さずに内部で処理してくれるのです。

—

5. 現場でよくある「落とし穴」

ここで、SREとして現場でよく遭遇するトラブルシューティングのヒントをお伝えしますね。

「設定したのに繋がらない！」という時は、ここをチェックしてください。

1. ファイアウォールルール:
VMから出すパケット（下り/Egress）を制限していませんか？
デフォルトでは全許可ですが、厳しく制限している場合は、宛先IP 199.36.153.8/30 への TCP:443 ポートを許可する必要があります。

2. DNSの優先順位:
VM内で /etc/resolv.conf がどうなっているか確認しましょう。自前のDNSサーバーを立てている場合、Cloud DNSの設定が反映されないことがあります。

3. 実は「外部IP」が付いていた:
外部IPが付いているVMは、プライベートGoogleアクセスの設定に関わらず、通常通りインターネット経由でアクセスしようとします。挙動が違う！と混乱しがちですが、外部IPの有無でルートが変わることを覚えておきましょう。

—

終わりに

いかがでしたでしょうか。
一見難しそうな「プライベートGoogleアクセス」も、「サブネットのスイッチを入れる」「DNSで住所を教える」「内部通路を通す」という3つのステップで成り立っていることが分かれば、ぐっと身近に感じられますよね。

インフラの世界は、こうした「目に見えないパケットの通り道」を一つずつ丁寧に作っていく作業の積み重ねです。最初は点と点だった知識が、ある日「線」として繋がる瞬間は、エンジニアとして最高の快感ですよ！

これからも、皆さんのクラウドジャーニーがワクワクするものになるよう、現場の知見をたっぷり込めてお届けしていきます。

一歩ずつ、楽しみながら理解を深めていきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました