インスタンスはApp Engineの basic building blocks で、アプリケーションをホストするために必要な全てのリソースを提供します。 これには、言語ランタイム、 App Engine API、あなたのアプリケーションのコードとメモリが含まれます。 各インスタンスには、誤って他のインスタンスに影響を与えないようにするためのセキュリティレイヤがあります。
インスタンスは、 App Engineがあなたのアプリケーションを自動的に拡張するために使う、計算単位です。 At any given time, your application may be running on one instance or many instances, with requests being spread across all of them.
インスタンスは 固定的 もしくは 動的に動作します。 動的インスタンスは、その時の必要に応じて自動的に起動とシャットダウンがなされます。 固定インスタンスは常に起動し、アプリケーションのパフォーマンスを向上できます。
インスタンスは、App Engine モジュールに含まれているコードのインスタンスを作成します。
アプリケーションの設定をする場合は、モジュールをどのように拡張するか(モジュールにおけるインスタンス数の初期値と、どれくらいのトラフィックで新しいインスタンスを作成するか、それくらいでそれを止めるか)、と、インスタンスがリクエストの処理をするのにかかる時間をどれくらいまで認めるか (その期限)を設定します。
次の表では、インスタンスが固定的や動的になるのはどのようなモジュール構成の場合かを示します。:
あなたがモジュールに割り当てる拡張クラスによって作成されるインスタンスの種類が決まります。:
App Engineではインスタンスの使用には時間ごとに料金がかかります。 開発者コンソールのインスタンスのページでインスタンスの使用状況を確認できます。 インスタンスの費用に制限を設定したい場合は、予算を設定することでそれが可能です。
App Engine が初めてリリースされた時、モジュールアーキテクチャは存在しませんでした。アプリケーションは、一つのフロントエンドで追加で複数のバックエンドで作られていました。 フロントエンドは既定モジュールの自動拡張版のような動作をします。 バックエンドは手動拡張モジュールや基本拡張モジュールどちらかのような動作をすることができ、どちらになるかは設定に依存します。 バックエンドが現在非推奨なので注意してください。
App Engine アプリケーションはその時間に起動している動的インスタンスの数に応じて強化され、インスタンスの数は届くリクエストの量に依存します。 あなたのアプリケーションへのリクエストが増えると、動的インスタンスの数も増えます。
App Engine スケジュールは新しいリクエストごとに、既存のインスタンスで処理するか (either one that is idle or accepts concurrent requests)、 リクエストを保留中のリクエストキューに置くか、新しくこのリクエスト用のインスタンスを起動させるかを判断します。 使用可能なインスタンスの数、あなたのアプリケーションがどれくらいの頻度でリクエストを処理しているか(そのレイテンシー)、新しいインスタンスを開始するのにどれくらいかかるかが判断基準となります。
各インスタンスは、届いたリクエスト用に専用のキューを持っています。 App Engine は各インスタンスのキューで待機しているリクエストの数を監視しています。 負荷の増加が原因でアプリケーションのキューが長くかかりすぎていることをApp Engineが検地した場合、その負荷を処理するためにアプリケーションの新しいインスタンスを自動的に作成します。
また、リクエスト量が減少した場合、App Engine はインスタンスを縮小します。 This scaling helps ensure that all of your application's current instances are being used to optimal efficiency and cost effectiveness.
アプリケーションがまったく使用されていない場合は、App Engineはそれに関連する動的インスタンスを停止しますが、必要になればすぐにそれらを再読み込みをします。 インスタンスの再読み込みによって、リクエストの読み込みとユーザーの追加待ち時間が発生することがあります。
あなたのアイドルインスタンスの最小値を設定することができます。 異常に高いリクエスト量が発生しない限り、リクエスト量に基づいてアプリケーションの適切な待機インスタンス数を設定することで、 全てのリクエストを少ない待ち時間で処理することができます。
あなたのアプリケーションの待ち時間は、トラフィックを処理するのに必要なインスタンスの数に対して最も大きな影響力を持っています。 リクエストをすばやく処理する場合、一つのインスタンスでたくさんのリクエストを処理することができます。
現在シングルスレッドインスタンス (Python や Java) では一つの concurrent リクエストを制御することができます。 したがって、待ち時間とインスタンス上で毎秒処理できるリクエストの数は直接関係します。 例えば、10ミリ秒の待ち時間があるとインスタンスで1秒間に処理できるリクエスト数は100となり、100ミリ秒の待ち時間があるとインスタンスで1秒間に処理できるリクエスト数は10となる、など。複数スレッドのインスタンスでは多くのconcurrent リクエストを制御することができます。 したがって、消費CPUと毎秒のリクエスト数は直接関係します。
Java とPython 2.7 のapp では concurrent リクエストをサポートしているので、他のリクエストが完了するのを待っている間に新しいリクエストを処理することができます。 同時実行機能によってあなたのアプリで必要なリクエストを大幅に減らすことができますが、特にマルチスレッドを念頭に置いてアプリを設計する必要があります。
例えば、B4 インスタンス (約 2.4GHz) で 1回のリクエストで10 Mサイクル消費する場合、インスタンスは1秒間に240のリクエストを処理できます。 1回のリクエストで100 Mサイクル消費する場合、インスタンスは1秒間に24のリクエストを処理できます、など。 こうした数値は理想的な場合のものであり、実際にインスタンスが叩き出す数値はもっと現実的なものになります。 Python 2.5ランタイムの場合、マルチスレッドインスタンスは使用できません。
App Engine があなたのアプリケーション用に新しいインスタンスを作成した時、まずインスタンスはリクエストを制御するのに必要なライブラリとリソースを読み込む必要があります。 この読み込みは、インスタンスへの最初のリクエストの際に発生し、読み込みリクエスト(Loading Request)と呼ばれます。 読み込みリクエストの間、あなたのアプリケーションでは初期化のためにリクエストの時間がかかります。
以下のベストプラクティスによって読み込みリクエストの時間を減らすことができます。:
ウォーミングアップリクエストは、リクエストが発生する前に事前にアプリケーションコードをインスタンスに読み込む、特別な種類の読み込みリクエストです。 ウォーミングアップリクエストを使用する方法についてさらに知りたいのであれば、アプリケーション設定ページのウォーミングアップリクエストの項目(Java | Python | Go | PHP)を参照してください。
インスタンスは通常、無料の起動時間15分に加えて起動時間1分ごとに料金が発生します。 課金はインスタンスが起動した時に開始され、インスタンスが停止して15分後に終了します (詳細については課金 FAQを参照してください)。 あなたが各モジュールに設定した待機インスタンスの最大数の分まで、待機インスタンスの課金が発生します。 実行中のオーバーヘッドは、インスタンスメモリとしてカウントされます。これは PythonよりもJava アプリケーションの場合に高くなります。
課金は固定インスタンスと動的インスタンスでは少し異なります。: