複数のリージョンからのトラフィックを処理する

複数のリージョンにサービスをデプロイし、最も近いリージョンにユーザーを転送することで、世界中のユーザーに迅速にレスポンスを返します。複数のリージョンにデプロイすることで、低レイテンシを実現し、リージョン停止時の高可用性を確保できます。

Cloud Run サービスは個々のリージョンにデプロイされるため、サービスを複数のリージョンにデプロイしてから、サービスのグローバルロードバランシングを構成する必要があります。

Cloud Run サービスの健全性を使用して、クロスリージョンフェイルオーバーを自動化できます。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Google Cloud プロジェクトで Cloud Run 開発環境を設定します。
gcloud CLI をインストールして初期化します。
アカウントに次の IAM ロールがあることを確認します。
- Cloud Run 管理者（roles/run.admin）
- プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）
- Service Usage ユーザー（roles/serviceusage.serviceUsageConsumer）

ロールを付与する

コンソール

Google Cloud コンソールで、[IAM] ページに移動します。
IAM に移動
プロジェクトを選択します。
[ アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに、ユーザー ID を入力します。これは通常、Cloud Run サービスのデプロイに使用する Google アカウントのメールアドレスです。
[ロールを選択] リストでロールを選択します。
追加のロールを付与するには、 [別のロールを追加] をクリックして各ロールを選択します。
[保存] をクリックします。

gcloud

プロジェクトで自分のアカウントに必要な IAM ロールを付与するには:

        gcloud projects add-iam-policy-binding PROJECT_ID \
            --member=PRINCIPAL \
            --role=ROLE

次のように置き換えます。

PROJECT_NUMBER: Google Cloud プロジェクト番号。
PROJECT_ID: 実際の Google Cloud プロジェクト ID。
PRINCIPAL は、バインディングを追加するアカウントに置き換えます。これは通常、Cloud Run サービスのデプロイに使用される Google アカウントのメールアドレスです。
ROLE: デプロイするアカウントに付与するロール。

Cloud Run の料金ページを確認します。料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
次のコマンドを実行して、Artifact Registry、Cloud Build、Cloud Run Admin API、Compute Engine、Network Services API の API を有効にします。

  gcloud services enable artifactregistry.googleapis.com \
    cloudbuild.googleapis.com \
    run.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

サービスを複数のリージョンにデプロイする

構成したスケーリングパラメータは、複数のリージョンに適用されます。たとえば、マルチリージョンデプロイでは、最小インスタンス値は複数のリージョンそれぞれに適用されます。

次のいずれかの方法で、同じサービスを複数のリージョンにデプロイします。

単一リージョンにデプロイする手順を繰り返します。
マルチリージョンサービスをデプロイします。

マルチリージョンサービスをデプロイする

このセクションでは、1 つの gcloud CLI コマンドで、または YAML ファイルか Terraform ファイルを使用して、マルチリージョンサービスをデプロイして構成する方法について説明します。

gcloud

マルチリージョンサービスを作成してデプロイするには、--regions フラグを使用して gcloud run deploy コマンドを実行します。
```
gcloud run deploy SERVICE_NAME \
  --image=IMAGE_URL \
  --regions=REGIONS
```
次のように置き換えます。
- SERVICE_NAME: デプロイするマルチリージョンサービスの名前。
- IMAGE_URL: コンテナイメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。
- REGIONS: デプロイ先の複数のリージョンのリスト例: europe-west1,asia-east1

YAML

サービスの YAML ファイルを作成します。run.googleapis.com/regions 属性を使用して、サービスをデプロイする複数のリージョンを設定します。
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
spec:
  template:
    spec:
      containers:
      - image: IMAGE_URL
```
次のように置き換えます。
- SERVICE_NAME: デプロイするマルチリージョンサービスの名前。
- REGIONS: 更新する複数のリージョンのリスト。例: europe-west1,asia-east1
- IMAGE_URL: コンテナイメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。
次のコマンドを使用してサービスを作成します。
```
gcloud run multi-region-services replace service.yaml
```

Terraform

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

Terraform 構成の google_cloud_run_v2_service リソースに次の内容を追加します。

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-multi-region"
  regions = [
    "REGION_1",
    "REGION_2",
  ]

template {
containers {
  image = "us-docker.pkg.dev/cloudrun/container/hello"
}
}
}

"REGION_1" と "REGION_2" は、必要なGoogle Cloud リージョンに置き換えます。例: europe-west1、us-central1

マルチリージョンサービスを更新する

このセクションでは、1 つの gcloud CLI コマンドまたは YAML ファイルからマルチリージョンサービスにリージョンを追加または削除する方法について説明します。

gcloud

マルチリージョンサービスからリージョンを追加または削除するには、gcloud run multi-region-services update コマンドを実行します。

マルチリージョンサービスを 1 つまたは複数のリージョンに追加するには、--add-regions フラグを使用します。
```
gcloud run multi-region-services update SERVICE_NAME \
  --add-regions=REGIONS
```
1 つまたは複数のリージョンからマルチリージョンサービスを削除するには、--remove-regions フラグを使用します。
```
gcloud run multi-region-services update SERVICE_NAME \
  --remove-regions=REGIONS
```
次のように置き換えます。
- SERVICE_NAME: 更新するマルチリージョンサービスの名前。
- REGIONS: サービスを追加または削除する 1 つまたは複数のリージョン。例: us-central1,asia-east1

YAML

既存のマルチリージョンサービスを更新するには、その YAML 構成をダウンロードします。
```
gcloud run multi-region-services describe SERVICE_NAME --format export > service.yaml
```
run.googleapis.com/regions 属性を更新して、サービスをデプロイするリージョンのリストを追加または削除します。
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
```
次のように置き換えます。
- SERVICE_NAME: デプロイするマルチリージョンサービスの名前。
- REGIONS: サービスリビジョンをデプロイする複数のリージョンの新しいリスト。
次のコマンドを使用してサービスを更新します。
```
gcloud run multi-region-services replace service.yaml
```

マルチリージョンサービスを削除する

マルチリージョンサービスを削除するには、gcloud run multi-region-services delete コマンドを実行します。
```
gcloud run multi-region-services delete SERVICE_NAME
```
SERVICE_NAME は、削除するマルチリージョンサービスの名前に置き換えます。

グローバル外部アプリケーションロードバランサを構成する

このガイドでは、グローバルエニーキャスト IP アドレスを指しているマネージド TLS 証明書で保護されたドメインを使用してグローバル外部アプリケーションロードバランサを構成する方法を説明します（これにより、ユーザーは、サービスがデプロイされている最寄りの Google データセンターに転送されます）。

次のセクションで説明するアーキテクチャでは、リージョンの Cloud Run サービスが応答しなくなったり、エラーが返されたりしても、リクエストが別のリージョンに自動的に転送されることはありません。

マルチリージョンサービスの可用性を高めるには:

Cloud Run サービスの健全性を使用してクロスリージョンフェイルオーバーを自動化します。
外れ値検出を構成して、正常でない Cloud Run サービスを HTTP エラー率に基づいて識別し、一部のリクエストを別のリージョンに分散します。

グローバル外部アプリケーションロードバランサを作成する

グローバル外部アプリケーションロードバランサを作成するには、さまざまなネットワークリソースを作成し、相互に接続する必要があります。

gcloud

静的 IP アドレスを予約することにより、ロードバランサを再作成するときに DNS レコードを更新する必要がなくなります。
```
gcloud compute addresses create --global SERVICE_IP
```
上記のコマンドの SERVICE_IP は、IP アドレスリソースの名前（myservice-ip など）に置き換えます。
この IP アドレスは、訪問者に最も近い Google データセンターまたはポイントオブプレゼンスにルーティングするグローバルエニーキャスト IPv4 アドレスです。
バックエンドサービスを作成します。
```
gcloud compute backend-services create \
  --global BACKEND_NAME \
  --load-balancing-scheme=EXTERNAL_MANAGED
```
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 \
  --load-balancing-scheme=EXTERNAL_MANAGED 
```
FORWARDING_RULE_NAME は、作成する転送ルールのリソースの名前に置き換えます。例: myservice-lb

Terraform

このセクションで説明する手順の代わりに、グローバル HTTP ロードバランサの Terraform モジュールを使用することもできます。

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

IP アドレスを構成します。

resource "google_compute_global_address" "lb_default" {
  provider = google-beta
  name     = "myservice-service-ip"

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.compute_api
  ]
}
output "load_balancer_ip_addr" {
  value = google_compute_global_address.lb_default.address
}

IP アドレスリソース名を myservice-service-ip に構成します。この値は独自の値に変更できます。この IP アドレスは、訪問者に最も近い Google データセンターまたはポイントオブプレゼンスにルーティングするグローバルエニーキャスト IPv4 アドレスです。

バックエンドサービスを作成して構成します。

resource "google_compute_backend_service" "lb_default" {
  provider              = google-beta
  name                  = "myservice-backend"
  load_balancing_scheme = "EXTERNAL_MANAGED"

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[0].id
  }

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[1].id
  }

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.compute_api,
  ]
}

このリソースは、バックエンドサービスを myservice-backend という名前で構成します。この値は独自の値に変更できます。

URL マップを構成する

resource "google_compute_url_map" "lb_default" {
  provider        = google-beta
  name            = "myservice-lb-urlmap"
  default_service = google_compute_backend_service.lb_default.id

  path_matcher {
    name            = "allpaths"
    default_service = google_compute_backend_service.lb_default.id
    route_rules {
      priority = 1
      url_redirect {
        https_redirect         = true
        redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
      }
    }
  }
}

バックエンドサービスリソース（myservice-backend）を新しい URL マップリソース（myservice-lb-urlmap）に接続します。これらの値は、独自の値に変更できます。

HTTPS トラフィックを処理するために、ドメインのマネージド TLS 証明書を作成します。example.com は、google_compute_managed_ssl_certificate リソースのドメイン名に置き換えます。
```
resource "google_compute_managed_ssl_certificate" "lb_default" {
  provider = google-beta
  name     = "myservice-ssl-cert"

  managed {
    domains = ["example.com"]
  }
}
```

HTTPS プロキシを構成します。

resource "google_compute_target_https_proxy" "lb_default" {
  provider = google-beta
  name     = "myservice-https-proxy"
  url_map  = google_compute_url_map.lb_default.id
  ssl_certificates = [
    google_compute_managed_ssl_certificate.lb_default.name
  ]
  depends_on = [
    google_compute_managed_ssl_certificate.lb_default
  ]
}

ターゲット名 myservice-https-proxy を使用して google_compute_target_https_proxy リソースを作成し、作成しておいた TLS 証明書（myservice-ssl-cert）と URL マッピングリソース（myservice-lb-urlmap）を接続します。これらの値は、独自の値に変更できます。

転送ルールを構成します。

resource "google_compute_global_forwarding_rule" "lb_default" {
  provider              = google-beta
  name                  = "myservice-lb-fr"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  target                = google_compute_target_https_proxy.lb_default.id
  ip_address            = google_compute_global_address.lb_default.id
  port_range            = "443"
  depends_on            = [google_compute_target_https_proxy.lb_default]
}

ターゲット名 myservice-https-proxy を使用して google_compute_global_forwarding_rule リソースを作成し、作成しておいた HTTPS プロキシターゲット（myservice-https-proxy）と IP アドレスリソース（myservice-service-ip）を接続します。これらの値は、独自の値に変更できます。

この構成を適用します。

Google Cloud プロジェクトで Terraform 構成を適用するには、次のセクションの手順を完了します。

Cloud Shell を準備する
1. Cloud Shell を起動します。
2. Terraform 構成を適用するデフォルトの Google Cloud プロジェクトを設定します。
  
  このコマンドは、プロジェクトごとに 1 回だけ実行する必要があります。これは任意のディレクトリで実行できます。
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
  Terraform 構成ファイルに明示的な値を設定すると、環境変数がオーバーライドされます。
ディレクトリを準備する

Terraform 構成ファイルには独自のディレクトリ（ルートモジュールとも呼ばれます）が必要です。
1. Cloud Shell で、ディレクトリを作成し、そのディレクトリ内に新しいファイルを作成します。ファイルの拡張子は .tf にする必要があります（例: main.tf）。このチュートリアルでは、このファイルを main.tf とします。
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
2. チュートリアルを使用している場合は、各セクションまたはステップのサンプルコードをコピーできます。
  
  新しく作成した main.tf にサンプルコードをコピーします。
  
  必要に応じて、GitHub からコードをコピーします。Terraform スニペットがエンドツーエンドのソリューションの一部である場合は、この方法をおすすめします。
3. 環境に適用するサンプルパラメータを確認し、変更します。
4. 変更を保存します。
5. Terraform を初期化します。これは、ディレクトリごとに 1 回だけ行います。
```
terraform init
```
  最新バージョンの Google プロバイダを使用する場合は、-upgrade オプションを使用します。
```
terraform init -upgrade
```
変更を適用する
1. 構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。
```
terraform plan
```
  必要に応じて構成を修正します。
2. 次のコマンドを実行します。プロンプトで「yes」と入力して、Terraform 構成を適用します。
```
terraform apply
```
  Terraform に「Apply complete!」というメッセージが表示されるまで待ちます。
3. Google Cloud プロジェクトを開いて結果を表示します。 Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。
注: Terraform のサンプルでは通常、必要な API が Google Cloud プロジェクトで有効になっていることを前提としています。

リージョン単位のネットワークエンドポイントグループを構成する

前の手順でデプロイしたリージョンごとに、次の手順でサーバーレスネットワークエンドポイントグループ（NEG）を作成し、バックエンドサービスに追加する必要があります。

gcloud CLI

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: サービスがデプロイされているリージョン。
- SERVICE_NAME: 実際のサービスの名前。
ネットワークエンドポイントグループをバックエンドサービスに追加します。
```
gcloud compute backend-services add-backend --global BACKEND_NAME \
  --network-endpoint-group-region=REGION \
  --network-endpoint-group=NEG_NAME
```
前の手順で作成した NEG_NAME をリージョンに指定します。
リージョンごとに上記の手順を繰り返します。

Terraform

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

run_regions 変数で指定された各リージョンの Cloud Run サービス用に、名前が myservice-neg のネットワークエンドポイントグループを構成します。

resource "google_compute_region_network_endpoint_group" "lb_default" {
  provider              = google-beta
  count                 = length(local.run_regions)
  name                  = "myservice-neg"
  network_endpoint_type = "SERVERLESS"
  region                = local.run_regions[count.index]
  cloud_run {
    service = google_cloud_run_v2_service.run_default[count.index].name
  }
}

ネットワークエンドポイントグループ（myservice-neg）を接続するようにバックエンドサービスを構成します。

resource "google_compute_backend_service" "lb_default" {
  provider              = google-beta
  name                  = "myservice-backend"
  load_balancing_scheme = "EXTERNAL_MANAGED"

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[0].id
  }

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[1].id
  }

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.compute_api,
  ]
}

ドメインの DNS レコードを構成する

作成した転送ルールをドメイン名が指すように、作成した IP アドレスで DNS レコードを更新する必要があります。

次のコマンドを実行して、ロードバランサの予約済み IP アドレスを見つけます。
```
gcloud compute addresses describe SERVICE_IP \
  --global \
  --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 見つかりません」が返されます。http:// URL へのリクエストを https:// プロトコルにリダイレクトする必要がある場合は、次の手順に沿って追加の URL マップと転送ルールを作成します。

gcloud CLI

リダイレクトルールで 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

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

リダイレクトルールで URL マップリソースを作成します。

resource "google_compute_url_map" "https_default" {
  provider = google-beta
  name     = "myservice-https-urlmap"

  default_url_redirect {
    redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
    https_redirect         = true
    strip_query            = false
  }
}

新しく作成した URL マップリソース（myservice-https-urlmap）を使用して、ターゲット HTTP プロキシを作成します。

resource "google_compute_target_http_proxy" "https_default" {
  provider = google-beta
  name     = "myservice-http-proxy"
  url_map  = google_compute_url_map.https_default.id

  depends_on = [
    google_compute_url_map.https_default
  ]
}

同じ予約済み IP アドレスリソース（myservice-http-proxy）のポート 80 での転送ルールを作成します。

resource "google_compute_global_forwarding_rule" "https_default" {
  provider   = google-beta
  name       = "myservice-https-fr"
  target     = google_compute_target_http_proxy.https_default.id
  ip_address = google_compute_global_address.lb_default.id
  port_range = "80"
  depends_on = [google_compute_target_http_proxy.https_default]
}

その他の構成オプションについては、Cloud Run を使用してグローバル外部アプリケーションロードバランサを設定するをご覧ください。

Cloud Run サービスの健全性を使用してクロスリージョンフェイルオーバーを自動化する

Cloud Run サービスの健全性により、サービスの中断を最小限に抑え、クロスリージョンフェイルオーバーとフェイルバックを自動化します。内部トラフィック用に自動フェイルオーバーとフェイルバック機能を備えたマルチリージョン高可用性 Cloud Run サービスを設定します。

制限事項

Cloud Run サービスの健全性には、次の制限が適用されます。

健全性を計算するには、リージョンごとにサービスレベルまたはリビジョンレベルの最小インスタンス数を 1 つ以上構成する必要があります。Cloud Monitoring のコンテナインスタンス数指標を使用して、リージョンに必要な最小インスタンス数を推定することもできます。
フェイルオーバーには、異なるリージョンのサービスが少なくとも 2 つ必要です。そうでない場合、1 つのサービスが失敗すると、エラーメッセージ no healthy upstream が表示されます。
Cloud Run サービスの健全性は、5 つを超えるサーバーレス NEG バックエンドを持つクロスリージョン内部アプリケーションロードバランサをサポートしていません。
サーバーレス NEG で URL マスクやタグを構成することはできません。
バックエンドサービスまたはロードバランサから IAP を有効にすることはできません。Cloud Run から直接 IAP を有効にします。
Cloud Run サービスが削除されると、Cloud Run はロードバランサに異常なステータスを報告しません。
新しいインスタンスの起動では最初の準備状況プローブはカウントされないため、リクエストは、正常な状態になる前に、新しく起動されたサービスに短時間ルーティングされる可能性があります。
Cloud Run サービスの健全性は、すべてのインスタンスで計算されます。プローブのないリビジョンは不明として扱われます。ロードバランサは、不明なインスタンスを正常と見なします。

リージョンの健全性を報告する

リージョン Cloud Run サービスの健全性を集計し、正常または異常なステータスをロードバランサに報告するには、次の操作を行います。

1 つ以上の最小インスタンスを使用して、複数のリージョンに Cloud Run サービスリビジョンをデプロイします。次のコマンドを実行して、前の手順で構成した準備状況プローブを使用します。
```
gcloud beta run deploy SERVICE_NAME \
--regions=REGION_A,REGION_B \
--min=MIN_INSTANCES
```
次のように置き換えます。
- SERVICE_NAME: サービスの名前。
- REGION_A、REGION_B: サービスリビジョンの異なるリージョン。たとえば、REGION_A を us-central1 に、REGION_B を europe-west1 に設定します。
- MIN_INSTANCES: ウォーム状態を維持し、リクエストを受信できるコンテナインスタンスの数。最小値は 1 以上に設定する必要があります。
各コンテナインスタンスに設定された gRPC または HTTP 準備状況プローブを構成します。
クロスリージョン内部アプリケーションロードバランサを構成して、異常なリージョンからトラフィックを転送します。
各リージョンの各 Cloud Run サービスにサーバーレス NEG を設定します。
サーバーレス NEG と接続するようにバックエンドサービスを構成します。

ベストプラクティス

準備状況プローブ、トラフィック分割、最小インスタンスを組み合わせて使用すると、安全かつ段階的なロールアウトを実行できます。これにより、新しいリビジョンを昇格させる前に単一の「カナリア」リージョンで健全性を確認し、ロードバランサが正常なリージョンバックエンドにのみトラフィックを送信するようにします。

推奨されるロールアウトプロセス

準備状況プローブまたは Cloud Run サービスの健全性を使用していない既存の Cloud Run サービスにサービスリビジョンをロールアウトできます。このプロセスをリージョンごとに 1 つずつ実行して、新しいリビジョンを安全にデプロイします。

準備状況プローブが構成された単一の「カナリア」リージョンに新しいリビジョンをデプロイします。
新しいリビジョンに少量のトラフィック（1% など）を送信します。
最小インスタンス数には、リビジョンレベルではなくサービスレベルでゼロ以外の値を使用します。
準備状況プローブ指標（run.googleapis.com/container/instance_count_with_readiness）を調べて、新しいインスタンスが正常であることを確認します。
段階的に、新しいリビジョンへのトラフィックの割合を増やします。ランプアップするときは、ロードバランサで使用されるリージョン Cloud Run サービスの健全性指標（run.googleapis.com/service_health_count）をモニタリングします。十分なトラフィックが新しいリビジョンに転送されるまで、Cloud Run サービスの健全性は UNKNOWN を返します。
リビジョンが 100% のトラフィックを受信し、リージョン Cloud Run サービスの健全性が安定して正常になったら、他のすべてのリージョンでこのプロセスを繰り返します。

ヘルスチェックをモニタリングする

Cloud Run サービスの健全性を設定すると、サーバーレス NEG は Cloud Monitoring サービスの健全性指標を収集します。既存のリージョンサービスの健全性ステータスを表示できます。次の図は、これらの Cloud Run サービスの健全性コンポーネントがサービスへのリクエストにどのように応答するかを示しています。

リージョンのサービスが異常な状態の場合、ロードバランサは異常なリージョンから正常なリージョンにトラフィックを転送します。リージョンが再び正常になると、トラフィックは回復します。

マルチリージョンデプロイで認証済みの Pub/Sub push サブスクリプションを使用する

デフォルトでは、Pub/Sub サービスは Pub/Sub サービスがメッセージを格納するのと同じ Google Cloud リージョン内の push エンドポイントにメッセージを配信します。この動作を回避するには、マルチリージョンの Cloud Run デプロイで認証済みの Pub/Sub push サブスクリプションを使用するをご覧ください。

手動フェイルオーバーを構成する

正常なリージョンにフェイルオーバーするようにトラフィックを手動で構成するには、グローバル外部アプリケーションロードバランサの URL マップを変更します。

グローバル外部アプリケーションロードバランサの URL マップを更新するには、--global フラグを使用して、バックエンドサービスから NEG を削除します。
```
gcloud compute backend-services remove-backend BACKEND_NAME \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-region=REGION \
--global
```
次のように置き換えます。
- BACKEND_NAME: バックエンドサービスの名前。
- NEG_NAME: ネットワークエンドポイントグループリソースの名前（例: myservice-neg-uscentral1）。
- REGION: NEG が作成され、サービスを削除するリージョン。例: us-central1,asia-east1
正常なリージョンがトラフィックを処理していることを確認するには、https://<domain-name> に移動します。

次のステップ

準備状況プローブなど、Cloud Run サービスのヘルスチェックを構成する方法を確認する。

Cloud Run の準備状況プローブとサービスの健全性に関する Go コードサンプルを確認する。

複数のリージョンからのトラフィックを処理する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

ロールを付与する

コンソール

gcloud

サービスを複数のリージョンにデプロイする

マルチリージョン サービスをデプロイする

gcloud

YAML

Terraform

マルチリージョン サービスを更新する

gcloud

YAML

マルチリージョン サービスを削除する

グローバル外部アプリケーション ロードバランサを構成する

グローバル外部アプリケーション ロードバランサを作成する

gcloud

Terraform

Cloud Shell を準備する

ディレクトリを準備する

変更を適用する

リージョン単位のネットワーク エンドポイント グループを構成する

gcloud CLI

Terraform

ドメインの DNS レコードを構成する

認証済みサービスを使用する場合のカスタム オーディエンスを構成する

ロードバランサのプロビジョニングを待つ

ステータスを確認

HTTP から HTTPS へのリダイレクトを設定する

gcloud CLI

Terraform

Cloud Run サービスの健全性を使用してクロスリージョン フェイルオーバーを自動化する

制限事項

リージョンの健全性を報告する

ベスト プラクティス

推奨されるロールアウト プロセス

ヘルスチェックをモニタリングする

マルチリージョン デプロイで認証済みの Pub/Sub push サブスクリプションを使用する

手動フェイルオーバーを構成する

次のステップ

複数のリージョンからのトラフィックを処理する

マルチリージョンサービスをデプロイする

マルチリージョンサービスを更新する

マルチリージョンサービスを削除する

グローバル外部アプリケーションロードバランサを構成する

グローバル外部アプリケーションロードバランサを作成する

リージョン単位のネットワークエンドポイントグループを構成する

認証済みサービスを使用する場合のカスタムオーディエンスを構成する

Cloud Run サービスの健全性を使用してクロスリージョンフェイルオーバーを自動化する

ベストプラクティス

推奨されるロールアウトプロセス

マルチリージョンデプロイで認証済みの Pub/Sub push サブスクリプションを使用する