これを読めば Google App Engine（GAE）FE の魅力がわかる

　GCP の PaaS である GAE を使っていますか？GCP のサービスの中でも歴史あるサービスが GAE で、高いスケーラビリティと高いアベイラビリティを持ち、Google の多くのサービスは GAE 上で構築されていると言われています。GAE には大きく2種類の実行環境があります。

1. Standard Environment (GAE SE)
2. Flexible Environment (GAE FE)

　GAE SE はノンメンテナンス運用に向いたサービスであり、GAE FE は柔軟性を保持したままメンテナンスを減らして運用する事に向いています。
　今回は GAE FE にフォーカスし、開発環境、デプロイ方法、利用シーンまで GAE FE の魅力にせまってみます。

1. Google App Engine Flexible Environment （GAE FE）とは

　GAE FE は GCE の VM インスタンス上の Docker コンテナで実行するサービスです。GAE FE は、元々は2014年に登場した「Managed VMs」と呼ばれていたサービスです。2016年に名称が「Google App Engine Flexible Environment」に変更され、2017年に正式リリースとなりました。
　GAE FE は GAE SE のように Google が管理する専用インスタンスは利用せずに、GCE の VM インスタンス上の Docker コンテナで動作します。
　GAE SE では開発者がインフラレイヤーの管理から開放された代わりに、開発者には GAE SE 特有の制限が設けられていましたが、多くのフィードバックを受けて進化し続けています。
　一方、GAE FE ではそういった制限の一部が GAE SE と比較して柔軟になってます。例えば、柔軟になっている制限には下記のようなものがあります。

• 利用できる言語・ランタイムが多い。
  　→　Python、Java、PHP、Go 以外の開発者も利用できる。
• サードパーティのソフトウェアがインストールできる。
  　→　ImageMagick といったようなソフトウェアスイートなパッケージが利用できる。
• リクエストのタイムアウト制限が60分。
  　→　オンライン処理で長時間の処理が可能。

　GAE FE も GAE SE と同じく進化し続けていくと考えられますので、開発者は両方のサービスの特徴を理解することはとても良いアプローチです。

2. 利用できる言語・ランタイム

　GAE SE より GAE FE の方が利用できる言語/ランタイムが多いです。下表は GAE SE と GAE FE でそれぞれ利用できる言語・ランタイムの比較表になります。

　Go、PHP、Java、Python、Node.js、.NET、Ruby のランタイムを利用する場合は SDK でデフォルトの Docker ファイルが用意されています。
　それ以外の言語やランタイムで GAE FE を動かす場合はカスタムランタイムと呼ばれ、開発者自身が作成した Dockerfile を使用することができます。
　カスタムランタイムを使用することで、GAE FE では事実上 HTTP リクエストを扱える全ての言語、ランタイムが使用できるようになると言えます。

3. 料金体系

　GAE FE のインスタンスの料金は、デプロイ時に指定した vCPU のコア数とメモリ、永続ディスクのサイズ、GAE のリージョンによって変わります。例えば、東京リージョンを使用する場合は下表のような料金になります。

　上表以外のリソースや API の利用にかかる料金は GAE SE と変わりません。1か月あたりの課金額がいくらぐらいになるか調べたい場合は、Google が公式で料金計算ツールを公開していますので、下記の URL のページを参考にして下さい。
https://cloud.google.com/products/calculator/?hl=ja#tab=app-engine

4. スケーリング

　GAE FE で使用できるスケーリングは「Manual scaling」と「Automatic scaling」の二種類です。GAE FE のスケーリングで注意しなければいけないのはインスタンスの起動時間です。
　GAE SE では、言語やランタイムによって違いはありますが、Google が管理する専用インスタンスの起動とコンテナの起動のみのためミリ秒単位で完了します。しかし、GAE FE ではインスタンスとして GCE の VM が起動するため、GAE FE と比較して時間（それでも分単位レベル）を要する場合があります。そのため、リクエストが非常に多いサービスなどで GAE FE を使う場合は余裕を持ってインスタンスを配置しておくのが良いです。

5. セキュリティ

　GAE SE と同様に GAE FE のインスタンスは Google が管理しています。そのため Firewall、Custom Domain、SSL(TLS)、Security Scan などの設定も GAE FE で可能です。
　セキュリティパッチの適用は Google が定期的に行われます。セキュリティの定期的な更新は週に1回、インスタンスの再起動と共に行われます。

6. サービス、バージョン、インスタンス

　GAE SE のサービス、バージョン、インスタンスの概念や構成は GAE FE でも適用されます。そのため、作成したアプリケーションは「マイクロサービス」として作成することができます。

7. ベンダーロックイン

　GAE SE が Google の優れた PaaS サービスであることは言うまでもありません。ですがその反面、GAE SE の環境以外では実行できないアプリケーションになりやすいという「ベンダーロックイン」のリスクがあります。
　例えば、GAE SE から Datastore へアクセスする場合、App Engine SDK を使用します。そのため App Engine SDK を使用しない GCE や GKE へ移行する場合はコード修正が多く発生してしまいます。
　しかし、GAE FE の場合はそうではありません。GAE FE から Datastore へのアクセスは GCE や GKE でも利用できる Google Cloud クライアント ライブラリを使用するため、GCE や GKE への移行は軽微で済みます。ベンダーロックインをできるだけ避けたい場合は、GAE FE でアプリケーションを構築するのが良いと言えます。

