App Engine スタンダード環境ユーザーのための App Engine フレキシブル環境

このガイドでは、スタンダード環境に慣れているユーザーのためにフレキシブル環境を紹介します。それぞれの環境の類似点と重要な相違点を説明し、両方の環境を使用するアプリケーションにおすすめの一般的なアーキテクチャを紹介します。

スタンダード環境で使用可能なサービスをフレキシブル環境の類似サービスにマッピングするには、スタンダード環境からフレキシブル環境へのサービスの移行をご覧ください。

類似点と重要な相違点

App Engine のデプロイ、サービス、スケーリング インフラストラクチャは、両方の環境で提供されます。重要な違いは、環境がアプリケーションを実行する方法、アプリケーションが外部サービスにアクセスする方法、アプリケーションをローカルで実行する方法、アプリケーションのスケーリング方法です。これらの違いの概要については、環境を選択するでも確認できます。

アプリケーションの実行

スタンダード環境では、アプリケーションはサンドボックス内の軽量なインスタンス上で実行されます。このサンドボックスでは、アプリケーションにできることが制限されます。たとえば、アプリケーションはディスクに書き込んだり、ホワイトリストに登録されていないバイナリ ライブラリを使用したりすることはできません。またスタンダード環境では、アプリケーションで使用できる CPU とメモリ量のオプションが制限されます。これらの制限のため、App Engine スタンダード アプリケーションのほとんどは HTTP リクエストに素早く応答するステートレス ウェブ アプリケーションとなる傾向があります。

対照的に、フレキシブル環境ではアプリケーションは制限の少ない Google Compute Engine 仮想マシン(VM)上の Docker コンテナで実行されます。たとえば、任意のプログラミング言語の使用、ディスクへの書き込み、任意のライブラリの使用、さらに複数プロセスの実行が可能です。またフレキシブル環境では、インスタンスに対して任意の Compute Engine マシンタイプを選択して、アプリケーションがより多くのメモリと CPU にアクセスできるようにすることができます。

外部サービスにアクセスする

スタンダード環境では、アプリケーションは通常、組み込みの google.appengine API を介して Cloud Datastore などのサービスにアクセスします。しかし、フレキシブル環境ではこうした API を使用できません。代わりに、Google Cloud クライアント ライブラリを使用します。これらのクライアント ライブラリはどこでも使用できるので、アプリケーションのポータビリティが高まります。フレキシブル環境で実行されるアプリケーションは、通常は大きな変更を加えずに、必要に応じて Google Kubernetes Engine または Compute Engine で実行できます。

ローカルでの開発

スタンダード環境では通常、アプリケーションを App Engine SDK を使用してローカルで実行します。SDK がアプリケーションの実行を処理し、App Engine サービスをエミュレートします。フレキシブル環境では、アプリケーションの実行に SDK は使用されません。代わりに、フレキシブル環境向けのアプリケーションは、どこででも実行できる標準的なウェブ アプリケーションとして記述する必要があります。前述のように、フレキシブル環境ではアプリケーションは Docker コンテナで実行されるだけです。つまり、ローカルでアプリケーションをテストするには、アプリケーションを直接実行することになります。たとえば、Django を使用して Python アプリケーションを実行するには、python manage.py runserver を実行すればよいのです。

もう一つの重要な違いとして、ローカルで実行されるフレキシブル環境のアプリケーションは、Cloud Datastore などの実際の Cloud Platform サービスを使用します。ローカルでのテストには別のプロジェクトを使用し、可能な場合にはエミュレータを使用してください。

スケーリングの特徴

どちらの環境も App Engine の自動スケーリング インフラストラクチャを使用しますが、スケーリングの方法は異なります。スタンダード環境では 0 個のインスタンスから数千のインスタンスまで素早くスケーリングできます。対照的に、フレキシブル環境では実行中のアプリケーションのインスタンスが少なくとも 1 つなければならず、トラフィックに応じてスケーリングするのに時間がかかる場合があります。

スタンダード環境では、カスタム設計の自動スケーリング アルゴリズムが使用されます。フレキシブル環境では、Compute Engine オートスケーラーを使用します。フレキシブル環境は、Compute Engine で使用可能なすべての自動スケーリング オプションをサポートしているわけではありません。デベロッパーは、さまざまな条件下でアプリケーションの動作をテストする必要があります。たとえば、CPU バウンドのアプリケーションが、リモート サービスを呼び出す際のレイテンシが長くなって I/O バウンドになった場合、自動スケーリングがどのように応答するかを確認する必要があります。

