ロードバランサ

ひと目で使い分け

Google Cloud では、AWS（ALB/NLB/GWLB）や Azure（Load Balancer/Application Gateway/Front Door）のように別々の製品に分かれているのではなく、Cloud Load Balancing という単一プロダクトの中で「種類（type）」を切り替えるのが最大の特徴です。まず レイヤ（L7 か L4 か）、次に スコープ（グローバルかリージョンか）、そして 外部向けか内部向けかの 3 軸で当たりをつけます。

やりたいこと	選ぶ種類
HTTP/HTTPS をパス・ホストで振り分け（外部公開）	外部アプリケーション LB（L7）
世界中へ単一 IP でグローバル配信＋エッジ終端	グローバル外部アプリケーション LB（L7）
TCP/SSL を超低遅延でプロキシ分散	外部プロキシネットワーク LB（L4）
TCP/UDP を送信元 IP 保持のまま分散	外部パススルーネットワーク LB（L4）
VPC 内部のみで L7 振り分け	内部アプリケーション LB（L7）
VPC 内部のみで L4 を低遅延分散	内部パススルーネットワーク LB（L4）
DNS レベルでリージョン間を振り分け	Cloud DNS（ルーティングポリシー）

まず L7 か L4 か（アプリケーション LB とネットワーク LB）

最初の分岐はレイヤです。HTTP の中身（URL/ホスト/ヘッダ）でルーティングしたい・TLS 終端や Cloud CDN・Cloud Armor を使いたいなら アプリケーション LB（L7）。TCP/UDP をそのまま速く流したいなら ネットワーク LB（L4） です。

観点	アプリケーション LB (L7)	ネットワーク LB (L4)
レイヤ	L7 (HTTP/HTTPS/HTTP2/gRPC)	L4 (TCP/UDP/SSL)
方式	リバースプロキシ（中身を解釈）	プロキシ型またはパススルー型
ルーティング	URL マップでパス/ホスト/ヘッダ/クエリ	5タプル等のハッシュで転送
TLS 終端	可（LB で HTTPS を終端）	プロキシ型のみ可（パススルーは不可）
Cloud CDN	可（バックエンドで --enable-cdn）	不可
Cloud Armor (WAF)	可（バックエンドサービスに紐付け）	ネットワークエッジセキュリティポリシー（L3/L4 防御）のみ
送信元 IP の保持	不可（GFE の IP に置換）	パススルー型は保持／プロキシ型は置換
設定単位	転送ルール+ターゲットプロキシ+URL マップ+バックエンドサービス	転送ルール+ターゲットプール／バックエンドサービス

L4 の中の選択（プロキシ型とパススルー型）

ネットワーク LB（L4）はさらに プロキシ型 と パススルー型 に分かれます。送信元 IP を保持したいか／TLS を LB で終端したいかで決まります。

観点	プロキシネットワーク LB	パススルーネットワーク LB
接続の扱い	GFE/Envoy で終端し新規接続を張り直す	接続をそのままバックエンドへ転送
内部実装	Google Front End / Envoy プロキシ	Maglev（一貫性ハッシュ）
送信元 IP	LB の IP に置換される	クライアントの IP を保持
TLS/SSL 終端	可（SSL プロキシ）	不可（中身に触れない）
対応プロトコル	TCP / SSL(TLS)	TCP / UDP / その他 IP プロトコル
典型用途	グローバルな TCP 分散・SSL オフロード	送信元 IP 必須・超低遅延・非 HTTP

スコープの選択（グローバルとリージョン）

Google の強みは 単一 Anycast IP でのグローバル分散です。アプリケーション LB と外部プロキシネットワーク LB はグローバル展開でき、最寄りの Google エッジ（GFE）でリクエストを受けて最適なリージョンへ振り分けます。一方、パススルーネットワーク LB はリージョン単位です。

観点	グローバル（外部アプリ/プロキシ LB）	リージョン（パススルー/リージョン LB）
IP の性質	単一の Anycast IP で世界中から受信	リージョン内の IP（外部/内部）
受信点	最寄りの GFE（Google Front End）	対象リージョンの LB
フェイルオーバー	リージョン障害時に別リージョンへ自動オーバーフロー	リージョン内のバックエンド間
バックエンド配置	複数リージョンの MIG/NEG を束ねられる	原則同一リージョン
代表ユースケース	全世界向け Web/API、グローバル冗長	特定リージョンの内部システム/低遅延

