Google Cloud · Compute Engine

1つの入口から、
壊れないサービスを組み立てる。

ロードバランサは「1つの IP に来たトラフィックを複数のサーバーへ振り分ける」仕組みです。 本ガイドは L4 パススルーL7 アプリケーション内部LBの3方式を、gcloud コマンドでゼロから構築しながら、初学者向けにステップバイステップで解説します。

対象: Compute Engine 初学者ゴール: どのLBを・いつ・なぜ使うか形式: ハンズオンリビジョン: 2026年6月版
00

このガイドの全体像

ロードバランサ(負荷分散装置)は、トラフィックを複数のサーバーに振り分けることで、高可用性(1台落ちても止まらない)と スケーラビリティ(アクセス増にも耐える)を実現します。 本ガイドでは、難易度順に4つのシナリオを扱います。

構築するものレイヤー公開範囲主な用途
第2章パススルー ネットワークLBL4外部(インターネット向け)IP/ポート単位の高速振り分け
第3章アプリケーション ロードバランサL7外部(グローバル)URL/ヘッダー単位のHTTP振り分け
第4章内部パススルー ネットワークLBL4内部(VPC内のみ)社内・サービス間通信
第5章チャレンジ(総合演習)L4 L7外部学んだ内容の実践
01

事前準備(全シナリオ共通)

1.1 用語の整理

Google Cloud のロードバランサは 2系統 × 2方式 に分類されます。 最初にこの軸を押さえると全体が一気に見通せます。核心はL4 は IP・ポートで扱い中身を見ないのに対し、L7 は HTTP(S) を解釈し URL・ヘッダー・Cookie で判断できるという違いです。

アプリケーションLB(L7)ネットワークLB(L4)
判断材料URL・ヘッダー・Cookie・コンテンツIPアドレス・プロトコル・ポート
中身を見るか見る(HTTP/HTTPSを解釈)見ない(パケットをそのまま転送)
方式プロキシ型のみプロキシ型 / パススルー型
💡 パススルー型 vs プロキシ型

プロキシ型はクライアント接続を LB 側で一旦終端し、新しい接続をバックエンドへ張り直します。 一方パススルー型は接続を終端せず、送信元・宛先・ポートを変えずに VM へ届け、 応答は LB を経由せずクライアントへ直接戻ります(DSR = ダイレクトサーバーリターン)。 クライアントの送信元 IP を保持したい場合はパススルー型が向いています。

出典: ロードバランサのリソースモデル

1.2 共通セットアップの流れ

Figure · 共通セットアップ手順

1.3 リージョンとゾーンの設定

すべてのシナリオは、まずデフォルトのリージョン(地域)とゾーン(地域内の区画)の設定から始めます。

bash
# デフォルトのリージョンを設定(例: us-central1)
gcloud config set compute/region REGION
# デフォルトのゾーンを設定(例: us-central1-a)
gcloud config set compute/zone ZONE
⚠️ ベストプラクティス

Cloud Shell では設定がセッションをまたいで保持されません。再接続のたびにgcloud config set を実行する必要があります(自分のPCの gcloud では永続化されます)。

02

外部パススルー ネットワークLB L4

2.1 何を作るのか

3台の Web サーバー(VM)の前段に L4 ロードバランサを置き、インターネットからのアクセスを3台に振り分けます。

Figure · L4 外部パススルー NLB の構成

2.2 コンポーネントの役割

コンポーネント役割
転送ルール(Forwarding Rule)LB の「フロントエンド」。受け付ける IP・プロトコル・ポートを定義
ターゲットプール(Target Pool)トラフィックを受け取るバックエンド VM のグループ
ヘルスチェック(Health Check)各 VM が正常かを定期監視し、健全な VM にのみ振り分ける
📌 重要な制約

ターゲットプールベースの LB はレガシー HTTP ヘルスチェックしか使えません。 新しい TCP ヘルスチェックを使いたい場合はバックエンドサービスベースの LB が必要です。 本シナリオはラボ構成に合わせてターゲットプール方式で解説します。

出典: パススルー ネットワークLB 概要

2.3 ステップバイステップ

ステップ1: 3台の Web サーバーを作成

各 VM に network-lb-tag タグを付けるのがポイントです。タグを付けておくと、後でファイアウォールルールを「このタグが付いた VM 全部」に一括適用できます。

