The Go gopher was designed by Renee French.

このサイト write.kogu は、Goによる自作のCMSを、Google App Engine（GAE）で運用しています。

AWSのEC2や、同じGCPのGoogle Compute Engine、PaaSとして採用も多いHerokuなど、より情報も事例も豊富なサービスではなく、なぜGoogle App Engineなのか。Google App Engineの歴史と現在をおさらいしつつ、その魅力を解説します。

Google App Engine

Google App Engineは素晴らしいプラットフォームです。Immutableなランタイム、VMより軽量なコンテナベースのインスタンス、柔軟なデプロイ、マイクロサービスのサポート、セキュリティパッチの自動適用などといった先進的な思想や機能は、GAEでは基本設計に組み込まれているほどです。AWSやGCPで新たに採用される機能がGAEでは以前から提供されていた、ということも珍しくありません。なぜこれほど素晴らしい、しかもGoogleが提供するプラットフォームが衰退してしまったのでしょうか。

まずは登場初期から現在まで、ざっとおさらいしましょう。

盛り上がりと衰退

Google App Engineは、Googleが提供するPaaSです。もしPaaSについて詳しくなければ、多少古いですが、以下の解説がわかりやすくまとまっています。

• PaaSの基礎知識とHerokuで開発を始める準備 (¹⁄₃)：CodeZine（コードジン）

Googleのクラウドサービスの中では古く、登場は2008年4月。Amazon EC2が2006年ですから、Googleは先行していたIaaSの事例を充分調査した上で、PaaSを選択したことになります。その選択通り、GAEのコンセプトは魅力的でした。しかし同時に、理想とのギャップ、そして理想のための犠牲を持ち合わせていました。最終的にそういったデメリット受け入れられず、普及のハードルを越えられないまま衰退していきます。

Trendsに見えるように、登場直後は非常に盛り上がりました。Googleが自社の強力なインフラをプラットフォームとして提供し、開発者はアプリケーションの開発に集中。無限並にスケールアウト可能なアーキテクチャ。競合サービスより大きな無料枠。こういったコンセプトは多くの開発者を惹きつけました。しかし今、その頃の存在感はありません。Trendsでは発表直後の急上昇と急下降、そして2010年初頭をピークとして右肩下がりの状況も見えます。

多くのユーザーを惹きつけたはずのGAEは、制約の多さ、データストレージのクセの強さ、そして障害などから、徐々に見放されていきました。色々な試行錯誤があったものの、ユーザーはより制約の少ないAWS EC2などに戻っていきます。残ったのは一部のハマった者達と、無料枠に惹かれた限定的な者だけでした。

決定的だったのは料金体系の見直しです。実質値上げとなるケースが多かったため、多くのユーザーが離れて行きました。また標準のデータストレージであるDatastoreで、ユーザー側の対応を必要とする設計変更も、ユーザー離れを決定的にしました。そしてそのまま現在に至ります。

その間もGAEはそれなりに改良を重ねます。登場初期に問題となった仕様を見直し、SDKと補助ツールは増え、新たな言語での開発も可能になりました。しかし根本的な制約が変わらない以上、広まってしまった残念な印象は払拭しにくいものです。最初期に触れて離れた人、料金改定で離れた人にとっては、未だにGAEの悪印象は強いでしょう。特に日本では利用者が大きく減り、存在すら知らない、あるいはGoogle Appsと混同されるなど散々です。”GAE”を検索してみても、すでに解消された問題に言及した古い記事も多く悲惨な状態です。

GAEの現在

このようにユーザーが離れていったGAEですが、徐々に再評価され始めています。もちろんGAEそのものの改善もありますが、トレンドがGAEのコンセプトに追いついてきた、という面もあります。またGoというGAEに適した言語での開発が正式に可能になったことなどから、Go利用の場として、改めて見直されているという事例も見かけます。

