リージョン ID
REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。
詳しくは、リージョン ID をご覧ください。
このガイドでは、App Engine アプリのサービスと関連するリソースを構造化する方法を説明します。
ディレクトリ構造
App Engine サービスの各バージョンは、app.yaml 構成ファイルで定義されます。単純なアプリでは、app.yaml ファイルの定義がデプロイの最小要件になります。app.yaml ファイルは、デプロイ記述子の役割を果たし、特定のバージョンのサービスについて、スケーリング タイプや、ランタイム、ハンドラ、その他のリソース設定を定義します。複数のバージョンのサービスをデプロイする場合は、同じディレクトリ内に複数の YAML ファイルを作成して、各バージョンの構成を表すことができます。
ローカルで開発している場合は、アプリのルートにサービスごとに別個のディレクトリを作成できます。GitHub などのバージョン管理システム（VCS）から取得したアプリをホストする場合は、サービスごとにリポジトリ内の別個のディレクトリを使用するように、または別個のリポジトリを使用するように、アプリを構造化することもできます。各ディレクトリまたはリポジトリは 1 つのサービスを表し、そのサービスに関連するソースコードと app.yaml ファイルを含みます。
オプションで、各サービスの app.yaml ファイルに一意の名前を指定することもできます。たとえば、構成ファイルにサービスを表す名前を付けたり、特定のサービスの各バージョンを表す一意の名前（service1.yaml や app.standard.yaml など）を使用したりできます。
その他のオプションの構成ファイルは、アプリの default サービスのルート ディレクトリまたはリポジトリに配置する必要があります。これらのオプションの構成ファイルは、特定のサービスに固有でないアプリ全体の設定を適用するもので、dispatch.yaml、index.yaml、cron.yaml ファイルなどがあります。
例
簡単なアプリではアプリのソースファイルと同じ場所に app.yaml を追加するだけで済みます。単一サービスのアプリの場合、そのアプリには default サービスのみが含まれ、すべてのファイルを同じディレクトリ（そのアプリのルート）内に配置できます。
次の例は、アプリをローカルで開発する場合に、3 つのサービスを含むアプリがどのようになるかを構造化する方法を示しています。オプションの dispatch.yaml ファイルは、そのアプリのルート ディレクトリに追加されています。また、ルートには、アプリの各サービスに対応する 3 つのディレクトリがあります。service1 のサブディレクトリには、そのサービスのソースファイルと構成ファイルが含まれています。同様に、service2 と service3 は別々のディレクトリにあり、各ディレクトリに各サービスのファイルが含まれていますが、service3 には YAML 構成ファイルの 2 つのバージョンが含まれています。
次の例では、1 つのサービスにオプションの dispatch.yaml ファイルと、そのサービスの異なるバージョンを表す 2 つの構成ファイル（service1.yaml と service2.yaml）があります。
インスタンスの稼働率に関する設計上の考慮事項
ハードウェアやソフトウェアの障害のため、事前の警告なくインスタンスが途中で終了したり頻繁に再起動したりする場合があり、このような障害の解決に長い時間がかかることもあります。アプリケーションはこのような障害に対処できる必要があります。
インスタンスの再起動によるダウンタイムを回避するには、次のような手法が効果的です。
- インスタンスの再起動や新規インスタンスの起動にかかる時間を短縮する。
- 長時間実行される処理では、チェックポイントを定期的に作成して、その状態から再開できるようにする。
- アプリを「ステートレス」にして、インスタンスに何も格納されないようにする。
- 非同期タスクの実行にキューを使用する。
- インスタンスを手動スケーリングとして構成する場合:
- 複数のインスタンス間でロード バランシングを行う。
- 通常のトラフィックの処理に必要な数よりも多くのインスタンスを構成する。
- 手動スケーリング インスタンスを利用できないときにキャッシュ内の結果を使用するよう、フォールバック ロジックを作成する。
インスタンスの詳細については、インスタンスの管理方法をご覧ください。
default サービス
すべての App Engine アプリケーションには default サービスが含まれています。アプリの初期バージョンを default サービスにデプロイする必要があります。その後、追加のサービスを作成してアプリにデプロイできます。
default サービスは、app.yaml で service: default の設定を使用して指定できます（この設定は省略可能です）。
Java と以前のバンドル サービスを使用する場合は、appengine-web.xml で <service>default</service> を設定してデフォルト サービスを指定できます。
Google Cloud プロジェクトを使用するアプリに送信されたリクエストは、default サービスに送信されます（例: https://PROJECT_ID.REGION_ID.r.appspot.com）。他のサービスをターゲットに設定する方法については、サービス間の通信をご覧ください。
オプションの構成ファイル
以下の構成ファイルを使用すると、個々のアプリに含まれるすべてのサービスに適用されるオプション機能を制御できます。各オプション機能の詳細については、以下をご覧ください。
cron.yamlは、定義された時刻または一定間隔で動作する定期スケジュール タスクを構成します。dispatch.yamlは、受信リクエストを URL のパスまたはホスト名に基づいて特定のサービスに送信することで、ルーティングのデフォルト ルールをオーバーライドします。index.yamlは、Datastore クエリを使用する場合に、アプリに必要なインデックスを指定します。
ファイル名
App Engine は、最新の Ubuntu Linux ディストリビューションのコンテナ内でアプリを実行します。App Engine スタンダード環境で使用するファイル名は、UTF-8、あるいは UTF-8 または UTF-8 に安全に自動変換できるものにする必要があります。ファイル名に異なるエンコードが使用されている場合は、UTF-8 互換のファイル名の言語設定を持つマシンからアプリをデプロイします。
ファイル名が UTF-8 と互換性がない場合、デプロイは失敗します。ファイル内で使用する文字エンコードに制限はありません。
データとファイルの保存に関する考慮事項
App Engine から、Datastore、Cloud SQL、Cloud Storage といった他の Google Cloud サービスに簡単にアクセスできます。
外部またはサードパーティのデータベースがご使用の言語でサポートされ、App Engine インスタンスからアクセスできる場合は、そのデータベースを使用することもできます。
ファイルを Google Cloud または外部に保存する方法については、データとファイルの保存についてをご覧ください。
静的コンテンツの提供方法を選択することもできます。App Engine でアプリからその静的コンテンツを直接提供する、Cloud Storage をはじめとする Google Cloud のサービスに静的コンテンツをデプロイしてホストする、サードパーティのコンテンツ配信ネットワーク（CDN）を使用するといった選択肢があります。静的コンテンツの提供に関する詳細については、静的ファイルの提供をご覧ください。
次のステップ
複数のサービスを使用していて、それらのサービスを一緒にデプロイする場合は、複数のサービスをデプロイするの手順をご覧ください。