インスタンスの管理方法

インスタンスは 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 使用率のしきい値を設定します。この値は、トラフィックを処理するために追加のインスタンスを起動する基準となります。
ターゲットのスループット使用率 リクエストを同時に処理するスループットのしきい値を設定します。この値を超えると、トラフィックを処理するために追加のインスタンスが起動されます。
最大同時要求 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 リクエストを送信します。基本スケーリング サービスのインスタンスを起動すると、App Engine はそのインスタンスに対してトラフィックの受け入れを許可しますが、インスタンスが最初のユーザー リクエストを受信するまで /_ah/start リクエストはインスタンスに送信されません。基本スケーリング インスタンスは、トラフィックの増加に対応するために必要な数だけ起動されます。自動スケーリング インスタンスは /_ah/start リクエストを受信しません。

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

読み込みリクエスト

App Engine がアプリケーションのインスタンスを新たに作成すると、そのインスタンスはリクエストの処理に必要なライブラリとリソースを最初にすべて読み込む必要があります。これはそのインスタンスに対する最初のリクエスト(読み込みリクエストと呼ぶ)の過程で行われます。途中でアプリケーションの初期化が行われるので、読み込みリクエストは通常より時間がかかります。

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

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

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

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

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

インスタンス稼働時間

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

インスタンスの課金

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

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

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

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

App Engine standard environment for PHP 7.2 docs