GAEに積み重ねられてきた改善の多くは柔軟性を増やすものです。GAEの基本コンセプトに魅力を感じていても、融通の利かなさから採用を諦めたのだとしたら、今なら見直せるかも知れません。特にFlexible Environment（旧MVMs）は、GAEのガワを被ったGCEであり、自由度は劇的に上がります。

料金設定の見直しも、最初期と比べれば非常に大きなものです。最初の大きな見直しでは値上げとなったユーザーも多くいましたが、その後はずっと値下げ方向であり、過去に比べれば見積もりもしやすくなっています。特にDatastoreの値下げ幅は大きく、公開当初に比べると劇的に安くなっています。

こういった良い変化も、一度離れたユーザーには届きにくいものです。そこで、現在のGAEを見直す上で重要な、大きな変化を幾つか取り上げてみましょう。

GCPの一員へ

Googleは当初、GAEを自社クラウドサービスの柱と考えていたようです。しかし低迷したためか、IaaSであるGoogle Compute Engine（GCE）が登場し、前面でアピールされ始めます。このGCEと、ネットワークやログ、ストレージ、そしてMapやCalendarなどのサービスのAPIも、合わせてGoogle Cloud Platformとしてブランディングされました。そして現在、GAEもこのGCPの一員となっています。

by Google Googleより引用

このように”GCPのGAE”として明確に扱われています。GAE独自だった管理画面もGCPのCloud Consoleにほぼ統合されました。更に従来GAEの一部だったDatastoreは、Google Cloud Datastoreとして、独立したサービスとなるなどの見直しも行われています。独立したことで、GCEからGAEのインスタンスを介さずにDatastoreにアクセスできるなど、全体でよりプラットフォームらしくなっています。

当然GAEからも、GCPの各サービスが利用しやすくなっています。たとえばこのサイトでは、画像などのファイルをGoogle Cloud Storageに置き、GAEから直接利用しています。またログをBigqueryに書き出して分析したり、独自のダッシュボードにAnalyticsのカスタマイズした表示を出したりしています。

GCPで各サービスを利用する場合、プロジェクトという単位で取り扱われ、認証の手間が色々と省けたり、一元管理したりできます。ログやトレースも専用のWebコンソールから閲覧できますし、GCEのインスタンスが必要になれば、いつでも起動してプロジェクトの一部として扱えます。

最初期にはGAEこそがGoogleのクラウドという印象でしたが、すでにGCPという大きなプラットフォームの一部となりました。GAEだけでは不安の多い用途でも、必要に応じて他のサービスと組み合わせることが可能です。むしろ、GAEの「メンテナンスフリーな無数の超軽量インスタンス」という特徴を、GCP採用時の武器のひとつとして考えた方が良いかも知れません。たとえばGCEとCloud SQLベースのプロダクトに、強烈なスパイクが予想される場合だけ、GAEやTaskqueueを活用する、といった風に。

Flexible Environment（旧MVMs）

GAEでは通常、Googleが用意した専用コンテナが起動してインスタンスとなります。負荷と設定に応じた、この柔軟なインスタンスの起動こそが、GAEのスケールアウトの基本です。一方この専用インスタンスは様々な制約の原因でもあり、ローカルのファイルシステムに書き込みできなかったり、対応した言語しか扱えなかったりします。

これら専用インスタンスの問題に対して、任意の環境をインスタンスとして扱える”App Engine Flexible Environment”が登場しました。これはGAEをフロントにしつつ、実際に起動するのはGCPベースのVMという機能であり、以前は”MVMs”と呼ばれていたものです。一方、これまで通りの専用インスタンスは”App Engine Standard Environment”と呼ばれるようになりました。

• The App Engine Environments - App Engine — Google Cloud Platform
• The App Engine Standard Environment
• App Engine Flexible Environment

