インスタンスは、アプリケーションを自動的にスケーリングするために App Engine で使われるコンピューティング単位です。ある時点において、アプリケーションは 1 つのインスタンスで実行されていることもあれば、複数のインスタンスで実行されていることもあります（このときリクエストはすべてのインスタンス間で分散されます）。
手動スケーリングのインスタンスは継続的に実行されますが、障害や更新のための再起動によりインスタンスが早期に停止される可能性があるため、稼働率の保証はありません。ハードウェアやソフトウェアの障害のため、事前の警告なくインスタンスが途中で終了したり、頻繁に再起動したりする場合があり、このような障害の解決には長い時間がかかることがあります。
利用可能な更新があると、フレキシブル環境のすべてのインスタンスは毎週再起動されます。ただし、スケジュールは保証されません。 再起動中には、下位互換性のある重要な更新が基盤オペレーティング システムに自動的に展開されます。アプリケーションのイメージは再起動後も同じままです。
ヘルスチェック
App Engine は、ヘルスチェック リクエストを定期的に送信して、インスタンスが動作していることと、インスタンスが完全に起動して受信リクエストを受け入れる準備ができていることを確認します。デフォルトでは、これらのヘルスチェックが有効になっており、スプリット ヘルスチェックと呼ばれます。ヘルスチェックを受信するインスタンスは、指定された時間間隔内にそのヘルスチェックに応答する必要があります。
スプリット ヘルスチェックのデフォルトの動作をアプリケーションにまで拡張する必要がある場合は、app.yaml ファイルをカスタマイズして次の 2 種類のヘルスチェックを構成します。
- liveness チェックでは、VM インスタンスとそのコンテナが実行中であることを確認します。VM インスタンスが liveness チェックに失敗すると、インスタンスは自動的に再起動されます。liveness チェックは、構成されたしきい値と時間間隔、またはコンテナの障害が原因で失敗することがあります。
- 準備チェックでは、VM インスタンスが受信リクエストを受け入れる準備ができたことを確認します。VM インスタンスが準備チェックに失敗する場合、その VM インスタンスは起動が完了していないか、リクエストを受信する準備ができていないことを意味します。VM インスタンスが準備チェックに合格して起動が完了すると、使用可能なインスタンスのプールに追加されます。
スプリット ヘルスチェックの動作の詳細については、スプリット ヘルスチェックへの移行ガイドをご覧ください。
インスタンスがこれらのヘルスチェックを行うと、App Engine ログでインスタンスが次のいずれかの状態になります。
- 正常。インスタンスはヘルスチェック リクエストを受信し、リクエストを処理しています。正常なステータスでは、インスタンスの使用可能なディスク容量が 820 MB を超えていることが示されます。ヘルスチェックには、HTTP ステータス コード
200で応答する必要があります。 - 異常。インスタンスがヘルスチェック リクエストを拒否し、特定の回数にわたって連続してヘルスチェック リクエストへの応答に失敗しました。App Engine は、ヘルスチェック リクエストを続行し、異常なインスタンスが事前定義された回数にわたってヘルスチェックへの無応答を続ける場合にはインスタンスを再起動します。
- レームダック。インスタンスには、シャットダウンまたは再起動がスケジュール設定されています。シャットダウン時には、インスタンスは進行中のリクエストを終了し、新しいリクエストを拒否します。アプリからは、インスタンスでリクエストを処理できないことを示す
503コードが返されます。インスタンスがシャットダウンまたは再起動する前にシャットダウン スクリプトの実行期間は制限されており、短くすることや、長くするように構成することはできません。 - アプリのレームダック。インスタンスでは、トラフィックを処理するための準備が進んでいます。アプリからは、インスタンスでリクエストを処理できないことを示す
503コードが返されます。VM インスタンスが起動を完了しトラフィックを処理する準備が整うと、インスタンスは正常になりリクエストを処理します。VM インスタンスが時間内に起動しない場合は、インスタンスが異常に変更されて削除されます。
レームダックとアプリ レームダックの動作は、VM インスタンスが通過する通常のプロセスの一部です。
リソース使用状況のモニタリング
Google Cloud コンソールの [インスタンス] ページでは、インスタンスのパフォーマンスを確認できます。各インスタンスのメモリと CPU の使用状況、稼働時間、リクエスト数と他の統計情報を確認できます。また、任意のインスタンスのシャットダウン プロセスを手動で開始できます。
App Engine フレキシブル環境における NTP
App Engine フレキシブル環境には、Google NTP サーバーを使用するネットワーク タイム プロトコル（NTP）サービスがあります。ただし、フレキシブル環境の NTP サービスは変更できません。
インスタンスの場所
各インスタンスは、プロジェクトの設定に従って地理的なリージョンごとに自動的に配置されます。
インスタンスのスケーリング
アプリケーションの実行中、受信リクエストは適切なサービスやバージョンの既存または新規のインスタンスに転送されます。各アクティブ バージョンには少なくとも 1 つのインスタンスが実行され、サービスまたはバージョンのスケーリング タイプによって追加のインスタンスの作成方法が制御されます。
スケーリング タイプはアプリの app.yaml で指定します。
デフォルトでは、アプリは自動スケーリングを使用します。つまり、App Engine はアイドル インスタンスの数を管理します。
- 自動スケーリング
- 自動スケーリングは、リクエスト率、レスポンスのレイテンシなどのアプリケーションの指標に基づいてインスタンスを作成します。
automatic_scaling要素を構成することで、それぞれの指標のしきい値と、常時稼働する最小数のインスタンスを指定できます。
- 手動スケーリング
- 手動スケーリングでは、負荷レベルに関係なく、常に実行されるインスタンスの数を指定します。これにより、複雑な初期化などのタスクや、時間の経過に伴うメモリの状態に依存するアプリケーションが実行できるようになります。
サービスを管理する
インスタンスのスケーリング タイプに応じて、Google Cloud コンソールまたは Google Cloud CLI でサービスとバージョンを管理できます。
バージョンの停止
App Engine の各バージョンは、処理するように構成したトラフィックの量に応じて、1 つ以上のインスタンス内で実行されます。
使用するツールのタブをクリックして、手順を確認してください。
コンソール
サービスのバージョンを停止または無効にするには:
Google Cloud コンソールの App Engine の [バージョン] ページに移動します。
テーブルからバージョンを選択し、[停止] をクリックします。
gcloud
以下のコマンドを実行します。
gcloud app versions stop --service=SERVICE VERSION
次のように置き換えます。
- SERVICE は、実際のサービスの名前に置き換えます。
- VERSION は、実際のサービスのバージョン名に置き換えます。
サービスの削除
各サービスは、それぞれ異なるランタイムを使用したり、異なるパフォーマンス設定で動作したりするように構成できます。デフォルトのサービスは削除できません。サービスを削除すると、プロジェクト内の付随するバージョンもすべて削除されます。
使用するツールのタブをクリックして、手順を確認してください。
コンソール
サービスを削除するには:
Google Cloud コンソールの App Engine の [サービス] ページに移動します。
テーブルからサービスを選択し、[削除] をクリックします。
gcloud
以下のコマンドを実行します。
gcloud app services delete SERVICE
次のように置き換えます。
- SERVICE は、実際のサービスの名前に置き換えます。