1つの入口から、
壊れないサービスを組み立てる。
ロードバランサは「1つの IP に来たトラフィックを複数のサーバーへ振り分ける」仕組みです。 本ガイドは L4 パススルー・L7 アプリケーション・内部LBの3方式を、gcloud コマンドでゼロから構築しながら、初学者向けにステップバイステップで解説します。
このガイドの全体像
ロードバランサ(負荷分散装置)は、トラフィックを複数のサーバーに振り分けることで、高可用性(1台落ちても止まらない)と スケーラビリティ(アクセス増にも耐える)を実現します。 本ガイドでは、難易度順に4つのシナリオを扱います。
| 章 | 構築するもの | レイヤー | 公開範囲 | 主な用途 |
|---|---|---|---|---|
| 第2章 | パススルー ネットワークLB | L4 | 外部(インターネット向け) | IP/ポート単位の高速振り分け |
| 第3章 | アプリケーション ロードバランサ | L7 | 外部(グローバル) | URL/ヘッダー単位のHTTP振り分け |
| 第4章 | 内部パススルー ネットワークLB | L4 | 内部(VPC内のみ) | 社内・サービス間通信 |
| 第5章 | チャレンジ(総合演習) | L4 L7 | 外部 | 学んだ内容の実践 |
事前準備(全シナリオ共通)
1.1 用語の整理
Google Cloud のロードバランサは 2系統 × 2方式 に分類されます。 最初にこの軸を押さえると全体が一気に見通せます。核心はL4 は IP・ポートで扱い中身を見ないのに対し、L7 は HTTP(S) を解釈し URL・ヘッダー・Cookie で判断できるという違いです。
| アプリケーションLB(L7) | ネットワークLB(L4) | |
|---|---|---|
| 判断材料 | URL・ヘッダー・Cookie・コンテンツ | IPアドレス・プロトコル・ポート |
| 中身を見るか | 見る(HTTP/HTTPSを解釈) | 見ない(パケットをそのまま転送) |
| 方式 | プロキシ型のみ | プロキシ型 / パススルー型 |
プロキシ型はクライアント接続を LB 側で一旦終端し、新しい接続をバックエンドへ張り直します。 一方パススルー型は接続を終端せず、送信元・宛先・ポートを変えずに VM へ届け、 応答は LB を経由せずクライアントへ直接戻ります(DSR = ダイレクトサーバーリターン)。 クライアントの送信元 IP を保持したい場合はパススルー型が向いています。
出典: ロードバランサのリソースモデル1.2 共通セットアップの流れ
1.3 リージョンとゾーンの設定
すべてのシナリオは、まずデフォルトのリージョン(地域)とゾーン(地域内の区画)の設定から始めます。
# デフォルトのリージョンを設定(例: us-central1)gcloud config set compute/region REGION# デフォルトのゾーンを設定(例: us-central1-a)gcloud config set compute/zone ZONE
Cloud Shell では設定がセッションをまたいで保持されません。再接続のたびにgcloud config set を実行する必要があります(自分のPCの gcloud では永続化されます)。
外部パススルー ネットワークLB L4
2.1 何を作るのか
3台の Web サーバー(VM)の前段に L4 ロードバランサを置き、インターネットからのアクセスを3台に振り分けます。
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 全部」に一括適用できます。
# 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 は VM 起動時に自動実行されるスクリプトです。 ここで Apache をインストールし、どのサーバーが応答したか分かるようホスト名入りページを置いています。
ステップ2: ファイアウォールルールで HTTP を許可
gcloud compute firewall-rules create www-firewall-network-lb \ --target-tags network-lb-tag --allow tcp:80ステップ3: 動作確認
# 各VMの外部IPを確認gcloud compute instances list # curl で各VMに直接アクセスして応答を確認curl http://[IP_ADDRESS]ステップ4: ロードバランシングサービスの構成
# 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: トラフィックを流して確認
# 転送ルールの外部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 になるのを待つのがコツです。
外部アプリケーション ロードバランサ L7
3.1 何を作るのか
第2章との最大の違いは、マネージドインスタンスグループ(MIG) とグローバル配信 を使う点です。
3.2 なぜグローバルなのか
アプリケーションロードバランシングは Google Front End(GFE)上に実装され、 GFE は世界中に分散して Google のグローバルネットワークと制御プレーンで連携します。 リクエストは原則としてユーザーに最も近いインスタンスグループへルーティングされ、 空きが足りなければ次に近い空きのあるグループへ送られます。
出典: Cloud Load Balancing 製品ページ3.3 コンポーネントの役割
| コンポーネント | 役割 |
|---|---|
| インスタンステンプレート | VM の「設計図」(マシンタイプ・イメージ・起動スクリプト) |
| マネージドインスタンスグループ(MIG) | テンプレートから同一 VM を複製。オートスケール・自動修復が可能 |
| バックエンドサービス | トラフィックの分配方法を定義(ヘルスチェック含む) |
| URLマップ | URL に応じてどのバックエンドへ送るかのルーティング表 |
| ターゲットHTTPプロキシ | URL マップに従ってリクエストを処理 |
| グローバル転送ルール | グローバル外部 IP でリクエストを受け付ける入り口 |
マネージドインスタンスグループは、オートスケーリング・自動修復(autohealing)・複数ゾーン展開・自動アップデートといった機能で、ワークロードをスケーラブルかつ高可用にします。
3.4 ステップバイステップ
# 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=80130.211.0.0/22 と 35.191.0.0/16 はGoogle のヘルスチェックシステムの送信元 IP です。 このレンジからのトラフィックを許可しないと、ヘルスチェックが失敗して VM が「不健全」と判定され、トラフィックが流れません。
3.5 動作確認
コンソールの「ロードバランシング」から web-map-http を開き、バックエンドの VM がHealthy になっているのを確認してから、ブラウザで http://[IP_ADDRESS]/ にアクセスします。
反映には 3〜5分かかることがあります。Page served from: lb-backend-group-xxxx のように VM 名が表示されれば成功です。
内部パススルー ネットワークLB 内部 L4
4.1 何を作るのか
これまでと違い、インターネットに公開しない内部専用の LB です。よくある2層アーキテクチャを構築します。
- Web ティア(公開): ユーザー向け Web サーバー
- 内部サービスティア(非公開): 素数計算サービス(複数台に分散)
ラボ本文では「内部アプリケーションロードバランサ」と表現されますが、実際の gcloud は--load-balancing-scheme internal と --protocol tcp、L4 バックエンドサービスを使っており、 技術的には内部パススルー ネットワークLB(L4)を構築しています。 内部パススルー NLB は、同一リージョン内の内部 VM にトラフィックを分散し、 同じ VPC ネットワーク内(または接続されたネットワーク)からのみアクセス可能な内部 IP の背後でサービスを運用・スケールします。
4.2 内部LBの3つの構成要素
| コンポーネント | 役割 |
|---|---|
| 転送ルール | 他の内部サービスがリクエストを送るプライベート IP アドレス |
| バックエンドサービス | VM への分配方法を定義(ヘルスチェックを含む) |
| ヘルスチェック | バックエンド VM の健全性を継続的に監視 |
4.3 ステップバイステップ(要点)
# ── バックエンド(素数計算サービス)の準備 ── # 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 します。
# テスト用VMを作成してSSHgcloud compute instances create testinstance \ --machine-type=e2-standard-2 --zone ZONEgcloud compute ssh testinstance --zone ZONE # VM内部から内部LBへ(2と5はTrue=素数、4はFalse)curl IP/2 # Truecurl IP/4 # Falsecurl IP/5 # True2 と 5 が素数(True)、4 が非素数(False)と正しく返れば、内部 LB がバックエンドに正常に振り分けられている証拠です。 確認後は testinstance を削除しておきましょう。
総合演習 — チャレンジラボの攻略方針
チャレンジラボは手順書がなく、学んだスキルを応用して自力で解く形式です。第2〜4章の知識を組み合わせます。
5.1 タスク分解と対応表
| タスク | 参照する章 | 必須リソース名 |
|---|---|---|
| 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/22 と 35.191.0.0/16 を FW で許可したか確認 |
| すぐ反映されない | L7 は 3〜5分、VM の healthy 化に 30秒程度待つ |
| エラーが出る | エラーメッセージを読んで調べるのも採点対象のスキル |
ロードバランサ選定の早見チャート
HTTP(S) トラフィックのアプリには L7 のアプリケーションLBを、 TLS オフロード(プロキシ型)や TCP/UDP/ESP/GRE/ICMP などの IP プロトコルが必要な場合はL4 のネットワークLBを選びます。 クライアントの送信元 IP を保持したい・プロキシのオーバーヘッドを避けたい・UDP/ESP/ICMP などに対応したい場合はパススルー型を選びます。
出典: ロードバランサの選び方ベストプラクティス総まとめ
| 観点 | ベストプラクティス |
|---|---|
| ヘルスチェック | 必ず設定し、130.211.0.0/22・35.191.0.0/16 を FW で許可する |
| タグ設計 | VM にタグを付け、FW ルールをタグ単位で一括管理する |
| 最小公開 | 内部サービスは --no-address で公開 IP を持たせない |
| 命名規則 | リソース名は一貫したルールで(チャレンジでは指定厳守) |
| 静的IP | 外部公開用は静的 IP を予約し、変動を防ぐ |
| スケール | 本番は MIG + オートスケーリングで弾力性を確保 |
| リージョン整合 | L4 はリージョナル。全コンポーネントを同一リージョンに揃える |
| 反映待ち | 構築直後は数分待ってからテストする |
参考ソース(公式ドキュメント)
| トピック | 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)ロードバランサ」は「アプリケーションロードバランサ」に整理されています。 ラボ教材によっては旧称が残っている場合があるため、公式ドキュメントの最新表記を基準にすると混乱しません。