GCP Load Balancing の構築手順｜gcloud でグローバル外部アプリケーションロードバランサを作る

Google Cloud でWebサーバーの前にロードバランサを置く場合、HTTPS で公開するWebサイトなら「グローバル外部アプリケーションロードバランサ」を選ぶのが一般的です。この記事では、Compute Engine のマネージドインスタンスグループ（MIG）をバックエンドにして、gcloud コマンドでヘルスチェック、バックエンドサービス、URL マップ、証明書、転送ルールを順に作り、HTTP から HTTPS へのリダイレクトまで設定する手順を説明します。各リソースの役割と、つまずきやすい箇所の確認方法もあわせて解説します。

先に種類を選ぶ

Google Cloud のロードバランサは、扱う層（L7 か L4 か）、公開範囲（外部か内部か）、配置（グローバルかリージョンか）の組み合わせで種類が分かれています。

• アプリケーションロードバランサ：HTTP(S) を扱う L7 のロードバランサ。URL のパスやホスト名で振り分けられ、マネージド証明書や Cloud Armor と組み合わせられます。Webサイトや API の公開に向いています。
• ネットワークロードバランサ：TCP / UDP を扱う L4 のロードバランサ。プロキシ型とパススルー型があり、HTTP 以外のプロトコルや、クライアントの送信元 IP をそのままバックエンドで受けたい場合に使います。

製品名や区分はこれまでにも整理し直されており、管理画面の表記も変わることがあります（2026年10月現在）。この記事では、グローバル外部アプリケーションロードバランサ（gcloud ではロードバランシングスキーム EXTERNAL_MANAGED）を前提にします。従来型（クラシック）は EXTERNAL を指定するもので、新規構築では公式ドキュメントで推奨されている方を確認してから選んでください。

全体の構成

リソースは次の順につながります。どこかが欠けると通信が通らないため、作る順番もこの流れに沿います。

クライアント
  → 転送ルール（外部IP:443）
  → ターゲット HTTPS プロキシ（証明書を持つ）
  → URL マップ（振り分けルール）
  → バックエンドサービス（ヘルスチェック・タイムアウト）
  → インスタンスグループ（VM）

以下のコマンドは例です。プロジェクト、リージョン、ゾーン、名前は自分の環境に合わせて置き換えてください。本番環境に作る前に、検証用のプロジェクトで一度通しておくと安心です。

手順1：バックエンドの VM を用意する

インスタンステンプレートから MIG を作り、バックエンドが待ち受けるポートに名前（名前付きポート）を付けます。バックエンドサービスはこの名前でポートを参照します。

gcloud compute instance-templates create web-template \
  --machine-type=e2-small \
  --image-family=debian-12 --image-project=debian-cloud \
  --tags=allow-health-check

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

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

VM には Nginx や Apache などのWebサーバーを入れ、ヘルスチェック用のパス（例: /healthz）が 200 を返すようにしておきます。トップページをヘルスチェックに使うと、アプリケーションの一時的な不調でバックエンドがまとめて外れることがあるため、軽い専用パスを用意するのがおすすめです。

手順2：ヘルスチェック用のファイアウォールルール

グローバル外部アプリケーションロードバランサのヘルスチェックとプロキシからの通信は、Google が公開している送信元範囲 130.211.0.0/22 と 35.191.0.0/16 から届きます。この範囲からバックエンドのポートへの通信を許可しないと、ヘルスチェックが失敗し続けます。

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

手順3：ヘルスチェックとバックエンドサービス

gcloud compute health-checks create http web-hc \
  --port=80 --request-path=/healthz

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

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

バックエンドサービスにはタイムアウトの設定があります。管理画面での重い処理やファイルのアップロードなど、応答に時間がかかる処理がある場合は、既定値で足りるかを確認しておきます。

手順4：URL マップ、IP アドレス、証明書

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

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

gcloud compute ssl-certificates create web-cert \
  --domains=www.example.com --global

予約した IP アドレスは次のコマンドで確認し、DNS で対象ドメインの A レコードをこのアドレスに向けます。

gcloud compute addresses describe web-ip --global --format="get(address)"

Google マネージド証明書は、DNS がロードバランサの IP を指していて、ロードバランサ経由でドメインに到達できるようになってから発行されます。DNS を切り替える前は状態が PROVISIONING のまま進まないのが正常な動きです。証明書を事前に用意したい場合や、ワイルドカード証明書を使いたい場合は Certificate Manager を検討します。

手順5：HTTPS プロキシと転送ルール

gcloud compute target-https-proxies create web-https-proxy \
  --url-map=web-map --ssl-certificates=web-cert

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

手順6：HTTP から HTTPS へのリダイレクト

HTTP（80番）で来たアクセスを HTTPS に転送するには、リダイレクトだけを行う URL マップを別に作り、同じ IP アドレスの 80 番に割り当てます。

cat > web-redirect.yaml <<'EOF'
kind: compute#urlMap
name: web-redirect
defaultUrlRedirect:
  redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
  httpsRedirect: True
EOF

gcloud compute url-maps import web-redirect --source=web-redirect.yaml --global

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

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

動作確認

構築後は、バックエンドの状態、証明書の状態、実際の応答の3つを確認します。

# バックエンドが HEALTHY になっているか
gcloud compute backend-services get-health web-backend --global

# 証明書の状態（ACTIVE になれば発行済み）
gcloud compute ssl-certificates describe web-cert --global \
  --format="get(managed.status)"

# 応答ヘッダーの確認
curl -I http://www.example.com/
curl -I https://www.example.com/

ロードバランサの設定は、作成直後は反映に数分かかることがあります。すぐに疎通しなくても、少し待ってから再確認してください。

つまずきやすいポイント

• 502 が返る：バックエンドが UNHEALTHY の可能性が高いです。ファイアウォールの送信元範囲、ヘルスチェックのパスとポート、VM 上のWebサーバーの起動状態を順に確認します。
• 証明書が ACTIVE にならない：DNS の A レコードがロードバランサの IP を指しているか、AAAA レコードなど別の宛先が残っていないかを確認します。
• アプリケーションが HTTP と誤認する：TLS はロードバランサで終端されるため、バックエンドには HTTP で届きます。WordPress などのアプリケーションは、X-Forwarded-Proto ヘッダーを見て HTTPS と判断する設定が必要です。
• アクセスログのクライアント IP：バックエンドにはプロキシの IP が記録されます。実際のクライアント IP は X-Forwarded-For ヘッダーで受け取ります。

まとめ

• HTTPS のWebサイトには、グローバル外部アプリケーションロードバランサ（EXTERNAL_MANAGED）が基本の選択肢。
• 転送ルール → プロキシ → URL マップ → バックエンドサービス → インスタンスグループの順につながる。
• ヘルスチェックの送信元範囲をファイアウォールで許可し、軽い専用パスで判定する。
• マネージド証明書は DNS をロードバランサに向けてから発行される。
• HTTP→HTTPS のリダイレクトは別の URL マップを同じ IP の 80 番に割り当てて実現する。

• GCP Certificate Manager で証明書を発行する手順
• WordPressをGoogle Cloud Armorで守るセキュリティポリシー設定手順