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

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

  • App Engine のデフォルトのルーティング ルールを、ドメインレベルで終わる URL のリクエストに適用します。

  • または、独自のルールに従って特定の URL パターンのルートを指定するディスパッチ ファイルを使用することもできます。

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

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

リクエストとドメイン

App Engine は、受信したリクエストのドメイン名を使用して、そのリクエストの対象がどのアプリであるかを判断します。ドメイン名が http://[YOUR_PROJECT_ID].appspot.com のリクエストは、ID が[YOUR_PROJECT_ID]のアプリにルーティングされます。どのアプリも無料で appspot.com ドメイン名を取得できます。

appspot.com ドメインは、[SUBDOMAIN]-dot-[YOUR_PROJECT_ID].appspot.com という形式のサブドメインもサポートしています。[SUBDOMAIN]は、ドメイン名の一部に使用できる任意の文字列です。ただし「.」文字は使用できません。このようにして任意のサブドメインに送信されたリクエストは、アプリにルーティングされます。

G Suite を使用してカスタム トップレベル ドメインを設定したうえで、そのサブドメインをさまざまなアプリ(Gmail や Google サイトなど)に割り当てることができます。また、App Engine アプリをサブドメインに関連付けることもできます。カスタム ドメインとアプリをマッピングする方法については、SSL によるカスタム ドメインの保護をご覧ください。

これらの URL に対するリクエストはすべて、トラフィックを受信するように構成されたアプリのバージョンに送信されます。アプリの各バージョンには専用の URL も割り当てられるので、新しいバージョンをデプロイしてテストしてから、トラフィックを受信するようにそのバージョンを構成できます。バージョン固有の URL では、appspot.com ドメイン名に加え、その特定のバージョンの ID を使用します(例: http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com)。バージョン固有の URL を含むサブドメインを使用することもできます(例: http://[SUBDOMAIN]-dot-[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com)。詳細と使用例については、URL 経由のルーティングをご覧ください。

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

URL 経由のルーティング

さまざまな特性レベルを指定して HTTP リクエストをターゲットにできます。次の例では、appspot.com をアプリのカスタム ドメイン(存在する場合)に置き換えることができます。URL の部分文字列[VERSION_ID][SERVICE_ID][MY_PROJECT_ID]はそれぞれアプリのリソース ID を表します。

ヒント: アプリのリソース ID を取得するには、次のツールを使用します。

Console

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

gcloud

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

API

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

デフォルトのルーティング

次の URL パターンには、デフォルトのルーティング動作があります。ディスパッチ ファイルに一致パターンが定義されている場合、デフォルトのルーティングは上書きされます。

  • default サービスで使用可能なインスタンスにリクエストを送信します。
    https://[MY_PROJECT_ID].appspot.com
    http://[MY_CUSTOM_DOMAIN]

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

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

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

  • 特定のバージョンの
    default サービスで使用可能なインスタンスにリクエストを送信します。
    https://[VERSION_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[MY_CUSTOM_DOMAIN]

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

ソフト ルーティング

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

ターゲット ルーティング

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

  • 特定のサービスとバージョンの使用可能なインスタンスにリクエストを送信する場合:
    https://[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[SERVICE_ID].[MY_PROJECT_ID].[MY_CUSTOM_DOMAIN]
  • 手動でスケーリングを行うサービスを使用する場合、インスタンス ID を使用してリクエストを特定のインスタンスに送信できます。インスタンス ID は、0 から実行中のインスタンスの合計数までの範囲の整数であり、次のように指定できます。

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

    https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[INSTANCE_ID].[VERSION_ID].[SERVICE_ID].[MY_CUSTOM_DOMAIN]

デフォルト サービス

default サービスは、App Engine にアプリの最初のバージョンをデプロイする際に作成されます。サービスが指定されていないリクエストや無効なサービスが指定されているリクエストは、default サービスにルーティングされます。これらのリクエストは、default サービス内でトラフィックを受信するように構成されているバージョンで処理されます。トラフィックに構成済みのバージョンは、GCP Console の [バージョン] ページで確認できます。

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

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

URL パターンを説明するために、サンプルの GCP プロジェクトを使用します。このプロジェクトの ID は requestsProject であり、2 つのサービスとバージョンを実行するアプリが含まれています。このサンプルアプリの default サービスにはバージョン vFrontend が含まれ、2 番目のサービス service2 にはバージョン vBackend が含まれます。

特定のサービスとバージョンをターゲットに設定するには、次の URL パターンを使用します。

  1. HTTPS を使用して default サービスのバージョンをターゲットに設定するには、次のパターンを使用します。

    https://vFrontend-dot-default-dot-requestsProject.appspot.com
    https://vFrontend-dot-requestsProject.appspot.com
    
  2. HTTPS を利用せずにカスタム ドメインを使用して vBackend バージョンをターゲットに設定するには、次のパターンを使用します。

    http://vBackend.service2.example.net
    http://vBackend.example.net
    

    requestsProject.appspot.comexample.net ドメインにマッピングされます。

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

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

ディスパッチ ファイルの作成方法については、dispatch.yaml リファレンスをご覧ください。

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

注: このリファレンスでは、YAML 形式の構成ファイルを使用します。このファイルは、gcloud コマンドラインなどの Cloud SDK に基づくツールや、Cloud SDK ベースの MavenGradleEclipseIntelliJ の各プラグインで使用されます。appcfg などの App Engine SDK for Java 用のツールを使用している場合は、XML 形式を使用します。

ディスパッチ ファイルは、app.yaml など、他の構成ファイルに使用するディレクトリと同じディレクトリに配置されている必要があります。ディスパッチ ファイルでは最大 20 個のルーティング ルールを定義できます。各ルールは service 要素と url 要素から構成されます。

たとえば、http://simple-sample.appspot.com/mobile/ などのモバイル リクエストはモバイル フロントエンドにルーティングし、http://simple-sample.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

dispatch.yaml の定義方法については、dispatch.yaml リファレンス ドキュメントをご覧ください。

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

dispatch.yaml ファイルはソースコードのディレクトリ内であればどこに配置しても構いません。

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

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

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

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

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

ローカルの開発用サーバーでは、起動時にすべてのインスタンスを作成します。このとき、開発用サーバーでは基本スケーリング インスタンスがサポートされていないことに注意してください。作成されるインスタンスごとに個別のポートが割り当てられます。ポート割り当ては、サーバーのログメッセージ ストリームに表示されます。ウェブ クライアントは、このポートをターゲットに指定することで、特定のインスタンスと通信できます。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/ http://v1.service-auto.[PROJECT_ID].appspot.com/
service-manual 0 http://localhost:43190/ http://0.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual 1 http://localhost:52642/ http://1.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual (未使用) http://localhost:12361/ http://v1.service-manual.[PROJECT_ID].appspot.com/

Maven または Gradle プラグインを使用している場合には、ローカル開発用サーバーで使用されるポート番号を割り当てることができます。詳細については、Apache MavenApache Maven(Cloud SDK ベース)または Gradle をご覧ください。

ディスパッチ ファイル

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

フィードバックを送信...

Java の App Engine スタンダード環境