Java 8 ランタイム環境

App Engine を使用すると、Google のスケーラブルなインフラストラクチャとサービスを使用するウェブ アプリケーションをビルドできます。App Engine は Java 8 JVM を使用してウェブ アプリケーションを実行します。App Engine は、アプリケーションのサーブレット クラスを呼び出して、この環境でリクエストの処理とレスポンスの準備を行います。

App Engine プラットフォームには、コードから呼び出せる多数の組み込み API サービスが用意されています。また、アプリケーションでは、指定の間隔で実行されるタスクのスケジュールを設定することもできます。

アプリ用の Java 8 ランタイムの指定

アプリで Java 8 ランタイムを使用するには、以下の行を appengine-web.xml ファイルに追加します。

<runtime>java8</runtime>

このように変更するだけで、現在 Java 7 ランタイムを使用している既存の App Engine アプリケーションは、Java 8 ランタイムで実行されるようになります。

Java 8 ランタイムの拡張機能とアップグレード

OpenJDK 8 に基づく App Engine Java 8 ランタイムは、OpenJDK 7 に基づく現在の Java 7 ランタイムの既存の機能をすべてサポートしますが、以下のアップグレードと拡張が行われています。

  • Java 7 ランタイムのようにセキュリティ マネージャが使用されないため、コードは Java の権限によって制限されません。
  • Java 7 ランタイムで使用できるホワイトリスト登録クラスのサブセットだけでなく、標準のパブリック Java ライブラリをサポートします。
  • Jetty9 を使用します。
  • Java Servlet 3.1 および Java Servlet 2.5 仕様をサポートします。
  • Java 用 Google Cloud クライアント ライブラリからアクセス可能な Google Cloud ベースの API をすべてサポートします。

はじめに

Java ランタイムの選択

App Engine API for Java は、App Engine SDK に付属の appengine-api-*.jar で表されます(* は API と App Engine SDK のバージョンを表します)。アプリケーションで使用する API のバージョンを選択するには、この JAR をアプリケーションの WEB-INF/lib/ ディレクトリに配置するか、Maven を使用して依存関係を処理します。リリースされた新しいバージョンの Java ランタイム環境に、既存のアプリケーションと互換性のない変更が導入された場合、この環境には新しいバージョン番号が付与されます。

Maven を使用して依存関係を処理する

Maven を使用してすべての依存関係を管理できます。たとえば、以下の pom.xml エントリには、最新の App Engine API(Maven Central で入手可能な Rappengine-api-1.0-sdk)が含まれています。

<dependency>
    <groupId>com.google.appengine</groupId>
    <artifactId>appengine-api-1.0-sdk</artifactId>
    <version>1.9.53</version>
</dependency>

サンドボックス

App Engine Java ランタイムは、複数のアプリケーションへのリクエストを複数のウェブサーバーに分散し、アプリケーションが相互に干渉しないようにします。App Engine アプリのレスポンスが遅くならないようにする必要があります。アプリケーションへのウェブ リクエストは、60 秒以内に処理される必要があります(TaskQueue リクエストの場合は 10 分)。このレスポンス時間の制限を超えるプロセスは、ウェブサーバーのオーバーロードを回避するために終了します。

ユーザーがファイルを書き込むことができる場所は /tmp ディレクトリのみです。/tmp 内のファイルは、インスタンスに割り当てられたメモリを消費します。

通常、アプリケーションでリソース ファイルを取得するには、Class.getResource() または ServletContext.getResource() を使用して、依存しているファイル群をアプリケーションの WEB-INF 下にリソースとしてパッケージ化します。デフォルトでは、WAR に含まれるすべてのファイルは「リソース ファイル」です。「リソース ファイル」のグループからファイルを除外するには、appengine-web.xml ファイルを使用します。

クラスローダーでの JAR の順序付け

クラス名の衝突を解決するために、JAR ファイルをスキャンしてクラスを検索する順序を定義し直す必要が生じることがあります。このような場合は、appengine-web.xml ファイルに、<priority-specifier> 要素を含む <class-loader-config> 要素を追加して、特定の JAR ファイルが優先的に読み込まれるようにすることができます。次に例を示します。

<class-loader-config>
	<priority-specifier filename="mailapi.jar"/>
</class-loader-config>

このようにすると、war/WEB-INF/classes/ ディレクトリ内の JAR ファイルではなく「mailapi.jar」が、クラスを検索する最初の JAR ファイルになります。

