Java でのバックエンドの構成

Backend API は、2014 年 3 月 13 日から非推奨扱いとなっております。Google では利用規約に従って Backend API のサポートを継続していますが、新しく作成するすべてのアプリケーションで Modules API を代わりに使用することを強くおすすめします。

Backend API を使用している既存のアプリを Modules API に変換する方法については、アプリを Modules に変換するをご覧ください。

アプリケーションにバックエンドを追加するには backends.xml という構成ファイルを使用して、各バックエンド サーバーの名前と必要なプロパティを宣言します。backends.xml ファイルは、アプリケーションの WEB-INF ディレクトリに保存します。

backends.xml について

バックエンドには、デフォルトの App Engine インスタンスにはない重要な違いがあります。バックエンドの仕組みについて詳しくは、バックエンドに関するドキュメントをご覧ください。下のサンプルコードに、backends.xml ファイルの例を示します。この構成ファイルには 3 つのバックエンドが個別に定義されています。

  1. memdb。このバックエンドでは、インスタンス クラス B8 の 5 つのインスタンスを設定しています。
  2. worker。デフォルトのクラスを使用して 1 つのインスタンスを設定し、保留キューの動作を無効にするフェイルファストを設定しています。
  3. cmdline。アプリケーションの管理者による実行時間の長いコマンドを実行するために使用されます。
<backends>
 <backend name="memdb">
   <class>B8</class>
   <instances>5</instances>
 </backend>
 <backend name="worker">
   <options>
     <fail-fast>true</fail-fast>
   </options>
 </backend>
 <backend name="cmdline">
   <options>
     <dynamic>true</dynamic>
   </options>
 </backend>
</backends>

バックエンドのアップロード

アプリケーションのアップロードと同じツール(appcfg)を使って、バックエンドをアップロードします。

 appcfg backends <dir> update backend_name

バックエンドのタイプ

App Engine は常駐バックエンドと動的バックエンドの 2 種類のバックエンドをサポートしています。「常駐」バックエンドはデフォルトのバックエンド タイプで、常駐インスタンスを使用します。常駐インスタンスはアイドル時もメモリ内に維持され、自動的に再起動されます。そのため、大規模なタスクや継続的な処理を必要とするタスクを実行できます。デフォルトでは、バックエンドに設定されるインスタンスは 1 つですが、構成ファイルでインスタンスを追加できます。

常駐バックエンドと動的バックエンドの主な機能の比較を次の表に示します。

  常駐バックエンド  動的バックエンド 備考
インスタンスのタイプ

常駐

動的

デフォルトでは、常駐バックエンドと動的バックエンドは両方とも 1 つのインスタンスを持ちます。オプションの instances 要素を使用すると、インスタンス数を設定できます。

起動

手動、管理コンソールまたはコマンドライン ツールから

HTTP リクエストを受け取ったとき

シャットダウン

通常は手動、管理コンソールまたはコマンドライン ツールから

アイドル状態のまま数分経過後

シャットダウンに影響する要因は他にもあります。詳しくはシャットダウンをご覧ください。

状態

手動でシャットダウンするか、予期しないシャットダウン イベントが発生するまで保持されます。シャットダウン イベントについて詳しくはシャットダウンをご覧ください。

アイドル状態のまま数分経過後にバックエンドがシャットダウンされるときに消去されます。

 
処理のタイプ 

継続的またはリクエストにより駆動

リクエストにより駆動

 
費用

比較的高め(常駐バックエンドは継続して実行されるため)

比較的低め(動的バックエンドはアイドル時には終了するため)

時間単位で課金(アイドル時も課金対象)
用途 継続的な処理や状態保持を必要とする、次のような作業:
  • ゲームの状態をメモリ内に格納する
  • ソーシャル グラフやウェブ インデックスをキャッシュに保存する
  • ウェブクローラを実行する

次のようなリクエスト ベースの作業:

  • 完了するのにより多くの処理能力、時間、またはメモリを必要とするタスクキュー リクエスト
  • レポート生成
  • 大規模または複雑なユーザー リクエスト

常駐バッエンドと動的バックエンドの両方で、バックエンドの特定のインスタンスにタスクをアドレス指定できます。インスタンス名とバックエンド名はプログラムで取得できます。エンドポイントは次のような形式になります: http://[instance].[backend_name].[your_app_id].appspot.com

負荷分散 リクエストはバックエンドのすべてのインスタンス間で均等に分散されます。 リクエストは最初に最も番号の小さいインスタンスで集中的に処理され、トラフィックが増加するにつれて、使用するインスタンスが増えます。  

リクエスト処理

常駐バックエンドと動的バックエンドはいずれも、保留キューを使用して受信トラフィックを処理します。バックエンドでリクエストを処理中に新たにリクエストを受け取った場合、新しいリクエストは保留キュー内で短時間(10 秒)待機した後、中止されます。

