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

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

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

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

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

リクエストとドメイン

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 Console で、対応するインスタンスサービスバージョンのページを表示できます。

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]

デフォルト サービス

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

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 リファレンスをご覧ください。

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

ディスパッチ ファイルは、プロジェクト ディレクトリのルートか、default サービスのルート ディレクトリのいずれかに配置する必要があります。ディスパッチ ファイルには最大 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 リファレンス ドキュメントをご覧ください。

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

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

gcloud

gcloud app deploy dispatch.yaml
このページは役立ちましたか?評価をお願いいたします。

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

Python 3 の App Engine スタンダード環境