Cloud Load Balancing・Cloud DNS・Cloud CDN

図 5-2 のチェーンを下から上へ組み立て、単一 IP の背後で 2 台の Web サーバーに分散させます。所要 30〜45 分。費用: e2-small 2 台 + 転送ルールなどを 1 時間弱で数十円程度。作成直後の反映待ちがあるので、失敗と勘違いして作り直さないのがコツです。

1. 起動スクリプト入りのインスタンステンプレートと MIG（2 台）を作り、ポート 80 に http という名前を付ける:

gcloud compute instance-templates create web-template \
    --machine-type=e2-small \
    --image-family=debian-12 --image-project=debian-cloud \
    --tags=allow-health-check \
    --metadata=startup-script='#! /bin/bash
apt-get update
apt-get install -y apache2
echo "Hello from $(hostname)" > /var/www/html/index.html'

gcloud compute instance-groups managed create web-mig \
    --template=web-template --size=2 --zone=asia-northeast1-b

gcloud compute instance-groups set-named-ports web-mig \
    --named-ports=http:80 --zone=asia-northeast1-b

2. ヘルスチェックプローブと GFE 転送トラフィックの送信元レンジを許可するファイアウォール、グローバル静的 IP、ヘルスチェック、バックエンドサービスを作って MIG をぶら下げる:

gcloud compute firewall-rules create fw-allow-health-check \
    --network=default --action=allow --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-health-check --rules=tcp:80

gcloud compute addresses create lb-ip \
    --ip-version=IPV4 --network-tier=PREMIUM --global

gcloud compute health-checks create http basic-check --port=80

gcloud compute backend-services create web-backend \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP --port-name=http \
    --health-checks=basic-check --global

gcloud compute backend-services add-backend web-backend \
    --instance-group=web-mig \
    --instance-group-zone=asia-northeast1-b --global

3. フロントエンド側（URL マップ → ターゲット HTTP プロキシ → 転送ルール）を組む。今回は手順を短くするため HTTP:80 で公開する（本番は HTTPS + マネージド証明書が前提）:

gcloud compute url-maps create web-map --default-service=web-backend

gcloud compute target-http-proxies create web-proxy --url-map=web-map

gcloud compute forwarding-rules create web-rule \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --network-tier=PREMIUM --address=lb-ip \
    --global --target-http-proxy=web-proxy --ports=80

4. ヘルス状態を確認してからアクセスする。反映まで数分かかることがある:

gcloud compute backend-services get-health web-backend --global

LB_IP=$(gcloud compute addresses describe lb-ip \
    --global --format="get(address)")
curl "http://$LB_IP/"

期待される出力: get-health で 2 インスタンスとも healthState: HEALTHY になった後、curl が Hello from web-mig-xxxx を返します。何度か curl を繰り返すとホスト名が入れ替わり、2 台に分散されていることを確認できます。

後片付け: 参照関係があるため、必ずフロントエンドから逆順に削除します。

gcloud compute forwarding-rules delete web-rule --global --quiet
gcloud compute target-http-proxies delete web-proxy --quiet
gcloud compute url-maps delete web-map --quiet
gcloud compute backend-services delete web-backend --global --quiet
gcloud compute health-checks delete basic-check --quiet
gcloud compute addresses delete lb-ip --global --quiet
gcloud compute instance-groups managed delete web-mig \
    --zone=asia-northeast1-b --quiet
gcloud compute instance-templates delete web-template --quiet
gcloud compute firewall-rules delete fw-allow-health-check --quiet

Cloud Storage をオリジンにした CDN 配信を組み、Age ヘッダーでキャッシュヒットを観測してから無効化を実行します。所要 20〜30 分。費用: 数 KB のオブジェクトと転送ルールを 30 分程度で数円以内。

1. 公開バケットとテストオブジェクトを用意する。Cache-Control をオブジェクトに設定して、テキストでも確実にキャッシュ対象（フレッシュな応答）にする:

export BUCKET="$(gcloud config get-value project)-cdn-handson"

gcloud storage buckets create "gs://$BUCKET" \
    --location=asia-northeast1 --uniform-bucket-level-access

