appengine-web.xml リファレンス

リージョン ID

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

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

OK

注: 以前のバンドル サービスを使用していて Java 21 にアップグレードする場合は、アプリが Java Enterprise Edition 8（EE8）で実行されている場合にのみ引き続き javax.servlet.* API を使用できます。EE8 のまま使用する場合は、appengine-web.xml ファイルを更新する必要があります。構成オプションの詳細については、既存のアプリケーションをアップグレードするをご覧ください。

既存のアプリを App Engine Java 8 ランタイムからサポートされている最新バージョンの Java に移行し、以前のバンドル サービスを使用する場合に限り、appengine-web.xml ファイルを使用してアプリを構成する必要があります。プロジェクトで appengine-web.xml を使用している場合、app.yaml はデプロイ時に自動的に生成されます。

App Engine Java アプリケーションでは、appengine-web.xml という名前の構成ファイルを使用してアプリに関する情報を指定します。また、このファイルを使用して、アプリの WAR ファイル内にあるどのファイルが静的ファイル（画像など）で、どのファイルがアプリケーションによって使用されるリソース ファイルを識別します。

構文

App Engine Java アプリでは、WAR 内のディレクトリ WEB-INF/ に appengine-web.xml というファイルを含める必要があります。この XML ファイルのルート要素は <appengine-web-app> です。

appengine-web.xml のドキュメント タイプ定義とスキーマの仕様は、SDK の docs/ ディレクトリにあります。

注: 標準的な appengine-web.xml ファイルには、デフォルトのサービスが定義されています。デフォルト以外のサービス（以前のモジュール）の場合には、サービスごとに追加の構成パラメータを指定する必要があります。この詳細については、App Engine の概要をご覧ください。これらの構成パラメータも、デフォルトのサービスに適用できます。