ヘルスチェック

スタンダード環境では、インスタンスにトラフィックを送信するかどうかの決定にヘルスチェックは使用されません。フレキシブル環境では、アプリケーション デベロッパーは独自のヘルスチェック ハンドラを作成できます。これはロードバランサによって、トラフィックをインスタンスに送信するかどうかや自動修復を行うかどうかの決定に使用されます。デベロッパーは、ヘルスチェックにロジックを追加する際に注意する必要があります。たとえば、ヘルスチェックによって外部サービスを呼び出し、そのサービスで一時的な障害が発生すると、すべてのインスタンスが異常になり、カスケード障害が発生する可能性があります。

過負荷時のリクエストのドロップ

カスケード障害を回避するための戦略の一環として、過負荷時にアプリケーションがリクエストをドロップすることができます。この機能は、スタンダード環境のトラフィック ルーティング レイヤに組み込まれています。フレキシブル環境における QPS の非常に高いアプリケーションを開発する場合は、同時リクエストの数を制限して過負荷トラフィックをドロップする機能をアプリケーションに組み込むことをおすすめします。

フレキシブル環境のアプリケーションがこのタイプの障害の影響を受けないことを確認するには、最大インスタンス数を制限したバージョンを作成します。その後、リクエストがドロップされるまで、トラフィックを徐々に増やします。アプリケーションが過負荷時にヘルスチェックに失敗しないことを確認する必要があります。

Jetty ランタイムを使用している Java アプリでは、過負荷トラフィックをドロップするように Quality of Service フィルタを構成できます。アプリによって同時処理されるクエストの最大数と、この機能によってリクエストがキュー内に入っている時間の長さを設定できます。

インスタンス サイズ

フレキシブル環境のインスタンスでは、CPU とメモリの上限をスタンダード環境のインスタンスよりも高く設定できます。これにより、フレキシブル インスタンスではメモリと CPU をより多く消費するアプリケーションを実行できます。ただし、単一インスタンス内のスレッド数が増加するため、同時実行に関するバグの発生する可能性が高くなります。

デベロッパーは、フレキシブル環境インスタンスに SSH で接続してスレッドダンプを取得することで、このタイプの問題のトラブルシューティングを実施できます。

$ ps auwwx | grep java
$ sudo kill -3 
$ sudo docker logs gaeapp

リクエストの最大タイムアウト

スタンダード環境では、自動スケーリングを使用するバージョンに対して 60 秒のリクエスト期限が設けられています。フレキシブル環境にはそうした期限は設けられていないため、アプリケーション プログラマーは、リクエストが無期限にハングアップして最終的にウェブサーバー上のすべてのスレッドが使い尽くされることを避けるために、外部サービスに対するすべての呼び出しでタイムアウトを確実に指定するように注意する必要があります。

アプリケーション デベロッパーは、フレキシブル環境で 60 秒以上かかるリクエストを強制終了するために、独自のサーブレット フィルタを実装できます。アプリケーションが一貫性のない状態にならないように、リクエスト スレッドの強制終了時には、クリーンアップを適切に処理することが重要です。

スレッドの管理

スタンダード環境の場合、Java 8 より前の Java ランタイムで使用できるのは App Engine スタンダード環境の SDK で作成されたスレッドだけです。最初の世代の Java スタンダード環境ランタイムをフレキシブル環境に移植する場合は、ネイティブ スレッドのライブラリを使用するように切り替える必要があります。非常に多くのスレッドを必要とするアプリケーションの場合、スレッドを明示的に作成するよりも、スレッドプールを使用したほうが効率的に実行される可能性があります。

トラフィックの移行

スタンダード環境には、レイテンシの急増を最小限に抑えるために、新しいバージョンへのトラフィックの移行を徐々に行うトラフィック移行機能が用意されています。トラフィックを新しいバージョンに切り替える際にレイテンシの急増を確実に回避する方法については、トラフィック移行のドキュメントをご覧ください。

単一ゾーンの障害

スタンダード環境のアプリケーションはシングルホームです。つまり、アプリケーションのインスタンスはすべて、単一の可用性ゾーンに存在します。そのゾーンで障害が発生した場合、アプリケーションは新しいインスタンスを同じリージョン内の別のゾーンで起動し、ロードバランサはトラフィックを新しいインスタンスにルーティングします。リクエストの読み込みと Memcache のフラッシュにより、レイテンシが一時的に急増します。

