Serverless NEGという機能が追加されたことにより、Google Cloudが誇るグローバルロードバランサ(HTTP(S)負荷分散)がさらに強力になりました。本記事では、この機能を使ってマルチリージョンCloud Runが実現できるのかを試していきたいと思います。

はじめに

Serverless NEGについては、つい最近追加されたGoogle Cloudの新機能になります。グローバルロードバランサのバックエンドサービスとして、 Google App Engine, Cloud Functions, Cloud Runといったサーバレスアプリケーションプラットフォームを選択することができる機能です。

Serverless NEGについてはGoogle CloudのSeiji ArigaさんがMediumに「Serverless NEG でシステム開発をより柔軟に」という素晴らしい解説＆作成手順記事を投稿されており、未読の方は、まずこの記事をご一読頂く事を強く推奨致します。

また、弊社エンジニアによりGoogle App Engineで利用する場合の記事を投稿しており、Cloud RunよりAppEngineのユースケースにご興味がある方は、下記の記事をご一読ください。

Serverless NEG + GAE を試してみる

本記事は、上記の内容を踏まえCloud Buildを使って、マルチリージョン動作のCloud Runアプリケーションをデプロイし、その動作を見てみる内容になります。

構成図

今回構築するCloud Runは以下のような構成になります。アプリケーションは全く同じものを、東京(asia-northeast1)と大阪(asia-northeast2)にデプロイします。

アプリケーション動作

デプロイするアプリケーションは特に面白みのないものですが、Cloud Runが動作しているゾーンを表示するだけのものです。これによって、ロードバランサからアクセスしたときにうまいこと分散している様子を眺めたいと思います。

デプロイ手順概要

今回作成するリソースはコマンドラインで作成すると案外面倒でして以下のようなリソースを順番に作成していく必要があります。

Cloud Run サービス (東京、大阪で２つ)
Serverles NEG (東京、大阪で２つ)
バックエンドサービス
URLマップ
HTTPプロキシ
グローバルフォワーディングルール

これは説明するのも読むのも面倒なので、まとめて作成するCloud Build設定を作成しました。デプロイ手順は、Cloud Buildを使った内容で説明していきます。

デプロイ手順

では、デプロイしていきましょう。

Cloud Shell起動とサンプル設定のダウンロード
Cloud Build サービスアカウントへのIAMロール付与
Cloud Buildを実行する
アクセスしてみる
クリーンアップ

Cloud Shell起動とサンプル設定のダウンロード

まず、Cloud Shellを起動してください。Cloud Shellについてよく分からない方は、以下の記事を読んでみてください。

HandsOn環境迷子に贈るCloud Shell

Cloud Shell にログインできましたら、以下のコマンドを実行して、サンプル設定のリポジトリをCloudShellにクローンしてください。

git clone https://github.com/cloud-ace/apps-gcp-serverless-neg-multiregion-cloud-run-sample
cd apps-gcp-serverless-neg-multiregion-cloud-run-sample

Cloud Build サービスアカウントへのIAMロール付与

Cloud Buildサービスアカウントに、今回のデプロイで必要なロールを付与します。付与するロールは以下の４つです。

- Compute インスタンス管理者（v1）
Compute ロードバランサ管理者
サービスアカウントユーザー
Cloud Run 管理者

作業対象のGCPプロジェクトは、Cloud Shellを起動したプロジェクトを前提にしており、 DEVSHELL_PROJECT_ID 変数を多用しています。もし、別のGCPプロジェクトでデプロイしたい方は、変数の部分を固定のプロジェクトIDに置き換えてください。

gcloud config set core/project "${DEVSHELL_PROJECT_ID}"
PROJECT_NUMBER=$(gcloud projects describe "${DEVSHELL_PROJECT_ID}" --format='value(projectNumber)')
CLOUDBUILD_SA="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"

gcloud projects add-iam-policy-binding "${DEVSHELL_PROJECT_ID}" --member="serviceAccount:${CLOUDBUILD_SA}" --role=roles/compute.loadBalancerAdmin
gcloud projects add-iam-policy-binding "${DEVSHELL_PROJECT_ID}" --member="serviceAccount:${CLOUDBUILD_SA}" --role=roles/compute.instanceAdmin.v1
gcloud projects add-iam-policy-binding "${DEVSHELL_PROJECT_ID}" --member="serviceAccount:${CLOUDBUILD_SA}" --role=roles/iam.serviceAccountUser
gcloud projects add-iam-policy-binding "${DEVSHELL_PROJECT_ID}" --member="serviceAccount:${CLOUDBUILD_SA}" --role=roles/run.admin

