インスタンスの管理方法

インスタンスは App Engine の基本的な構成要素で、アプリケーションのホスティングに必要なすべてのリソースを提供します。必要なリソースには、言語ランタイム、App Engine API、アプリケーションのコード、メモリなどがあります。各インスタンスにはセキュリティ レイヤが組み込まれており、インスタンスが誤って相互に影響しないようになっています。

インスタンスは、アプリケーションを自動的にスケーリングするために App Engine で使われるコンピューティング単位です。ある時点において、アプリケーションは 1 つのインスタンスで実行されていることもあれば、複数のインスタンスで実行されていることもあります(このときリクエストはすべてのインスタンス間で分散されます)。

インスタンスの概要

インスタンスには、常駐型のインスタンスと動的インスタンスがあります。動的インスタンスは、必要に応じて自動的に起動、シャットダウンされます。常駐型のインスタンスは常に稼働しているため、アプリケーションのパフォーマンスが向上します。動的インスタンスと常駐型のインスタンスはどちらも App Engine サービス バージョンに含まれるコードをインスタンス化したものです。

アプリの手動スケーリングを有効にすると、そのアプリが実行されるインスタンスは常駐型のインスタンスになります。基本スケーリングまたは自動スケーリングを使用している場合、アプリは動的インスタンスで実行されます。

アプリを構成するときに、サービスのスケーリング方法も次のように指定します。

  • サービスの初期インスタンス数。
  • トラフィックに応じて新しいインスタンスを作成または停止する方法。
  • リクエストの処理用としてインスタンスに割り当てる時間。

常駐型のインスタンスになるか動的インスタンスになるかは、サービスに割り当てるスケーリング タイプによって決まります。

  • 自動スケーリング サービスでは、動的インスタンスが使用される。
  • 手動スケーリング サービスでは、常駐型のインスタンスが使用される。
  • 基本スケーリング サービスでは、動的インスタンスが使用される。

App Engine の料金は、インスタンスの使用量に応じて 1 時間単位で発生します。インスタンスの使用状況は、Google Cloud Platform Console の [インスタンス] ページで確認できます。インスタンスに課金される料金の上限を設定するには、使用量上限の設定を行います。App Engine にデプロイするサービスは、構成に基づいて独立してスケーリングされるマイクロサービスと同様に動作します。

動的インスタンスのスケーリング

App Engine アプリケーションを実行する動的インスタンスの数は、受信するリクエストの量に応じて常に変化します。アプリケーションに対するリクエストが増えると、動的インスタンスの数も増えます。

App Engine スケジューラは、リクエストが送られてくるたびに、それを既存のインスタンス(アイドル状態のインスタンスまたは同時リクエストを処理できるインスタンス)で処理するか、保留リクエスト キューに入れるか、そのリクエスト用に新しいインスタンスを起動するかを決定します。このとき、使用可能なインスタンスの数、アプリケーションでリクエストの処理に費やしている時間(レイテンシ)、新しいインスタンスの起動に要する時間が考慮されます。

自動スケーリングを使用する場合、target_cpu_utilizationtarget_throughput_utilizationmax_concurrent_requests の値を設定することにより、スケジューラの動作を最適化して、パフォーマンスとコストのバランスをとることができます。

自動スケーリング パラメータ 説明
ターゲットの CPU 使用率 CPU 使用率のしきい値。CPU の使用量がこの値を超えると、トラフィックを処理するために追加インスタンスが起動されます。
ターゲットのスループット使用率 同時リクエスト数のスループットのしきい値。この値を超えると、トラフィックを処理するために追加インスタンスが起動されます。
最大同時リクエスト 1 つのインスタンスが同時に受け入れることができるリクエストの最大数。この値を超えると、スケジューラは新しいインスタンスを生成します。

App Engine の新しいスケジューラの設定の動画を見ると、これらの設定の効果を確認できます。

各インスタンスには、送られてくるリクエストを受け入れるための専用のキューがあります。App Engine は、各インスタンスのキューで待機しているリクエストの数をモニタリングし、アプリケーションの負荷が増えてキューが長くなりすぎると、アプリケーションの新しいインスタンスを自動的に作成してその負荷に対処します。

App Engine のスケールアップは極めて短時間で行われます。そのため、サービスに対するリクエストをまとめて、タスクキューに送信して処理するような場合は、大量のインスタンスが急激に作成されます。可能であれば、これを制御するために 1 秒あたりの送信リクエスト数を制限することをおすすめします。

リクエスト量が減ると、App Engine はインスタンスのスケールダウンを行います。このスケーリングによって、アプリケーションの現在のインスタンスがすべて使用される状態になり、処理の効率と費用対効果が向上します。

あるアプリケーションがまったく使用されていないとき、App Engine はそのアプリケーションに関連付けられた動的インスタンスを無効にしますが、インスタンスが必要になった時点で直ちに再読み込みを行います。インスタンスの再読み込みが行われると、読み込みリクエストが発生し、ユーザーの待ち時間が長くなることがあります。

