最近お客さんごとにサブドメインが変わるサービスを作ろうと思い、ワイルドカードでの証明書に対応したCDNサービスでお手頃価格のものを検討していてGCPのロードバランサを調査してみたのでメモを残します。ひとまず今回の解説範囲はこんな感じ。
前提として「グローバル外部 HTTP(S) ロードバランサ」を念頭にメモを残すので、UDPや内部LBなどの目的では適さないことを断っておきます。
（注意）コンポーネントViewで確認する
通常、CloudCDNから設定したり負荷分散のトップから選択するとこのビューであるのですが
今回の設定内容を確認する場合はこちらのビューに切り替える必要があります
1. 転送ルール
Google Cloud ロードバランサのフロントエンド構成は、転送ルールとそれに対応する IP アドレスによって表されます。
まずインターネットからやってきたトラフィックを受け持つのは、ロードバランサのうち「転送ルール」と呼ばれるコンポーネントです。これはIPとポートがセットされており、HTTPSの場合次のターゲットプロキシにトラフィックを流します。
リファレンス：https://cloud.google.com/load-balancing/docs/forwarding-rule-concepts?hl=ja
2. ターゲットプロキシ
ターゲット プロキシは 1 つ以上の転送ルールから参照されます。外部 HTTP(S) ロードバランサと内部 HTTP(S) ロードバランサの場合、プロキシは受信リクエストを URL マップに転送します。(後略)
このターゲットプロキシはプロトコルに応じていろんな役割があるんだけど、HTTPSロードバランサに関してはURLマップに転送するということを覚えておけば良さそう。なお、ターゲットプロキシは総称なので、この目的でつか場合は「グローバル ターゲット HTTP(S) プロキシ」と呼ぶらしいです。ここまではL4って感じがしますね。
リファレンス：https://cloud.google.com/load-balancing/docs/target-proxies
3-1. URLマップ
グローバルターゲットHTTPSプロキシ にはURLマップと証明書マップがセットされます。ドメイン及びホストに基づいた処理をするんじゃないかと思います。
Google Cloud HTTP(S) ロードバランサと Traffic Director は、URL マップと呼ばれる Google Cloud 構成リソースを使用して、バックエンド サービスまたはバックエンド バケットにリクエストをルーティングします。
nginxとかだと、パスルールに基づいてプロキシ先を決めるディレクティブを書くような部分ですね。なので
www.example.com/ -> Cloud Run
www.example.com/assets/ -> Cloud Storage
bbb.example.com/ -> Google App Engine
一致しない場合 -> Cloud Run
のようなマッピングを設定することができます。
3-2. 証明書マップ
ここが最近新しくできた部分です。もともとロードバランサ自体にもSSL証明書を管理する機能があったのですが、Certificate Managerが新たに登場したことで、ワイルドカード証明書を含む柔軟な設定ができるようになりました。従来のSSL証明書は実際のアクセスが到達しないとダメなので、ロードバランサをデプロイしてある程度アクセスしないと証明書が有効になりませんでした。
Certificate Managerを使わなくていい場合として以下があげられています。
You require 15 or fewer certificates per load balancer.
ロードバランサあたり15個以下しか扱わない場合
Your migration from a third-party solution can incur downtime.
ロードバランサの移行時にダウンタイムが許容できる場合
You do not use wildcard domains.
ワイルドカードドメインを使用しない場合
つまり15個以上、またはダウンタイムなしの移行、あるいはワイルドカードサブドメインを使いたい場合はCertificateManagerが適しているということですね。
URLマップと同様に証明書マップというものを作ります。
www.example.com -> 証明書A
bbb.example.com -> 証明書B
一致しない場合 -> 証明書A
リファレンス：https://cloud.google.com/certificate-manager/docs/overview
4. バックエンドサービス（バケット）
ターゲットプロキシが、URLマップと証明書マップを使用して転送先を決定したら、最後は実際のリクエストを処理するバックエンドに転送されます。たぶんこの段階ではSSLのTerminationも終わっており、Googleの内部プロトコルで起動するんでしょうね。
バックエンドサービス（バケット）にはCompute EngineほかIPアドレスベースのサービスと、Cloud RunなどServerless系サービス、Cloud Storageが選択できます。
また、これらのバックエンドサービスには、個別にCloud CDN（とCloud Armor）を設定することができます。これらを設定することで、バックエンドにトラフィックが届く前に不審な通信をブロックしたり、キャッシュを返すといった操作が可能になります。
ここまできて晴れてトラフィックがアプリケーションなりリソースなりに届きますので、処理をして返すという流れとなります。一見たくさんのコンポーネントを通過しますが、ひとつひとつ見ていくとどれもロードバランスでは必要な処理ばかりなので、流れを追ってみることで理解が進みました。
お役に立てば幸いです。なお2022年4月時点ではCertificate Managerを使用したHTTPSロードバランスの構築はGAではなく、gcloudコマンドまたはAPIのみで、コンソールからは操作できない点に注意してください。