G-gen の杉村です。 Google Cloud (旧称 GCP) の強力なネットワークインフラサービスである External Application Load Balancer (外部アプリケーションロードバランサ) について解説します。

サービスの概要
ユースケース
料金
- Cloud Load Balancing の料金体系
- 計算例
  - 計算条件
  - 計算式
ロードバランサーの選び方
External Application Load Balancer の機能
External Application Load Balancer の内部構成（アーキテクチャ）
高度なアーキテクチャ
- VPC・プロジェクトをまたぐ負荷分散
- グローバルな可用性

サービスの概要

Cloud Load Balancing とは

Cloud Load Balancing とは Google Cloud が提供する仮想的なロードバランサです。

クライアントからのリクエストを受け、背後にある複数の Compute Engine VM や Cloud Storage バケット等にトラフィックを負荷分散 (ロードバランス) します。

Cloud Load Balancing は仮想的・論理的な存在であり、分散型アーキテクチャです。またフルマネージドサービスでもあります。そのため、我々利用者はインフラを考慮・管理する必要がありません。

毎秒 100 万件以上のリクエストに対応でき、安定した高パフォーマンス・低レイテンシが提供されます。

またスケーリングも自動的に行われます。トラフィックがゼロの状態から例え急激なスパイクが発生しても対応できます。プレウォーミング (暖機運転) も必要ありません。

ロードバランサーの種類

Cloud Load Balancing には9種類の用途別のロードバランサーが用意されており、適切なものを選択して利用することになります。

Global external Application Load Balancer
Global external Application Load Balancer (Classic)
Regional external Application Load Balancer
Regional internal Application Load Balancer
Global external proxy Network Load Balancer
Regional external proxy Network Load Balancer
Regional internal proxy Network Load Balancer
Regional external passthrough Network Load Balancer
Regional internal passthrough Network Load Balancer

種類が多く難しいようですが「Global か Regional か」「External か Internal か」「Application か Network か (プロトコル)」「プロキシ型かパススルー型か」といった軸で別れています。

名称変更

Cloud Load Balancing は 2023/06/21 にリブランディングが行われ、旧名称から変更されました。

これまで10種類だったロードバランサは9種類に統合され HTTP(S) トラフィックを扱う Application Load Balancer とその他の TCP/UDP トラフィックを扱う Network Load Balancer に大別できるようになりました。

なお当記事で扱う External Application Load Balancer は、従来でいう External HTTP(S) Load Balancing に当たります。

External Application Load Balancer とは

9 種類のロードバランサーのうち、当記事では以下の 3 つを総称して External Application Load Balancer (外部アプリケーションロードバランサ) として解説します。

Global external Application Load Balancer
Global external Application Load Balancer (Classic)
Regional external Application Load Balancer

External Application Load Balancer は「外部向け (External)」の「HTTP(S) プロトコル」用ロードバランサの総称です。パブリック IP アドレスを持っており インターネットからのリクエスト を受け付けます。これが「外部 (External)」の意味です。

また External Application Load Balancer は「プロキシ型」であり TCP コネクションをいったんロードバランサーで終端します。

その後、再度バックエンドの VM 等に TCP コネクションを作成します。そのため、バックエンドから見ると接続元 IP アドレスはロードバランサになります。

また「レイヤ 7」ロードバランサーであり、対応しているプロトコルは HTTP / HTTPS です。使える TCP ポート番号は 80/8080 (HTTP) と 443 (HTTPS) のみであり、その他のプロトコルやポート番号を使いたい場合は別のロードバランサを選択します。

3 種類の External Application Load Balancer

当記事で取り上げる以下の 3 種類のロードバランサーの違いについて説明します。

Global external Application Load Balancer
Global external Application Load Balancer (Classic)
Regional external Application Load Balancer

1. Global external Application Load Balancer と 2. Global external Application Load Balancer (Classic) は新型・旧型の関係であり、細かい違いがあるものの基本的には同じ理解が適用できます。