アイドル状態のインスタンスの最小数を指定することができます。アプリケーションのアイドル状態のインスタンス数をリクエスト数に基づいて適切に設定すると、リクエスト数が異常に多くなった場合を除き、アプリケーションは短いレイテンシですべてのリクエストを処理できます。

インスタンスのスケーリング

特定のバージョンのサービスをアップロードするときに、app.yaml で、そのバージョンのすべてのインスタンスに適用されるスケーリング タイプインスタンス クラスを指定します。スケーリング タイプでインスタンスの作成方法が制御されます。インスタンス クラスでコンピューティング リソース(メモリサイズと CPU 速度)や料金が決まります。スケーリング タイプは手動、基本、自動の 3 つがあります。利用できるインスタンス クラスは、スケーリング タイプによって異なります。

手動スケーリング
手動スケーリングを使用するサービスでは、負荷レベルに関係なく指定された数のインスタンスを連続して実行する常駐型のインスタンスが使用されます。これにより、複雑な初期化などのタスクや、時間の経過に伴うメモリの状態に依存するアプリケーションを実行できます。
自動スケーリング
自動スケーリング サービスでは、リクエスト率やレスポンス レイテンシといったアプリケーション関連の指標に基づいて作成された動的インスタンスが使用されます。ただし、アイドル状態のインスタンスの最小数を指定した場合は、指定した数のインスタンスが常駐型のインスタンスとして実行され、追加のインスタンスは動的インスタンスとして作成されます。
基本スケーリング
基本スケーリングを使用するサービスでは、動的インスタンスが使用されます。各インスタンスは、アプリケーションがリクエストを受け取ったときに作成されます。アプリケーションがアイドル状態になると、インスタンスはシャットダウンされます。基本スケーリングは、断続的な処理やユーザーのアクティビティに左右される処理に適しています。

以下に、3 つのスケーリング タイプのパフォーマンス機能を比較した表を示します。

機能 自動スケーリング 手動スケーリング 基本スケーリング
期限 HTTP リクエストの場合は 60 秒、タスクキューのタスクの場合は 10 分。 リクエストは最大 24 時間実行できます。手動スケーリングしたインスタンスでは、/_ah/start を処理し、HTTP レスポンス コードを返さずに何時間もプログラムやスクリプトを実行できます。タスクキューのタスクは最大 24 時間実行できます。 手動スケーリングと同様。
常駐 インスタンスは使用パターンに基づいてメモリから強制排除されます。 インスタンスはメモリに残り、状態はリクエスト間で保持されます。インスタンスを再起動すると、/_ah/stop リクエストがログに示されます。シャットダウン フックが登録されている場合、完了まで 30 秒待ってからシャットダウンが発生します。 インスタンスは idle_timeout パラメータに基づいて強制排除されます。リクエストを受信していない時間が idle_timeout を超えた場合など、アイドル状態になっているインスタンスは強制排除されます。
起動とシャットダウン インスタンスはリクエスト処理のためにオンデマンドで作成され、アイドル時には自動的にシャットダウンされます。 インスタンスには App Engine から開始リクエストが /_ah/start への空の GET リクエストの形式で自動的に送信されます。手動で停止されたインスタンスは、リクエストの処理完了まで 30 秒待ってから強制終了されます。 インスタンスはリクエスト処理のためにオンデマンドで作成され、idle_timeout 設定パラメータに基づいてアイドル時には自動的にシャットダウンされます。手動スケーリングの場合と同様、手動で停止されたインスタンスは、リクエスト処理の完了まで 30 秒待ってから強制終了されます。
インスタンスのアドレス指定 インスタンスは匿名です。 サービス「s」のバージョン「v」のインスタンス「i」は http://i.v.s.app_id.appspot.com という形式の URL でアドレス指定できます。カスタム ドメインにワイルドカード サブドメイン マッピングを設定している場合、http://s.domain.com または http://i.s.domain.com という形式の URL でサービスまたはその任意のインスタンスをアドレス指定できます。各インスタンスの状態をキャッシュに確実に保存できるので、後続のリクエストでその状態を取得できます。 手動スケーリングと同様。
スケーリング App Engine は処理量に応じて自動的にインスタンスの数を増減させます。このスケーリングは、構成ファイルでバージョンごとに指定されている automatic_scaling 設定に基づいて実行されます。 各バージョンのインスタンスの数は該当するサービスの構成ファイルで設定します。インスタンスの数は通常、メモリに保持されているデータセットのサイズまたはオフライン作業の目標スループットに対応します。 基本スケーリングを適用するサービスについては、basic_scaling 設定の max_instances パラメータでインスタンスの最大数を設定します。実行中のインスタンスの数は、処理量に応じて増減します。
1 日の無料割り当て使用量 28 インスタンス時間 8 インスタンス時間 8 インスタンス時間

インスタンスのライフサイクル

インスタンスの状態