フレキシブル環境のアプリケーションは、リージョナル マネージド インスタンス グループを使用します。つまり、インスタンスはリージョン内の複数の可用性ゾーンに分散されます。単一のゾーンに障害が発生した場合、ロードバランサはそのゾーンへのトラフィックのルーティングを停止します。インスタンスを可能な限りホットな状態で実行するように自動スケーリングを設定している場合は、自動スケーリングによってインスタンスがさらに作成される前に、短時間の過負荷状態が発生します。

費用の比較

スタンダード環境とフレキシブル環境で実行されるワークロードの費用の比較には、さまざまな要因が関係します。たとえば、次のようなものです。

  • MCycle ごとに支払われる料金。
  • CPU プラットフォーム機能。これは 1 MCycle ごとに実施できる作業に影響します。
  • インスタンスを各プラットフォームでどれだけホットな状態で実行できるか。
  • デプロイの費用。プラットフォームごとに異なる可能性があり、またアプリケーションに継続的デプロイを使用している場合は高額になる可能性があります。
  • 実行時のオーバーヘッド。

各プラットフォームでのワークロードの費用を決定するには、実験を行う必要があります。フレキシブル環境では、変更が費用に影響するかどうかを実験によって判断する際に、アプリケーションのコスト効率の代わりにコアあたりの QPS を使用できます。スタンダード環境では、アプリケーションのコスト効率に関するリアルタイム指標を取得できるメカニズムは用意されていません。変更した後、1 日の請求サイクルが完了するのを待つ必要があります。

マイクロサービス

スタンダード環境では、X-Appengine-Inbound-Appid リクエスト ヘッダーを使用してアプリケーション間の安全な認証を行えます。フレキシブル環境にそのような機能はありません。アプリケーション間の認証を安全に行うには、OAuth の使用をおすすめします。

デプロイ

一般に、スタンダード環境でのデプロイはフレキシブル環境でのデプロイよりも短時間で済みます。フレキシブル環境での既存バージョンのスケールアップは、新しいバージョンのデプロイよりも迅速に行えます。新しいバージョンのためのネットワーク プログラミングは通常、フレキシブル環境でのデプロイにおけるボトルネックとなるためです。フレキシブル環境で迅速なロールバックを行うための戦略のひとつに、正常稼働した実績のあるバージョンを単一インスタンスにスケールダウンして維持しておく、という方法があります。そうしておけば、そのバージョンをスケールアップし、トラフィック分割を使用してすべてのトラフィックをそのバージョンにルーティングするだけで済みます。

フレキシブル環境を使用する際の判断基準

フレキシブル環境は、スタンダード環境を補完することを目的としています。既存のアプリケーションをスタンダード環境で実行している場合、通常、アプリケーション全体をフレキシブル環境に移行する必要はありません。そうではなく、アプリケーションの中で、より多くの CPU やメモリ、特殊なサードパーティ ライブラリやプログラムを必要とする部分や、スタンダード環境では不可能な動作を必要とする部分を見極めてください。アプリケーションにそのような部分があったら、その部分だけをフレキシブル環境を使用して処理する小さな App Engine サービスを作成します。スタンダード環境で実行されている既存のサービスでは、HTTP、Cloud Tasks、Cloud Pub/Sub を使用して他のサービスを呼び出すことができます。

たとえば、スタンダード環境で実行中の既存のウェブ アプリケーションに対して、ファイルを PDF に変換する新しい機能を追加する場合は、PDF への変換のみを処理する別個のマイクロサービスを作成し、それをフレキシブル環境で実行できます。このマイクロサービスは、1 つか 2 つのリクエスト ハンドラだけが含まれたシンプルなプログラムにすることができます。このマイクロサービスでは、変換に役立つ任意の Linux プログラム(unoconv など)をインストールして使用できます。

メイン アプリケーションは、スタンダード環境に残ったまま、HTTP を使用してこのマイクロサービスを直接呼び出せます。また、変換に時間がかかると予想される場合、アプリケーションでは Cloud Tasks または Cloud Pub/Sub を使用してリクエストをキューに追加できます。

次のステップ

スタンダード環境でアプリが使用するサービスをフレキシブル環境の類似サービスにマッピングする

このページは役立ちましたか?評価をお願いいたします。

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

Java の App Engine フレキシブル環境に関するドキュメント