注: Java 8 は、2024 年 1 月 31 日にサポートが終了しました。既存の Java 8 アプリケーションは引き続き実行され、トラフィックを受信します。ただし、サポート終了日を過ぎると、ランタイムを使用するアプリケーションの再デプロイが App Engine によってブロックされることがあります。サポートされている最新バージョンの Java に移行することをおすすめします。

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

リージョン ID

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

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

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

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

ローカルの開発用サーバーを使用してアプリをテストする場合は、利用できるルーティングとディスパッチの機能が多少異なります。本番環境サーバーと開発用サーバーの両方で使用できる 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 を取得するには、次のいずれかのツールを使用できます。

コンソールgcloudAPI

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

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

リソース 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
```
注: 自動スケーリングまたは基本スケーリングが構成されているサービスでは、特定のインスタンスをターゲットにすることはできません。インスタンス ID は、0 から実行中のインスタンスの合計数までの整数にする必要があります。スケーリングタイプやインスタンスクラスに関係なく、特定のインスタンスにリクエストを送信するには、インスタンス内のサービスまたはバージョンをターゲットにする必要があります。

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

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

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

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

app.yaml などの他の構成ファイルに使用するディレクトリと同じディレクトリに dispatch.yaml という名前のファイルを作成します。
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

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

現在使用中のバージョンを変更せずにディスパッチ構成ファイルをデプロイするには、お使いの環境に応じて、ディスパッチファイルを含むディレクトリで次のいずれかのコマンドを使用します。

gcloudMavenGradleIDE

gcloud app deploy dispatch.yaml

mvn appengine:deployDispatch dispatch.yaml

gradle appengineDeployDispatch dispatch.yaml

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 は次のツールで確認できます。

コンソールgcloud

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

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

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

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

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

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

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