Google Cloud のコンソールでロードバランサを作ろうとすると、アプリケーション ロードバランサとネットワーク ロードバランサという2つの選択肢が出てきます。一方で gcloud のサブコマンドには target-http-proxies や target-tcp-proxies が並んでいて、その名前はどこにも出てきません。検索して出てくる記事には HTTP(S) 負荷分散と書いてあります。
3つの語彙が同時に流通しているためで、原因ははっきりしています。2023年6月にコンソールとドキュメントの名前が変わり、API は変わらなかったからです。
名前の対応さえ持っておけば、どの語彙で書かれた情報でも同じ場所に着地できます。対応表を作ります。
2023年6月の改名
公式のリリースノートに、この日の告知が残っています。
We're announcing the rebranding of Cloud Load Balancing into two main types of load balancers: Application Load Balancers and Network Load Balancers.
（Cloud Load Balancing リリースノート 2023年6月21日）
同じエントリの最後の一文が、現在の混乱の元です。
The Google Cloud Console has also been updated to reflect these changes. No changes have been made to the API.
コンソールは新しい名前になり、API は変わっていません。ドキュメントも新しい名前に書き換えられたので、既存の構成を触っているだけの人にとっては、ある日から読み物だけが別言語になった状態です。Terraform のリソース名も、gcloud のフラグも、そのまま動き続けています。
旧名は現行ドキュメントからは消えています。ただしリリースノートは過去のエントリを書き換えないので、2023年6月21日より前まで遡ると旧名がそのまま読めます。2023年4月14日のエントリには「Internal HTTP(S) Load Balancing」、2022年6月6日のエントリには「External TCP/UDP Network Load Balancing」と書かれています。改名前後で同じ製品を追いたいときは、ここを時系列で読むのが確実です。
新しい名前の読み方
新しい名前は、いくつかの軸の組み合わせでできています。順に当てはめると、名前から性質が読めます。
- アプリケーションかネットワークか。L7（HTTP/HTTPS）を見るのがアプリケーション、L4（TCP/UDP など）を見るのがネットワーク
- ネットワークの場合、プロキシかパススルーか。プロキシは接続を終端して張り直す。パススルーは終端せず、パケットの送信元 IP を保ったままバックエンドに届ける
- 外部か内部か。インターネットから受けるか、VPC の中から受けるか
- スコープ。グローバル、リージョン、クロスリージョン、従来（classic）
公式の分類表がこうなっています。
| 外部 | 内部 | |
|---|---|---|
| アプリケーション ロードバランサ（L7） | グローバル外部、リージョン外部、従来 | クロスリージョン内部、リージョン内部 |
| プロキシ ネットワーク ロードバランサ（L4） | グローバル外部、リージョン外部、従来 | クロスリージョン内部、リージョン内部 |
| パススルー ネットワーク ロードバランサ（L4） | グローバル外部（プレビュー）、リージョン外部 | リージョン内部 |
パススルーだけ内部がリージョン内部の1つしかありません。パケットを終端せずにバックエンドへ渡す方式なので、リージョンをまたいだ配置と相性が悪い、と理解しておくと覚えやすいです。
旧名との対応
改名で変わったのは呼び方だけで、機能が入れ替わったわけではありません。公式に一枚の対応表があるわけではないので、リリースノートの記述と現行ドキュメントの分類を突き合わせて作ったものを載せます。
| 旧名 | 新名 |
|---|---|
| 外部 HTTP(S) 負荷分散（グローバル） | グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ |
| 外部 HTTP(S) 負荷分散（リージョン） | リージョン外部アプリケーション ロードバランサ |
| 内部 HTTP(S) 負荷分散 | リージョン内部アプリケーション ロードバランサ |
| SSL プロキシ負荷分散、TCP プロキシ負荷分散 | 外部プロキシ ネットワーク ロードバランサ（従来、グローバル、リージョン） |
| 内部 TCP プロキシ負荷分散 | リージョン内部プロキシ ネットワーク ロードバランサ |
| 外部 TCP/UDP ネットワーク負荷分散 | 外部パススルー ネットワーク ロードバランサ |
| 内部 TCP/UDP 負荷分散 | 内部パススルー ネットワーク ロードバランサ |
1行目が2つに分かれているのは、改名とは別に実装の系統が分かれたためです。従来のものは Google Front End の上で動き、新しいグローバル外部アプリケーション ロードバランサは Envoy ベースの GFE の上で動きます。コンソールの表示も分かれます。
プロキシ ネットワーク ロードバランサの行も同じ事情で、2023年9月29日にグローバル版が追加されたときのリリースノートに、既存のものがどう表示されるようになるかが書かれています。
Load balancers that are already deployed in the classic mode are renamed as classic Proxy Network Load Balancer in the console.
改名は一度で終わったわけではなく、新しいモードが増えるたびに既存のものへ「従来（classic）」という名前が付き直しています。SSL プロキシと TCP プロキシが1つの名前に統合されたのも、扱うプロトコルの違いが target-ssl-proxies と target-tcp-proxies というリソースの違いに落ちていて、ロードバランサとしては同じものだからです。
API は変わっていない
ここが実務で一番使える部分です。名前が変わっていない層、つまり API を軸に置けば、どの語彙で書かれた情報でも同じ場所に着地します。
軸になるのはバックエンドサービスと転送ルールが持つ --load-balancing-scheme です。gcloud のリファレンスに、値とロードバランサの対応がそのまま書かれています。
Choose EXTERNAL for the classic Application Load Balancers, the external passthrough Network Load Balancers, and the global external proxy Network Load Balancers. Choose EXTERNAL_MANAGED for the Envoy-based global and regional external Application Load Balancers, and the regional external proxy Network Load Balancers. Choose INTERNAL for the internal passthrough Network Load Balancers. Choose INTERNAL_MANAGED for Envoy-based internal load balancers such as the internal Application Load Balancers and the internal proxy Network Load Balancers.
（gcloud compute backend-services create）
整理するとこうです。
| 値 | 対応するロードバランサ |
|---|---|
EXTERNAL |
従来のアプリケーション ロードバランサ、外部パススルー ネットワーク ロードバランサ、グローバル外部プロキシ ネットワーク ロードバランサ |
EXTERNAL_MANAGED |
Envoy ベースのグローバル外部・リージョン外部アプリケーション ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ |
INTERNAL |
内部パススルー ネットワーク ロードバランサ |
INTERNAL_MANAGED |
内部アプリケーション ロードバランサ、内部プロキシ ネットワーク ロードバランサ |
INTERNAL_SELF_MANAGED |
Traffic Director |
MANAGED が付くかどうかが、GFE か Envoy かの境目になっています。公式ドキュメントも、この語が「GFE か Envoy プロキシのマネージドサービスとして実装されている」という意味だと注記しています。名前の見た目からは想像しにくい対応ですが、覚えてしまえばスキーム名だけで実装が分かります。
なお、ドキュメントの一覧表にはプレビューのグローバル外部パススルー ネットワーク ロードバランサに EXTERNAL_PASSTHROUGH という値が載っています。ただし gcloud compute backend-services create の --load-balancing-scheme が受け付ける値は上の5つで、EXTERNAL_PASSTHROUGH は入っていません。
移行に関わる非対称もあります。
It is possible to attach EXTERNAL_MANAGED backend services to EXTERNAL forwarding rules. However, EXTERNAL backend services cannot be attached to EXTERNAL_MANAGED forwarding rules.
EXTERNAL_MANAGED のバックエンドサービスは EXTERNAL の転送ルールに付けられますが、逆はできません。従来のものから移行するときは、この向きの制約が段取りを決めます。
部品の並びも変わっていない
名前が変わっても、組み立てる部品とその順番は同じです。アプリケーション ロードバランサなら、リクエストはこの順に流れます。
- 転送ルール（
forwarding-rules）が、フロントエンドの IP アドレスとポートを受ける - 転送ルールがターゲットプロキシ（
target-http-proxiesまたはtarget-https-proxies）に渡す - ターゲットプロキシが URL マップ（
url-maps）のルールを見て、どのバックエンドサービスに送るかを決める - バックエンドサービス（
backend-services）が、インスタンスグループや NEG に振り分ける
パススルー ネットワーク ロードバランサはプロキシを持たないので、2と3がありません。転送ルールがバックエンドサービスを直接指します（古い構成では、バックエンドサービスの代わりにターゲットプールを指しているものもあります。新規はバックエンドサービスが推奨です）。
旧名で書かれた手順書がそのまま動くのはこのためです。名前が変わったのは製品の呼び方であって、リソースの型ではありません。
実装技術から見ると分類が腑に落ちる
公式ドキュメントには、どのロードバランサが何の上で動いているかの表もあります。
| ロードバランサ | 実装 |
|---|---|
| グローバル外部アプリケーション ロードバランサ | Envoy ベースの GFE |
| 従来のアプリケーション ロードバランサ | GFE |
| リージョン外部、リージョン内部、クロスリージョン内部のアプリケーション ロードバランサ | Envoy |
| グローバル外部プロキシ ネットワーク ロードバランサ | Envoy ベースの GFE |
| 従来のプロキシ ネットワーク ロードバランサ | GFE |
| リージョン外部、リージョン内部、クロスリージョン内部のプロキシ ネットワーク ロードバランサ | Envoy |
| 外部パススルー ネットワーク ロードバランサ | Maglev |
| 内部パススルー ネットワーク ロードバランサ | Andromeda |
改名の告知にも、Envoy をデータプレーンとして揃えてきた流れが背景にあると書かれています。従来（classic）と呼ばれているものだけが GFE のまま残っていて、新しい機能はそちらには入りません。従来のものを使い続ける判断は、機能追加の対象から外れるという判断とセットになります。
パススルーの2つだけ系統が違い、Maglev と Andromeda の上で動きます。プロキシを介さないので、レスポンスはバックエンドからクライアントへ直接返ります（ダイレクトサーバーリターン）。送信元 IP が保たれるのも、そもそも書き換える中継点がいないためです。
引っかかりやすいところ
名前を覚えたうえで、実際に組むときに手が止まる箇所を3つ挙げます。
1つ目は、リージョン内部のロードバランサが既定では同一リージョンからしか受け付けないことです。公式の注記にこうあります。
By default, regional internal load balancers only allow traffic from clients in the same region as the load balancer. However, you can allow traffic from clients in other regions by enabling global access on the forwarding rule.
転送ルールでグローバルアクセスを有効にすると他リージョンのクライアントからも届きます。VPC はグローバルなので繋がるはずだ、という感覚で組むとここで止まります。名前にリージョンと入っているのはバックエンドの範囲の話で、クライアントの範囲は別の設定です。
2つ目はプロキシ専用サブネットです。Envoy で動くロードバランサの一部は、専用のサブネットを別に用意しないと作成できません。対象は次のとおりで、グローバル外部アプリケーション ロードバランサは含まれません（こちらは Envoy ベースの GFE 上で動くため、自分の VPC にプロキシを置きません）。
| 用途 | 必要とする製品 |
|---|---|
GLOBAL_MANAGED_PROXY |
クロスリージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ |
REGIONAL_MANAGED_PROXY |
リージョン外部・リージョン内部のアプリケーション ロードバランサ、リージョン外部・リージョン内部のプロキシ ネットワーク ロードバランサ、Secure Web Proxy |
同じ VPC の同じリージョンで、各用途につき有効にできるプロキシ専用サブネットは1つだけです。そのサブネットが、上の表の製品すべてを賄います。サイズは64アドレス以上（/26 以下のプレフィックス長）が必須で、公式は /23 から始めることを勧めています。転送ルールの IP アドレスもバックエンドの IP アドレスもここからは取られません。純粋に Envoy プロキシの置き場所です。
3つ目はネットワークティアです。従来のアプリケーション ロードバランサとプロキシ ネットワーク ロードバランサは、プレミアム ティアではグローバル、スタンダード ティアでは単一リージョンになります。公式の一覧表を見ると、ティアによってスコープが変わると書かれているのは従来のものだけです。
選び方
判断の順序はこうなります。
- HTTP/HTTPS を見て振り分けたいならアプリケーション ロードバランサ。それ以外のプロトコルや TLS のオフロードが要件ならネットワーク ロードバランサ
- ネットワーク ロードバランサなら、送信元 IP を保ちたい、UDP や ESP、GRE を通したい、直接サーバーリターンが欲しい、のいずれかに当てはまればパススルー。そうでなければプロキシ
- インターネットから受けるなら外部、VPC 内からなら内部
- バックエンドを複数リージョンに置くならグローバル（内部の場合はクロスリージョン）、単一リージョンでよければリージョン
新規に作るなら、従来（classic）を選ぶ理由はほとんどありません。公式も、グローバル外部アプリケーション ロードバランサでしか使えない新機能があるとして移行を勧めています。
まとめ
- 2023年6月21日にアプリケーション ロードバランサとネットワーク ロードバランサの2系統へ改名された。コンソールとドキュメントは新名、API は変更なし
- 旧名は現行ドキュメントから消えているが、リリースノートの当該日より前のエントリには残っている
- 名前は「アプリケーション/ネットワーク」「プロキシ/パススルー」「外部/内部」「グローバル・リージョン・クロスリージョン・従来」の組み合わせでできている
-
--load-balancing-schemeの5つの値を軸に置くと、新旧どちらの語彙からでも同じ場所に着地できる。MANAGEDが付くものは GFE か Envoy のマネージド実装 -
EXTERNAL_MANAGEDのバックエンドサービスはEXTERNALの転送ルールに付けられるが、逆はできない - リージョン内部のロードバランサは、既定では同一リージョンのクライアントからしか受け付けない。グローバルアクセスは転送ルールの設定
- Envoy が自分の VPC に立つもの（リージョン系とクロスリージョン内部）はプロキシ専用サブネットが必要。グローバル外部アプリケーション ロードバランサは不要
名前が分かりにくいのは、実装の系統が増えた順に名前を足してきた結果です。逆に言えば、名前から実装が読めるように整理された結果でもあります。スキーム名との対応まで押さえておくと、旧名で書かれた記事も現行ドキュメントも同じ地図の上で読めます。