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

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

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

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

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

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

リクエストとドメイン

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]

デフォルト サービス

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

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

すべてのサービスが、デフォルトで一般公開に設定されます。サービスへのアクセスを制限するには、サービスのハンドラlogin: admin 要素を追加します。

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

appcfg

元の App Engine SDK をインストールする場合は、次のコマンドを実行できます。

appcfg.py update_dispatch [YOUR_APP_DIR]

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

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

開発用サーバーは起動時に、すべての手動スケーリングのインスタンスを作成します。自動スケーリングおよび基本スケーリング サービスのインスタンスは動的に管理されます。サーバーは各サービスにポートを割り当て、クライアントはサーバーを使用して、ロードバランシングを行い、インスタンスを自動的に選択します。各サービスに対処するためのポート割り当ては、サーバーのログメッセージ ストリームに表示されます。次は、3 つのサービスを定義するアプリのポートです(各サービスのスケーリング タイプは関係ありません)。

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

サービスのアドレス(http://localhost:8082/ など)を使用する場合、サーバーはそのサービスのインスタンスを選択(または作成)し、そのインスタンスにリクエストを送信します。

サーバーは、サービスの各インスタンスに一意のポートを割り当てます。これらのポートを検出するには、管理サーバーを使用する必要があります。管理サーバーには一意のポートがあり、それはメッセージログに表示されています。

INFO Starting admin server at: http://localhost:8000

このアドレスにより、管理サーバーのコンソールに移動できます。そこから [Instances] をクリックし、アプリのインスタンスの動的状態を確認できます。

dev_appserver admin console

手動インスタンスと基本インスタンスにはそれぞれ、別々のエントリが表示されます。インスタンス番号は、各インスタンスの一意のポートアドレスとリンクしています。リンクの上にマウスを置くと、そのインスタンスに割り当てられたポートが表示されます。または、リンクをクリックすると、そのインスタンスにリクエストが直接、送信されます。

ディスパッチ ファイル

アプリに dispatch.yaml ファイルが含まれている場合、ログメッセージ ストリームにはディスパッチ ポートが含まれます。

INFO Starting dispatcher running at: http://localhost:8080

このポートへのリクエストは、ディスパッチ ファイルのルールに従ってルーティングされます。サーバーはホスト名(url: "customer1.myapp.com/*" など)を含む dispatch.yaml ファイル ルールをサポートしません。相対パスパターン(url: "*/fun")を持つルールが機能するので、http://localhost/fun/mobile のような URL を使用してインスタンスに到達できます。ホストベースのルールが含まれる dispatch.yaml ファイルを使用してアプリケーションを起動しようとすると、サーバーはログストリームでエラーを報告します。

このページは役立ちましたか?評価をお願いいたします。

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

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