Cloud Load Balancing

解決する課題

物理的なロードバランサ機器を調達・冗長化せずに、Google が運用するソフトウェア定義の負荷分散をすぐ利用できます。

• 1 つのバックエンドに集中させず負荷を分散したい
• 異常なインスタンスをヘルスチェックで自動的に切り離したい
• 複数リージョン・複数ゾーンに自動追従し、ユーザーに最も近いバックエンドへ振り分けたい
• 事前の暖機運転（プレウォーミング）なしに急激なトラフィック増に即応したい

主要概念と用語

• 転送ルール（Forwarding Rule）: 受信する IP アドレス・プロトコル・ポートを定義する入口。グローバル外部 IP か、リージョン内部 IP を割り当てる
• ターゲットプロキシ（Target Proxy）: L7（HTTP(S)）の場合に転送ルールと URL マップを結びつける。TLS 終端もここで行う
• URL マップ（URL Map）: パス／ホストベースのルーティング規則。AWS の ALB のリスナールールに相当
• バックエンドサービス（Backend Service）: 振り分け先のグループ、負荷分散方式、ヘルスチェック、セッションアフィニティ、Cloud CDN などを束ねる中核設定
• バックエンド: インスタンスグループ（MIG）またはネットワークエンドポイントグループ（NEG）。サーバーレス NEG で Cloud Run / App Engine / Cloud Functions も背後に置ける
• ヘルスチェック: 正常なバックエンドだけに振り分けるための監視（HTTP/HTTPS/HTTP2/TCP/SSL/gRPC）
• 負荷分散の種類: グローバル外部アプリケーション LB（L7）、グローバル外部プロキシ ネットワーク LB（L4 TCP/SSL）、外部パススルー ネットワーク LB（L4、送信元 IP を保持）、内部アプリケーション LB / 内部パススルー ネットワーク LB（VPC 内部向け）

仕様・制限・クォータ

• Anycast IP によるグローバル配信: グローバル外部アプリケーション LB は、世界中の Google エッジ（GFE: Google Front End）で単一の IP を受け、最寄りのバックエンドへルーティングする
• プレウォーミング不要: 事前申請なしに毎秒数百万リクエスト規模へスケールする（ELB のような暖機が要らない）
• TLS 終端: Google マネージド SSL 証明書、またはセルフマネージド証明書を証明書マネージャーで管理。ロードバランサ側で HTTPS を終端できる
• 対応プロトコル: HTTP/1.1、HTTP/2、HTTP/3（QUIC）、gRPC、WebSocket、TCP、UDP、SSL（TLS）
• プロジェクト/リージョンごとのクォータ: 転送ルール数、バックエンドサービス数などに上限があり、引き上げ申請が可能
• パススルー型（L4）は送信元 IP を保持して NAT せずにバックエンドへ届ける（プロキシ型は GFE の IP に置き換わる）

内部の仕組み

グローバル外部アプリケーション LB は、Google のエッジに分散配置された GFE（Google Front End） がリクエストを受け付けます。ユーザーは Anycast IP に接続すると、BGP によりネットワーク的に最も近い GFE に到達します。GFE は URL マップに従ってルーティング先のバックエンドサービスを決め、ヘルスチェックを通過した正常なバックエンドだけにリクエストを転送します。

• バックエンドの選択は、各リージョンの容量・使用率・レイテンシを考慮して行われ、最寄りリージョンが過負荷なら自動的に**別リージョンへ自動でオーバーフロー（フェイルオーバー）**する
• TLS はエッジ（GFE）で終端され、GFE からバックエンドまでは Google の内部バックボーンを経由するため、ユーザー〜エッジ間の RTT が短縮される
• パススルー ネットワーク LB（L4）はプロキシを介さず、Maglev（Google のソフトウェアロードバランサ）が一貫性ハッシュで接続を分散し、送信元 IP を保持したまま転送する

設計パターン / ベストプラクティス

• グローバル外部アプリケーション LB + マネージドインスタンスグループ（MIG）+ 複数リージョンが王道。MIG の自動スケーリングと組み合わせ、容量に応じた分散を任せる
• HTTPS はロードバランサで終端し、Google マネージド SSL 証明書で更新を自動化する（背後は HTTP でも可）
• Cloud Armor を前段に付与して L7 の WAF・DDoS 防御・IP 許可リストを適用する
• Cloud CDN を有効化して静的コンテンツをエッジでキャッシュし、オリジン負荷とレイテンシを下げる
• サーバーレス NEG を使えば Cloud Run / App Engine / Cloud Functions を同じ LB の背後に統合し、共通の証明書・ドメイン・WAF を適用できる
• ヘルスチェックのパス・閾値・間隔を適切に設定し、誤検知での切り離しを避ける

運用・監視

• Cloud Monitoring でメトリクス（https/request_count、https/backend_latencies、https/request_bytes_count など）とバックエンドのヘルス状態を監視
• Cloud Logging でロードバランサのリクエストログを有効化し、レスポンスコード・レイテンシ・クライアント情報を分析
• 5xx / レイテンシ急増はバックエンドの過負荷やヘルスチェック設定、容量（最大 RPS/使用率）の上限を確認
• Network Topology / Performance Dashboard でトラフィック経路とリージョン間の偏りを可視化

コスト

課金は「ロードバランサの時間課金（転送ルール数に応じた基本料金）」＋「処理データ量（アウトバウンド/インバウンド）」が基本です。Cloud CDN や Cloud Armor は別課金になります。

セキュリティ

• TLS をロードバランサで終端し、最新の SSL ポリシー（TLS バージョン/暗号スイートのプロファイル: MODERN / RESTRICTED など） を適用する
• Cloud Armor を L7 LB に紐付け、WAF ルール（OWASP プリセット）・レート制限・地理ベースのアクセス制御・DDoS 防御を実施
• IAP（Identity-Aware Proxy） をロードバランサ前段で有効化すると、アプリ改修なしに ID ベースのアクセス制御を追加できる
• 内部向けには内部アプリケーション LB / 内部パススルー ネットワーク LBを使い、VPC とファイアウォールルールで受信を制御する

関連サービス・比較（AWS との対応）

Cloud Load Balancing は単一プロダクトの中で L7/L4・外部/内部を「種類」で切り替えます。AWS では ALB / NLB / GWLB という別タイプとして提供される点が対応関係の要です。

ハンズオン / CLI例

# 1. ヘルスチェックを作成（HTTP /healthz を監視）
gcloud compute health-checks create http web-hc \
  --port=80 --request-path=/healthz

# 2. バックエンドサービスを作成（グローバル/外部・HTTP）
gcloud compute backend-services create web-backend \
  --protocol=HTTP --port-name=http \
  --health-checks=web-hc --global

# 3. マネージドインスタンスグループをバックエンドに追加
gcloud compute backend-services add-backend web-backend \
  --instance-group=web-mig \
  --instance-group-zone=asia-northeast1-a --global

# 4. URL マップ（既定の振り分け先）を作成
gcloud compute url-maps create web-map \
  --default-service=web-backend

# 5. ターゲット HTTP プロキシ + グローバル転送ルール（入口の IP/ポート）
gcloud compute target-http-proxies create web-proxy --url-map=web-map
gcloud compute forwarding-rules create web-fr \
  --target-http-proxy=web-proxy --global --ports=80