1. Global external Application Load Balancer と 3. Regional external Application Load Balancer の違いは、Global か Regional かです。

Global は、複数のリージョン (世界中) にフロントエンドが分散しています。世界中のユーザーは、自動的に最も近いフロントエンドにルーティングされ、最適なネットワーク経路を辿ってバックエンドまで到達できます (プレミアムティアの場合。後述) 。

Regional は、特定のリージョンにのみフロントエンドを配置します。バックエンドが同一のリージョン内に存在するためスタンダードティアネットワークを使って料金を抑えたい (後述) 場合や、法令遵守のためにトラフィックを特定のリージョンに留めたい場合に用います。

ユースケース

External Application Load Balancer が活躍する最も代表的なケースは以下のような、Web/AP サーバへのリクエストの振り分けです。

ロードバランサの配下の Compute Engine VM は インスタンスグループ でまとめられており、オートスケーリングを設定することもできます。この場合、負荷状況に応じてインスタンスが増減し、自動的にロードバランサーがトラフィックを振り分けます。

その他にも複雑なユースケースが考えられます。以下の参考ドキュメントもご参照ください。

参考 : 外部アプリケーションロードバランサのユースケース

料金

Cloud Load Balancing の料金体系

Cloud Load Balancing の料金は「 内部 (Internal) の Application Load Balancer」と「それ以外」で料金体系が異なります。当記事でご紹介しているのは 3 つとも Application Load Balancer ですので、同じ料金の計算方法が適用できます。

Application Load Balancer の料金には以下の軸があります。

転送ルール数 × 利用時間の従量課金
内向き (Inbound = Ingress) のデータ処理量 (GB) に応じた従量課金
外向き (Outbound = Egress) のデータ処理量 (GB) に応じた従量課金

1つ目の料金軸の 転送ルール (Forwarding rules) については後述しますが、簡単に言うとロードバランサーの「入り口」です。転送ルールの料金はロードバランサを構築後、存在し続けている限り発生すると考えればよいでしょう。

計算例

計算条件

大まかな料金のイメージを掴むために実際の例で計算してみます。

以下のような構成のロードバランサーの料金を試算してみます。

課金軸	数量
転送ルール	HTTPS (443/tcp) / Premium tier
内向きトラフィック	1 KB のリクエストが 1000 万回 / 月 ≒ 10 GB
外向きトラフィック	0.1 MB のレスポンスが 1000 万回 / 月 ≒ 1,000 GB

計算式

記載の単価は2023年6月現在の Global external Application Load Balancer・東京リージョンのものです。最新の料金や詳細は必ず公式の料金表をご参照ください。

課金軸	計算式	計
転送ルール ( ※ )	$0.025 * 730h	$18.25 /月
内向きトラフィック	$0.012 * 10 GB	$0.12 /月
外向きトラフィック	$0.012 * 100 GB	$1.2 /月
合計	$18.25 + $0.12 + $1.2	$19.57 / 月

※ 最初の5ルールまでの範囲内とする

なお、上記はロードバランサだけの料金であり、これに加えて Google Cloud のネットワーク外向き (Outbound = Egress) の転送料金が発生することに注意が必要です。上記の例では $0.14 * 100 GB で $14 となります。

ロードバランサーの選び方

9 種類からの選択

9 種類あるロードバランサーから適切な選択をするには、以下のドキュメントを参照します。

参考 : ロードバランサの選択

以下は同ドキュメントから引用したフローチャート図です。このドキュメントと図に沿って適切なロードバランサーを選択するのが基本的な考え方になります。

当記事で取り上げる External Application Load Balancer は「バックエンドのサービスが提供するプロトコルが HTTP(S) である場合」に選択するロードバランサですので、最も利用機会が多いものとなります。

次に 3 つの External Application Load Balancer の中からどのように適切なロードバランサを選択するか、について解説します。

Global vs Regional

3種類ある External な Application Load Balancer は、以下のうち前者の2つが Global で、最後が Regional です。