要素	説明
<application>	gcloud app deploy コマンドなどの Google Cloud SDK ベースのツールや、IntelliJ、Maven、Gradle の各プラグインを使用してアプリをデプロイする場合には、必須ではありません。Google Cloud SDK ベースのツールは、この要素を無視し、gcloud 構成プロジェクトのプロパティからプロジェクト ID を取得します。gcloud コマンドライン ツールでプロジェクト ID をオーバーライドできますが、これはマシンワイドのプロジェクト ID であり、複数のプロジェクトを開発している場合、混乱が起きる可能性があるので注意してください。<application> 要素にはアプリケーションのプロジェクト ID が格納されます。これは、 Google Cloud consoleでプロジェクトを作成するときに登録するプロジェクト ID です。
<app-engine-apis>	省略可。第 2 世代ランタイムに App Engine の以前のバンドル サービスを使用する場合は、このフィールドを true に設定します。
<entrypoint>	省略可。第 2 世代ランタイムのみ。デフォルトのエントリポイント（Java アプリケーションを起動するプロセス コマンドライン）をオーバーライドします。デフォルトでは、F4 インスタンス クラス用に生成されるエントリ ポイント（メモリ設定はインスタンス クラスから算出されます）は、次の構成と同等です。 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <entrypoint> java -showversion -Xms32M -Xmx819M -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:+PrintCommandLineFlags --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.logging/java.util.logging=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED -Dclasspath.runtimebase=/base/java_runtime -Djava.class.path=/base/java_runtime/runtime-main.jar -Djava.library.path=/base/java_runtime: com/google/apphosting/runtime/JavaRuntimeMainWithDefaults --fixed_application_path=/workspace /base/java_runtime </entrypoint> </appengine-web-app> 構成を変更して、JVM プロセスフラグを追加したり、独自のプロセスを定義できます。アプリケーションは /workspace ディレクトリにデプロイされていますが、ランタイム JAR は /base/java_runtime ディレクトリの下にあります。 環境変数を使用して Java ランタイムのエントリ ポイントをカスタマイズする方法を確認してください。
<async-session-persistence>	省略可。HTTP セッション データをデータストアに非同期に書き込むようにアプリケーションを構成すると、リクエストのレイテンシを短縮できます。 <async-session-persistence enabled="true" /> 非同期のセッションの永続化を有効にすると、App Engine は、memcache にデータを書き込む前に、セッション データをデータストアに書き込むために、タスクキューのタスクを送信します。デフォルトでは、このタスクは default キューに送信されます。別のキューを使用するには、queue-name 属性を追加します。 <async-session-persistence enabled="true" queue-name="myqueue"/> セッション データは常に同期的に memcache に書き込まれます。memcache が利用できないとき（またはセッション データがフラッシュされたとき）に、セッション データを読み込むリクエストが試行されると、Datastore にフェイルオーバーされますが、ここには最新のセッション データが保存されていない場合があります。つまり、非同期のセッションの永続化を有効にすると、アプリケーションで最新のセッション データを取得できないことがあります。大半のアプリケーションでは、このリスクよりもレイテンシの短縮によるメリットが大きいと言えます。
<auto-id-policy>	省略可。エンティティ ID を自動的に設定している場合、自動 ID ポリシーを設定すると、使用するメソッドを変更できます。有効なオプションは次のとおりです。 default デフォルト。64 ビット浮動小数点として表現可能で、適度に分散された ID を自動的に割り当てます。 legacy レガシー オプションは今後のリリースで非推奨となり、最終的に削除される予定です。詳細については、この変更を発表したブログ投稿をご覧ください。
<automatic-scaling>	省略可。詳細については、自動スケーリングをご覧ください。
<basic-scaling>	省略可。詳細については、基本スケーリングをご覧ください。
<env-variables>	省略可。appengine-web.xml ファイルには、アプリケーションの実行時に設定される環境変数を定義できます。 <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> ローカル環境での競合を避けるため、開発用サーバーでは、このファイルに基づいて環境変数を設定していません。ローカル環境では、これらの変数に一致値が設定されている必要があります。 export DEFAULT_ENCODING="UTF-8" dev_appserver war App Engine にデプロイされている場合、これらの変数は環境ですでに設定されています。 クライアントが接続を閉じる前に、データ転送なしで接続が非アクティブな状態を維持する時間を決定するには、次の構文を使用してアイドル タイムアウトを構成します。 <env-variables> <env-var name="APPENGINE_API_CALLS_IDLE_TIMEOUT_MS" value="TIMEOUT_IN_MS" /> </env-variables> TIMEOUT_IN_MS は、必要なタイムアウト（ミリ秒単位）に置き換えます。 リクエスト/URL 取得の全体的な期限を 60 秒に設定するには、60000 に設定します。または、サーバーサイドのタイムアウト（通常は 60 秒）より少し短く設定すると、メリットがある場合があります（例: 59000）。現在のデフォルトは 58000 ミリ秒です。 このアイドル タイムアウト構成は、スケーリングの全体的なリクエスト期限や、appengine.api.urlfetch.defaultDeadline を使用して構成する URL 取得 API の期限とは異なります。
<inbound-services>	省略可。アプリケーションでメール メッセージを受信するには、このサービスを有効にするようにアプリケーションを構成しておく必要があります。このサービスを Java アプリで有効にするには、appengine-web.xml ファイルに <inbound-services> セクションを追加します。 以下のインバウンド サービスが使用できます。 mail アプリケーションにメールの受信を許可します。
<instance-class>	省略可。このモジュールのインスタンス クラスのサイズ。 異なるスケーリング オプションを指定するときに、次のインスタンス クラスを使用できます。 automatic_scaling 自動スケーリングの場合、F1、F2、F4、F4_1G のインスタンス クラスを使用できます。 デフォルト: automatic_scaling 要素とともにインスタンス クラスを指定しない場合は、F1 が割り当てられます。 basic_scaling 基本スケーリングの場合、B1、B2、B4、B4_1G、B8 インスタンス クラスを使用できます。 デフォルト: basic_scaling 要素とともにインスタンス クラスを指定しない場合は、B2 が割り当てられます。 manual_scaling 手動スケーリングの場合、B1、B2、B4、B4_1G、B8 のインスタンス クラスを使用できます。 デフォルト: manual_scaling 要素とともにインスタンス クラスを指定しない場合は、B2 が割り当てられます。 注: instance-class が F2 以上に設定されている場合、max-concurrent-requests を 10（デフォルト）より大きい値に設定することで、インスタンスを最適化できます。最適な値を見つけるには、値を少しずつ増やしながらアプリケーションのパフォーマンスをモニタリングします。
<manual-scaling>	省略可。詳細については、手動スケーリングをご覧ください。
<precompilation-enabled>	省略可。App Engine では、Java Runtime Environment でのアプリのパフォーマンスを向上させるために、アプリの Java バイトコードで「プリコンパイル」処理を行います。プリコンパイルされたコードは、元のバイトコードとまったく同じように機能します。 アプリでプリコンパイルを行わない場合、次の行を appengine-web.xml ファイルに追加すると、プリコンパイルを無効にできます。 <precompilation-enabled>false</precompilation-enabled>
<module>	注: モジュールはサービスという名前に変わりましたが、appengine-web.xml ファイルでは、<module>service_name</module> のようにモジュールとしてサービスが宣言されます。 サービスを作成する場合は必須です。デフォルトのサービスでは省略できます。サービスとバージョンには名前を付ける必要があります。名前には、数字、文字、ハイフンを使用できます。名前は 63 文字以下にする必要があります。また、名前の先頭にも最後にもハイフンは使用できず、文字列「-dot」を含めることもできません。各サービスとバージョンには一意の名前を付ける必要があります。サービスとバージョンに同じ名前を使うことはできません。 サービスもご覧ください。
<public-root>	省略可。<public-root> はアプリケーションのディレクトリです。ここに、アプリケーションの静的ファイルが格納されます。静的ファイルがリクエストされると、リクエストパスの先頭にアプリケーションの <public-root> が追加されます。これにより、リクエストされているコンテンツを含むアプリケーション ファイルのパスが渡されます。 デフォルトの <public-root> は / です。 たとえば、次の例では URL パス /index.html がアプリケーション ファイルのパス /static/index.html にマッピングされています。 <public-root>/static</public-root>
<resource-files>	省略可。<resource-files> 要素に記述されているファイルは、ファイル システムを使用するアプリケーション コードからアクセスできるようになります。静的ファイルとは異なり、これらのファイルはアプリと一緒にアプリケーション サーバーに格納されます。 <resource-files> 要素には次の要素を設定できます。 <include> <include> 要素は、ファイルをリソース ファイルに指定し、アプリケーション コードから使用できるようにします。これらのファイルは読み取り専用で、トラフィックの処理には使用できません。ファイルの追加と除外をご覧ください。 <exclude> <exclude> パターンに一致するファイルとディレクトリはアップロードされず、アプリケーション コードでも使用できません。ただし、ローカルの開発用サーバーでアプリケーションを実行する場合には、これらのファイルやディレクトリにアクセスできます。詳細については、ファイルの追加と除外をご覧ください。 例: <resource-files> <include path="/**.xml" /> <exclude path="/feeds/**.xml" /> </resource-files> この例では、feeds/ ディレクトリとそのすべてのサブディレクトリにあるファイルを除き、すべての .xml ファイルをリソース ファイルとして定義しています。 App Engine リソース ファイルの読み取りには、java.io.File または javax.servlet.ServletContext.getResource/getResourceAsStream が使用されます。Class.getResourceAsStream() でアクセスすることはできません。
<runtime>	サポートされている最新バージョンの Java を使用するには、このエントリを値 java21 で指定する必要があります。 例: <runtime>java21</runtime>
<service>	サービスは、モジュールと呼ばれていました。 現在、サービスを <service>service_name</service > として定義するには、gcloud app コマンドを使用する必要があります。
<service-account>	省略可。<service-account> 要素を使用すると、バージョンの ID としてユーザー管理のサービス アカウントを指定できます。指定したサービス アカウントは、他の Google Cloud サービスにアクセスしてタスクを実行するときに使用されます。 例: <service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
<sessions-enabled>	省略可。App Engine には、サーブレット セッション インターフェースを使用して実装されるセッションがあります。この実装では、永続性のためにセッション データが Datastore に保存されるだけでなく、高速化を図るために memcache も使用されます。他のほとんどのサーブレット コンテナと同様、リクエスト時に session.setAttribute() で設定されるセッション属性が、リクエストの終了時に永続化されます。 この機能はデフォルトで無効になっています。有効にするには次の行を appengine-web.xml に追加します。 例: <sessions-enabled>true</sessions-enabled> この実装では、種類が _ah_SESSION の Datastore エンティティと、接頭辞 _ahs のキーを使用した memcache エントリが作成されます。これらのエンティティは、Dataflow テンプレートを使用して削除できます。 注: App Engine はセッション データを Datastore と memcache に保存するため、セッションで保存されるすべての値で java.io.Serializable インターフェースを実装する必要があります。 セッション データの保存でレイテンシを短縮する方法については、async-session-persistence 要素をご覧ください。
<ssl-enabled>	省略可。デフォルトでは、どのユーザーも HTTP または HTTPS を使用して任意の URL にアクセスできます。デプロイ記述子の特定の URL には HTTPS を必須とするように、アプリを構成できます。詳細については、デプロイ記述子: 保護された URL をご覧ください。 アプリケーションで HTTPS の使用を禁止する場合は、appengine-web.xml ファイルに次の行を追加します <ssl-enabled>false</ssl-enabled> Java Runtime Environment の一部の URL パスのみで HTTPS を禁止する方法はありません。
<static-error-handlers>	省略可。特定のエラーの発生時に、App Engine によって汎用的なエラーページが表示されます。このような汎用的なエラーページではなくカスタムの静的ファイルを表示するようにアプリを構成できます。ただし、カスタム エラーデータは 10 KB 未満にする必要があります。サポート対象のエラーコードごとに異なる静的ファイルが表示されるように設定するには、アプリの appengine-web.xml ファイルでファイルを指定します。カスタム エラーページを表示するには、次の例のように、appengine-web.xml に <static-error-handlers> セクションを追加します。 <static-error-handlers> <handler file="default_error.html" /> <handler file="over_quota.html" error-code="over_quota" /> </static-error-handlers> 警告: エラー レスポンス ファイルのパスが静的ファイル ハンドラのパスと重ならないようにしてください。 file エントリには、汎用的なエラー レスポンスの代わりに表示される静的ファイルを指定します。error-code には、関連ファイルを表示するエラーコードを指定します。使用可能なエラーコードは次のとおりです。 over_quota アプリがリソース割り当てを超過したことを示します。 timeout アプリからレスポンスが返される前に時間切れとなった場合に使用されます。 error-code は省略可能です。省略すると、指定したファイルがアプリのデフォルトのエラー レスポンスになります。 カスタムエラーの処理時に使用する mime-type を指定することもできます。MIME タイプのリストをご覧ください。
<static-files>	省略可。<static-files> 要素には、静的ファイルのリストに追加または除外するパスのパターンを指定します。これにより、デフォルトの動作を変更または修正できます。静的ファイルは専用のサーバーとアプリケーション サーバーとは別のキャッシュから提供されます。画像、CSS スタイルシート、JavaScript ファイルなどの静的コンテンツを配信する場合に便利です。 <static-files> 要素には次の要素を設定できます。 <include> <include> 要素は、デフォルトの動作（JSP 以外のすべてのファイルを対象）をオーバーライドします。<include> 要素には、指定したリソースのリクエストに対するレスポンスの HTTP ヘッダーを指定できます。詳細については、ファイルの追加と除外をご覧ください。 include 要素に expiration 属性を指定すると、デフォルトの静的キャッシュの有効期限をオーバーライドできます。設定する値は、数値と単位の文字列をスペースで区切ったものです。単位には、日数を表す d、時間数を表す h、分数を表す m、秒数を表す s を指定できます。たとえば、"4d 5h" と指定すると、キャッシュの有効期限はファイルが最初にリクエストされてから 4 日と 5 時間後に設定されます。詳細については、キャッシュの有効期限をご覧ください。 <exclude> <exclude> パターンに一致するファイルとディレクトリは、アプリを App Engine にデプロイする際にアップロードされません。ただし、ローカルの開発用サーバーでアプリケーションを実行する場合には、これらのファイルやディレクトリにもアクセスできます。詳細については、ファイルの追加と除外をご覧ください。 例 <static-files> <include path="/my_static-files" > <http-header name="Access-Control-Allow-Origin" value="http://example.org" /> </include> </static-files>
<system-properties>	省略可。appengine-web.xml ファイルでは、アプリケーションの実行時に設定されるシステム プロパティと環境変数を定義できます。 <system-properties> <property name="myapp.maximum-message-length" value="140" /> <property name="myapp.notify-every-n-signups" value="1000" /> <property name="myapp.notify-url" value="http://www.example.com/signupnotify" /> </system-properties> <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> 省略可。CPU とメモリの使用率を改善するために HTTP コネクタを構成できます。アプリケーションが Datastore またはタスクキュー オペレーションとやり取りする場合は、この機能を有効にした後のパフォーマンスと動作への影響をモニタリングするようにモニタリングを設定します。 <system-properties> <property name="appengine.use.httpconnector" value="true"/> </system-properties> 省略可。次のシステム プロパティを使用して、基盤となるランタイムが EE8 または EE10 で動作するように構成できます。EE サポートの詳細については、Java 21 にアップグレードするをご覧ください。 <system-properties> <property name="appengine.use.EE10" value="true"/> <!-- or EE8 --> </system-properties> Java 21 以降では、仮想スレッドを使用するように Java ウェブサーバーを構成できます。次に例を示します。 <system-properties> <property name="appengine.use.virtualthreads" value="true"/> </system-properties> スレッド サポートの詳細については、Jetty 12 - 仮想スレッドのサポートをご覧ください。
<url-stream-handler>	省略可。有効な値は native または urlfetch です。 デフォルト値は native です（標準の Java ネットワーク クラスでは標準の Java HTTP(S) 転送を使用します）。この設定を使用するには、アプリの課金を有効にする必要があります。有効にしないと、リクエストの発行に記載されているとおり、例外が発生します。 url-stream-handler を urlfetch に設定すると、URL.openConnection と関連メソッドは、http と https の転送に URL 取得を使用します。 <url-stream-handler>urlfetch</url-stream-handler>
<version>	<version> 要素には、アプリの最新のコードのバージョン ID を指定します。バージョン ID には、小文字、数字、ハイフンを使用できます。接頭辞「ah-」で始めることはできません。「default」と「latest」は予約されているので使用できません。 バージョン名は、常に番号で指定される数値インスタンスと区別するために、英字で始まる必要があります。これにより、123.my-module.uc.r.appspot.com のような URL の曖昧さを回避できます。この URL は、2 通りに解釈できます。バージョン「123」が存在する場合は、指定されたモジュールのバージョン「123」がターゲットになります。そのバージョンが存在しない場合は、このモジュールのデフォルト バージョンのインスタンス番号 123 がターゲットになります。
<warmup-requests-enabled>	省略可。デフォルトは true です。Java アプリケーションの場合、ウォームアップ リクエストはデフォルトで有効になっています。 ウォームアップ リクエストを有効にすると、App Engine インフラストラクチャは /_ah/warmup に GET リクエストを送信し、<load-on-startup> サーブレット、ServletContextListeners、カスタム ウォームアップ サーブレットを初期化します。この方法で、必要に応じてアプリケーションのコードを初期化できます。選択した方法によっては、/_ah/warmup に独自のハンドラを実装する必要があります。 ウォームアップ リクエストを無効にするには、この要素に false を指定します。 <warmup-requests-enabled>false</warmup-requests-enabled>
<vpc-access-connector>	省略可。サーバーレス VPC アクセス コネクタを使用するようにアプリケーションを構成して、アプリケーションが VPC ネットワークの内部リソースにリクエストを送信できるようにします。<name> 要素にコネクタの完全修飾名を指定します。 <vpc-access-connector> <name>projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]</name> </vpc-access-connector> 詳細については、VPC ネットワークの内部リソースへの接続をご覧ください。

