リクエストのルーティング方法

リージョン ID

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。

詳しくは、リージョン ID をご覧ください。

このページでは、ユーザーからの HTTP リクエストが、適切なバージョンのサービスにどのように到達するかについて説明します。リクエストは、次の方法でルーティングできます。

これらのオプションは、デプロイ済みのアプリにのみ適用されます。ローカルでテストするときのルーティングの動作は、使用している個々のランタイムと開発環境に応じて異なります。

URL を使用してルーティングする

アプリが App Engine で実行されたら、次の URL を使用して HTTP リクエストをアプリに送信できます。
https://PROJECT_ID.REGION_ID.r.appspot.com

PROJECT_ID は、アプリを含む Google Cloud プロジェクトの ID です。

この URL は、トラフィックを受信するように構成したバージョンのアプリのデフォルト サービスにリクエストを送信します。

サービスとバージョンの URL

アプリで複数のサービスを作成する場合は、各サービスに専用の URL が割り当てられます。サービスの各バージョンには独自の URL があるため、トラフィックを受信するよう構成する前に新しいバージョンをデプロイしてテストできます。

特定のサービスとバージョンの URL は次の形式になります。

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

特定のバージョンを対象とする必要がない場合は、VERSION-dot- を省略できます。

アプリのサービスとバージョンの ID を取得するには、次のいずれかのツールを使用できます。

コンソール

Google Cloud コンソールで、対応するインスタンス、サービス、バージョンのページを表示できます。

gcloud

特定の Google Cloud プロジェクト内のリソース ID の一覧を表示するには、gcloud app instances list コマンドを実行します。

API

リソース ID をプログラムで取得する方法については、Admin API の list メソッドをご覧ください。

URL の例

以下に、いくつかの App Engine の URL の例を示します。これらは App Engine がアプリに割り当てる appspot.com ドメインと、アプリ用に設定できるカスタム ドメインの両方を示しています。

  • default サービスの使用可能なインスタンスにリクエストを送信する場合:
    
https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN

    default サービスの中で、このトラフィック用に構成されている任意のバージョンがトラフィックを受信します。

  • 特定のサービスで使用可能なインスタンスにリクエストを送信します。
    
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN

    対象のサービスの中で、このトラフィック用に構成されている任意のバージョンがリクエストを受信します。対象のサービスが存在しない場合、リクエストはソフト ルーティングされます。

  • 特定のバージョンの
    default サービスの使用可能なインスタンスにリクエストを送信する場合:
    
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN

    対象のサービスが存在しない場合、リクエストは default サービスに送信されます。

ソフト ルーティング

リクエストがホスト名の PROJECT_ID.REGION_ID.r.appspot.com 部分と一致するものの、存在しないサービス、バージョン、インスタンス名が含まれている場合、リクエストは default サービスにルーティングされます。ソフト ルーティングは、カスタム ドメインには適用されません。ホスト名が無効な場合、カスタム ドメインへのリクエストは HTTP 404 ステータス コードを返します。

ターゲット ルーティング

次の URL パターンは、そのターゲットに到達することが保証されています（ターゲットが存在する場合）。これらのリクエストは傍受されず、ディスパッチ ファイルに定義されているパターンで再ルーティングされません。

  • 特定のサービスとバージョンの使用可能なインスタンスにリクエストを送信する場合:
    
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

  • 手動でスケーリングするサービスを使用する場合、特定のインスタンスをターゲットに送信するには、リクエストにインスタンス ID を組み込みます。インスタンス ID は、0 から実行中のインスタンスの合計数までの範囲の整数であり、次のように指定できます。

    特定のインスタンス内の特定のサービスとバージョンにリクエストを送信する場合:

    https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN

ディスパッチ ファイルを使用してルーティングする

App Engine の URL に基づくルーティング ルールをオーバーライドするディスパッチ ファイルを作成し、独自のカスタム ルーティング ルールを定義できます。ディスパッチ ファイルを使用すると、リクエスト URL のパスまたはホスト名に基づいて受信リクエストを特定のサービスに送信できます。