bash
# www1 を作成(www2, www3 も名前だけ変えて同様に作成)
gcloud compute instances create www1 \
--zone=ZONE \
--tags=network-lb-tag \
--machine-type=e2-small \
--image-family=debian-12 \
--image-project=debian-cloud \
--metadata=startup-script='#!/bin/bash
apt-get update
apt-get install apache2 -y
service apache2 restart
echo "<h3>Web Server: www1</h3>" | tee /var/www/html/index.html'
🔍 startup-script とは

startup-scriptVM 起動時に自動実行されるスクリプトです。 ここで Apache をインストールし、どのサーバーが応答したか分かるようホスト名入りページを置いています。

ステップ2: ファイアウォールルールで HTTP を許可

bash
gcloud compute firewall-rules create www-firewall-network-lb \
--target-tags network-lb-tag --allow tcp:80

ステップ3: 動作確認

bash
# 各VMの外部IPを確認
gcloud compute instances list
# curl で各VMに直接アクセスして応答を確認
curl http://[IP_ADDRESS]

ステップ4: ロードバランシングサービスの構成

bash
# 1. 静的外部IPを予約
gcloud compute addresses create network-lb-ip-1 --region REGION
# 2. レガシーHTTPヘルスチェックを作成
gcloud compute http-health-checks create basic-check
# 3. ターゲットプールを作成(ヘルスチェックを紐付け)
gcloud compute target-pools create www-pool \
--region REGION --http-health-check basic-check
# 4. 3台のVMをプールに追加
gcloud compute target-pools add-instances www-pool \
--instances www1,www2,www3
# 5. 転送ルールを作成(80番ポート → プールへ)
gcloud compute forwarding-rules create www-rule \
--region REGION --ports 80 \
--address network-lb-ip-1 --target-pool www-pool

ステップ5: トラフィックを流して確認

bash
# 転送ルールの外部IPを変数に取得
IPADDRESS=$(gcloud compute forwarding-rules describe www-rule \
--region REGION --format="json" | jq -r .IPAddress)
# 繰り返しアクセスして3台に振り分けられる様子を観察(Ctrl+Cで停止)
while true; do curl -m1 $IPADDRESS; done

応答が www1/www2/www3 の間でランダムに切り替われば成功です。最初は失敗することがありますが、約30秒待って VM が healthy になるのを待つのがコツです。

03

外部アプリケーション ロードバランサ L7

3.1 何を作るのか

第2章との最大の違いは、マネージドインスタンスグループ(MIG)グローバル配信 を使う点です。

Figure · L7 外部アプリケーション LB の構成

3.2 なぜグローバルなのか

🌐 Google Front End (GFE)

アプリケーションロードバランシングは Google Front End(GFE)上に実装され、 GFE は世界中に分散して Google のグローバルネットワークと制御プレーンで連携します。 リクエストは原則としてユーザーに最も近いインスタンスグループへルーティングされ、 空きが足りなければ次に近い空きのあるグループへ送られます。

出典: Cloud Load Balancing 製品ページ

3.3 コンポーネントの役割

コンポーネント役割
インスタンステンプレートVM の「設計図」(マシンタイプ・イメージ・起動スクリプト)
マネージドインスタンスグループ(MIG)テンプレートから同一 VM を複製。オートスケール・自動修復が可能
バックエンドサービストラフィックの分配方法を定義(ヘルスチェック含む)
URLマップURL に応じてどのバックエンドへ送るかのルーティング表
ターゲットHTTPプロキシURL マップに従ってリクエストを処理
グローバル転送ルールグローバル外部 IP でリクエストを受け付ける入り口
💡 MIG の価値

マネージドインスタンスグループは、オートスケーリング・自動修復(autohealing)・複数ゾーン展開・自動アップデートといった機能で、ワークロードをスケーラブルかつ高可用にします。

3.4 ステップバイステップ