通常のGAE、つまりStandard Environmentでは、Googleが用意した専用のインスタンスが起動します。このインスタンスにはメリットと制限があり、従来のGAEのイメージ通りのものです。一方Flexible Environmentは、オートスケールやトラフィックの分割などGAEの恩恵を受けつつ、リクエストを受けて起動するのはIaaSであるGCEのインスタンスです。

Flexible Environmentによって、GAEは専用インスタンスの制約から解き放たれます。一方で、Standard Environmentが持つ魅力は損なわれます。とはいえ、重要なのは選択の幅が広がったことであり、GAEの持つ融通の効かなさを、根本的に回避し得る方法が用意された点にあります。

前出の公式ドキュメントThe App Engine Environmentsから、両者を比較した表をざっと訳して掲載します。なお公式ドキュメントはCC BY 3.0でライセンスされています。

機能	Standard environment	Flexible environment
インスタンスの起動時間	ミリ秒単位	分単位
タイムアウトまでの最大時間	60秒	24時間
バックグラウンドのスレッド	◯ (制限あり)	◯
バックグラウンドプロセス	×	◯
SSHでのデバッグ	×	◯
スケーリング	Manual, Basic, Automatic	Manual, Automatic
ローカルディスクへの書き込み	×	◯ ただし一時的(VM起動時に初期化)
サーバースタックのカスタマイズ	×	◯ (Dockerfileによるカスタマイズ)
セキュリティパッチの自動適用	◯	◯
ネットワークアクセス	App Engineのサービス経由のみ (外向きのsokectサービス)	◯
サードパーティのバイナリインストール	×	◯
利用可能な地域	アメリカまたはEU	ベータ期間中はアメリカのみ
価格	利用するインスタンス時間	ベータ期間中はVMで利用するGCEの価格 (将来改定)

この表だけを見れば、Standardは制約が多すぎて、Flexibleが圧倒的に優れているようです。Standardは、タイムアウトまで60秒しか使えず、SSHも使えず、スレッドもプロセスも不自由。ローカルディスクへの書き込みは全くできず、外部へのネットワークアクセスすらサービス経由を強制、好きなバイナリも配置できません。

唯一Standardが圧倒しているのは「インスタンスの起動（スピンアップ）時間」です。誇張でなく、GAEのStandardなインスタンスは数十ミリ秒でスピンアップします。ただしそれは言語としてGoを採用した場合で、最速はGo、PythonとPHPが続き、最遅はJavaと、実行環境のボリュームに比例しています。

Goの場合、アプリケーションは通常、単一の実行可能バイナリファイル（とリソースファイル）となります。そのため複雑なランタイム環境を準備する必要がありません。これによりインスタンスは非常に軽量となり、例えば50ms程度で起動します。これがJavaのように大きな環境の場合、スピンアップに数十秒かかってしまう場合もあります。起動済みのインスタンスが十分にあればリクエストに即応できますが、稼働時間分の費用がかかります。

by kogu CC BY 3.0

この画像は適当にログから抜き出したもので、特に速かったものを選んだわけではありません。スピンアップにかかった時間である”cpu_ms”を見ると、44msとなっています。他に直近のログから確認すると、フロント用のインスタンスの起動は、最遅で90ms、最速では22msでした。このインスタンスの起動の速さが、必要な時に必要なだけインスタンスを起動する、GAEのオートスケールを実現します。

PythonやPHPでも、Goよりは遅いですが、Javaよりは素早く起動します。そのJavaですら、Flexibleと比べればまだ速く起動します。この迅速な起動は、Standard environmentが全ユーザーに共通の構成で、しかも絞られた環境だからだと考えられます。Flexibleのように自由な構成では、どうしても分単位の起動時間がかかってしまいますが、Standardならスピンアップに不要な処理を極限まで削ぎ落とせます。更にランタイム環境がほとんど不要なGoであれば、数十msという馬鹿げた速度で起動してくれます。