8. リクエストとレスポンス

　GAE FE にはリクエストとレスポンスについての以下の制限があります。

・リクエストの処理の制限事項

• リクエストヘッダー内のサイズは最大 15KB まで
• リクエストの合計サイズは 32MB まで
• すべての HTTP/2 リクエストは、アプリケーションサーバーに転送される際に HTTP/1.1 リクエストに変換される
• SSL 接続はロードバランサで終了される

・レスポンスの処理の制限事項

• レスポンスは 64K ブロック単位でバッファリングされる
• レスポンスのサイズに制限ない
• レスポンス時間の 最大 1 時間

・その他の機能制限

• バックエンドサービスへの HTTP/2 トラフィック
• WebSocket
• インスタンスに直接アクセスする HTTP リクエスト

9. GAE FE をデプロイしてみる

　各言語/ランタイムごとにクイックスタートが用意されています。本記事では「Java の GAE FE」を採用してみます。他の言語のクイックスタートをやりたい場合は下記のURLから言語を選択し、Google のチュートリアルに沿って実施して下さい。
　https://cloud.google.com/appengine/docs/flexible/?hl=ja

・開発環境
　今回使用する開発環境は下記のとおりです。

・リポジトリからクイックスタートプロジェクトをクローン
　リポジトリの URL を指定して、git の clone コマンドを実行します。

$ git clone https://github.com/GoogleCloudPlatform/getting-started-java
Cloning into 'getting-started-java'...
remote: Counting objects: 6222, done.
remote: Compressing objects: 100% (38/38), done.
remote: Total 6222 (delta 33), reused 30 (delta 22), pack-reused 6162
Receiving objects: 100% (6222/6222), 50.62 MiB | 7.12 MiB/s, done.
Resolving deltas: 100% (3449/3449), done.
$

・サンプルコードのあるプロジェクトに移動

$ cd getting-started-java/helloworld-servlet
$

・ローカル PC 上で GAE FE のアプリケーションを実行
　ローカル PC で実行する場合は、mvn コマンドを使用して Jetty ウェブサーバーを起動します。

$ mvn jetty:run-exploded
[INFO] Scanning for projects...
・
・
・
------- 中略 -------
・
・
・
[INFO] Started ServerConnector@7a04f730{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
[INFO] Started @5685ms
[INFO] Started Jetty Server

　エラーなく「Started Jetty Server」と表示されれば起動成功です。

・ローカル PC 上に起動したアプリケーションにブラウザからアクセス
　ブラウザの URL 入力バーに「localhost:8080」と入力し、エンターキーを押します。ブラウザに下記の画面が表示されればローカル PC での起動確認ができたことになります。

　※ アプリケーションの停止はターミナルで「control + c」のコマンドで実行します。

・GCP 環境にデプロイする
　ローカル PC 上でアプリケーションが動作することが確認できましたので、次は実際に GCP 環境へデプロイを実施します。まずはデプロイ先の GCP プロジェクトを設定します。

$ gcloud config set project apps-project

$ mvn appengine:deploy
[INFO] Scanning for projects...
・
・
・
------- 中略 -------
・
・
・
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 06:55 min
[INFO] Finished at: 2018-03-19T18:02:58+09:00
[INFO] Final Memory: 25M/211M
[INFO] ------------------------------------------------------------------------
$

　上記のように「BUILD SUCCESS」と表示されたらデプロイ完了です。

・GCP 環境にデプロイしたアプリケーションにブラウザからアクセス
　デプロイが完了したのでブラウザからアプリケーションにアクセスし、最終確認します。デプロイしたアプリケーションの URL は下記の形式になります。
　
　URL: http://＜GCPプロジェクトID＞.appspot.com/

　「＜GCPプロジェクトID＞」はご自身のGCPプロジェクトの ID を入力して下さい。ローカル PC で実行したときと同様に下記の画面が表示できればデプロイは成功です。

10. GAE FE の利用シーン

　これから皆さんが作るサービスやシステムに GAE SE と GAE FE のどちらが適しているのか悩むかと思います。現状では、基本的には無料枠や優れたスケーラビリティを持つ GAE SE を選択すれば良いと思います。もし、GAE FE を選択しなければならないとしたら下記のような要件や条件がある場合です。

• Java、Python、PHP、Go 以外で作る
• サードパーティ製のツールでの処理が必要
• ローカルディスクにファイルを作らないといけない
• GAE SE のホワイトリストにないライブラリを使う
• CPU やメモリを大量に使う必要がある
• できるだけベンダーロックインしたものは作りたくない

　GAE でアプリケーション開発を行う上で忘れてはいけないことの 1 つとして、GAE は「マイクロサービス」を作るのに適しているということが挙げられます。上記の要件や条件に合致して GAE FE を使用しなければならない場合でも、その処理の部分だけをマイクロサービス化して、他の機能は GAE SE として実装するということも可能です。アプリケーションの設計は非常に重要ですね。

　GCP 全般について、クラウドエースでは豊富な技術者によるサポートで快適な GCP 生活のお手伝いをしておりますので、是非ご相談ください。