bash
# 1. インスタンステンプレート(VMの設計図)を作成
gcloud compute instance-templates create lb-backend-template \
--region=REGION --network=default --subnet=default \
--tags=allow-health-check --machine-type=e2-medium \
--image-family=debian-12 --image-project=debian-cloud \
--metadata=startup-script='#!/bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | tee /var/www/html/index.html
systemctl restart apache2'
# 2. テンプレートからMIGを作成(VM 2台)
gcloud compute instance-groups managed create lb-backend-group \
--template=lb-backend-template --size=2 --zone=ZONE
# 3. ヘルスチェック用のファイアウォールルールを作成
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
# 4. グローバル静的外部IPを予約
gcloud compute addresses create lb-ipv4-1 --ip-version=IPV4 --global
# 5. ヘルスチェックを作成
gcloud compute health-checks create http http-basic-check --port 80
# 6. バックエンドサービスを作成
gcloud compute backend-services create web-backend-service \
--protocol=HTTP --port-name=http \
--health-checks=http-basic-check --global
# 7. MIGをバックエンドサービスに追加
gcloud compute backend-services add-backend web-backend-service \
--instance-group=lb-backend-group \
--instance-group-zone=ZONE --global
# 8. URLマップを作成
gcloud compute url-maps create web-map-http \
--default-service web-backend-service
# 9. ターゲットHTTPプロキシを作成
gcloud compute target-http-proxies create http-lb-proxy \
--url-map web-map-http
# 10. グローバル転送ルールを作成
gcloud compute forwarding-rules create http-content-rule \
--address=lb-ipv4-1 --global \
--target-http-proxy=http-lb-proxy --ports=80
⚠️ 重要な IP レンジ

130.211.0.0/2235.191.0.0/16Google のヘルスチェックシステムの送信元 IP です。 このレンジからのトラフィックを許可しないと、ヘルスチェックが失敗して VM が「不健全」と判定され、トラフィックが流れません。

出典: 外部パススルーNLB のセットアップ

3.5 動作確認

コンソールの「ロードバランシング」から web-map-http を開き、バックエンドの VM がHealthy になっているのを確認してから、ブラウザで http://[IP_ADDRESS]/ にアクセスします。

📌 反映待ち

反映には 3〜5分かかることがあります。Page served from: lb-backend-group-xxxx のように VM 名が表示されれば成功です。

04

内部パススルー ネットワークLB 内部 L4

4.1 何を作るのか

これまでと違い、インターネットに公開しない内部専用の LB です。よくある2層アーキテクチャを構築します。

  • Web ティア(公開): ユーザー向け Web サーバー
  • 内部サービスティア(非公開): 素数計算サービス(複数台に分散)
Figure · 内部パススルー NLB を含む2層構成
📝 用語の注意

ラボ本文では「内部アプリケーションロードバランサ」と表現されますが、実際の gcloud--load-balancing-scheme internal--protocol tcp、L4 バックエンドサービスを使っており、 技術的には内部パススルー ネットワークLB(L4)を構築しています。 内部パススルー NLB は、同一リージョン内の内部 VM にトラフィックを分散し、 同じ VPC ネットワーク内(または接続されたネットワーク)からのみアクセス可能な内部 IP の背後でサービスを運用・スケールします。

出典: 内部パススルー ネットワークLB 概要

4.2 内部LBの3つの構成要素

コンポーネント役割
転送ルール他の内部サービスがリクエストを送るプライベート IP アドレス
バックエンドサービスVM への分配方法を定義(ヘルスチェックを含む)
ヘルスチェックバックエンド VM の健全性を継続的に監視

4.3 ステップバイステップ(要点)

bash
# ── バックエンド(素数計算サービス)の準備 ──
# 1. 内部VM用テンプレート(--no-address で公開IPなし=セキュア)
gcloud compute instance-templates create primecalc \
--metadata-from-file startup-script=backend.sh \
--no-address --tags backend --machine-type=e2-medium
# 2. ポート80を内部向けに開放
gcloud compute firewall-rules create http --network default \
--allow=tcp:80 --source-ranges IP --target-tags backend
# 3. MIG(3台)を作成
gcloud compute instance-groups managed create backend \
--size 3 --template primecalc --zone ZONE
# ── 内部ロードバランサの構築 ──
# 4. ヘルスチェック(/2 にアクセスして200 OKかを確認)
gcloud compute health-checks create http ilb-health --request-path /2
# 5. 内部バックエンドサービス(scheme=internal, protocol=tcp)
gcloud compute backend-services create prime-service \
--load-balancing-scheme internal --region=REGION \
--protocol tcp --health-checks ilb-health
# 6. MIGをバックエンドサービスに追加
gcloud compute backend-services add-backend prime-service \
--instance-group backend --instance-group-zone=ZONE --region=REGION
# 7. 内部転送ルール(静的内部IP)を作成
gcloud compute forwarding-rules create prime-lb \
--load-balancing-scheme internal --ports 80 --network default \
--region=REGION --address IP --backend-service prime-service
🔒 セキュリティのベストプラクティス