スケーリングの要素

次の表では、アプリケーションのスケーリングを指定する場合のオプションについて説明します。

スケーリング タイプのパフォーマンス機能の比較については、動的インスタンスのスケーリングをご覧ください。

要素	説明
<automatic-scaling>	省略可。特に指定のない限り、自動スケーリングが適用され、デフォルトのインスタンス クラス F1 が使用されます。 automatic_scaling 要素には、モジュールのインスタンス、レイテンシ、同時接続の最小数と最大数を設定します。 この要素には次の要素を設定できます。 <target-cpu-utilization> 省略可。0.5～0.95 の値を指定します。 このパラメータは、トラフィックを処理する新しいインスタンスを起動するための CPU 使用率のしきい値を指定します。これにより、パフォーマンスとコストのバランスをとることができます。値を小さくするほど、パフォーマンスが向上してコストは増加し、値を大きくするほどパフォーマンスは低下してコストが削減されます。たとえば、値を 0.7 にすると、CPU 使用率が 70% に達した後に新しいインスタンスが起動されます。 <target-throughput-utilization> 省略可。0.5～0.95 の値を指定します。 max-concurrent-requests とともに使用して、同時リクエストによって新しいインスタンスが起動されるタイミングを指定します。同時リクエストの数が max-concurrent-requests と target-throughput-utilization の積に等しい値に達すると、スケジューラは新しいインスタンスを起動します。 <max-instances> 省略可。App Engine によってこのアプリケーションのバージョンに対して作成されるインスタンスの最大数。これはモジュールのコストを抑える場合に便利です。0～2147483647 の値を指定します。 <min-instances> 省略可。App Engine によってこのモジュール バージョンに作成されるインスタンスの最小数。これらのインスタンスは、リクエストが届いたときにトラフィックを処理し、トラフィックを処理するために必要な追加インスタンスが起動されてもトラフィックを処理し続けます。 0～1000 の値を指定します。このパラメータを 0 に設定すると、リクエストが処理されていないときにインスタンス数を 0 にスケールしてコストを削減できます。ただし、トラフィックを受信しているかどうかにかかわらず、指定されたインスタンス数分の料金が請求される点に注意してください。 <max-concurrent-requests> 省略可。自動スケーリング インスタンスが受け入れることのできる同時リクエスト数。この数を超えると、スケジューラによって新しいインスタンスが生成されます（デフォルト: 10、最大: 80）。 この値が大きすぎると、API のレイテンシが増加する場合があります。リクエストの最大数に達する前にスケジューラが新しいインスタンスを生成する場合もあります。 注: instance-class が F2 以上に設定されている場合、max-concurrent-requests を 10（デフォルト）より大きい値に設定することで、インスタンスを最適化できます。最適な値を見つけるには、値を少しずつ増やしながらアプリケーションのパフォーマンスをモニタリングします。 <max-idle-instances> App Engine がこのバージョンに保持できるアイドル状態のインスタンスの最大数。デフォルト値は「automatic」です。以下のことに注意してください。 最大数を大きく設定すると、負荷レベルの急増後に通常のレベルに戻る際に、アイドル インスタンスの数がより緩やかに減っていきます。その結果、アプリケーションがリクエスト負荷変動の前後を通じて安定したパフォーマンスを維持しやすくなる一方で、そのような負荷の高い期間のアイドル インスタンスの数（その結果としてランニング コスト）も増えます。 最大数を小さく設定すると、ランニング コストは低く抑えられますが、負荷レベルの変動があったときにパフォーマンスが低下する可能性があります。 注: 負荷の急増後に通常のレベルに戻るときに、アイドル インスタンスの数が指定した最大数を一時的に超える可能性があります。この場合、指定した最大数を超える分について料金が請求されることはありません。 <max-pending-latency> App Engine でリクエストが保留キューで待機できる最長時間。この時間を経過すると、リクエストを処理する新しいインスタンスが起動されて保留待ち時間が短くなります。 最大時間を短く設定すると、App Engine が保留中のリクエストに対処するための新しいインスタンスを作成するタイミングが早くなり、パフォーマンスは向上しますがランニング コストも高くなります。 最大時間を長く設定すると、ユーザーがリクエストの処理を待つ時間は長くなる可能性があります（保留中のリクエストがあり、それらに対処するアイドル インスタンスがない場合）が、アプリケーションのランニング コストは低くなります。 <min-idle-instances> 動作を継続中で、トラフィックの処理に対応できるインスタンス数。この設定は、トラフィックの大半を受信するバージョンにのみ適用されます。以下のことに留意します。 最小数を小さく設定すると、アイドル時間にかかるランニング コストは低く抑えられますが、負荷の急増があった場合にすぐに対処できるインスタンスの数が少なくなります。 最小数を大きく設定すると、アプリケーションがリクエスト負荷の急増に対応できるようになります。App Engine では、最小数のインスタンスを常に実行して、受信したリクエストの処理に当たります。これらのインスタンスはリクエストの処理中であるかどうかにかかわりなく、料金が発生します。この機能を適正に機能させるには、ウォームアップ リクエストが有効であること、およびアプリケーションでウォームアップ リクエストが処理されることを確認する必要があります。 アイドル インスタンスの最小数を設定すると、保留待ち時間がアプリケーションのパフォーマンスに与える影響は小さくなります。一定数のアイドル インスタンスが常に確保されるため、異常なほど負荷が急増した場合を除き、リクエストが保留中のキューに入る可能性は低くなります。理想的な予約インスタンス数を判定するには、アプリケーションと予測トラフィック量をテストする必要があります。 <min-pending-latency> App Engine でリクエストが保留キューで待機できる最短時間（秒）。この時間を経過すると、リクエストを処理する新しいインスタンスが起動されます。0.01～15 の値を指定します。 最小待ち時間を短く設定すると、既存のインスタンスがすべて稼働中のときにリクエストが保留中のキューにとどまる時間が短くなります。パフォーマンスは向上しますが、アプリケーションのランニング コストも高くなります。 最小時間を長く設定すると、既存のインスタンスがすべて稼働中のときにリクエストが保留中のキューにとどまる時間が長くなります。ランニング コストは低くなりますが、ユーザーがリクエストの処理を待つ時間は長くなります。 例 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>F2</instance-class> <automatic-scaling> <target-cpu-utilization>0.65</target-cpu-utilization> <min-instances>5</min-instances> <max-instances>100</max-instances> <max-concurrent-requests>50</max-concurrent-requests> </automatic-scaling> </appengine-web-app>
<basic-scaling>	省略可。<basic-scaling> 要素には、モジュールのインスタンス数を設定します。 この要素には次の要素を設定できます。 <idle-timeout> 省略可。最後のリクエストを受信した後、この時間が経過すると、インスタンスはシャットダウンされます。デフォルトは 5 分です。 <max-instances> 必須。App Engine によってこのモジュール バージョンに作成されるインスタンスの最大数。これはモジュールのコストを抑える場合に便利です。 例 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <basic-scaling> <max-instances>11</max-instances> <idle-timeout>10m</idle-timeout> </basic-scaling> </appengine-web-app>
<manual-scaling>	省略可。<manual-scaling> 要素を使用すると、モジュールで手動スケーリングを有効にし、モジュールのインスタンス数を設定できます。 この要素には次の要素を設定できます。 <instances> モジュール起動時にモジュールに割り当てるインスタンスの数。 例 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <manual-scaling> <instances>5</instances> </manual-scaling> </appengine-web-app>