Cloud Buildを実行する

あとは、 Cloud Build を実行するだけです。

gcloud builds submit .

特に問題なくデプロイできれば、以下のような表示が確認できると思います。
以下の部分で、　print-zone-fw-rules の隣に表示されているIPアドレスが、ロードバランサのエンドポイントになります。

Starting Step #12 - "show Load balancing IP address"
Step #12 - "show Load balancing IP address": Already have image (with digest): gcr.io/google.com/cloudsdktool/cloud-sdk
Step #12 - "show Load balancing IP address": NAME                 REGION  IP_ADDRESS     IP_PROTOCOL  TARGET
Step #12 - "show Load balancing IP address": print-zone-fw-rules          XX.XXX.XXX.XXX  TCP          print-zone-target-http-proxy
Finished Step #12 - "show Load balancing IP address"
PUSH
DONE

実行した後、10分ほど待ちましょう。グローバルロードバランサは、立ち上がりきるまで、数分かかるためです。

アクセスしてみる

curl等でアクセスしてみましょう。
※ XX.XXX.XXX.XXX はロードバランサのIPアドレスです。

curl XX.XXX.XXX.XXX

すると、以下のような表示が得られると思います。
※セキュリティ的な事情により、プロジェクト番号の部分はアスタリスクで伏せました。

東京リージョンのCloud Runにアクセスできた場合

Zone: projects/*******/zones/asia-northeast1-1

大阪リージョンのCloud Runにアクセスできた場合

Zone: projects/*******/zones/asia-northeast2-1

連続してアクセスしたい場合

以下のようなコマンドを実行すると、curl連続で実行し続けることができます。
※ XX.XXX.XXX.XXX はロードバランサのIPアドレスです。

while :; do curl XX.XXX.XXX.XXX; sleep 1; done

Cloud Shellは、日本以外のリージョン（私が検証したときは台湾リージョンでした)で実行されるため、以下のように東京リージョン6割、大阪リージョン4割程度で応答していました。

Zone: projects/*******/zones/asia-northeast1-1
Zone: projects/*******/zones/asia-northeast1-1
Zone: projects/*******/zones/asia-northeast1-1
Zone: projects/*******/zones/asia-northeast2-1
Zone: projects/*******/zones/asia-northeast2-1
Zone: projects/*******/zones/asia-northeast2-1
Zone: projects/*******/zones/asia-northeast1-1
Zone: projects/*******/zones/asia-northeast1-1

ちなみに、自端末(所在地東京)で実行した場合は100%東京リージョン(asia-northeast1)から応答していました。これは、グローバルロードバランサがネットワーク近接性を考慮したルーティングを行う性質があり、Serverless NEGを使用した場合も、その仕様に従った動作をしたと考えられます。

クリーンアップ

サンプルリポジトリにある cleanup.sh を実行すれば、今回作成したCloudRunとロードバランサは削除されます。

bash cleanup.sh

ただし、事前に付与したCloud BuildサービスアカウントのIAMロールと、 Container Registryにプッシュしたサンプルアプリケーション(print-zone)は削除されないため、これにつきましては手動での削除をお願いします。(お手数をおかけします。)

まとめ

如何でしたでしょうか。Cloud Run単体のデプロイと比較して、設定や管理がやや複雑になるとはいえ、グローバルロードバランサとServerless NEGを組み合わせることで、容易に、かつ、低価格で、マルチリージョンアプリケーションを展開することができるようになりました。今回の検証は東京と大阪の2リージョンだけで構成しましたが、仕様上は3拠点以上の設定が可能であり、もはやGoogle Cloudは世界規模のコンピューティングリソースをその手中に収めたと言っても過言ではないでしょう。

Google Cloudが進めるアプリケーションモダナイゼーション、コンテナライズ、そして Anthos といったアプリケーション近代化にご興味がございましたら、是非クラウドエースまでご相談ください。