Global external Application Load Balancer
Global external Application Load Balancer (Classic)
Regional external Application Load Balancer

以下の全てに当てはまる場合は Regional が選択できます。

サービス利用者が特定の国や地域だけである
バックエンド (VM 等) が単一リージョンだけであり利用者の地域と一致している
バックエンドサービスは Compute Engine Cloud Run GKE など Regional に対応しているサービスである
Cloud CDN は使わない (将来も利用予定がない)

一方で以下の いずれか に当てはまる場合は Global なロードバランサーが適切です。

サービスの利用者が複数の国や地域に跨っている
バックエンド (VM 等) が複数リージョンに跨っている
バックエンドとして Cloud Functions App Engine Cloud Storage を使いたい (Regional では対応していない)
Cloud CDN を使う (または将来使う可能性がある)

Global vs Regional の留意点

見落としがちなポイントとして、 Global と Regional では対応しているバックエンドのサービスが異なることに注意が必要です。

3. Regional external Application Load Balancer ではバックエンドに Cloud Storage バケットや Cloud Functions 関数を指定することができません。

対応しているバックエンドを始め、ロードバランサー種別ごとの機能の差異は以下のドキュメントで確認できます。

参考 : ロードバランサの機能比較

新型 vs 従来型

Global を使おうと考えたとき、 1. Global external Application Load Balancer と 2. (Classic) は「新旧」の差ですので、原則的には新型である 1. を選択するべきです。

公式ドキュメントの詳細な機能比較を見て、従来型 ( 2. ) でしか実現できない要件がある場合のみ、従来型を選びます。

参考 : 機能の違い

また、新型 ( 1. ) のほうが従来型より高度な信頼性・スケーラビリティを実現できるよう、アーキテクチャが改善されています。Google としては、従来型から新型への移行を推奨しています。

External Application Load Balancer の機能

バックエンドへの負荷分散

External Application Load Balancer の最も基本的な機能は、インターネットからのトラフィックをバックエンドに負荷分散することです。

バックエンドとして以下のような多様な選択肢があります。

Compute Engine
Cloud Storage
Cloud Run
App Engine
Cloud Functions
Google Kubernetes Engine (GKE)
オンプレ (ハイブリッド NEG)

ただし前述の通り Global か Regional かによって利用可能なバックエンドが異なりますので注意が必要です。

ヘルスチェック

配下のインスタンス等が障害を起こしてサービス停止状態になった場合、ロードバランサーはトラフィックを正常なインスタンスにのみ振り分けます。それには、ロードバランサーが配下のサービスが正常動作しているかを知る必要があります。

ロードバランサーからは定期的に ヘルスチェック が実行されます。例えば 1 分に一度、 HTTPS リクエストを各インスタンスに投げ、 200 OK を正常とみなすなどです。

ロードバランサーから配下のサービスへのヘルスチェックが通るようにするためには VPC ファイアウォール等での許可設定が必要です。

External Application Load Balancer では以下の IP アドレスを接続元としたアクセスを許可する必要があります。

35.191.0.0/16
130.211.0.0/22

詳細な設定内容等は以下のドキュメントを参照してください。

参考 : ヘルスチェックの概要

トラフィック管理

外部ロードバランサには トラフィック管理機能 があり「トラフィックのミラーリング」「重み付けに基づくトラフィック分割」「リクエスト / レスポンスベースのヘッダー変換」などを実現できます。大まかに分けると以下のようになります。

名称	概要
トラフィックステアリング	HTTP(S) パラメータ (ホスト、パス、ヘッダー、その他のリクエストパラメータ) に基づいたルーティング
トラフィックアクション	リクエストとレスポンスに基づいたリダイレクト、ヘッダー変換、URL 書き換えなどのアクション
トラフィックポリシー	セッションアフィニティ、バランシングのアルゴリズムなどの指定

トラフィック管理は Cloud Load Balancing の最も強力な機能の一つです。

