Python のバックエンド構成

Backend API は 2014 年 3 月 13 日をもって非推奨となっており、2019 年 3 月 13 日に提供を終了しました。デベロッパーはすべてのバックエンド インスタンスをサービスに移行する必要があります。移行しないと、インスタンスを管理できなくなり、トラフィックの配信が停止されます。

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

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

backends.yaml について

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

  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

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

ハンドラの定義

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

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

インスタンスのクラス

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

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

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

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 ファイルには、backends という名前のリスト要素が 1 つだけあります。そのリスト内で、アプリケーションの 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 2 の App Engine スタンダード環境