インスタンスの管理方法

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

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

インスタンスの概要

インスタンスには、常駐型のインスタンスと動的なインスタンスがあります。動的なインスタンスは、必要に応じて自動的に開始し、シャットダウンします。常駐型のインスタンスは常時実行されるため、アプリケーションのパフォーマンスが向上します。

各インスタンスは、App Engine のサービスに含まれるコードをインスタンス化したものです。

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

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

サービスに割り当てるスケーリング クラスによって、作成されるインスタンスの種類が決まります。

  • 手動スケーリング サービスでは、常駐型のインスタンスが使用される。
  • 基本スケーリング サービスでは、動的インスタンスが使用される。
  • 自動スケーリング サービスでは動的インスタンスが使用されまる。ただし、アイドル状態のインスタンスの最小数(N)を指定した場合、最初の N 個のインスタンスが常駐し、必要に応じて追加の動的インスタンスが作成される。

App Engine の料金は、インスタンスの使用量に応じて 1 時間単位で発生します。インスタンスの使用状況は、Google Cloud Platform Console の [インスタンス] ページで確認できます。インスタンスに課金される料金の上限を設定するには、使用量の上限を設定できます。

App Engine にデプロイするサービスは、構成に基づいて独立してスケーリングされるマイクロサービスのように動作します。

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

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

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

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

リクエストの量が減ると、App Engine は逆方向にスケーリングしてインスタンス数を少なくします。このスケーリングによって、アプリケーションで現在稼動中のインスタンスが常にすべて使用される状態になり、無駄がなく費用対効果の高い運用が実現します。

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

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

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

インスタンスの状態

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

起動

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

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

スケーリングの種類(手動、基本、自動)によって、インスタンスの起動方法が異なります。手動スケーリングのインスタンスを開始すると、App Engine は各インスタンスに /_ah/start リクエストをすぐに送信します。基本スケーリング サービスのインスタンスを開始すると、App Engine はトラフィックの受信を許可しますが、最初のユーザー リクエストを受け取るまではインスタンスに /_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 は、手動スケーリングと基本スケーリングのインスタンスを継続的に実行しようと試みます。ただし、現時点では、手動および基本スケーリング インスタンスの稼働時間は保証されていません。ハードウェアやソフトウェアの障害のために事前の警告なく処理が途中で終了したり頻繁に再起動したりする場合もあり、このような障害の解決に長い時間がかかることもあります。これらの障害に耐えられるような方法でアプリケーションを構築してください。App Engine チームでは、統計情報が利用可能になり次第、インスタンスの予想稼働時間についてガイダンスを提供する予定です。

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

  • 複数のインスタンス間で負荷分散を行う。
  • トラフィック パターンの処理に通常必要となる数よりも多くのインスタンスを設定する。
  • 手動スケーリング インスタンスが使用不可の場合にキャッシュ内の結果を使用するよう、フォールバック ロジックを作成する。
  • インスタンスの起動とシャットダウンの所要時間を短縮する。
  • 複数のインスタンス間で状態情報を複製して共有する。
  • 長時間稼働する場合には、処理が完了しなかった場合に再開できるよう、状態のチェックポイントを定期的に作成する。

インスタンスの課金

通常、インスタンスでは 15 分間の起動料金に加えて、稼働時間に対して分単位の使用料金が発生します。インスタンスが起動すると課金が開始し、インスタンスのシャットダウンから 15 分後に課金が終了します(詳細については、料金をご覧ください)。アイドル インスタンスに対しては、各サービスに設定したアイドル インスタンス最大数に達するまでの範囲で課金されます。実行時オーバーヘッドは、インスタンスのメモリに対して計算されます。これは Python よりも Java アプリケーションの場合の方が大きくなります。

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

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

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

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