ステージング要素

JAR ファイルのアセンブルや、JSP のコンパイルなど、デプロイ中に行われる作業の多くは、ステージングと呼ばれる準備段階でローカルに実行されます。アプリケーション構成ファイル内のステージング要素を使用して、ステージング動作の特定の部分を構成することもできます。ほとんどのアプリケーションは、ステージング動作を手動で構成しなくてもデプロイできます。お使いのアプリがデプロイできない場合は、以下のオプションを使用してステージングを構成する必要があります。

要素

説明

<staging>

省略可。ほとんどのアプリケーションでは、デフォルト動作を変更する必要がありません。 ステージング要素により、デプロイに必要な特定のステージング構成を指定できます。 この要素には次の要素を設定できます。 <enable-jar-splitting> 省略可。10 メガバイトを超える大きい jar ファイルを小さいフラグメントに分割します（デフォルトは true です）。 <jar-splitting-excludes> ファイル接尾辞のカンマ区切りのリストを指定します。enable-jar-splitting を有効にすると、接尾辞に一致するすべてのファイルがすべての JAR から除外されます。 <disable_jar_jsps> JSP から生成されたクラスを jar に圧縮しません（デフォルトは false です）。 <enable-jar-classes> WEB-INF / クラスのコンテンツを jar に圧縮します（デフォルトは true です）。 <delete-jsps> コンパイル後に JSP ソースファイルを削除します（デフォルトは true です）。 <compile-encoding> コンパイルするソースファイルのエンコードを入力します（デフォルトは utf-8 です）。 例: <staging> <delete-jsps>false</delete-jsps> </staging>