バックエンド VM には --no-address(公開 IP なし)を付けています。内部サービスは外部から直接到達できないようにし、公開フロントエンド経由でのみアクセスさせるのが鉄則です。

4.4 テスト方法

内部 LB は VPC 内からしかアクセスできないため、Cloud Shell(VPC外)からは直接叩けません。 同じネットワークにテスト用 VM を作って SSH し、内部 IP に curl します。

bash
# テスト用VMを作成してSSH
gcloud compute instances create testinstance \
--machine-type=e2-standard-2 --zone ZONE
gcloud compute ssh testinstance --zone ZONE
# VM内部から内部LBへ(2と5はTrue=素数、4はFalse)
curl IP/2 # True
curl IP/4 # False
curl IP/5 # True
✅ 確認ポイント

2 と 5 が素数(True)、4 が非素数(False)と正しく返れば、内部 LB がバックエンドに正常に振り分けられている証拠です。 確認後は testinstance を削除しておきましょう。

05

総合演習 — チャレンジラボの攻略方針

チャレンジラボは手順書がなく、学んだスキルを応用して自力で解く形式です。第2〜4章の知識を組み合わせます。

5.1 タスク分解と対応表

Figure · チャレンジのタスク連鎖
タスク参照する章必須リソース名
1. Webサーバー作成第2章web1 web2 web3 / タグ network-lb-tag / FW www-firewall-network-lb
2. L4 ロードバランシング第2章静的IP network-lb-ip-1 / プール www-pool / ポート80
3. L7 HTTP ロードバランサ第3章lb-backend-template / lb-backend-group / lb-ipv4-1 / http-basic-check / web-map-http / http-lb-proxy

5.2 チャレンジ攻略のコツ

つまずきポイント対処
リソース名が指定と違う採点はリソース名を厳密にチェック。指定どおりに命名
イメージファミリーの指定このラボは debian-12 / debian-cloud を使用
ヘルスチェックが通らない130.211.0.0/2235.191.0.0/16 を FW で許可したか確認
すぐ反映されないL7 は 3〜5分、VM の healthy 化に 30秒程度待つ
エラーが出るエラーメッセージを読んで調べるのも採点対象のスキル
06

ロードバランサ選定の早見チャート

Figure · LB 選定の判断ツリー
💡 公式の選定指針

HTTP(S) トラフィックのアプリには L7 のアプリケーションLBを、 TLS オフロード(プロキシ型)や TCP/UDP/ESP/GRE/ICMP などの IP プロトコルが必要な場合はL4 のネットワークLBを選びます。 クライアントの送信元 IP を保持したい・プロキシのオーバーヘッドを避けたい・UDP/ESP/ICMP などに対応したい場合はパススルー型を選びます。

出典: ロードバランサの選び方
07

ベストプラクティス総まとめ

観点ベストプラクティス
ヘルスチェック必ず設定し、130.211.0.0/2235.191.0.0/16 を FW で許可する
タグ設計VM にタグを付け、FW ルールをタグ単位で一括管理する
最小公開内部サービスは --no-address で公開 IP を持たせない
命名規則リソース名は一貫したルールで(チャレンジでは指定厳守)
静的IP外部公開用は静的 IP を予約し、変動を防ぐ
スケール本番は MIG + オートスケーリングで弾力性を確保
リージョン整合L4 はリージョナル。全コンポーネントを同一リージョンに揃える
反映待ち構築直後は数分待ってからテストする
08

参考ソース(公式ドキュメント)

トピックURL
Cloud Load Balancing 概要load-balancing-overview
ロードバランサの選び方choosing-load-balancer
ロードバランサのリソースモデルload-balancer-resource-model
パススルー ネットワークLB 概要passthrough-network-load-balancer
内部パススルー ネットワークLB 概要internal
外部パススルーNLB のセットアップsetting-up-network-backend-service
Cloud Load Balancing 製品ページcloud.google.com/load-balancing
リリースノートrelease-notes
元コース(Google Skills Boost)paths/11/course_templates/648
ℹ️ 命名の変遷について

旧称「ネットワークロードバランサ」は現在「パススルー ネットワークロードバランサ」、 旧称「HTTP(S)ロードバランサ」は「アプリケーションロードバランサ」に整理されています。 ラボ教材によっては旧称が残っている場合があるため、公式ドキュメントの最新表記を基準にすると混乱しません。