例えば「 通常のトラフィックは VM の Web サーバに振り分ける。 /image/* 以下の画像ファイルは Cloud Storage バケットに振り分ける 」のような振り分けも、簡単にできてしまいます。これによりストレージコストの削減とレスポンスの改善が実現されます。

ロードバランサにより実現可能な機能が細かく異なるため、詳細は以下をご参照ください。

SSL/TLS

SSL/TLS の終端 (オフロード)

今日の Web サービスでは HTTPS による通信の暗号化がほぼ必須と言えます。 Cloud Load Balancing では SSL/TLS の終端 (オフロード) が可能です。

自分で別途証明書を用意して セルフマネージド証明書 として Google Cloud にアップロードし、ロードバランサで利用することができます。

一方で Google Cloud から証明書を発行することもでき、これは Google マネージド証明書 と呼ばれます。

なお、ロードバランサ側で簡単に HTTP から HTTPS へのリダイレクトを設定することができます。

Google マネージド証明書

Google Cloud 側で発行する SSL/TLS 証明書を Google マネージド証明書 と呼びます。

Google マネージド証明書は ドメイン検証（DV）証明書 です。また複数のドメイン名を登録することが可能ですが、ドメイン名にワイルドカードを使うことはできません (例 : *.example.com ) 。

ただし Google マネージド証明書は Regional のロードバランサでは使えないことに注意が必要です 。Google マネージド証明書が使えるのは、以下のロードバランサーのみです。

Global external Application Load Balancer
Global external Application Load Balancer (Classic)
Global external proxy Network Load Balancer (with a target SSL proxy)

また Google マネージド証明書はエクスポートしたりダウンロードしたりすることは できません。Cloud Load Balancing でのみ使用できる証明書です。

発行するには証明書のドメインの DNS ゾーンに Google から払い出された CNAME レコードを登録する、もしくはロードバランサーの IP アドレスを A レコードとして登録する必要があります。詳細な手順は以下を参照してください。

参考 : Google マネージド SSL 証明書を使用する

バックエンドまでの暗号化

ロードバランサーが SSL/TLS を終端した後、ロードバランサとバックエンドの通信は非暗号化の HTTP プロトコルで通信させることができます。

この場合でも Google Cloud の標準の仕組みにより 通信は全て透過的に暗号化され ます ( ネットワークレベルの自動暗号化 ) 。

耐障害性

Cloud Load Balancing は分散アーキテクチャの仮想的なロードバランサであり、高い可用性を持ちます。

Global なロードバランサはその名の通り全リージョンに分散されているのでゾーンレベルの可用性に加えあるリージョン全体が万一停止しても可用性を維持できます。

Region のロードバランサは、選択したリージョン内の複数ゾーンに分散されるので、ゾーン停止に対しての可用性は維持されますがリージョン全体が停止した場合には利用できなくなります。

なお Cloud Load Balancing では Compute Engine サービスの一部の扱いで Service Level Agreement (SLA) が定義されており、詳細は以下のドキュメントで確認可能です。

参考 : Compute Engine Service Level Agreement (SLA)

プロキシと HTTP ヘッダー

External Application Load Balancer はプロキシ型のロードバランサであるため、一度 TCP 接続を終端します。つまりバックエンドのサーバから見ると IP ヘッダの送信元 IP アドレスはロードバランサーのものとなります。

これでは本来の接続元であるクライアントの IP アドレスを特定することはできません。

これに対処するため (こういったプロキシ型のロードバランサでは一般的ですが) HTTP リクエストに X-Forwarded-For ヘッダがロードバランサによって追記されます。

また他にも、ロードバランサまでの接続プロトコル (http or https) を示す X-Forwarded-Proto や Google サービスを経由したことを示す Via : 1.1 google なども付与されます。

これらはデフォルトでロードバランサによって付与されるヘッダですが、任意のカスタムヘッダを付与するように指定することも可能です。

ロギング

Cloud Load Balancing ではアクセスログを有効化して Cloud Logging に出力することができます。

ロードバランサーのコンポーネントの一つである バックエンドサービス / バックエンドバケット (後述) でデフォルトで有効化されています (バックエンド バケット では無効化不可) 。

ログを表示するには Cloud Logging コンソールや gcloud コマンドを利用します。またログルーティングを用いて、ログをシームレスに BigQuery に投入することも可能です。

Cloud Load Balancing のログには例として以下のような要素が含まれます (詳細) 。

Key 名	概要
一般的な情報	重大度 / プロジェクト ID / タイムスタンプ等
HttpRequest	requestUrl, userAgent, remoteIp, serverIp など HTTP リクエストに関する情報 ( 詳細 )
statusDetails	正常/異常終了時メッセージ。値としてキャッシュヒット有無 (正常時) やエラーの原因 (異常時) が入る

モニタリング

Cloud Load Balancing は Cloud Monitoring によって自動的にモニタリングされます。

External Application Load Balancer では 1 分毎に指標 (メトリクス) が Cloud Monitoring に送出され、6週間保持されます。

Cloud Monitoring のアラート機能を使えば、指標に閾値を設定してアラートメールを発報する等の仕組みが簡単に実装できます。

以下はモニタリングされる指標の例です。詳細は公式ドキュメントを確認してください。

指標名	概要
https/request_count	ロードバランサによって処理されたリクエスト数
https/request_bytes_count	クライアントからロードバランサへのリクエストとして送信されたバイト数
https/response_bytes_count	ロードバランサからクライアントへのレスポンスとして送信されたバイト数
https/backend_latencies	GFE がバックエンドに最初のリクエストバイトを送信してから、バックエンドから最後のレスポンスバイトを受信するまでのレイテンシの分布

Cloud CDN と Cloud Armor

Global な External Application Load Balancer ではコンテンツ・デリバリ・ネットワークである Cloud CDN やマネージドな WAF である Cloud Armor が利用可能です。

一方で Regional external Application Load Balancer ではこれらの機能は使えません。

ただし、Cloud Armor については Regional external Application Load Balancer での利用が2023年6月に Public Preview 公開され、将来的に一般公開になる見込みです。

参考 : 外部アプリケーションロードバランサの概要

プレミアムティアとスタンダードティア

Google のネットワークティア

Google Cloud のネットワークには プレミアムティア と スタンダードティア があります。

プレミアムティアは Google の持つグローバルネットワークを使用するものです。低レイテンシで信頼性の高いことが特徴で、世界中に 100 以上の接続点 (PoP) を持っています。一方のスタンダードティアは、通常のインターネット経由でのトラフィック配信です。

Google Cloud のネットワークティアでは Google Cloud から 出ていくトラフィック量 (= ダウンロードされるデータサイズ) に対して料金が発生します。スタンダードティアのほうがプレミアムティアより安価な値段設定となっていますが、パフォーマンスは劣ります。

参考 : Network Service Tiers の概要

ロードバランサーの利用するティア

ロードバランサーの種別によって利用されるティアが異なり、以下のようになっています。

ロードバランサー種別	プレミアムティア	スタンダードティア
Global external Application Load Balancer	◯	✕
Global external Application Load Balancer (Classic)	◯	◯
Regional external Application Load Balancer	✕	◯

2. Global external Application Load Balancer (Classic) でのみ、プレミアムとスタンダードから選択できるようになっています。スタンダードを選択した場合は、ロードバランサーのフロントエンドを配置するリージョンを選択することになり、実質的にリージョナルな挙動をしますし、バックエンドもフロントエンドと同じリージョンにある必要があります。

※このときの Regional external Application Load Balancer との違いは、バックエンドの VPC ネットワークを選ばないという点です ( 参考 )。

プレミアムティアの挙動

プレミアムティアを用いたロードバランサでは エニーキャスト IP アドレス が用いられます。

Google の持つ世界中の PoP の中からクライアントに一番近い PoP が選択されトラフィックが Google のネットワークに入ることで、最適なネットワーク経路が選択されて高いパフォーマンスが発揮されます。その代わり、ダウンロード方向のトラフィックの課金が割高となります。

参考 : All networking pricing

このプレミアムティアの利用により、世界中からのトラフィックの経路を最適化できるのが、 Cloud Load Balancing の最大の特徴でもあります。

External Application Load Balancer の内部構成（アーキテクチャ）

アーキテクチャの概要

Cloud Load Balancing では、内部的に Google Front End（GFE）、Envoy、Maglev、Andromeda といったテクノロジーが使われています。その実体は Google Cloud の世界中のロケーション（データセンター）に分散配置されています。

参考 : Cloud Load Balancing の概要

External Application Load Balancer の内部構造は、論理的には4つのコンポーネントで構成されています。ロードバランサを構築・運用していくにあたり、これらの構成に対するある程度の理解が必要です。

転送ルール（Forwarding rule）
ターゲットプロキシ（Target proxy）
URL マップ（URL map）
バックエンドサービス / バックエンドバケット

Web コンソールや gcloud コマンドラインでロードバランサを構築したり管理するときにも、上記の用語が登場します。 Google Cloud の Web コンソールからロードバランサを構築する場合、ウィザードに沿って順番にパラメータを指定していくと、これら4つのコンポーネントが自動的に出来上がることになります。

External Application Load Balancer の内部構造

転送ルール（Forwarding rule）

転送ルールは、外部 IP アドレスを持ち、特定のポート・プロトコルをリッスンする（待ち受ける）コンポーネントです。転送ルールは、受け取ったトラフィックをターゲットプロキシ（次項で説明）へルーティングします。

参考 : 転送ルールと IP アドレス

外部ロードバランサを構築すると1つのパブリック IP アドレスが割り当てられますが、これは転送ルールに割り当てられているものです。もしロードバランサに対して www.example.com のようなドメイン名を割り当てる場合、 DNS で CNAME レコードを作り、この IP アドレスに向けることになります。

転送ルールは、待ち受けるポート番号とプロトコルも設定値として持ちます。なお HTTP(S) ロードバランサでは、HTTP では 80/tcp もしくは 8080/tcp 、 HTTPS では 443/tcp しか待ち受けられない仕様です。

また転送ルールには、Global と Regional の区別、また Premium tier と Standard tier の区別があります。

ターゲットプロキシ（Target proxy）

ターゲットプロキシは、クライアントからの HTTP(S) 接続を終端するコンポーネントです。

参考 : ターゲットプロキシ

ターゲットプロキシは、参照する URL マップ（次項で説明）を設定値として持っており、URL マップの設定に基づいてバックエンドサービス / バックエンドバケットにトラフィックを転送します。

前述したとおり、 HTTP リクエストにデフォルト / カスタムの追加ヘッダを付与するのは、このコンポーネントです。

証明書を保持して SSL/TLS を終端するのもこのコンポーネントです。なお Global なロードバランサーの場合、プロキシとバックエンドは異なるリージョンに配置することもできますが、前述の通りロードバランサとバックエンドの間は非暗号化プロトコルでも「ネットワークレベルの自動暗号化」が行われ、透過的に暗号化されます。

参考 : ロードバランサからバックエンドへの暗号化

URL マップ（URL map）

URL マップは、トラフィックルーティングのルール一覧です。前項のターゲットプロキシは、URL マップに定義された URL パターンに基づいて、バックエンドサービス / バックエンドバケットにトラフィックをルーティングします。

参考 : URL マップ

例として、URL マップには以下のような設定を定義できます。

デフォルトのバックエンドサービスを Compute Engine の Web サーバとする
/images/* というパスへのアクセスが来たら静的ファイルを保持する Cloud Storage のバックエンドバケットに振り分ける

バックエンドサービス / バックエンドバケット

バックエンドサービスとバックエンドバケット（Backend service / Backend bucket）は、バックエンドの VM インスタンスや Cloud Storage バケットをグルーピングする論理的なリソースです。

参考 : バックエンドサービスとバックエンドバケット

バックエンドサービスの実体として、インスタンスグループ（Compute Engine VM のグループ）を指定したり、サーバーレス NEG（Cloud Run / Cloud Functions / App Engine 等のグループ）指定したりできます。

またバックエンドに通信する際のプロトコル（HTTP、HTTPS、HTTP/2）を指定可能です。

前述のヘルスチェック機能の設定値を保持するのも、バックエンドサービスです。 130.211.0.0/22 か 35.191.0.0/16 の範囲からバックエンドサービスに対してヘルスチェックが行われますが、このときのプロトコルやパスも指定可能です。

Web コンソールの表記

ここまで、External Application Load Balancer を構成する4つのコンポーネントを紹介しました。

しかし、Google Cloud の Web コンソールからロードバランサを構築したり、あるいは設定を表示したりすると、前述の名称とは表記が異なっていることに気が付きます。これが Google Cloud のロードバランサーの理解を難しくしている要因でもあります。

分かりやすく表示するために、Web コンソール画面では4つのコンポーネントをまとめて「ロードバランサ」という1つの論理コンポーネントとして表現しています。

Web コンソールでロードバランサを構築するときの表記と、実際に API リソースとして存在するリソース構成との対照表は、以下のとおりです。

Web 画面での表現	実際のリソース
フロントエンド	転送ルール + ターゲットプロキシ
ルーティングルール	URL マップ
バックエンドサービス / バケット	バックエンドサービス / バケット

図示すると以下のとおりです。

また Web コンソールで構築すると「ロードバランサ」「フロントエンド」などに名称を入力しますが、実際のリソース名称への反映は以下のとおりです。

Web 画面での表現	リソース
「ロードバランサ」の名称	URL マップの名称となる。またターゲットプロキシの名称は `${ロードバランサ名称}-target-proxy` となる
「フロントエンド」の名称	転送ルールの名称となる
「バックエンドサービス / バケット」の名称	実際の「バックエンドサービス / バケット」のリソース名称は Web 画面と同じ

なお、gcloud コマンドにより単独で URL マップを作成 ( gcloud compute url-maps create ) すると、その URL マップを何にも紐付けなくても、コンソール画面上には「ロードバランサ」として表示されます。

高度なアーキテクチャ

VPC・プロジェクトをまたぐ負荷分散

External Application Load Balancer では共有 VPC (Shared VPC) を用いることで、VPC ネットワークやプロジェクトをまたいだ負荷分散を行うことができます。

ロードバランサ自体 (転送ルール / ターゲットプロキシ / URL マップ) はホストプロジェクト (共有 VPC の親プロジェクト) またはサービスプロジェクト (共有 VPC を利用する側のプロジェクト) のいずれにも作成できます。一方のバックエンド (負荷分散先の VM 等) は、これらロードバランサ本体コンポーネントと同じプロジェクトに作成することもできますし、他のプロジェクトに作成することもできます。

参考 : Shared VPC architecture

グローバルな可用性

特に External Load Balancer で非常に高度な対障害性を得たい場合、以下のようなアーキテクチャも提唱されています。

メインのトラフィックは Global external Application Load Balancer で処理する
Regional external Application Load Balancer を各リージョンに配置する
障害時は Global から Regional へ振り分け先をフェイルオーバする

Global external Application Load Balancer と Regional external Application Load Balancer はそれぞれ独立した基盤のうえで稼働しているため、片方の大規模障害がもう片方に影響しないという利点があります。そのため、こういったアーキテクチャが可能となっています。

参考 : Increasing Resiliency with Load Balancers

なお補足情報として、Google Cloud のフルマネージドサービスである Cloud DNS にはヘルスチェック機能がありますが Internal passthrough Network Load Balancer と internal Application Load Balancer にしか対応していないため、上記のアーキテクチャで障害時に Global から Regional への自動フェイルオーバさせるためには、Cloud DNS 以外の仕組みでヘルスチェック・自動フェイルオーバを構築する必要があります。