フェイルファスト機能を使うと、バックエンドの保留キューを無効にできます。フェイルファストは、リクエストごとに、またはバックエンド全体に対して構成できます(現在、バックエンド全体のオプションは試験運用機能として提供されています)。1 つのリクエストに対してフェイルファストを使用するには、タスクリクエストに次のヘッダーを追加します。

X-AppEngine-FailFast

バックエンド全体をフェイルファストにするには、backends.xml でバックエンドの定義に <fail-fast> オプションを追加します。

ハンドラの定義

バックエンドは、web.xml で定義されたサーブレットのセットをメインのアプリケーション バージョンと共有します。現在のところ、バックエンドごとに異なるサーブレットのセットを設定することはできません。YAML 設定を使用する場合、管理者に限定したいハンドラは login: admin と指定します。このログイン宣言により、外部リクエストはブロックされますが、内部リクエスト(アプリケーションの別のインスタンス、タスク キューなどからのリクエスト)は追加設定なしでアクセスが許可されます。

インスタンスのクラス

App Engine には 4 つの異なるバックエンド インスタンス クラスがあり、クラスごとにメモリ制限や CPU 制限が異なります。これらのクラスを使用することで、処理の実行に必要な処理容量を持つバックエンドを構成できます。クラスごとに 1 時間単位の課金レートが異なります。詳細は料金をご覧ください。

バックエンドのデフォルトのクラスは B2 です。このクラスでは、256 MB のメモリと 1200 MHz の CPU 容量を使用できます。

バックエンドのクラスを変更するには、backends.xml<class> ディレクティブを使用します。

<backends>
  <backend name="cmdline">
    <class>B4</class>
  </backend>
</backends>

<class> ディレクティブには、次の値を指定できます:

クラスの構成 メモリ制限 CPU 上限 1 時間あたりの費用*
B1 128 MB 600 MHz $0.08
B2(デフォルト) 256 MB 1200 MHz $0.16
B4 512 MB 2400 MHz $0.32
B8 1024 MB 4800 MHz $0.64
*バックエンドの課金について詳しくは、課金、割り当て、上限をご覧ください。

バックエンドの定義

backends.xml ファイルには backends というリスト要素を 1 つ指定します。そのリスト内で、アプリケーションの 1 つのバックエンドを各要素として指定します。バックエンドは、課金、割り当て、上限の対象となります。

<backends> 要素には、以下の要素と属性を指定できます:

<name>(必須属性)

英字、数字、ハイフンを使用したサーバー名。名前「default」は予約済みのため、使用できません。また、アプリケーションのバージョンとして使用済みの名前も使用できません。この名前は BACKEND_ID でも参照されます。

<class>

バックエンドのインスタンス クラス。インスタンス クラスによって、各インスタンスのメモリと CPU の上限が決定します。デフォルトのクラスは B2 です。

<instances>

指定したバックエンドに割り当てるインスタンス数を示す 120 の整数。指定しない場合のデフォルトは 1 です。インスタンス番号は INSTANCE_ID でも参照されます。

appengine-web.xmlthreadsafe と指定したアプリケーションでは複数のリクエストを処理できます。同時リクエストの最大数を設定することもできます。この機能は試験運用中です。バックエンドに保留キューがある場合、ビジー状態のインスタンスに対するリクエストは、10 秒間再試行した後、中止されます。

<max-concurrent-requests>試験運用版

インスタンスが同時に処理できるリクエストの最大数を指定します。指定しない場合、App Engine により動的に同時リクエストの上限が決定されます。

<options>

ブール設定のリスト。以下のオプションを 1 つ以上指定できます。デフォルトでは常駐インスタンスになりますが、複数のリクエストにまたがって状態が保持されるように、バックエンドを常にメモリ内に維持するように設定できます。これは、上記のバックエンドのタイプのセクションで説明したように、バックエンドを常にメモリ内に維持するように構成することを意味します。常駐サーバーが再起動されるのは、基盤になる appserver が再起動された場合のみです。

<dynamic>

デフォルトでは常駐インスタンスになりますが、このオプションは、常駐インスタンスではなく動的インスタンスを使用するようにバックエンドを設定します。

<fail-fast>試験運用

fail-fast オプションは試験運用機能です。キューを無効にするので、ビジー状態のインスタンスは、新しいリクエストを受け取ると、HTTP 503 エラーをすぐに返します。この動作は、X-AppEngine-FailFast ヘッダーをリクエストに追加することでも可能になります。このヘッダーは試験運用機能ではありません。

<public>試験運用

バックエンドへのアクセスを public に設定します。バックエンドが公開され、ウェブからの外部 HTTP リクエストを処理できます。詳しくは一般公開と限定公開のバックエンドをご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Java 8 の App Engine スタンダード環境