Zenn
📝

Cloud Load Balancing から Cloud Run Functions へルーティングする手順

2024/09/17に公開
Cloud Run
Cloud Functions
Google Cloud
Load Balancing
tech

はじめに

こんにちは、クラウドエースの岸本です。
今回は、 Cloud Load Balancing から Cloud Run Functions へルーティングする手順を紹介します。
Cloud Load Bnlancing を用いることで、複数の Cloud Run Functions に対して負荷分散を行うことができるだけでなく、独自のドメインを使用してアクセスすることができます。
リクエスト先の Cloud Run Functions は簡単な Web ページを表示します。

作成するもの

構成図は以下の通りです。
構成図
今回使用する主要なサービスは以下の通りです。

Cloud Load Balancing

Cloud Load Balancing とはアプリケーションの可用性を向上させるため、クライアントからのリクエストを最初に受け取り、その後複数のサーバーに効率よく振り分けるサービスです。
Cloud Load Balancing には、さまざまな種類があります。
今回使用するのは、Global External Application Load Balancer です。
この Load Balancer は、複数のリージョンにまたがるサービスを提供する際に使用します。
その他の Load Balancer については、公式ドキュメントをご参照ください。

Cloud Run Functions

Cloud Run Functions は、Google Cloud のマネージド型サーバーレス関数プラットフォームであり、サーバーの管理やスケーリングを意識せずにコードを実行できます。
HTTP リクエスト、Cloud Storage イベント、Pub/Sub メッセージなど、さまざまなトリガーに対応しています。
2024 年 8 月 22 日にリブランディングが行われ、「Cloud Functions」は「Cloud Run Functions」という名称に変更されました。
その他変更点については弊社のテックブログをご覧ください。

Global External Application Load Balancer の構成要素

次に、Global External Application Load Balancer の構成要素について説明します。
Global External Application Load Balancer は複数のリソースから構成されています。

構成要素

画像に示されているリソースは以下の通りです。

① 転送ルール（Forwarding Rule）

転送ルールは、外部 IP アドレスを持っており、リクエストを受け取るためのエントリポイントです。受け取ったリクエストは、転送先のターゲットプロキシに転送されます。

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

ターゲットプロキシは、クライアントからのリクエストを受け取り、終端する役割を持つコンポーネントです。その後、バックエンドサービスに新しい接続を確立し、URL マップに基づいてリクエストを転送します。

③ SSL 証明書（SSL Certificate）

SSL 証明書は、HTTPS リクエストを暗号化するために使用されます。ターゲットプロキシを構成する一部です。
証明書のタイプについては、独自に作成した証明書を使用することも、Google が提供するマネージド証明書を利用することも可能です。

④ URL マップ（URL Map）

URL マップでは、リクエストを URL パスやホスト名に基づいて適切なバックエンドサービスに振り分けるルールを定義します。
例えば、/images へのリクエストは画像サーバーに、/api へのリクエストは API サーバーに転送されるように設定できます。

⑤ バックエンドサービス（Backend Service）

バックエンドサービスは、リクエストを受け取るためのリソースです。
バックエンドサービスに紐付けられるバックエンドには、Google Compute Engine、Google Kubernetes Engine、Cloud Run Functions など、さまざまなプロダクトを利用できます。
今回使用する Cloud Run Functions は Serverless Network Endpoint Group（以下、サーバーレス NEG）という種類のバックエンドを使用します。
紐付け可能なリソースとバックエンドの種類については公式ドキュメントを参照してください。

リソースの流れをまとめると以下のようになります。

  1. クライアントからのリクエストが転送ルールに到達
  2. 転送ルールはターゲットプロキシにリクエストを転送
  3. ターゲットプロキシはリクエストを終端し、SSL 証明書を使用してリクエストを暗号化
  4. ターゲットプロキシはリクエストをURL マップに転送
  5. URL マップはリクエストを適切なバックエンドサービスに転送
  6. バックエンドサービスはリクエストを受け取り、バックエンドサービスに紐付けたプロダクトにリクエストを転送

また上記のコンポーネントは、コンソール画面で以下のように表示されています。

コンポーネント

以上が Global External Application Load Balancer の構成要素とリクエストの流れです。

構築手順

Cloud Load Balancing から Cloud Run Functions へのルーティングを行う手順を紹介します。
構築手順は以下の通りです。

  1. Cloud Load Balancing の作成
  2. ドメインの設定
  3. ブラウザで設定したドメインにアクセス

1. Cloud Load Balancing の作成

Cloud Load Balancing を作成する際は、2. Global External Application Load Balancer の構成要素で紹介したコンポーネント一覧の画像に示されているリソースを右から左の順に作成していくとスムーズに進めることができます。そのため、以下の順序で Cloud Load Balancing を作成していきます。

  • 1-1. バックエンドサービスの作成
  • 1-2. URL マップの作成
  • 1-3. SSL 証明書の作成
  • 1-4. ターゲットプロキシの作成
  • 1-5. 転送ルールの作成

1-1. バックエンドサービスの作成

