世界中のユーザーに迅速にレスポンスを返すには、複数のリージョンにサービスをデプロイし、最も近いリージョンにユーザーをルーティングする必要があります。
Cloud Run サービスは個々のリージョンにデプロイされるため、サービスの別のリージョンにユーザーをルーティングするように外部アプリケーション ロードバランサを構成する必要があります。
このガイドでは、グローバル エニーキャスト IP アドレスを指しているマネージド TLS 証明書で保護されたドメインを使用して外部アプリケーション ロードバランサを構成する方法を説明します(これにより、ユーザーは、サービスがデプロイされている最寄りの Google データセンターに転送されます)。
このガイドで説明するアーキテクチャでは、リージョンの Cloud Run サービスが応答しなくなったり、エラーが返されたりしても、リクエストが別のリージョンに自動的にルーティングされることはありません。マルチリージョン サービスの可用性を向上させるには、外れ値検出を構成して、正常でない Cloud Run サービスを HTTP エラー率に基づいて識別し、一部のリクエストを別のリージョンに分散します。
ロードバランサを作成する
外部ロードバランサを作成するには、さまざまなネットワーク リソースを作成し、相互に接続する必要があります。
コマンドライン
- 静的 IP アドレスを予約することにより、ロードバランサを再作成するときに DNS レコードを更新する必要がなくなります。
上記のコマンドの SERVICE_IP は、IP アドレス リソースの名前(gcloud compute addresses create --global SERVICE_IP
myservice-ip
など)に置き換えます。この IP アドレスは、訪問者に最も近い Google データセンターまたはポイント オブ プレゼンスにルーティングするグローバル エニーキャスト IPv4 アドレスです。
-
バックエンド サービスを作成します。
gcloud compute backend-services create --global BACKEND_NAME
上記のコマンドで、BACKEND_NAME をバックエンド サービスに付ける名前(
myservice-backend
など)に置き換えます。 - URL マップを作成します。
gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME
URLMAP_NAME は、URL マップに付ける名前(
myservice-urlmap
など)に置き換えます。 - HTTPS トラフィックを処理するために、ドメインのマネージド TLS 証明書を作成します。example.com はドメイン名で置き換えます。
gcloud compute ssl-certificates create CERT_NAME \ --domains=example.com
CERT_NAME は、マネージド SSL 証明書に付ける名前(
myservice-cert
など)に置き換えます。 - ターゲット HTTPS プロキシを作成します。
gcloud compute target-https-proxies create HTTPS_PROXY_NAME \ --ssl-certificates=CERT_NAME \ --url-map=URLMAP_NAME
HTTPS_PROXY_NAME は、ターゲット HTTPS プロキシに付ける名前(
myservice-https
など)に置き換えます。 - 作成したネットワーク リソースを IP アドレスに接続する転送ルールを作成します。
gcloud compute forwarding-rules create --global FORWARDING_RULE_NAME \ --target-https-proxy=HTTPS_PROXY_NAME \ --address=SERVICE_IP \ --ports=443
FORWARDING_RULE_NAME は、作成する転送ルールのリソースの名前(
myservice-lb
など)に置き換えます。
Terraform
このセクションで説明する手順の代わりに、グローバル HTTP ロードバランサの Terraform モジュールを使用することもできます。
Terraform ファイル(たとえば main.tf
)に以下を追加します。
-
IP アドレスを構成します。
IP アドレス リソース名を
myservice-service-ip
に構成します。この値は独自の値に変更できます。この IP アドレスは、訪問者に最も近い Google データセンターまたはポイント オブ プレゼンスにルーティングするグローバル エニーキャスト IPv4 アドレスです。 -
バックエンド サービスを作成して構成します。
このリソースは、バックエンド サービスを
myservice-backend
という名前で構成します。この値は独自の値に変更できます。 -
URL マップを構成します。
バックエンド サービス リソース(
myservice-backend
)を新しい URL マップリソース(myservice-lb-urlmap
)に接続します。これらの値は、独自の値に変更できます。 -
HTTPS トラフィックを処理するために、ドメインのマネージド TLS 証明書を作成します。
example.com
は、google_compute_managed_ssl_certificate
リソースのドメイン名に置き換えます。 -
HTTPS プロキシを構成します。
ターゲット名
myservice-https-proxy
を使用してgoogle_compute_target_https_proxy
リソースを作成し、以前に作成した TLS 証明書(myservice-ssl-cert
)と URL マッピング リソース(myservice-lb-urlmap
)を接続します。これらの値は、独自の値に変更できます。 -
転送ルールを構成します。
ターゲット名
myservice-https-proxy
を使用してgoogle_compute_global_forwarding_rule
リソースを作成し、以前に作成した HTTPS プロキシ ターゲット(myservice-https-proxy
)と IP アドレス リソース(myservice-service-ip
)を接続します。これらの値は、独自の値に変更できます。 -
この構成を適用します。
Google Cloud プロジェクトで Terraform 構成を適用するには、次のセクションの手順を完了します。
Cloud Shell を準備する
- Cloud Shell を起動します。
-
Terraform 構成を適用するデフォルトの Google Cloud プロジェクトを設定します。
このコマンドは、プロジェクトごとに 1 回だけ実行する必要があります。これは任意のディレクトリで実行できます。
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Terraform 構成ファイルに明示的な値を設定すると、環境変数がオーバーライドされます。
ディレクトリを準備する
Terraform 構成ファイルには独自のディレクトリ(ルート モジュールとも呼ばれます)が必要です。
-
Cloud Shell で、ディレクトリを作成し、そのディレクトリ内に新しいファイルを作成します。ファイルの拡張子は
.tf
にする必要があります(例:main.tf
)。このチュートリアルでは、このファイルをmain.tf
とします。mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
チュートリアルを使用している場合は、各セクションまたはステップのサンプルコードをコピーできます。
新しく作成した
main.tf
にサンプルコードをコピーします。必要に応じて、GitHub からコードをコピーします。Terraform スニペットがエンドツーエンドのソリューションの一部である場合は、この方法をおすすめします。
- 環境に適用するサンプル パラメータを確認し、変更します。
- 変更を保存します。
-
Terraform を初期化します。これは、ディレクトリごとに 1 回だけ行います。
terraform init
最新バージョンの Google プロバイダを使用する場合は、
-upgrade
オプションを使用します。terraform init -upgrade
変更を適用する
-
構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。
terraform plan
必要に応じて構成を修正します。
-
次のコマンドを実行します。プロンプトで「
yes
」と入力して、Terraform 構成を適用します。terraform apply
Terraform に「Apply complete!」というメッセージが表示されるまで待ちます。
- Google Cloud プロジェクトを開いて結果を表示します。Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。
複数のリージョンにデプロイする
使用可能な Cloud Run のリージョンにサービスをデプロイします。管理を容易にするため、複数のリージョンで同じサービス名を使用できます。
コマンドライン
- サービスを利用可能にするリージョンを選択します。
- Cloud Run サービスを個々のリージョンにデプロイします。
-
gcloud run deploy SERVICE_NAME \ --allow-unauthenticated \ --image=IMAGE_URL \ --region=REGION
次の変数を置き換えます。
- REGION は、デプロイ先のいずれか 1 つのリージョンに置き換えます。
- SERVICE_NAME は、実際のサービスの名前に置き換えます。複数のリージョンで同じサービス名を使用すると、マルチリージョン デプロイを簡単にトラッキングできるようになります。
- IMAGE_URL: コンテナ イメージへの参照(
us-docker.pkg.dev/cloudrun/container/hello:latest
など)。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式はLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
です。
- リージョンごとに前の手順を繰り返します。
Terraform
run_regions
変数で指定されたリージョンごとにサービスを構成します。
run_regions
変数で指定されたすべてのリージョンをループ処理し、それぞれの新しいサービスに次のような名前を付けます。
myservice-run-app-${var.run_regions[count.index]}
サービスのロケーションの定義も同様に適用されます。デフォルト イメージ us-docker.pkg.dev/cloudrun/container/hello"
を独自のイメージに置き換えます。
Cloud Run のロケーション
Cloud Run はリージョナルです。つまり、Cloud Run サービスを実行するインフラストラクチャは特定のリージョンに配置され、そのリージョン内のすべてのゾーンで冗長的に利用できるように Google によって管理されます。
レイテンシ、可用性、耐久性の要件を満たしていることが、Cloud Run サービスを実行するリージョンを選択する際の主な判断材料になります。一般的には、ユーザーに最も近いリージョンを選択できますが、Cloud Run サービスで使用されている他の Google Cloud サービスのロケーションも考慮する必要があります。使用する Google Cloud サービスが複数のロケーションにまたがっていると、サービスの料金だけでなくレイテンシにも影響することがあります。
Cloud Run は、次のリージョンで利用できます。
ティア 1 料金を適用
asia-east1
(台湾)asia-northeast1
(東京)asia-northeast2
(大阪)europe-north1
(フィンランド) 低 CO2europe-southwest1
(マドリッド) 低 CO2europe-west1
(ベルギー) 低 CO2europe-west4
(オランダ) 低 CO2europe-west8
(ミラノ)europe-west9
(パリ) 低 CO2me-west1
(テルアビブ)us-central1
(アイオワ) 低 CO2us-east1
(サウスカロライナ)us-east4
(北バージニア)us-east5
(コロンバス)us-south1
(ダラス) 低 CO2us-west1
(オレゴン) 低 CO2
ティア 2 料金を適用
africa-south1
(ヨハネスブルグ)asia-east2
(香港)asia-northeast3
(ソウル、韓国)asia-southeast1
(シンガポール)asia-southeast2
(ジャカルタ)asia-south1
(ムンバイ、インド)asia-south2
(デリー、インド)australia-southeast1
(シドニー)australia-southeast2
(メルボルン)europe-central2
(ワルシャワ、ポーランド)europe-west10
(ベルリン) 低 CO2europe-west12
(トリノ)europe-west2
(ロンドン、イギリス) 低 CO2europe-west3
(フランクフルト、ドイツ) 低 CO2europe-west6
(チューリッヒ、スイス) 低 CO2me-central1
(ドーハ)me-central2
(ダンマーム)northamerica-northeast1
(モントリオール) 低 CO2northamerica-northeast2
(トロント) 低 CO2southamerica-east1
(サンパウロ、ブラジル) 低 CO2southamerica-west1
(サンティアゴ、チリ) 低 CO2us-west2
(ロサンゼルス)us-west3
(ソルトレイクシティ)us-west4
(ラスベガス)
Cloud Run サービスをすでに作成している場合は、Google Cloud コンソールの Cloud Run ダッシュボードにリージョンが表示されます。
リージョン単位のネットワーク エンドポイント グループを構成する
前の手順でデプロイしたリージョンごとに、次の手順でサーバーレス ネットワーク エンドポイント グループ(NEG)を作成し、バックエンド サービスに追加する必要があります。
コマンドライン
-
REGION
に、Cloud Run サービスのネットワーク エンドポイント グループを作成します。gcloud compute network-endpoint-groups create NEG_NAME \ --region=REGION \ --network-endpoint-type=SERVERLESS \ --cloud-run-service=SERVICE_NAME
上記のコマンドの要素をそれぞれ次のように置き換えます。
- NEG_NAME: ネットワーク エンドポイント グループ リソースの名前。(例: myservice-neg-uscentral1)
- REGION: サービスがデプロイされている [region][loc]。
- SERVICE_NAME: 実際のサービスの名前。
-
ネットワーク エンドポイント グループをバックエンド サービスに追加します。
gcloud compute backend-services add-backend --global BACKEND_NAME \ --network-endpoint-group-region=REGION \ --network-endpoint-group=NEG_NAME
前の手順で作成した NEG_NAME をリージョンに指定します。
-
リージョンごとに上記の手順を繰り返します。
Terraform
-
run_regions
変数で指定された各リージョンの Cloud Run サービス用に、名前がmyservice-neg
のネットワーク エンドポイント グループを構成します。 -
ネットワーク エンドポイント グループ(
myservice-neg
)を接続するようにバックエンド サービスを構成します。
ドメインの DNS レコードを構成する
ドメイン名が作成した転送ルールを指すように、作成した IP アドレスで DNS レコードを更新する必要があります。
次のコマンドを実行して、ロードバランサの予約済み IP アドレスを見つけます。
gcloud compute addresses describe --global SERVICE_IP --format='value(address)'
SERVICE_IP は、前に作成した IP アドレスの名前に置き換えます。このコマンドにより、IP アドレスが出力されます。
この IP アドレスで
A
レコードを追加して、ドメインの DNS レコードを更新します。
認証済みサービスを使用する場合のカスタム オーディエンスを構成する
認証済みサービスは IAM によって保護されます。このような Cloud Run サービスでは、認証情報の生成時にリクエストの対象とする受信者(オーディエンス)を宣言するクライアント認証が必要です。
オーディエンスは通常ターゲット サービスの正式な URL であり、Cloud Run サービスの場合、デフォルトでは末尾が run.app
の URL が生成されます。ただし、マルチリージョン デプロイでは、クライアントはリクエストのルーティング先のリージョン サービスを事前に知ることはできません。したがって、マルチリージョン デプロイでは、カスタム オーディエンスを使用するようにサービスを構成します。
ロードバランサのプロビジョニングを待つ
ロードバランサの IP アドレスでドメインを構成した後は、DNS レコードが反映されるまでしばらく待つ必要があります。同様に、マネージド TLS 証明書がドメインに発行され、HTTPS トラフィックがグローバルに配信可能になるまで、しばらく待つ必要があります。
ロードバランサがトラフィックの配信を開始するまでに最大で 30 分かかることがあります。
準備ができたら、ウェブサイトの URL の先頭に https://
を付けて、アクセスしてみてください。
ステータスを確認する
DNS コマンドライン伝播のステータスを確認するには、
dig
コマンドライン ユーティリティを使用します。dig A +short example.com
DNS レコードに構成した IP アドレスが出力に表示されます。
マネージド証明書の発行ステータスを確認して、次を実行します。
gcloud compute ssl-certificates describe CERT_NAME
CERT_NAME は、前に SSL 証明書リソースに選択した名前で置き換えます。
出力には、
status: ACTIVE
を含む行が表示されます。
HTTP から HTTPS へのリダイレクトの設定
デフォルトでは、転送ルールは単一のプロトコルのみを処理するため、http://
エンドポイントへのリクエストには 404 Not Found が返されます。http://
URL へのリクエストを https://
プロトコルにリダイレクトする必要がある場合は、次の手順を使用して追加の URL マップと転送ルールを作成する必要があります。
コマンドライン
-
リダイレクト ルールで URL マップを作成します。
gcloud compute url-maps import HTTP_URLMAP_NAME \ --global \ --source /dev/stdin <<EOF name: HTTP_URLMAP_NAME defaultUrlRedirect: redirectResponseCode: MOVED_PERMANENTLY_DEFAULT httpsRedirect: True EOF
HTTP_URLMAP_NAME は、作成する URL マップリソースの名前(
myservice-httpredirect
など)で置き換えます。 -
URL マップを使用してターゲット HTTP プロキシを作成します。
gcloud compute target-http-proxies create HTTP_PROXY_NAME \ --url-map=HTTP_URLMAP_NAME
HTTP_PROXY_NAME は、作成するターゲット HTTP プロキシの名前(
myservice-http
など)で置き換えます。 -
同じ予約済み IP アドレスのポート
80
での転送ルールを作成します。gcloud compute forwarding-rules create --global HTTP_FORWARDING_RULE_NAME \ --target-http-proxy=HTTP_PROXY_NAME \ --address=SERVICE_IP \ --ports=80 \
HTTP_FORWARDING_RULE_NAME は、作成する新しい転送ルールの名前(
myservice-httplb
など)で置き換えます。
Terraform
-
リダイレクト ルールで URL マップリソースを作成します。
-
新しく作成した URL マップリソース(
myservice-https-urlmap
)を使用して、ターゲット HTTP プロキシを作成します。 -
同じ予約済み IP アドレス リソース(
myservice-http-proxy
)のポート80
での転送ルールを作成します。
マルチリージョン デプロイで認証済みの Pub/Sub push サブスクリプションを使用する
デフォルトでは、Pub/Sub サービスは Pub/Sub サービスがメッセージを格納するのと同じ Google Cloud リージョン内の push エンドポイントにメッセージを配信します。この動作を回避するには、マルチリージョンの Cloud Run デプロイで認証済みの Pub/Sub push サブスクリプションを使用するをご覧ください。