ステージング オプションのデフォルト値

ステージング オプションのデフォルト値は、gcloud CLI などの Google Cloud SDK ベースのツールを使用するか、Google Cloud SDK ベースの Maven、Gradle、IntelliJ の各プラグインを使用するかによって異なります。

ステージング要素	App Engine SDK ベースのデフォルト値 -	Google Cloud SDK ベースのデフォルト値
enable-jar-splitting	false	true
jar-splitting-excludes	なし	なし
disable-jar-jsps	false	false
enable-jar-classes	false	true。クラスの読み込み順序に影響を与えることがあります。そのため、アプリが以前の false デフォルト値を使用する特定の順序に依存する場合は、これを false に設定しても構いません。
delete-jsps	false	true
compile-encoding	utf-8	utf-8

include と exclude

パスのパターンを指定するときに、0 個以上の <include> と <exclude> 要素を使用できます。パターン内で、'*' はファイル名またはディレクトリ名内の 0 個以上の任意の文字を表し、** はパス内の 0 個以上のディレクトリを表します。<exclude> パターンに一致するファイルとディレクトリは、アプリを App Engine にデプロイする際にアップロードされません。ただし、ローカルの開発用サーバーでアプリケーションを実行する場合には、これらのファイルやディレクトリにアクセスできます。