Standardの利点ばかり挙げましたが、FlexibleもGAEの可能性を広げてくれる素晴らしい機能です。両者を組み合わせれば、膨大なリクエストを軽量なStandardインスタンスで捌きつつ、重たいジョブはFexibleでじっくり扱うといった構成が、GAEのみで可能になります。GAEだからと初めから諦めるしかなかった部分は、確実に減っています。

なお、初期から今までGAEを使い続けているユーザーほど、FlexibleをGAEだと言われると、もやもやするのではないでしょうか。Flexibleはたしかにフレキシブルです。しかしわざわざGAEを採用するのであれば、まずはStandardを活かすべきです。Standardが提供してくれるシンプルさとスケールアウトを前提としつつ、その不足をFlexibleで補えることこそが、Flexible登場の価値ではないでしょうか。

対応言語の追加

by Google CC BY 3.0

GAEでは使用できるプログラミング言語が限られています。初期はJavaとPythonでしたが、そこにGoとPHPが追加されました。

Goはインスタンスの起動の速さなどから、GAEのコンセプトに合った言語です。このサイトも自作のブログ風CMSをGoで作っていますし、元々Pythonで書いていた私的なプロジェクトは、ほとんどGoに移行しました。国内でも実戦投入もされており、たとえば最近公開された国内の事例としては、フリマアプリで有名なmercariの子会社、株式会社ソウゾウによるメルカリ アッテ | Mercari Atteのサーバーサイドに、GAE/Goが全面的に採用されています。

PHPは裾野の広さと、既存のプロダクトの豊富さが強力です。GAEの制限への対応が必要ですが、著名なプロダクトでは多少用意されています。たとえばWordpressは、Cloud Datastoreを設定し、GAE用のプラグインを有効にして、ローカルのストレージ代わりにCloud Storageを割り当て、といった手順で動かせます。

• WordPressをGAEで簡単に使う10のステップ - apps-gcp

最近では、Node.jsやRubyが使えるというニュースも流れました。ただしこれはJava・Python・Go・PHPとサポートの実装が異なります。Node.js、Ruby、Java8、Python3.xのサポートは、前述の”Flexible environment”で行われます。”Standard environment”でネイティブにサポートする言語は、Java(7)・Python(2.7)・Go・PHPです。Node.jsやRuby、そしてJava8やPython3などの追加サポートはFlexibleで行われるため、前述の表にある仕様となります。つまり本来のGAEであるStandardでは、変わらずJava・Python・Go・PHPしか使えません。

料金体系

最初の大きな料金体系見直しは批判を受けました。登場時、コンピューティングそのものの料金は「CPUの使用時間」を基準としていたので、効率の良い処理を行えばそれだけコストを抑えられたのです。しかし見直しによって、インスタンスの稼働時間で請求されるようになりました。インスタンスは一度起動すれば、その後何も処理をしていなくとも、最短でも15分は稼働時間としてカウントされます。これは多くのユーザーにとっては値上げとなり、低迷の決定打となります。

しかし批判されたこの改定以降、行われた見直しは全て値下げとなるものです。また複雑で直感的でない体系は徐々にシンプルになり、設計によるコスト削減の余地も増えています（だたし”クラウドのコストもムーアの法則のように下がっていくべき”とGoogleが言うほどには、GAEの値下げは頻繁でもありません）。

標準のKVSであるDatastoreの料金は、最近大幅な見直しが行われました。Datastoreは元々GAEの一部としてリリースされましたが、今ではGCPのひとつとして独立し、Google Cloud Datastoreとなっています。独立はしましたが、相変わらずGAEにとっては標準のデータストレージであり、大きめの無料枠もそのままです。このDatastoreの料金が大きく見直され、費用の計算が良い意味で大雑把になりました。これにより料金節約のための設計上の悩ましい工夫が、かなり減らせるようになっています。

