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

リージョン ID

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

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

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

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

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

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 を取得するには、次のいずれかのツールを使用できます。

コンソール

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

gcloud

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

API

リソース 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

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

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

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

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

  1. プロジェクト ディレクトリのルートか、default サービスのルート ディレクトリに dispatch.yaml という名前のファイルを作成します。

  2. 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

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

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

    gcloud app deploy dispatch.yaml

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 証明書、ロードバランサを経由して渡される秘密鍵をバイパスできます。

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

インスタンスのアドレスの検出

開発用サーバーは起動時に、すべての手動スケーリングのインスタンスを作成します。自動スケーリングおよび基本スケーリング サービスのインスタンスは動的に管理されます。サーバーは各サービスにポートを割り当て、クライアントはサーバーを使用して、ロード バランシングを行い、インスタンスを自動的に選択します。各サービスに対処するためのポート割り当ては、サーバーのログメッセージ ストリームに表示されます。次は、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

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

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

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

App Engine の URL に関するその他の詳細

URL のリージョン ID について

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

アプリのリージョン ID は次のツールで確認できます。

コンソール

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

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

gcloud

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

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

  1. gcloud app versions list コマンドを入力して、特定のサービスのバージョンの一覧を取得します。たとえば、デフォルトのサービスのバージョンを表示するには、「gcloud app versions list --service=default」を入力します。

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

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

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