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

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

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

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

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

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

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

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

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

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

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

2. dispatch.yaml リファレンスを参照して、ファイルにルーティング ルールを定義します。

ルーティング ルールについては、次の点にご注意ください。

• ルーティング ルールは、最大 20 個まで定義できます。各ルールには、url 要素と service 要素が含まれている必要があります。
• ルールには、HTTP URL パターンを使用し、サブドメインの区切りに「.」を使用する必要があります。HTTPS の「-dot-」表記で定義した URL はサポートされません。
• このルールは、cron.yaml ファイルに定義した 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 を使用してディスパッチ ファイルをデプロイするには、次のコマンドを実行します。

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

App Engine フレキシブル環境で Cloud Load Balancing を使用する場合の指標の不整合

App Engine フレキシブル環境ダッシュボードには、フレキシブル環境が管理するバックエンド経由でルーティングされたリクエストのみに関する指標がすべて表示されます。Cloud Load Balancing で App Engine フレキシブル環境を使用している場合、App Engine の指標表に含まれる特定の指標が loadbalancing テーブルからの指標として代わりにレポートされます。詳細については、HTTP(S) ロード バランシングのロギングとモニタリングをご覧ください。

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

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

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

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

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

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