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

世界中のユーザーに迅速にレスポンスを返すには、複数のリージョンにサービスをデプロイし、最も近いリージョンにユーザーをルーティングする必要があります。

ただし、Cloud Run(フルマネージド)サービスが個々のリージョンにデプロイされ、サービスの別のリージョンにルーティングするために、外部 HTTP(S) 負荷分散を構成する必要があります。

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

始める前に

ロードバランサの作成

外部ロードバランサを作成するには、以下の手順で説明するように、さまざまなネットワーク リソースを作成して接続します。

コマンドライン

  1. 静的 IP アドレスを予約することにより、ロードバランサを再作成するときに DNS レコードを更新する必要がなくなります。
    gcloud compute addresses create --global SERVICE_IP
    上記のコマンドの SERVICE_IP は、IP アドレス リソースの名前(myservice-ip など)に置き換えます。

    この IP アドレスは、訪問者に最も近い Google データセンターまたは接続拠点にルーティングするグローバル エニーキャスト IPv4 アドレスです。

  2. バックエンド サービスを作成します。
    gcloud compute backend-services create --global BACKEND_NAME

    上記のコマンドで、BACKEND_NAME をバックエンド サービスに付ける名前(myservice-backend など)に置き換えます。

  3. URL マップを作成します。
    gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME

    URLMAP_NAME は、URL マップに付ける名前(myservice-urlmap など)に置き換えます。

  4. HTTPS トラフィックを処理するために、ドメインのマネージド TLS 証明書を作成します。example.com はドメイン名で置き換えます。
    gcloud beta compute ssl-certificates create CERT_NAME \
      --domains=example.com

    CERT_NAME は、マネージド SSL 証明書に付ける名前(myservice-cert など)に置き換えます。

  5. ターゲット HTTPS プロキシを作成します。
    gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
      --ssl-certificates=CERT_NAME \
      --url-map=URLMAP_NAME

    HTTPS_PROXY_NAME は、ターゲット HTTPS プロキシに付ける名前(myservice-https など)に置き換えます。

  6. 作成したネットワーク リソースを 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 など)に置き換えます。

複数のリージョンへのデプロイ

使用可能な Cloud Run(フルマネージド)のリージョンにサービスをデプロイします。管理を容易にするため、複数のリージョンで同じサービス名を使用できます。

  1. サービスを利用可能にするリージョンを選択します。

  2. Cloud Run サービスを個々のリージョンにデプロイします。

      gcloud run deploy SERVICE_NAME \
          --platform=managed \
          --allow-unauthenticated \
          --image=IMAGE_URL \
          --region=REGION
    

    次の変数を置き換えます。

    • REGION は、デプロイ先のいずれか 1 つのリージョンに置き換えます。
    • SERVICE_NAME は、実際のサービスの名前に置き換えます。複数のリージョンで同じサービス名を使用すると、マルチリージョン デプロイを簡単にトラッキングできるようになります。
    • IMAGE_URL は、コンテナ イメージへの参照(gcr.io/myproject/my-image:latest など)に置き換えます。
  3. リージョンごとに前の手順を繰り返します。

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(フィンランド)
  • europe-west1(ベルギー)
  • europe-west4(オランダ)
  • us-central1(アイオワ)
  • us-east1(サウスカロライナ)
  • us-east4(北バージニア)
  • us-west1(オレゴン)

ティア 2 料金を適用

  • asia-east2(香港)
  • asia-northeast3(ソウル、韓国)
  • asia-southeast1(シンガポール)
  • asia-southeast2 (ジャカルタ)
  • asia-south1(ムンバイ、インド)
  • australia-southeast1(シドニー)
  • europe-central2(ワルシャワ、ポーランド)
  • europe-west2(ロンドン、イギリス)
  • europe-west3(フランクフルト、ドイツ)
  • europe-west6(チューリッヒ、スイス)
  • northamerica-northeast1(モントリオール)
  • southamerica-east1(サンパウロ、ブラジル)
  • us-west2(ロサンゼルス)
  • us-west3(ラスベガス)
  • us-west4(ソルトレイクシティ)

Cloud Run サービスをすでに作成している場合は、Cloud Console の Cloud Run ダッシュボードにリージョンを表示できます。

リージョン バックエンドの構成

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

  1. REGION に、Cloud Run(フルマネージド)サービスのネットワーク エンドポイント グループを作成します。

    gcloud beta 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 は、実際のサービスの名前に置き換えます。
  2. ネットワーク エンドポイント グループをバックエンド サービスに追加します。

    gcloud beta compute backend-services add-backend --global BACKEND_NAME \
        --network-endpoint-group-region=REGION \
        --network-endpoint-group=NEG_NAME

    前の手順で作成した NEG_NAME をリージョンに指定します。

  3. リージョンごとに上記の手順を繰り返します。

ドメインの DNS レコードの構成

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

  1. 次のコマンドを実行して、ロードバランサの予約済み IP アドレスを見つけます。

      gcloud compute addresses describe --global SERVICE_IP --format='value(address)'

    SERVICE_IP は、前に作成した IP アドレスの名前に置き換えます。このコマンドにより、IP アドレスが出力されます。

  2. この IP アドレスで A レコードを追加して、ドメインの DNS レコードを更新します。

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

ロードバランサの IP アドレスでドメインを構成した後は、DNS レコードが反映されるまでしばらく待つ必要があります。同様に、マネージド TLS 証明書がドメインに発行され、HTTPS トラフィックがグローバルに配信可能になるまで、しばらく待つ必要があります。

ロードバランサがトラフィックの配信を開始するまでに最大で 30 分かかることがあります。

準備ができたら、ウェブサイトの URL の先頭に https:// を付けて、アクセスしてみてください。

ステータスの確認

  1. DNS コマンドライン伝播のステータスを確認するには、dig コマンドライン ユーティリティを使用します。

    dig A +short example.com

    DNS レコードに構成した IP アドレスが出力に表示されます。

  2. マネージド証明書の発行ステータスを確認して、次を実行します。

    gcloud beta compute ssl-certificates describe CERT_NAME

    CERT_NAME は、前に SSL 証明書リソースに選択した名前で置き換えます。

    出力には、status: ACTIVE を含む行が表示されます。

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

デフォルトでは、転送ルールは単一のプロトコルのみを処理するため、http:// エンドポイントへのリクエストには 404 Not Found が返されます。http:// URL へのリクエストを https:// プロトコルにリダイレクトする必要がある場合は、次の手順を使用して追加の URL マップと転送ルールを作成する必要があります。

  1. リダイレクト ルールで 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 など)で置き換えます。

  2. URL マップを使用してターゲット HTTP プロキシを作成します。

    gcloud compute target-http-proxies create HTTP_PROXY_NAME \
      --url-map=HTTP_URLMAP_NAME

    HTTP_PROXY_NAME は、作成するターゲット HTTP プロキシの名前(myservice-http など)で置き換えます。

  3. 同じ予約済み 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 など)で置き換えます。

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

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