従来Datastoreの費用は、Datastore内部でのオペレーション数に基いて算出されていました。例えば書き込みの場合、データそのものの書き込み以外に、Indexの書き込み回数という内部のオペレーションが大きく影響していました。DatastoreはBigtableベースのKVSであり、Vに当たるEntityへのクエリは、Indexに対するスキャンで実現しています。そのため書き込み時には、Entityそのものの書き込みと同時に、Indexへの書き込みも必要です。このIndexの書き込みも内部オペレーションでカウントされ、それに基づく費用が発生していました。

この改定により、内部のオペレーション数によらず、操作するEntityの単位で費用が発生することになりました。また削除もEntity数でシンプルに計算できるようになります。これまでIndexを大量に持たせた複雑なEntityを頻繁に読み書きするとコストが気になりましたが、これからはEntityの件数で素直に見積もれます。インデックス爆発の問題は残りますから、インデックス数を無視できるようになった訳ではありませんが、少なくともコストに直結はしなくなりました。これはほとんどのDatastore利用者にとって値下げとなります。

リージョンとレイテンシ

GAEには東京はおろか、アジアのリージョンすらありません。他のGCP各サービスがアジアもサポートする中、GAEにはUSAとEUしかなく、レイテンシが問題になる用途では採用しにくい状況です。Google App Engineのリージョン別レイテンシ - Qiitaによると、最低のus-centralでも平均150ms程度のレイテンシ。このサイトのような用途であれば、GCPのエッジキャッシュを使ったり、外部のCDNで問題なくカバーできますが、リアルタイムなゲームなどでは許容できないでしょう。

しかし先日、ついに東京リージョン登場の可能性が出てきました。

Google Cloud Platform Japan 公式ブログ: Google Cloud Platform に 2 つの新リージョンが追加、今後 10 リージョンがさらに追加予定

ただしまだ、GCP全体で東京リージョンが出来るという話であって、そこにGAEが含まれるかは明らかにされていません。時期も「2017年にかけて行う増強の、最初の2箇所に含まれる」という曖昧なものです。しかしもし東京で稼働できれば、国内での用途は間違いなく広がります。これまでを考えると、既存のアプリケーションをそのまま移行できる可能性は低く、新規のプロジェクトでないと恩恵は受けにくくなりそうです。

GAEの魅力

GAEの衰退と現在までの大きな変化を振り返ったところで、改めてその魅力を挙げていきます。

PaaSであること

GAEの最大の魅力は、完成度の高いPaaSであることです。採用事例の多くで言われるように、ここまでインフラを意識せずに済むプラットフォームは他にありません。しかも同時に、強力なオートスケールとKVS、タスクのキューイングやmemcache、エッジキャッシュなども手に入ります。たとえば私たちはある程度プログラミングや運用が出来ますが、優れたプログラマでもサーバー管理者でもありません。IaaSやコンテナの利用ですら、特にセキュリティを考えると負担です。そんな私たちが、インフラの構築・運用・更新という層のほとんどを担わずに、これだけの機能を手に入れられるのは代えがたい魅力です。

GCPとして統一されたインターフェースのWebコンソールが手に入るのもありがたいです。ログやトレース、リソースの利用や負荷の状況、請求、リクエストのサマリーなどが一元管理でき、DatastoreのCRUDやCloud Storageのファイル管理も可能です。自前の管理画面はアプリケーションとして必要な姿に集中でき、非プログラマの利用者を惑わさずに済みます。

もしもGAEと同等のインフラを提供できるエンジニアを使えば、到底ペイできないコストが生じます。そんなインフラが安価に使えるというのは、Googleの優秀なエンジニアが自分たちのために、プラットフォームを用意し、運用し、維持してくれるのと同等です。しかも格安で。

PaaSであるがゆえの制限は、そのプラットフォームで可能な方法での実現に割り切ってしまえばシンプルですし、いざという時には、FlexibleやGCPという逃げもあります。ロックインの不安はありますが、DatastoreやTaskqueueなどのサービスに依存する箇所以外は、それほど酷くなりません。採用するライブラリでかなり切り分けることが可能です。