バックエンドサービスを作成するには、まずバックエンドを用意し、それをバックエンドサービスに紐づける必要があります。
今回のバックエンドは、サーバーレス NEG という種類のバックエンドを使用し、Cloud Run Functions をバックエンドサービスに紐付けます。

はじめに、サーバーレス NEG を作成します。

gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
    --region=us-central1\
    --network-endpoint-type=serverless  \
    --cloud-function-name=CLOUD_RUN_FUNCTION_NAME
  • SERVERLESS_NEG_NAME: サーバーレス NEG の名前を入力します。
  • --region=REGION: Cloud Run Functions のリージョンを入力します。
  • --network-endpoint-type=serverless: サーバーレスネットワークエンドポイントタイプを指定しています。
  • --cloud-function-name=CLOUD_RUN_FUNCTION_NAME: サーバレス NEG に紐付ける Cloud Run Functions の名前を指定します。

次に、バックエンドサービスを作成します。

gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
    --global \
    --protocol=HTTP \
    --timeout=30s \
    --load-balancing-scheme=EXTERNAL_MANAGED
  • BACKEND_SERVICE_NAME: バックエンドサービスの名前を入力します。
  • --global: グローバルバックエンドサービスを設定します。
  • --protocol=HTTPS: プロトコルを HTTPS に設定します。
  • --timeout=30s: タイムアウト時間を設定します。
  • --load-balancing-scheme=EXTERNAL_MANAGED: ロードバランシングスキームを設定します。EXTERNAL_MANAGED は、Global External Application Load Balancer を使用する場合に指定します。

最後に、バックエンドサービスに サーバーレス NEG を紐付けます。

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --global \
    --network-endpoint-group=SERVERLESS_NEG_NAME
  • BACKEND_SERVICE_NAME: バックエンドサービスの名前を入力します。
  • --global: グローバルバックエンドサービスを作成します。
  • --network-endpoint-group=SERVERLESS_NEG_NAME: サーバーレス NEG を指定します。

バックエンドサービスと Cloud Run Functions の紐付けが完了したか確認するために、以下のコマンドを実行します。

gcloud compute backend-services describe BACKEND_SERVICE_NAME --global

// 出力例
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/*****/regions/asia-northeast1/networkEndpointGroups/neg
connectionDraining:
  drainingTimeoutSec: 0
creationTimestamp: '2024-08-23T03:36:01.466-07:00'
description: ''
enableCDN: false
fingerprint: ***************
id: '********************'
kind: compute#backendService
loadBalancingScheme: EXTERNAL_MANAGED
name: bk-service2
port: 80
portName: http
protocol: HTTP
selfLink: https://www.googleapis.com/compute/v1/projects/*****/global/backendServices/bk-service2
sessionAffinity: NONE
timeoutSec: 30

これで、バックエンドサービスの作成が完了しました。

1-2. URL マップの作成

次に、URL マップを作成します。
今回は、バックエンドサービスを 1 つしか利用しませんが、複数のバックエンドサービスを利用する場合は、ホスト名によってリクエストを振り分けるルールを設定する必要があります。

gcloud compute url-maps create URL_MAP_NAME \
    --default-service=BACKEND_SERVICE_NAME
  • URL_MAP_NAME: URL マップの名前を入力します。
  • --default-service=BACKEND_SERVICE_NAME: 上記で作成したバックエンドサービスをデフォルトサービスとして指定します。

1-3. SSL 証明書の作成

次に SSL 証明書を作成します。
今回は、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書を使用します。

gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
    --domains=DOMAIN
  • SSL_CERTIFICATE_NAME: SSL 証明書の名前を入力します。
  • --domains=DOMAIN: ドメインを入力します。私は自身で所有しているlb.google-but.love を使用しました。

1-4. ターゲットプロキシの作成

次に、ターゲットプロキシを作成します。
Global External Application Load Balancer で設定するターゲットプロキシには、HTTP ターゲットプロキシ、HTTPS ターゲットプロキシの 2 種類があります。
今回は、HTTPS ターゲットプロキシで作成します。
HTTPS ターゲットプロキシは、SSL 証明書を保持しているため、コマンド実行時に SSL 証明書を指定する必要があります。
ターゲットプロキシとロードバランサの組み合わせは公式ドキュメントを参照してください。

gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
    --ssl-certificates=SSL_CERTIFICATE_NAME \
    --url-map=URL_MAP_NAME
  • TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシの名前を入力します。
  • --ssl-certificates=SSL_CERTIFICATE_NAME: 上記で作成した SSL 証明書を指定します。
  • --url-map=URL_MAP_NAME: 上記で作成した URL マップを指定します。

1-5. 転送ルールの作成

最後に、受信したリクエストを転送するための転送ルールを作成します。

// IP アドレスの作成
gcloud compute addresses create EXAMPLE_IP --global

// IP アドレスの確認
gcloud compute addresses list