<include> 要素はデフォルトの動作をオーバーライドします（デフォルトでは、すべてのファイルが対象になります）。<exclude> 要素は、すべての <include> パターン（<include> が明示的に指定されていない場合のデフォルトも含む）の後に適用されます。

次の例では、data/ ディレクトリとそのすべてのサブディレクトリ内のファイルを除くすべての .png ファイルを静的ファイルとして指定しています。

<static-files>
  <include path="/**.png" />
  <exclude path="/data/**.png" />
</static-files>

静的リソースのリクエストに対するレスポンスで使用する HTTP ヘッダーも設定できます。

<static-files>
  <include path="/my_static-files" >
    <http-header name="Access-Control-Allow-Origin"
                 value="http://example.org" />
  </include>
</static-files>

注: path 文字列の先頭がスラッシュでない場合、その HTTP ヘッダーは App Engine で機能しますが、開発用サーバーでは機能しません。

静的ファイルの MIME タイプ

デフォルトでは、静的ファイルはファイル名の拡張子に基づいて選択される MIME タイプで提供されます。web.xml で mime-mapping 要素を使用すると、静的ファイルのファイル名拡張子にカスタム MIME タイプを関連付けることができます。

URLFetch タイムアウト

URLFetch リクエストの期限を設定できます。デフォルトの取得期限は 5 秒です。このデフォルトを変更するには、appengine-web.xml 構成ファイルに次の設定を追加します。タイムアウトは秒単位で指定します。

<system-properties>
    <property name="appengine.api.urlfetch.defaultDeadline" value="10"/>
</system-properties>