インスタンスの管理方法

インスタンスは 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 使用率の上限を指定します。
ターゲットのスループット使用率 同時リクエストの数にスループットのしきい値を設定します。このしきい値を超えると、トラフィックを処理するインスタンスの増加が開始されます。
最大同時リクエスト インスタンスが受け入れることができる同時リクエストの最大数を設定します。これを超えると、スケジューラが新しいインスタンスを生成します。

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

それぞれのインスタンスには、そのインスタンス用の受信リクエストのキューがあります。App Engine では、各インスタンスのキューで待機中のリクエストの数がモニタリングされています。負荷の増大に伴ってアプリケーションのキューが過剰に長くなっていることが検出されると、負荷を処理できるようにアプリケーションの新しいインスタンスが自動的に作成されます。

App Engine は非常に短時間でスケールアップできます。そのため、処理のためにリクエストのバッチをサービス(タスクキューなど)に送信している場合は、多数のインスタンスが短時間で作成されます。可能であれば、これを制御するために 1 秒あたりの送信リクエスト数を制限することをおすすめします。たとえば、App Engine のタスクキューでは、タスクが push される速度を制御できます。

リクエストの量が減った場合、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.comhttp://i.s.domain.com という形式の URL でサービスやそのサービスの任意のインスタンスをアドレス指定できます。各インスタンスの状態を確実にキャッシュに保存できるので、後続のリクエストでその状態を取得できます。 手動スケーリングと同様。
スケーリング App Engine は処理量に応じて自動的にインスタンスの数を増減させます。このスケーリングは、構成ファイルでバージョンごとに指定されている automatic_scaling 設定に基づいて実行されます。 各バージョンのインスタンスの数は該当するサービスの構成ファイルで構成します。インスタンスの数は通常、メモリに保持されているデータセットのサイズまたはオフライン作業の目標スループットに対応します。 基本スケーリングを適用するサービスについては、max_instances 構成の basic_scaling パラメータでインスタンスの最大数を設定します。実行中のインスタンスの数は、処理量に応じて増減します。
1 日の無料割り当て使用量 28 インスタンス時間 8 インスタンス時間 8 インスタンス時間

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

インスタンスの状態

自動スケーリング サービスのインスタンスは常時実行されています。それに対して、手動または基本スケーリング サービスのインスタンスは実行中と停止中のどちらかになります。サービスとバージョンが同じであるインスタンスはすべて、同じ状態を共有します。インスタンスの状態を変更するには、バージョンを管理します。次の方法を使用できます。

起動

各サービス インスタンスは、開始リクエスト(/_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 分後に課金が終了します。
このページは役立ちましたか?評価をお願いいたします。

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

PHP 5 の App Engine スタンダード環境