// 転送ルールの作成
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --network-tier=PREMIUM \
    --address=EXAMPLE_IP \
    --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
    --global \
    --ports=443
  • FORWARDING_RULE_NAME: 転送ルールの名前を入力します。
  • --load-balancing-scheme=EXTERNAL: ロードバランシングスキームを指定します。
  • --network-tier=PREMIUM: ネットワークティアを指定します。
  • --address=EXAMPLE_IP: 予約した外部 IP アドレスを指定します。
  • --target-https-proxy=TARGET_HTTPS_PROXY_NAME: 上記で作成したターゲット HTTPS プロキシを指定します。
  • --global: グローバル転送ルールを作成します。
  • --ports=443: ポート番号を指定します。

その他のパラメータは、公式ドキュメントを参照してください。

以上で、Global External Application Load Balancer の作成が完了しました。

2. ドメインの設定

続いては、ドメインの設定を行います。
今回は Cloud DNS を使用します。
Global External Application Load Balancer に設定したドメインが名前解決できるように、Cloud DNS にレコードを追加します。

以下のステップに沿って進めます。
2-1. Cloud DNS にゾーンを作成
2-2. NS レコードの設定
2-3. レコードの追加

2-1. Cloud DNS にゾーンを作成

まずは、Cloud Load Balancing に設定したドメインを管理するため、Cloud DNS にゾーンを作成します。

gcloud dns managed-zones create ZONE_NAME \
    --dns-name=DOMAIN \
    --description="for load balancer" \
    --project=PROJECT_ID
  • ZONE_NAME: ゾーンの名前を入力します。
  • --dns-name=DOMAIN: ロードバランサーに設定したドメインを指定します。
  • --description="for load balancer": ゾーンの説明を入力します。

その他のパラメータは、公式ドキュメントを参照してください。

2-2. NS レコードの設定

次に、NS レコードを追加しドメインが Cloud DNS によって名前解決されるようにします。
ドメインを購入したサービスのコンソール画面にアクセスし、NS レコードを追加します。
NS レコードは、以下のコマンドを実行して取得します。

gcloud dns record-sets list --zone=ZONE_NAME --project=PROJECT_ID

// 出力例
NAME: lb.google-but.love.
TYPE: NS
TTL: 21600
DATA: ns-cloud-e1.googledomains.com.,ns-cloud-e2.googledomains.com.,ns-cloud-e3.googledomains.com.,ns-cloud-e4.googledomains.com.

NAME: lb.google-but.love.
TYPE: SOA
TTL: 21600
DATA: ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 2 21600 3600 259200 300

出力された 4 個の NS レコードを、ドメインを管理するサービスのコンソール画面で追加します。

NSレコード

2-3. レコードの追加

次に、Global External Application Load Balancer に設定した IP アドレスをレコードに追加します。

// レコードの一覧表示
gcloud dns record-sets list --zone=ZONE_NAME \
    --project=PROJECT_ID

// 登録する IP アドレスの取得
gcloud compute addresses list

// トランザクションを開始
gcloud dns record-sets transaction start --zone=ZONE_NAME \
    --project=PROJECT_ID

// レコードの追加
gcloud dns record-sets transaction add --zone=ZONE_NAME \
    --name=DOMAIN \
    --ttl=300 --type A IP_ADDRESS

// トランザクションの適用
gcloud dns record-sets transaction execute --zone=ZONE_NAME \
    --project=PROJECT_ID

// 確認
gcloud dns record-sets list --zone=ZONE_NAME --project=PROJECT_ID

// 出力例
NAME: lb.google-but.love.
TYPE: A
TTL: 300
DATA: xx.xx.xx.xx

NAME: lb.google-but.love.
TYPE: NS
TTL: 21600
DATA: ns-cloud-e1.googledomains.com.,ns-cloud-e2.googledomains.com.,ns-cloud-e3.googledomains.com.,ns-cloud-e4.googledomains.com.

NAME: lb.google-but.love.
TYPE: SOA
TTL: 21600
DATA: ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 2 21600 3600 259200 300
  • zone: ゾーンの名前を指定します。
  • --name=DOMAIN:ドメイン名を指定します。
  • --ttl=300: TTL を指定します。
  • --type A: レコードのタイプを指定します。
  • IP_ADDRESS: 上記で作成した外部 IP アドレスを指定します。

以上の設定で、ドメインが Cloud DNS によって名前解決されるようになりました。
最後にドメインが名前解決されるか確認するために、以下のコマンドを実行します。

nslookup DOMAIN

// 出力例
xx.xx.xx.xx

設定したドメインが名前解決されることを確認します。
nslookup

3. ブラウザで設定したドメインにアクセス

最後に、設定したドメインにアクセスして、Cloud Run Functions が正常に動作するか確認します。

Webページ

画像のように、設定したドメインにアクセスすると、Cloud Run Functions が正常に動作していることが確認できます。

以上で、Cloud Load Balancing から Cloud Run Functions へのルーティングが完了しました。

まとめ

以上で、Cloud Load Balancing から Cloud Run Functions へルーティングする方法を紹介しました。
Cloud Load Balancing を使用することで、複数の Cloud Run Functions に対して負荷分散を行うことができるだけでなく、独自のドメインを使用してアクセスすることができます。
Cloud Run Functions に限らず、他のサービスにも適用できるため、ぜひ活用してみてください。
最後までお読みいただき、ありがとうございました。

Discussion