バックエンドに置けるもの

どの種類でも振り分け先は バックエンドサービス（または外部 IP 向けのターゲットプール） に束ねます。ここに何を置けるかで構成が決まります。

バックエンドの種類	中身	代表的な使いどころ
インスタンスグループ（MIG）	Compute Engine の VM 群（自動スケール）	VM ベースの Web/アプリ層
ゾーン NEG	VM 内の IP:ポート（コンテナ等）	GKE の Pod を直接バックエンドに
サーバーレス NEG	Cloud Run / App Engine / Cloud Functions	サーバーレスを同じ LB/ドメイン配下に統合
インターネット NEG	外部 FQDN/IP のオリジン	オンプレや他クラウドをオリジンに
バックエンドバケット	Cloud Storage バケット	静的アセットを Cloud CDN で配信

選び方

Web/API を URL・ホストで振り分け、TLS 終端、グローバル冗長 → グローバル外部アプリケーション LB（L7）
L7 ＋ SQLi/XSS など Web 攻撃の防御も一体で → 上記＋ Cloud Armor を前段に付与
静的サイト／メディアを高速・安価に配信 → 外部アプリ LB ＋ バックエンドバケット＋ Cloud CDN
Cloud Run / App Engine / Cloud Functions を共通ドメイン・WAF 配下に → 外部アプリ LB ＋ サーバーレス NEG
TCP/SSL をグローバルに分散・SSL オフロード → 外部プロキシネットワーク LB（L4）
送信元 IP の保持・UDP・非 HTTP・超低遅延 → 外部パススルーネットワーク LB（L4）
VPC 内部だけで振り分け（外に出さない） → 内部アプリケーション LB（L7）／内部パススルーネットワーク LB（L4）
DNS レベルでリージョン間フェイルオーバー／最寄り誘導（プロキシ不要） → Cloud DNS のルーティングポリシー
API の認証・流量制限・変換まで欲しい（LB ではなく API ゲートウェイ） → API Gateway

多層で組み合わせるのが定石

1 つに絞る必要はありません。インターネット → グローバル外部アプリ LB（L7 / Cloud CDN / Cloud Armor）→ MIG またはサーバーレス NEG → 内部 LB（L4）→ DB 層のように重ねるのが大規模構成の王道。グローバルな振り分けだけ DNS で十分なら、前段を Cloud DNS のルーティングポリシーに置き換える手もあります。

L4 と L7 を取り違えない

TCP/UDP・送信元 IP 保持・超低遅延・非 HTTP ＝パススルーネットワーク LB（L4）、URL/ホストルーティング・TLS 終端・Cloud CDN・Cloud Armor ＝アプリケーション LB（L7）。HTTP の中身でルーティングしたいのに L4 を選ぶ、あるいは単なる TCP 分散に L7 プロキシを使ってオーバーヘッドを背負う、というミスマッチが頻出です。パススルー型は中身に触れないため TLS 終端も WAF もできない点も要注意。

試験・面接のひっかけ

Google Cloud の LB は 製品が分かれているのではなく「種類」で切り替える。AWS の ALB/NLB/GWLB、Azure の Load Balancer/Application Gateway/Front Door が、ここでは 1 製品の型違いに対応する
グローバル LB は単一 Anycast IP。リージョンごとに別 IP を用意する必要はなく、プレウォーミング（暖機）も不要で急増に即応する
Cloud CDN は独立サービスではなく、外部アプリケーション LB のバックエンドに --enable-cdn で付ける機能
WAF（Cloud Armor）はアプリケーション LB（L7）にのみフル機能で紐付く。パススルーネットワーク LB ではエッジでの L3/L4 防御が中心
TLS 終端はアプリケーション LB か SSL プロキシ。パススルーネットワーク LB では終端できない
送信元 IP を保持したいならパススルー型（プロキシ型・アプリ型は GFE の IP に置き換わるので X-Forwarded-For を見る）

アンチパターン