Backends Python API の概要

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

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

バックエンドは、高速のパフォーマンス、大量のメモリ、長時間実行されるバックグラウンド プロセスを必要とするアプリケーションのために設計されています。これらにはリクエストの有効期限がなく、通常のインスタンスよりも多くのメモリ(最大 1 GB)と CPU(最大 4.8 GHz)を使用します。通常のインスタンスとは異なり、バックエンドでは CPU の使用量ではなく稼働時間に対して課金されます。

バックエンドは、常駐または動的として設定されます。常駐バックエンドは途切れることなく実行されるため、時間が経過してもメモリの状態を信頼でき、複雑な初期化を実行することもできます。動的なバックエンドは、リクエストを受け取ったときに存在するようになり、アイドル状態になると終了します。動的バックエンドは、断続的な処理やユーザーのアクティビティに応じて動作する処理に適しています。常駐バックエンドと動的バックエンドの違いについて詳しくは、バックエンドの種類、また起動シャットダウンの説明をご覧ください。

バックエンドは、リクエストの量に応じて自動的に増減されることはありません。その代わりに、必要なバックエンド インスタンスの数を指定する必要があります。この数は、update または configure コマンドを実行して変更します。インスタンスの数は通常、データセットのサイズ、必要な処理能力、アプリケーションの予算に応じて設定されます。

バックエンドは、backends.yaml を使用して設定します。各バックエンドをリストし、インスタンスの数、メモリや CPU のクラス、一般公開と限定公開の種別などのプロパティを指定できます。バックエンドは、app.yaml で定義されたハンドラをメインのアプリケーション バージョンと共有します。コードやハンドラを共有しない場合、別個のアプリケーション ルート ディレクトリにバックエンドを配置できます。 または、login: admin を使用して関連するハンドラにマークを付けることもできます。

バックエンドのプロパティ

次の表に、バックエンド インスタンスとデフォルトの App Engine インスタンスの比較を示します。

機能

デフォルト インスタンス

バックエンド インスタンス

有効期限 HTTP リクエストの場合は 60 秒、タスクの場合は 10 分。 バックエンドへのリクエストは無期限に実行できます。バックエンドでは、/_ah/start を処理し、HTTP レスポンス コードを返さずに何時間もプログラムやスクリプトを実行できます。
CPU 柔軟性があり、インスタンス時間に対して課金されます。 600 MHz から 4.8 GHz の間で設定でき、これらはインスタンスの稼働時間の時間価格に含まれます。詳細については、インスタンス クラスをご覧ください。
メモリ 少ないメモリ容量(128 MB)。 インスタンスごとにメモリ制限を設定可能(128 MB~1 GB)。詳細については、インスタンス クラスをご覧ください。
常駐 インスタンスは使用パターンに基づいてメモリから強制排除されます。 メモリに維持される常駐インスタンスを使用するようバックエンドを設定できます。これにより、複数のリクエストにまたがって状態が保持されます。バックエンドを再起動する際、通常、シャットダウンする前に 30 秒の猶予が与えられます(詳細については、シャットダウンをご覧ください)。
起動とシャットダウン インスタンスはリクエスト処理のためにオンデマンドで作成され、アイドル時には自動的にシャットダウンされます。 バックエンドには、App Engine から開始リクエストが /_ah/start への空のリクエストの形式で自動的に送信されます。appcfg backends stop または管理コンソールの [シャットダウン] を使用してバックエンドを停止する際、強制終了される前に、リクエストの処理を完了するために 30 秒が与えられます。

起動とシャットダウンの詳細については、バックエンドの状態をご覧ください。

インスタンスのアドレス指定 インスタンスは匿名です。 次の形式の URL で、インスタンスに個別にアクセスできます。

http://instance.backend_name.your_app_id.appspot.com

カスタム ドメインにワイルドカード サブドメイン マッピングを設定している場合、次の形式の URL でバックエンドまたはそのインスタンスをアドレス指定できます。

http://backend_name.domain.com

ここで、instance は特定のインスタンスを識別する値の小さな番号です。また、backend_nameバックエンド設定ファイルに指定された名前です。

また、次の形式の URL も使用できます。

http://instance.backend_name.domain.com

各インスタンスの状態は確実にキャッシュされ、後続のリクエストでその状態を取得できます。

