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

リージョン ID

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

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

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

ローカルの開発用サーバーを使用してアプリをテストする場合は、利用できるルーティングとディスパッチの機能が多少異なります。本番環境サーバーと開発用サーバーの両方で使用できる URL をプログラムで作成するには、ModulesService.getVersionHostname メソッドを使用します。

詳しくは、開発用サーバーでのルーティングをご覧ください。

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. app.yaml などの他の構成ファイルに使用するディレクトリと同じディレクトリに 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

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

IntelliJ または Eclipse を使用する場合は、デプロイメント フォームを使用して、デプロイ対象の個々の構成ファイルを選択します。

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 証明書、ロードバランサを経由して渡される秘密鍵をバイパスできます。

開発用サーバーでのルーティング

インスタンス アドレスを検索する

ローカルの開発用サーバーでは、起動時にすべてのインスタンスを作成します。このとき、開発用サーバーでは基本スケーリング インスタンスがサポートされていないことに注意してください。作成されるインスタンスごとに個別のポートが割り当てられます。ポート割り当ては、サーバーのログメッセージ ストリームに表示されます。ウェブ クライアントは、このポートをターゲットに指定することで、特定のインスタンスと通信できます。1 つのインスタンス（とポート）のみが自動スケーリング サービス用に作成されます。サーバーログには次のように記録されます（サービスは以前はモジュールと呼ばれていたことに注意してください）。

INFO: Module instance service-auto is running at http://localhost:37251/

手動スケーリング サービスの各インスタンスに、一意のポートが割り当てられます。

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

さらに、それぞれの手動スケーリング サービスに追加ポートが 1 つ割り当てられるため、クライアントは特定のインスタンスを指定することなくサービスにアクセスできます。このポートへのリクエストは、構成されたいずれかのインスタンスに自動的にルーティングされます。

INFO: Module instance service-manual is running at http://localhost:12361/

次の表に、開発用サーバーと App Engine 環境でこれらのサービスを呼び出す方法を示しています。

サービス インスタンス 開発用サーバー アドレス App Engine アドレス
service-auto （未使用） http://localhost:37251/ https://v1-dot-service-auto-dot-PROJECT_ID.REGION_ID.r.appspot.com/
service-manual 0 http://localhost:43190/ https://0-dot-v1-dot-service-manual-dot-PROJECT_ID.REGION_ID.r.appspot.com/

ローカル開発用サーバーで使用されます。詳細については、Apache Maven または Gradle をご覧ください。

ディスパッチ ファイル

ローカルの開発用サーバーを起動している場合、ディスパッチ ファイルはすべて無視されます。インスタンスをターゲットに指定する唯一の方法は、インスタンスのポートを使用することです。

サービスへのアクセスを制限する

すべてのサービスが、デフォルトで一般公開に設定されます。サービスへのアクセスを制限する場合は、<role-name>admin</role-name> 要素をそのセキュリティ制約に追加します。

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 リクエスト ヘッダーを確認してドメイン名に応じて応答するようにアプリをコーディングします。