Python のバックエンド設定

Backend API は、2014 年 3 月 13 日をもって非推奨となりました。Google では、利用規約に従って Backend API のサポートを引き続き提供しますが、新しいアプリケーションではサービスを利用することを強くおすすめします。

既存のアプリを変換する方法については、バックエンドからサービスへの変換をご覧ください。

backends.yaml という設定ファイルでアプリケーションにバックエンドを追加できます。この設定ファイルでは、各バックエンド サーバーの名前と必要なプロパティを宣言します。

backends.yaml について

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

  1. memdb。このバックエンドでは、インスタンス クラス B8 の 5 つのインスタンスを設定しています。
  2. crawler。デフォルトのクラスとオプションを使用しますが、インスタンス数は 10 個です。このバックエンドは、開始ハンドラとして crawler.py を定義します。
  3. worker。デフォルトのクラスを使用して 1 つのインスタンスを設定し、保留キューの動作を無効にするフェイルファストを設定しています。
  4. cmdline。アプリケーションの管理者による実行時間の長いコマンドを実行するために使用されます。
backends:
- name: memdb
  class: B8
  instances: 5
- name: crawler
  instances: 10
  start: crawler.app
- name: worker
  options: failfast
- name: cmdline
  options: dynamic

バックエンドのタイプ

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

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

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

動的

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

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

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

シャットダウン 通常は手動、管理コンソールまたはコマンドライン ツールから

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

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

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

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

 
処理のタイプ  継続的またはリクエストにより駆動

リクエストにより駆動

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

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

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

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

  • 完了するのにより多くの処理能力、時間、またはメモリを必要とするタスクキュー リクエスト
  • レポート生成
  • 大規模または複雑なユーザー リクエスト
  • アドホック クエリまたは管理スクリプト
常駐バッエンドと動的バックエンドの両方で、バックエンドの特定のインスタンスにタスクをアドレス指定できます。インスタンス名とバックエンド名はプログラムで取得できます。エンドポイントは次のような形式になります: http://[instance].[backend_name].[your_app_id].appspot.com

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

リクエスト処理

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

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

X-AppEngine-FailFast

バックエンドをフェイルファストにするには、failfast でバックエンドの定義に backends.yaml オプションを追加します。

ハンドラの定義

バックエンドは、app.yaml で定義されたリクエスト ハンドラをメインのアプリケーション バージョンと共有します。バックエンドごとに別々のハンドラを設定することはできないため、管理者限定にするハンドラは login: admin と指定します。このログイン宣言により、外部リクエストはブロックされますが、内部リクエスト(アプリケーションの別のインスタンス、タスクキューなどからのリクエスト)は追加設定なしでハンドラにアクセスできます。

start ディレクティブを使用すると、各バックエンドで /_ah/start のハンドラを個別に定義できます。

インスタンスのクラス

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

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

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

backends:
- name: cmdline
  class: B4

class ディレクティブには次の値が設定されています

クラスの設定 メモリ制限 CPU 上限 1 時間あたりの費用*
B1 128 MB 600 MHz $0.05
B2(デフォルト) 256 MB 1.2 GHz $0.10
B4 512 MB 2.4 GHz $0.20
B4_1G 1024 MB 2.4 GHz $0.30
B8 1024 MB 4.8 GHz $0.40

* バックエンドの課金について詳しくは、課金、割り当て、上限をご覧ください。

バックエンドの定義

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

backends ディレクティブには、次のディレクティブを持つことができます。

name(必須)
英字、数字、ハイフンを使用したサーバー名。「default」は予約済みのため、使用できません。また、アプリケーションのバージョンとして使用済みの名前も使用できません。この名前は BACKEND_ID でも参照されます。
class
バックエンドのインスタンス クラス。各インスタンスのメモリと CPU の上限がこれにより決定されます。デフォルトのクラスは B2 です。
instances

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

各インスタンスで同時に 1 つのリクエストを処理できます。バックエンドに保留キューがある場合、ビジー状態のインスタンスに対するリクエストは、10 秒間再試行した後、中止されます。

start

start 時に実行するスクリプトを指定します。このディレクティブを追加すると、/_ah/start にハンドラを定義することと同じ結果になりますが、この操作は 1 つのバックエンドにのみ適用されます。この値は、WSGI アプリケーションまたはアプリケーションのルート ディレクトリに関連するファイル名にする必要があります。

backends.yaml に起動スクリプトを指定すると、app.yaml/_ah/start に一致する他のハンドラがオーバーライドされます(url: .*url: /_ah/start など)。指定しないと、start リクエストは通常のリクエストと同様に処理されます。app.yaml で宣言された handlers と比較されます。一致するハンドラが存在しないと、start リクエストは 404 を返します。これは正常なレスポンスです。

詳細については、起動をご覧ください。

options

設定のリスト。以下のオプションを 1 つ以上指定できます。

  • dynamic: デフォルトで常駐インスタンスになります。このオプションは、常駐インスタンスではなく動的インスタンスを使用するようにバックエンドを設定します。バックエンドはデフォルトで常駐インスタンスになります。複数のリクエストにまたがって状態が保持されるように、バックエンドを常にメモリ内に維持するように設定できます。これは、上記のバックエンドのタイプのセクションで説明したように、バックエンドを常にメモリ内に維持するように設定することを意味します。常駐サーバーが再起動されるのは、基盤になる appserver が再起動された場合のみです。
  • failfast(試験運用中): failfast オプションを設定すると、保留キューが無効になり、ビジー状態のインスタンスが新しいリクエストを受け取るとすぐに HTTP 503 エラーを返すようになります。この動作は、X-AppEngine-FailFast ヘッダーをリクエストに追加することでも可能となります(このヘッダーは試験運用機能ではありません)。
  • public(試験運用中): バックエンドへのアクセスを public に設定します。バックエンドが公開され、ウェブからの外部 HTTP リクエストを処理できます。詳しくは公開と非公開のバックエンドをご覧ください。
このページは役立ちましたか?評価をお願いいたします。

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

Python の App Engine スタンダード環境