echo "Hello CDN" > hello.txt
gcloud storage cp hello.txt "gs://$BUCKET/"
gcloud storage objects update "gs://$BUCKET/hello.txt" \
    --cache-control="public, max-age=3600"

gcloud storage buckets add-iam-policy-binding "gs://$BUCKET" \
    --member=allUsers --role=roles/storage.objectViewer

2. --enable-cdn 付きのバックエンドバケットを作り、LB のフロントエンドをかぶせる:

gcloud compute backend-buckets create cdn-backend \
    --gcs-bucket-name="$BUCKET" \
    --enable-cdn --cache-mode=CACHE_ALL_STATIC

gcloud compute url-maps create cdn-map \
    --default-backend-bucket=cdn-backend

gcloud compute target-http-proxies create cdn-proxy --url-map=cdn-map

gcloud compute addresses create cdn-ip \
    --ip-version=IPV4 --network-tier=PREMIUM --global

gcloud compute forwarding-rules create cdn-rule \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --network-tier=PREMIUM --address=cdn-ip \
    --global --target-http-proxy=cdn-proxy --ports=80

3. 数分待ってから同じ URL を 2 回以上取得し、ヘッダーを比較する。確認後にキャッシュを無効化する:

CDN_IP=$(gcloud compute addresses describe cdn-ip \
    --global --format="get(address)")

curl -sD - -o /dev/null "http://$CDN_IP/hello.txt"
curl -sD - -o /dev/null "http://$CDN_IP/hello.txt"

gcloud compute url-maps invalidate-cdn-cache cdn-map --path="/hello.txt"

期待される出力: 2 回目以降の応答に Age: 12 のような 0 より大きい Age ヘッダーが付けばキャッシュヒットです（初回はエッジへの cache fill なので付きません）。無効化の完了後に再取得すると Age が消え、再びオリジンから取得されたことが分かります。

後片付け:

gcloud compute forwarding-rules delete cdn-rule --global --quiet
gcloud compute target-http-proxies delete cdn-proxy --quiet
gcloud compute url-maps delete cdn-map --quiet
gcloud compute backend-buckets delete cdn-backend --quiet
gcloud compute addresses delete cdn-ip --global --quiet
gcloud storage rm -r "gs://$BUCKET"

ドメインを所有していなくても試せる限定公開ゾーンで、VPC 内だけで解決できる名前を作ります。所要 15 分。費用: マネージドゾーンは時間割り課金（2026-08 時点で約 $0.000274/時、月額換算 $0.20）なので 1 時間なら 1 円未満 + 確認用 e2-micro 1 台を数分で数円以内。

1. Cloud DNS API を有効化し、default ネットワークに紐付く限定公開ゾーンと A レコードを作る:

gcloud services enable dns.googleapis.com

gcloud dns managed-zones create internal-zone \
    --dns-name="internal.example." \
    --description="handson private zone" \
    --visibility=private --networks=default

gcloud dns record-sets create db.internal.example. \
    --zone=internal-zone --type=A --ttl=300 \
    --rrdatas=10.0.0.42

gcloud dns record-sets list --zone=internal-zone

2. VPC 内の VM からだけ解決できることを確認する:

gcloud compute instances create dns-probe \
    --zone=asia-northeast1-b --machine-type=e2-micro \
    --image-family=debian-12 --image-project=debian-cloud

gcloud compute ssh dns-probe --zone=asia-northeast1-b \
    --command="getent hosts db.internal.example"

期待される出力: 10.0.0.42 db.internal.example。VM は VPC のメタデータサーバー経由で名前解決し、そこに限定公開ゾーンの応答が合成されます。同じ名前を Cloud Shell（VPC 外）で引いても解決できないことも確かめると、「どの VPC から見えるか」というゾーンのスコープが体感できます。

後片付け: ゾーンはレコードを消してからでないと削除できません。

gcloud compute instances delete dns-probe \
    --zone=asia-northeast1-b --quiet
gcloud dns record-sets delete db.internal.example. \
    --zone=internal-zone --type=A
gcloud dns managed-zones delete internal-zone