ディスパッチ ファイルの作成

ディスパッチ ファイルを作成するには:

  1. プロジェクト ディレクトリのルートか、default サービスのルート ディレクトリに dispatch.yaml という名前のファイルを作成します。

  2. dispatch.yaml リファレンスを参照して、ファイルにルーティング ルールを定義します。

ルーティング ルールについては、次の点にご注意ください。

  • ルーティング ルールは、最大 20 個まで定義できます。各ルールには、url 要素と service 要素が含まれている必要があります。
  • ルールには、HTTP URL パターンを使用し、サブドメインの区切りに「.」を使用する必要があります。HTTPS の「-dot-」表記で定義した URL はサポートされません。
  • このルールは、cron ファイルに定義した URL にも適用されます。

たとえば、https://simple-sample.uc.r.appspot.com/mobile/ などのモバイル リクエストはモバイル フロントエンドにルーティングし、https://simple-sample.uc.r.appspot.com/work/ などのワーカー リクエストは静的バックエンドにルーティングするためのディスパッチ ファイルを作成できます。

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

ディスパッチ ファイルのデプロイ

ディスパッチ ファイルをデプロイするには、次のコマンドを実行します。

    gcloud app deploy dispatch.yaml

Cloud Load Balancing を使用してルーティングする

Cloud Load Balancing は個別のプロダクトで、これを使用すると、Google Cloud 上で実行されるすべてのアプリケーションに対し、高度なネットワークを構成することが可能になります。

サーバーレス アプリで HTTP(S) 負荷分散を有効にすると、次のことが可能になります。

  • 他のサービスと共有されない専用の IPv4 または IPv6 の IP アドレスから動作するように、サーバーレス アプリを構成する。

  • Compute Engine、Google Kubernetes Engine、Cloud Storage で使用する同じ SSL 証明書と秘密鍵を再利用する。これにより、サーバーレス アプリの個別の証明書を管理する必要がなくなります。

ロードバランサにより、dispatch.yaml ファイル内のルーティング ルールが妨げられることや、ロードバランサがルーティング ルールに関わることはありません。dispatch.yaml ルールは、サーバーレス NEG が App Engine にトラフィックを転送するまで評価されません。

次の点にご注意ください。

  • アプリがロードバランサ（および使用している場合は VPC）から送信されたリクエストのみを受信するように、上り（内向き）制御を使用することをおすすめします。使用しない場合、ユーザーはアプリの App Engine URL を使用して、ロードバランサ、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、ロードバランサを経由して渡される秘密鍵をバイパスできます。

App Engine の URL に関するその他の詳細

URL のリージョン ID について

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r が App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。

アプリのリージョン ID は次のツールで確認できます。

コンソール

Google Cloud コンソールでは、アプリのインスタンス、サービス、バージョンの URL を確認できます。

これらの URL にはリージョン ID が含まれます。

gcloud

アプリまたはサービスのデプロイに成功した後に、gcloud app deploy コマンドを実行すると、URL が表示されます。この URL にはリージョン ID が含まれます。

デプロイされているサービスの URL を表示するには:

  1. gcloud app versions list コマンドを入力して、特定のサービスのバージョンの一覧を取得します。たとえば、デフォルトのサービスのバージョンを表示するには、「gcloud app versions list --service=default」を入力します。

  2. gcloud app versions describe コマンドを入力します。このコマンドの出力には、バージョンの URL とアプリのリージョン ID が含まれます。たとえば、デフォルト サービスのバージョン 20191023t101741 を指定するには、gcloud app versions describe 20191023t101741 --service=default を入力します。

リクエスト データに含まれるドメイン名

リクエストに使用されるドメイン名は、アプリに渡されるリクエスト データに含まれています。したがって、リクエスト データを使用すると、リクエストのドメイン名に応じてアプリの応答を制御できます。たとえば、正式なドメインにリダイレクトする場合には、Host リクエスト ヘッダーを確認してドメイン名に応じて応答するようにアプリをコーディングします。