スケーリング App Engine は処理量に応じて自動的にインスタンスの数を増減させます。 backends.yaml で各バックエンドのインスタンスの数を設定します。インスタンスの数は通常、メモリに保持されているデータセットのサイズまたはオフライン作業の目標スループットに対応します。動的バックエンドには、インスタンスの最大数を設定します。稼働中のインスタンスの数は、処理量に応じて増減します。バックエンドのインスタンスの数は、現在稼働中のインスタンスを停止せずに、configure コマンドを使用してすぐに調整できます。
一般公開と限定公開の HTTP リクエスト インスタンスは、限定公開と一般公開のリクエストを処理できます。 インスタンスはデフォルトで限定公開リクエストを処理しますが、一般公開リクエストを処理するようにインスタンスを設定できます。

コマンド

App Engine では、backends.yaml で設定されたバックエンドとやり取りすることができる以下のコマンドライン ツールを提供します。

dev_appserver.py を実行する際に、--backends を渡し、バックエンド サポートを有効にします。

appcfg backends <dir> update [backend]
backends.yaml で設定されるバックエンドを作成または更新します。バックエンド名を指定すると 1 つのバックエンドが更新されます。バックエンドを指定せずにこのコマンドを実行すると、すべてのバックエンドを更新できます。更新前にバックエンドが START 状態だった場合、更新後も START 状態のままになります。一方 STOP 状態だった場合は、更新後も STOP 状態のままになります。バックエンドを更新すると、現在実行されているインスタンスがシャットダウンされてから、新しいインスタンスが起動されます。更新中のエラー発生から次のエラーが引き起こされてダウンタイムが生じる事態を避けるため、インスタンスは更新の最後のステップまでシャットダウンされません。
appcfg backends <dir> rollback <backend>
ユーザーによって中断された、または設定エラーのために停止したバックエンドの更新をロールバックします。正常に適用された更新はロールバックの対象になりません。
appcfg backends <dir> list
dir/app.yaml に指定されたアプリに設定されたすべてのバックエンドをリストします。
appcfg backends <dir> start <backend>
バックエンドの状態を START に設定します。これで、このバックエンドで HTTP リクエストを受信できるようになります。常駐バックエンドの場合は即時に開始します。動的バックエンドの場合は最初のユーザー リクエストが届くまで開始しません。すでに開始しているバックエンドには影響しません。
appcfg backends <dir> stop <backend>
バックエンドの状態を STOP に設定し、実行中のすべてのインスタンスをシャットダウンします。停止されたバックエンドは HTTP リクエストを受信できなくなります。リクエストを受信した場合、404 レスポンスが返されます。すでに停止しているバックエンドには影響しません。
appcfg backends <dir> delete <backend>
指定されたバックエンドを削除します。このコマンドを発行した後、削除されたバックエンドへのリクエスト(たとえば、http://backend_name.your_app_id.appspot.com)は、デフォルト バージョンのアプリにルーティングされます。
appcfg backends <dir> configure <backend>

バックエンドを停止せずに backends.yaml の設定を動的に更新します。コードやハンドラには影響しません。以下の設定のみをサポートします。

  • instances
  • options: public
  • options: failfast

バックエンドの状態

バックエンドは、START または STOP のいずれかの状態になります。appcfg または管理コンソールの [バックエンド] タブを使用してバックエンドの状態の表示と変更ができます。状態によって、バックエンド インスタンスがアクティブでリクエストを処理できるか、無効でありシャットダウンするかどうかが制御されます。

起動

各バックエンド インスタンスは開始リクエスト(/_ah/start への空の GET リクエスト)に対するレスポンスとして作成されます。App Engine は、この特別なリクエストを送信してインスタンスを生成します。ユーザーがリクエストを /_ah/start に送信することはできません。

バックエンド インスタンスは、別のリクエストを処理する前に、開始リクエストに応答する必要があります。開始リクエストは、次の 2 つの目的で使用できます。

  1. それ以上のリクエストを受け入れずに、無期限に実行するプログラムを開始するため
  2. 追加のトラフィックを受け取る前に、インスタンスを初期化するため

常駐バックエンドと動的バックエンドの起動の仕方は異なります。常駐バックエンドを開始すると、App Engine は /_ah/start リクエストを各バックエンド インスタンスにすぐに送信します。動的バックエンドを開始すると、App Engine はバックエンドにトラフィックを受け入れることを許可しますが、バックエンドを呼び出す最初のユーザー リクエストを App Engine が受け取るまで、/_ah/start リクエストはインスタンスに送信されません。複数の動的インスタンスが開始されるのは、増加したトラフィックを処理するために必要とされる場合のみです。

インスタンスが HTTP ステータス コード 200~299 または 404 で /_ah/start リクエストに応答する場合、正常に開始されたとみなされ、追加のリクエストを処理できるようになります。それ以外で応答した場合、App Engine はインスタンスを終了し、必要に応じて開始リクエストを再発行します。常駐バックエンドはすぐに再開されますが、動的バックエンドはトラフィックを処理するために必要とされるときにのみ再開されます。backends.yaml のバックエンドごとに異なる開始ハンドラを指定できます。この構文は試験運用版です。

シャットダウン

App Engine がバックエンド インスタンスを終了する必要がある場合、既存のリクエストが完了するために 30 秒間待機し、新規リクエストにはすぐに 404 を返します。シャットダウン プロセスは、次のようなさまざまな計画的または計画外のイベントによってトリガーされます。

  • 管理コンソールまたは appcfg backends <dir> stop を使用してバックエンドを手動で停止した。
  • appcfg backends <dir> update を使用してバックエンドを更新した。
  • バックエンドのメモリ使用量が、設定されたクラスの最大メモリを超過した。
  • アプリケーションがバックエンド使用量割り当てを使い果たした。
  • バックエンドを実行するマシンが再起動され、バックエンドが強制的に別のマシンに移された。
  • 負荷分散を改善するために、App Engine がバックエンドを別のマシンに移動する必要が生じた。

可能な場合、App Engine は終了する 30 秒前にバックエンドに通知します。この通知を受け取るには 2 つの方法があります。まず、google.appengine.api.runtime から is_shutting_down() メソッドを呼び出して、true が返されることを確認する方法です。2 つ目は、シャットダウン フックを登録し、呼び出させる方法です。開始リクエストでシャットダウン フックを登録することをおすすめします。

リクエストを処理している場合、App Engine がそのリクエストを一時停止してフックを実行します。リクエストを処理していない場合、App Engine は /_ah/stop リクエストを送信し、これによってシャットダウン フックが実行されます。/_ah/stop リクエストは通常の処理ロジックをバイパスするので、ユーザーコードではこのリクエストを処理できません。このリクエストの唯一の目的はシャットダウン フックを起動することです。別のリクエストの処理中にシャットダウン フックで例外を発生させると、それがリクエストに伝播して、キャッチ可能になります。

Python 2.7 で threadsafe を使用する場合、シャットダウン フックから例外を発生させると、その例外がすべてのスレッドにコピーされます。

次のコードサンプルは、基本的なシャットダウン フックを実行します。

from google.appengine.api import apiproxy_stub_map
from google.appengine.api import runtime

def my_shutdown_hook():
  apiproxy_stub_map.apiproxy.CancelApiCalls()
  save_state()
  # May want to raise an exception

runtime.set_shutdown_hook(my_shutdown_hook)

別の方法として、次の例に示す is_shutting_down() メソッドを使用することもできます。

while more_work_to_do and not runtime.is_shutting_down():
  do_some_work()
  save_state()

バックエンドの稼働時間

App Engine は、バックエンドを継続的に実行しようと試みます。ただし、現時点では、バックエンドの稼働時間は保証されていません。ハードウェアやソフトウェアの障害のために事前の警告なく処理が途中で終了したり頻繁に再起動したりする場合もあり、このような障害の解決に長い時間がかかることもあります。これらの障害に耐えられるようにアプリケーションを構築してください。App Engine チームは、統計が利用可能になり次第、予想されるバックエンド稼働時間に関する詳細なガイダンスを提供します。

バックエンドの再起動によるダウンタイムを回避するには、次のような手法が効果的です。

  • 複数のバックエンド インスタンスで負荷分散する
  • トラフィック パターンの処理に通常必要となる数よりも多くのバックエンド インスタンスを設定する
  • バックエンドが利用できない場合にキャッシュされた結果を使用するためのフォールバック ロジックを作成する
  • バックエンドの起動とシャットダウンの所要時間を短縮する
  • 複数のバックエンド インスタンスで同じ状態を複製する

バックエンドの終了前に必ずしもシャットダウン フックを実行できるとは限りません。まれなケースですが、停電が発生して、App Engine が 30 秒のシャットダウン時間を設けることができないことがあります。このため、バックエンドの状態を定期的にチェックポイントとして保存し、信頼性の高いデータストアではなく、メモリ内キャッシュとしてこれを主に使用することをおすすめします。

バックエンドのアドレス指定

アプリケーションのカスタム ドメインで http://[instance]-dot-[backend_name]-dot-[your_app_id].appspot.com への HTTP リクエストを使用することによりバックエンド インスタンスをターゲットとすることができます。http://[backend_name]-dot-[your_app_id].appspot.com を使用してインスタンスをターゲットとせずにバックエンドをターゲットとする場合、App Engine はバックエンドの最初の使用可能なインスタンスを選択します。

Backends API は、バックエンドまたはインスタンスのアドレスを取得する関数を提供します。これを使用して、アプリケーション バージョンがリクエストに対してバックエンドをターゲットとする、あるバックエンドが別のバックエンドをターゲットとする、またはあるバックエンドの 1 つのインスタンスが別のインスタンスをターゲットとすることができます。これは開発と本番のどちらの環境でも使用できます。

環境変数 BACKEND_IDINSTANCE_ID には、リクエストを処理するインスタンスのバックエンド名とインスタンス インデックスが入っています。

注: リクエストは HTTPS プロトコルを使用してアプリに送信することをおすすめしますappspot.com でホストされるドメインで、ワイルドカードが 2 つ以上含まれるものには SSL 証明書が発行されません。そのため、下記の例に示すように、HTTPS ではサブドメインの区切りに「.」の代わりに「-dot-」という文字列を使用する必要があります。独自のカスタム ドメインや HTTP アドレスには「.」を使用できます。

一般公開と限定公開のバックエンド

バックエンドは一般公開する(つまり、何らかの方法でユーザーに直接公開する)ことも、限定公開する(つまり、ユーザーには公開しない)こともできます。バックエンドはデフォルトでは限定公開となるため、一般公開用としてではなく通常アプリケーション内部のコンポーネントとして機能します。限定公開バックエンドは、特別な設定なしに、アプリケーション管理者、アプリケーションのインスタンス、App Engine の API とサービス(タスクキュー タスクや cron ジョブなど)からアクセスできます。バックエンドはユーザー トラフィックの処理を目的とはしていませんが、テスト目的で、または外部システムとやり取りするためにバックエンドを一般公開できます。

オフライン処理に使用するバックエンドは、通常、ユーザーが認識しない方法で、停止、更新、サイズ変更ができます。バックエンドが、ユーザーが認識するリクエスト フローに組み込まれる場合、その更新にはより注意する必要があります。バックエンドへの更新ではほとんどの場合、既存のインスタンスをシャットダウンし、新しいインスタンスを起動する必要があります。起動とシャットダウンを早く行えれば、ユーザー トラフィックへの影響を最小限に抑えながら速やかに更新を実行できます。特定のバックエンド設定では、バックエンドを再起動せずに、appcfg backends configure コマンドを使用して更新できます。

バックグラウンド スレッド

バックエンドで実行するコードは、スレッドを生成したリクエストよりも「長く存続」できるバックグラウンド スレッドを開始できます。これらのスレッドにより、バックエンド インスタンスは任意の周期またはスケジュールによってタスクを実行できるようなるほか、リクエストがユーザーに返された後でもバックグラウンドで作業を続行できるようになります。

バックグラウンド スレッドの os.environ とロギング エントリは、生成元スレッドのそれらの値とは無関係です。

バックグラウンド スレッド API は、google.appengine.api.background_thread で定義されています。その BackgroundThread クラスは通常の Python threading.Thread クラスに似ていますが、スレッドを生成したリクエストよりも「長く存続」できます。

from google.appengine.api import background_thread

def f(arg1, arg2, **kwargs):
  ...something useful...

t = background_thread.BackgroundThread(target=f, args=["foo", "bar"])
t.start()

start_new_background_thread 関数はバックグラウンド スレッドを作成し、開始します。

from google.appengine.api import background_thread

def f(arg1, arg2, **kwargs):
  ...something useful...

tid = background_thread.start_new_background_thread(f, ["foo", "bar"])

同時実行バックグラウンド スレッドの最大数は 10 個です。

リソース使用状況のモニタリング

管理コンソールの [インスタンス] コンソール セクションで、バックエンド インスタンスの実行状況を確認できます。バージョン/バックエンド ドロップダウンでバックエンドを選択することによって、各インスタンスのメモリと CPU の使用状況、稼働時間、リクエスト数と他の統計情報を確認できます。また、任意のインスタンスに対してシャットダウン プロセスを手動で開始できます。

Runtime API を使用して、バックエンド インスタンスの CPU やメモリの使用量を表示する統計情報にアクセスすることもできます。これらの統計情報によって、リソースの使用量がリクエストや実行される処理にどのように対応しているか、またバックエンド クラスのメモリ制限を超えないようにするためメモリに格納されたデータ量をどのように制御するかを把握できます。

定期的なロギング

アプリケーション ログは、バックエンドのリクエスト中に、定期的に自動でフラッシュされます。フラッシュ設定を調整することも、Logs API を使用して即座にフラッシュを実行することもできます。フラッシュが実行されると、その時点でまだフラッシュされていないログメッセージを含む新しいログエントリが作成されます。これらのエントリは、フラッシュのマークが付けられて [ログ] コンソールに表示されます。また、フラッシュを生成したリクエストの開始時間も示されます。

リクエストログとアプリケーション ログのフェッチ

プログラムからリクエストや使用しているアプリケーションのアプリケーション ログにアクセスするために、Logs API(特にその fetch() 関数)を使用できます。この機能によって、リクエスト ID、タイムスタンプ、バージョン ID などさまざまなフィルタを使用してログを取得できます。

バックエンドの管理

管理コンソールの [バックエンド] コンソール セクションでは、すべてのバックエンドのリストが表示され、バックエンドを開始、停止、削除するオプションが提供されます。バックエンドはアルファベット順にリストされ、バックエンドを設定したときに選択した options(バックエンドを動的に設定するオプションなど)と一緒に表示されます。

課金、割り当て量、制限

課金

バックエンドは、バックエンド クラスごとに異なる時間単価に基づいて計算されます。次の表は各クラスのコストをまとめたものです。

クラスの設定 メモリ制限 CPU 制限 1 インスタンスの 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.8GHz $0.40

バックエンドの使用料金は通常、バックエンドの稼働時間に応じて時間単位で課金されます。バックエンドが起動すると課金が開始し、バックエンドがシャットダウンした 15 分後に課金が終了します。実行時オーバーヘッドはインスタンスのメモリ制限に対して計算されます。この金額は、Python よりも Java の方が高くなります。

課金は常駐バックエンドと動的バックエンドで多少異なります。

  • 常駐バックエンドの場合、バックエンドがシャットダウンされてから 15 分後までが課金対象となります。
  • 動的バックエンドの場合、最終リクエストの処理完了から 15 分後までが課金対象となります。

バックエンド クラスの変更も課金に影響します。

  • 金額の高いクラスから低いクラスに切り替える場合、変更してから 15 分間は高い金額が課金されます。
  • 金額の低いクラスから高いクラスに切り替える場合、金額の高いクラスのバックエンドが最初のリクエストを受け取ったときに、高い金額の課金が開始されます。

割り当て量と制限

バックエンドでは、ユーザー リクエストの 60 秒間の有効期限、タスクの 10 分間の有効期限は適用されず、無期限に実行できます。バックエンドは、以下の例外を除き、通常のインスタンスと同じ API の割り当て、制限、呼び出しの有効期限が適用されます。

  • バックエンドでは、最大 100 個までの同時 API 呼び出しが許可されます
  • タスクキューのタスクがバックエンドに送信される場合、24 時間の有効期限があります。

バックエンドの数とサイズに対するデフォルトの制限は、アプリケーションのロケーションと、それが課金対象であるかどうかに依存します。

リソースタイプ 無料アプリの制限 課金アプリの制限
US HRD EU HRD
1 つのアプリケーションに対するバックエンド数 5 20 20
1 つのバックエンドに対するインスタンス数 20 200 25
1 つのアプリケーションに対する設定済み常駐および動的バックエンド メモリの合計 10 GB 200 GB 50 GB
このページは役立ちましたか?評価をお願いいたします。

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

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