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

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

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

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

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

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

リクエストとドメイン

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 の [バージョン] ページで確認できます。

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

すべてのサービスが、デフォルトで一般公開に設定されます。サービスへのアクセスを制限するには、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

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 管理コンソールのスクリーンショット

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

ディスパッチ ファイル

アプリに 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 ファイルを使用してアプリケーションを起動しようとすると、サーバーはログストリームでエラーを報告します。

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

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

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