スケールアウト

スケールアウトはGAEの基本思想です。今でもStandard environmentでは変わらないでしょうし、GAEを使う大きなメリットのひとつです。

GAEのスケールアウトは、リクエスト量に応じて軽量なコンテナのインスタンスを必要量起動することで実現します。スケールアップでは、凄まじく落差のあるスパイクに対応し切れず、拡大にも限界があります。非常に小さなインスタンスを、リクエスト量に応じて無数に起動し、リクエストが減ればインスタンスも減らす。GAEはこういった方法でスケールアウトを実現します。

環境としてStandard、言語としてGoを選んだ場合、インスタンスのスピンアップ速度は最短で数十msという速さになります。GAEでGoを使う理由のひとつはこのスピンアップ速度で、GAEはとにかくリクエストを捌き、実処理の多くはGCEで行う、といった構成の場合でも有効です。このようなスケールアウトはGAEの基本であり、標準で有効且つほぼ全自動で行われます。ユーザーが指定するのは、同時起動するインスタンスの最大数と、インスタンスの待機時間程度です。

インスタンスだけでなく、標準のデータストレージであるDatastoreも、スケールアウトを前提としています。BigtableベースのこのKVSは、そもそもGoogleのインフラ上に分散しています。RDBMSでいうレコードに相当する（実態はかなり異なる）Entityは、テーブルに相当する（同上）Kindが同じでも、分散して保管されます。そもそもが分散しているため、Googleの巨大なインフラが受け入れられる限り、異なるEntityへの読み書きはスケールアウトします。もちろんその代償として、同一のEntityやEntity Groupというケースではスケールアウトしなかったり、クエリを実現するIndexがもたらすタイムラグなど、デメリットと必要な対処も存在します。

memcacheが手軽なのも魅力的です。これは、いわゆるmemcachedのような揮発性のキャッシュを標準で提供するサービスです。memcacheを噛ませてDatastoreを読み書きすれば、比較的高いDatastoreのOpsを節約できますし、応答速度も向上します。クエリ結果でもレンダリング結果でも、とにかく放り込んでおけるキャッシュが、何の構築も無しで使えるのはとてもありがたいです。ただしひとつの値が1MBまでのため、扱う内容によっては分割や圧縮など工夫が必要です。

Taskqueueはタスクのキューイングを実現するサービスです。これも非常に強力で、大量のタスクを放り込み、任意の間隔で実行したり、エラー時には間隔を広げながらリトライさせたりといったことが可能です。そもそもGAEにはタイムアウトまで最大60秒（当初は30秒）という制限時間があります。そこで、時間のかかりそうな処理は小分けにしてTaskqueueに投げるといった設計はしばしば必要です。しかしそういった逃げの用途ではなく、プラットフォームが標準で強力なタスクのキューイングを備えているというのは、様々な状況でありがたいものです。このTaskqueueも、当然スケールアウトします。

費用

請求の対象は、インスタンスの稼働時間とネットワーク、そしてDatastoreなどのサービスの利用量です。全て従量制で、基本料金はありません。むしろそれぞれに大きめの無料枠があるため、用途次第ではそれなりの規模まで無料で使えてしまいます。有料分の料金設定は格安とは言えませんが、見直しによってそれぞれが順次値下げされています。なお、無制限のリソースに対する従量制なので、無制限の請求の危険も持ち合わせていますが、これは予算の上限を設定して回避できます。

システムの設計次第でコストを大きく減らし得るのも従量制の魅力です。たとえばmemcacheの活用と、それを自動化してくれるライブラリ。もうひとつの大きなコスト発生元であるDatastoreの場合、Pythonならndb、Goならgoonなど、memcacheにEntityのキャッシュを取りつつ、読み書き時に適切に更新までしてくれるライブラリのおかげで、意識せずに不要なEntityのReadを抑えてくれます。