自動スケーリング サービスのインスタンスは常時実行されています。ただし、手動または基本スケーリング サービスのインスタンスは、実行中または停止中のいずれかになります。同じサービス / バージョンのすべてのインスタンスは、同じ状態を共有します。インスタンスの状態を変更するには、使用しているバージョンを停止します。具体的には、GCP Console の [バージョン] ページを使用するか、 gcloud app versions start gcloud app versions stop コマンドを使用します。

起動

各サービス インスタンスは、開始リクエスト(/_ah/start に対する空の HTTP GET リクエスト)へのレスポンスとして作成されます。App Engine がこのリクエストを送信するとインスタンスが生成されます。ユーザーが /_ah/start にリクエストを送ることはできません。手動または基本スケーリングのインスタンスは、開始リクエストに応答した後で初めて別のリクエストを処理できるようになります。開始リクエストは、次の 2 つの目的で使用されます。

  • 追加のリクエストを受け入れずに、無期限で実行されるプログラムを起動する。
  • 追加のトラフィックを受信する前に、インスタンスを初期化する。

スケーリングの種類(手動、基本、自動)によって、インスタンスの起動方法が異なります。手動スケーリングのインスタンスを起動すると、App Engine によって各インスタンスに直ちに /_ah/start リクエストが送信されます。基本スケーリング サービスのインスタンスを起動すると、そのインスタンスはトラフィックの受信を許可されますが、最初のユーザー リクエストを受け取るまでインスタンスに /_ah/start リクエストは送信されません。複数の基本スケーリングのインスタンスが起動されるのは、トラフィックの増加に対応する必要がある場合だけです。自動スケーリングのインスタンスは /_ah/start リクエストを受信しません。

インスタンスが /_ah/start リクエストに対して HTTP ステータス コード 200–299 または 404 を返した場合、そのインスタンスは正常に起動したと見なされ、追加のリクエストを処理できます。それ以外の場合、App Engine はインスタンスを終了します。手動スケーリングのインスタンスは直ちに再起動されますが、基本スケーリングのインスタンスはトラフィックの処理に必要になった時点で初めて再起動されます。

シャットダウン

シャットダウン プロセスは、次に示すような計画的なイベントや計画外のイベントによって開始します。

  • インスタンスを手動で停止した。
  • 更新されたバージョンをサービスにデプロイした。
  • インスタンスのメモリ量が、instance_class で設定されている最大値を超えた。
  • アプリケーションが、インスタンスの時間割り当てをすべて消費した。
  • インスタンスが別のマシンに移動された(インスタンスを現在実行しているマシンが再起動されたか、App Engine が負荷分散の目的でインスタンスを移動したため)。

読み込みリクエスト

App Engine でアプリケーションの新しいインスタンスが作成されるとき、リクエストの処理に必要なすべてのライブラリとリソースを最初にインスタンスで読み込む必要があります。この読み込みは、インスタンスへの最初のリクエスト(「読み込みリクエスト」とも呼ばれる)の際に発生します。読み込みリクエスト中にアプリケーションで初期化が行われるため、リクエストの処理に通常より時間がかかります。

読み込みリクエストの所要時間を短縮するためのベスト プラクティスを次に紹介します。

  • 起動に必要なコードのみを読み込みます。
  • ディスクへのアクセスをできる限り少なくします。
  • 場合によっては、1 個の zip または jar ファイルからコードを読み込む方が、多数のファイルから読み込むよりも高速です。

ウォームアップ リクエスト

ウォームアップ リクエストとは、読み込みリクエストのうち、実際のリクエストが行われる前にインスタンスにアプリケーション コードを読み込んでおく特別なリクエストのことです。手動スケーリングと基本スケーリングのインスタンスは /_ah/warmup リクエストを受信しません。

ウォームアップ リクエストの使用方法については、ウォームアップ リクエストの構成をご覧ください。

インスタンス稼働時間

App Engine は、手動スケーリングと基本スケーリングのインスタンスを継続的に実行しようと試みます。ただし、現時点では、手動および基本スケーリング インスタンスの稼働時間は保証されていません。

インスタンスの課金

通常、インスタンスでは 15 分間の起動料金に加えて、稼働時間に対して分単位の使用料金が発生します(詳細は料金を参照)。アイドル状態のインスタンスについては、サービスごとに設定するアイドル状態のインスタンスの最大数を上限とし、その範囲内で課金されます。実行時オーバーヘッドはインスタンスのメモリに対して計算されます。これは Python よりも Java アプリケーションの場合の方が大きくなります。

課金は常駐インスタンスと動的インスタンスで多少異なります。

  • 常駐型のインスタンスの場合、インスタンスのシャットダウンから 15 分後に課金が終了します。
  • 動的インスタンスの場合、最終リクエストの処理完了から 15 分後に課金が終了します。
このページは役立ちましたか?評価をお願いいたします。

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

Node.js 用 App Engine スタンダード環境に関するドキュメント