リージョン ID
REGION_ID
は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r
は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。
詳しくは、リージョン ID をご覧ください。
このページでは、ユーザーからの HTTP リクエストが、適切なバージョンのサービスにどのように到達するかについて説明します。リクエストは、次の方法でルーティングできます。
これらのオプションは、デプロイ済みのアプリにのみ適用されます。ローカルでテストするときのルーティングの動作は、使用している個々のランタイムと開発環境に応じて異なります。
従来のバンドル サービスを使用してローカル開発用サーバーでアプリをテストする場合は、利用できるルーティングとディスパッチの機能が多少異なります。本番環境サーバーと開発用サーバーの両方で機能する URL をプログラムで作成するには、 get_hostname メソッド。詳しくは、開発サーバーでのルーティングをご覧ください。
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 プロジェクト内のリソース ID の一覧を表示するには、gcloud app instances list
コマンドを実行します。
リソース ID をプログラムで取得する方法については、Admin API の list
メソッドをご覧ください。
URL の例
以下に、いくつかの App Engine の URL の例を示します。これらは App Engine がアプリに割り当てる appspot.com
ドメインと、アプリ用に設定できるカスタム ドメインの両方を示しています。
default
サービスの使用可能なインスタンスにリクエストを送信する場合:https://
https://PROJECT_ID .REGION_ID .r.appspot.comCUSTOM_DOMAIN
default
サービスの中で、このトラフィック用に構成されている任意のバージョンがトラフィックを受信します。- 特定のサービスで使用可能なインスタンスにリクエストを送信します。
https://
https://SERVICE_ID -dot-PROJECT_ID .REGION_ID .r.appspot.comSERVICE_ID .CUSTOM_DOMAIN
対象のサービスの中で、このトラフィック用に構成されている任意のバージョンがリクエストを受信します。対象のサービスが存在しない場合、リクエストはソフト ルーティングされます。
- 特定のバージョンの
default
サービスの使用可能なインスタンスにリクエストを送信する場合:https://
https://VERSION_ID -dot-default-dot-PROJECT_ID .REGION_ID .r.appspot.comVERSION_ID .CUSTOM_DOMAIN
対象のサービスが存在しない場合、リクエストは
default
サービスに送信されます。
ソフト ルーティング
リクエストがホスト名の PROJECT_ID.REGION_ID.r.appspot.com
部分と一致するものの、存在しないサービス、バージョン、インスタンス名が含まれている場合、リクエストは default
サービスにルーティングされます。ソフト ルーティングは、カスタム ドメインには適用されません。ホスト名が無効な場合、カスタム ドメインへのリクエストは HTTP 404
ステータス コードを返します。
ターゲット ルーティング
次の URL パターンは、そのターゲットに到達することが保証されています(ターゲットが存在する場合)。これらのリクエストは傍受されず、ディスパッチ ファイルに定義されているパターンで再ルーティングされません。
特定のサービスとバージョンの使用可能なインスタンスにリクエストを送信する場合:
https://
https://VERSION -dot-SERVICE -dot-PROJECT_ID .REGION_ID .r.appspot.comVERSION_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 のパスまたはホスト名に基づいて受信リクエストを特定のサービスに送信できます。
ディスパッチ ファイルの作成
ディスパッチ ファイルを作成するには、次の手順で操作します。
他の構成ファイル(
app.yaml
など)に使用するディレクトリと同じディレクトリに、dispatch.yaml
は、プロジェクト ディレクトリのルートまたはdefault
サービスのルート ディレクトリにあります。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 の URL に関するその他の詳細
URL のリージョン ID について
REGION_ID
は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r
が App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。
アプリのリージョン ID は次のツールで確認できます。
Google Cloud コンソールでは、アプリのインスタンス、サービス、バージョンの URL を確認できます。
これらの URL にはリージョン ID が含まれます。
アプリまたはサービスのデプロイに成功した後に、gcloud app deploy
コマンドを実行すると、URL が表示されます。この URL にはリージョン ID が含まれます。
デプロイされているサービスの URL を表示するには:
gcloud app versions list
コマンドを入力して、特定のサービスのバージョンの一覧を取得します。たとえば、デフォルトのサービスのバージョンを表示するには、「gcloud app versions list --service=default
」を入力します。gcloud app versions describe
コマンドを入力します。このコマンドの出力には、バージョンの URL とアプリのリージョン ID が含まれます。たとえば、デフォルト サービスのバージョン 20191023t101741 を指定するには、gcloud app versions describe 20191023t101741 --service=default
を入力します。
リクエスト データに含まれるドメイン名
リクエストに使用されるドメイン名は、アプリに渡されるリクエスト データに含まれています。したがって、リクエスト データを使用すると、リクエストのドメイン名に応じてアプリの応答を制御できます。たとえば、正式なドメインにリダイレクトする場合には、Host
リクエスト ヘッダーを確認してドメイン名に応じて応答するようにアプリをコーディングします。