複数の JAR ファイルが優先されている場合は、元の読み込み順序(互いに対する順序)が使用されます。つまり、<priority-specifier> 要素自体の順序は関係ありません。

スレッド

Java 7 ランタイムでは、App Engine の ThreadManager API でのみスレッドを作成できます。Java 8 ランタイムでもその方法でスレッドを作成できますが、Java の組み込み API(new Thread() など)も使用できます。現在、App Engine API(com.google.appengine.api.*)を呼び出す場合は、リクエスト スレッドまたは ThreadManager API を使用して作成されたスレッドからそれらの API を呼び出す必要があります。

アプリケーションでは次のことが可能です。

アプリケーションは、thread.interrupt() など、現在のスレッドに対するオペレーションを実行できます。

各リクエストは、50 の同時実行 App Engine API リクエスト スレッドに制限されます。

スレッドを使用するときは、ExecutorRunnable などの高水準の同時実行オブジェクトを使用します。これらのオブジェクトは、割り込みスケジュールと記帳のような、細かいことであっても重要な同時実行の詳細の多くを処理します。

App Engine API で作成される同時実行バックグランド スレッドの最大数はインスタンスごとに 10 個です(この制限は App Engine API に関係しない通常の Java スレッドには適用されません)。

ツール

サポートされている IDE

Cloud Tools for Eclipse を導入すると、App Engine プロジェクト用の Eclipse IDE に、新しいプロジェクト ウィザードとデバッグ設定が追加されます。App Engine プロジェクトを Eclipse 内からライブで本番環境にデプロイできます。

Cloud Tools for IntelliJ を使用すると、IntelliJ IDEA 内で App Engine アプリケーションを実行し、デバッグできます。IDE を終了しなくても App Engine プロジェクトをライブで本番環境にデプロイできます。

サポートされているビルドツール

開発プロセスを高速化するには、Apache Maven または Gradle 用の APP Engine プラグインを使用できます。

ローカルの開発用サーバー

開発用サーバーを使用すると、アプリケーションの開発とテストのために、ローカルのパソコン上でアプリケーションを実行できます。開発用サーバーでは、Cloud Datastore サービスがシミュレートされます。また、開発用サーバーでは、テスト中にアプリケーションが実行するクエリに基づいて、Cloud Datastore インデックスの設定を生成することもできます。

AppCfg

AppCfg は App Engine SDK for Java に含まれています。これは App Engine で動作しているアプリケーションに対するすべてのコマンドライン操作を処理する多目的ツールです。AppCfg を使用すると、アプリケーションを App Engine にアップロードすることも、Cloud Datastore インデックス設定のみを更新することもできるため、コードを更新する前に新しいインデックスを作成できます。また、アプリケーションのログデータをダウンロードして、独自のツールでアプリケーションのパフォーマンスを分析することもできます。

同時実行とレイテンシ

トラフィックに対処するために必要なインスタンスの数に特に大きく影響するのはアプリケーションのレイテンシです。リクエストを短時間のうちに処理できるサービスであれば、1 つのインスタンスで多くのリクエストを処理できます。

現在、シングルスレッドのインスタンスでは、1 度に 1 件のリクエストしか処理できません。そのため、レイテンシと、1 つのインスタンスで処理できる 1 秒あたりのリクエスト数の間には直接の相関関係があります。たとえば、10 ミリ秒のレイテンシでは、1 つのインスタンスで 1 秒間に 100 件のリクエストを処理します。

マルチスレッドのインスタンスでは、多数のリクエストの同時処理が可能です。そのため、CPU 使用量と 1 秒あたりのリクエスト処理数の間に直接の相関関係があります。

Java アプリケーションは、同時リクエストをサポートしているため、1 つのインスタンスで他のリクエストが完了するまで待機している間に、新しいリクエストを処理できます。同時実行により、アプリケーションに必要なインスタンスの数は大幅に減りますが、アプリケーションの設計ではマルチスレッド処理に特に配慮する必要があります。

たとえば、B4 インスタンス(約 2.4 GHz)がリクエスト 1 件につき 10 M サイクルを使用する場合、1 つのインスタンスでの 1 秒あたりのリクエスト処理数は 240 件になります。リクエスト 1 件につき 100 M サイクルを使用する場合は、1 つのインスタンスでの 1 秒あたりのリクエスト処理数は 24 件になります。これらの数字は理想的な条件を想定したものですが、インスタンスの処理能力という点ではかなり現実的な数字です。

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

App Engine standard environment for Java