App Engine の概要

リージョン ID

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

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

App Engine アプリは、1 つ以上のサービスからなる単一のアプリケーション リソースで構成されています。各サービスは、それぞれ異なるランタイムを使用したり、異なるパフォーマンス設定で動作したりするように構成できます。各サービス内で、そのサービスの複数のバージョンをデプロイします。その後、各バージョンは、処理するように構成したトラフィックの量に応じて、1 つ以上のインスタンス内で実行されます。

アプリケーションのコンポーネント

アプリケーション リソースを作成すると、Google Cloud プロジェクト内に App Engine アプリが作成されます。App Engine アプリケーションは、アプリを構成するサービス、バージョン、およびインスタンスのリソースを格納する最上位のコンテナです。App Engine アプリを作成すると、アプリコードや、設定、認証情報、アプリのメタデータなどのすべてのリソースが、選択したリージョン内に作成されます。

各 App Engine アプリケーションには少なくとも 1 つのサービス(default サービス)があり、アプリの課金ステータスに応じて多数のバージョンを保持できます。詳細については、後述の上限をご覧ください。

次の図に、複数のサービスで動作する App Engine アプリの階層を示します。この図で、アプリは 2 つのサービスからなり、各サービスは複数のバージョンで構成されています。このうち 2 つのバージョンが、複数のインスタンス上で稼働しています。

アプリのサービス、バージョン、インスタンスの階層グラフ

Datastore など、他の Google Cloud サービスは App Engine アプリ全体で共有されます。詳細については、ウェブサービスの構造化をご覧ください。

サービス

App Engine 内のサービスを使用することで、大規模なアプリを論理コンポーネントに分解できます。これらのコンポーネントは、App Engine の機能を安全な方法で共有し、相互に通信できます。通常、App Engine サービスはマイクロサービスのように動作します。アプリ全体を単一のサービスで実行することも、複数のサービスを設計およびデプロイして、一連のマイクロサービスとして実行することもできます。

たとえば、お客様のリクエストを処理するアプリには、次のような異なるタスクを処理する個別のサービスが含まれていることがあります。

  • モバイル デバイスからの API リクエスト
  • 管理タイプの内部リクエスト
  • 課金パイプラインやデータ分析などのバックエンド処理

App Engine の各サービスは、アプリのソースコードと、対応する App Engine 構成ファイルで構成されています。サービスにデプロイする一連のファイルは、そのサービスの単一バージョンを表し、そのサービスに対してデプロイを行うたびに、同じサービス内に追加のバージョンが作成されます。

バージョン

それぞれのサービス内にアプリの複数のバージョンを用意することで、ロールバック用、テスト用、その他の一時的なイベント用といった、アプリの各種バージョンをすばやく切り替えることができます。トラフィックを移行または分割することで、1 つ以上の特定のバージョンのアプリにトラフィックをルーティングできます。

インスタンス

サービスに含まれる各バージョンは、1 つ以上のインスタンスで実行されます。デフォルトでは、App Engine は負荷に合わせてアプリのスケーリングを行います。アプリは、稼働中のインスタンスの数を増やしてパフォーマンスの一貫性を確保し、アイドル状態のインスタンスを最小限に減らしてコストを抑えます。インスタンスの詳細については、インスタンスの管理方法をご覧ください。

App Engine フレキシブル環境では、インスタンスは Compute Engine リソースを基盤にしています。App Engine フレキシブル環境のインスタンスが使用する一部のリソース(ディスク、CPU、メモリなど)は、プロジェクトの Compute Engine API の割り当てにカウントされます。App Engine による Compute Engine リソースの使用に関する詳細は、App Engine フレキシブル環境の概要をご覧ください。

アプリケーション リクエスト

アプリの各サービスの名前やサービス内の各バージョンの名前は、一意でなければなりません。こうした一意の名前は、URL によってトラフィックを特定のリソースにターゲット指定およびルーティングするために使用できます。次に例を示します。

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

なお、フレキシブル環境では、VERSION-dot-SERVICE-dot-PROJECT_IDVERSION はバージョンの名前、SERVICE はサービス名、PROJECT_ID はプロジェクト ID)全体の長さを 63 文字以下にする必要があります。また、名前の先頭や末尾にハイフンは使用できません。すべて含めた長さが 63 文字を超える場合、エラー DNS address could not be found. が表示されることがあります。

受信ユーザー リクエストは、トラフィックを処理するように構成されている、さまざまなサービスまたはバージョンにルーティングされます。特定のサービスやバージョンを対象にトラフィックをルーティングすることもできます。詳細については、サービス間の通信をご覧ください。

アプリケーション リクエストのロギング

アプリケーションがリクエストを処理するときに、独自のロギング メッセージを stdoutstderr に書き込むこともできます。アプリのログの詳細については、アプリケーション ログの書き込みをご覧ください。

上限

各アプリケーションのサービス、バージョン、インスタンス(手動スケーリング サービスの場合)の数には上限があります。

説明 上限
アプリケーションごとの最大サービス数 5
アプリケーションごとの最大バージョン数 5 *
手動スケーリングによるバージョンあたりの最大インスタンス数 20

*外部 HTTP ロードバランサによって使用されるバックエンド サービスなど、バックエンド サービスは最大バージョン数の上限にカウントされる場合があります。

また、アプリケーションの URL の文字数にも上限があります。

説明 上限
VERSION-dot-SERVICE-dot-PROJECT_ID URL のプロジェクト URL の最大文字数 63

すべてのプロジェクトに上記の上限があるわけではありません。時間とともに、Google Cloud Platform の使用量が多くなると、上限も大きくなる可能性があります。使用量の大幅な増加が見込まれる場合には、事前に Google Cloud コンソールの App Engine の [割り当て] ページから、割り当て量の調整をリクエストできます。