そもそも無限のスケールアウトに適したPaaSの用途から外れていますが、ブログやCMSなど、読み込みが圧倒的に多い用途では、CDNで更に劇的にコストを抑えられます。私たちはCloudFlareを利用していますが、GCP標準のエッジキャッシュもあり、これは今後Google Cloud CDNとして大幅な強化が予定されています。それでもCloudFlareを使うのは、ロックインからの逃げと、DoSやDDoSなど従量制に致命的な攻撃をある程度防いでくれる点からです。GAEにもプロテクション機能や救済措置もありますが、やはり面倒です。ただしこういった外部CDNの利用は、Cloud CDNの発展とともに不要になるかも知れません。

また大きな無料枠は当然魅力です。ただしこれは無料で使おうとするのではなく、システムが本当に稼働した時だけ、プラットフォームの使用料が発生する。それまでは放置しておいてもコストはかからない、という健全な運用のための緩衝だと考えるべきです。

柔軟な構成とデプロイ

GAEのアプリケーションには、Versionsと、Services(旧Modules)という、構成やデプロイをコントロールする機能が用意されています。

Services(旧Modules)は、ひとつのアプリケーションの中で独立したモジュールを提供します。各モジュールは独立したデプロイ対象となり、別個のランタイムを指定できます。そのため、フロントでリクエストを捌くのはStandardのGo、管理者向けにはStandardのPythonでDjango、画像処理はFlexibleのJava8、といった構成も採れます。もちろんランタイムを揃えてマイクロサービス志向で分割も出来ますし、dispatch設定で割り振りの一元的な指定も可能です。

Versionsは、モジュール内で復数のバージョンを保持できる機能で、デプロイ時にターゲットのバージョンを指定するだけで利用できます。デプロイしたバージョンは、どれにリクエストをどの程度振り分けるのか指定が可能です。最も基本的な用途はリリースのコントロールで、次のバージョンをデプロイし十分な確認の上で切り替える、いわゆるグリーン・ブルーデプロイが標準で可能です。また割合を指定してトラフィックを分割することも可能なため、ABテストなどにも利用できます。

GAEの登場初期からVersionは使えましたが、Services(旧Modules)の層が追加されたことで、より細かく、アプリケーション全体の構成をコントロールできるようになっています。

開発環境

GAEのSDKには、開発用のサーバーが付属しています。またGoの場合、goappというGoの環境一式をGAEように拡張したツールも付属します。開発ツールの補助としてPythonは必要ですが、それさえあればSDKを展開するだけでほぼ開発環境の準備が終わります。SDKには各サービスのエミュレーションもあり、開発用の管理画面も付属します。

開発用サーバーやデプロイツールにはGUIも付属しますが、開発用サーバーをモジュール指定して起動したり、デプロイツールでIndexやQueueの更新をするなど、CUIでしか出来ない操作もあります。バッチスクリプトを一度用意してしまえば、プロジェクトに応じた細かなデプロイも自動化できるため、CUIを前提としておいた方が使いやすいです。

開発環境としては、Mac、Windows、Linuxに対応しています。私たちはMacとWindowsの両方で作業することが多いですが、デプロイやメンテナンス用のスクリプトさえそれぞれのシェル用に用意すれば、どちらのOSでもスムーズに作業できます。

SDKの展開で大半の準備が済み、ローカルでフルセットのコピーが簡単に動かせる。こういった開発の手軽さもGAEの魅力です。

まとめ

今まで続くGoogle App Engineというプラットフォームの不人気は、振り返れば仕方のないことだったのだと思います。Google自身ですら、その先進的なコンセプトを表現しきれず、多くの混乱がありました。

しかしこのプラットフォームは確実に洗練されてきました。またそのコンセプトに合致する、市場の要求と開発のトレンドも膨らんできています。

もしもあなたがまだGAEに触れていなかったり、登場初期にがっかりしたままだったなら、今こそ2016年半ば現在のGAEを試してみてはいかがでしょうか。