2019.12.27追記
この記事は4年前に書いたものをメンテしていて、これまでたくさん読まれたようですが、平成時代のものだと思えてきました。最近、アプリのバックエンドに使い始めたFirebaseのほうが今の時代にあったPaaSだと思います。Google App Engineは2nd generationからはIaaSよりになっていると思うので、高速に開発することを求めるPaaSならFirebaseでしょうということで、この記事は飛ばしてFirebaseの紹介記事を適宜探してお読みください。
クラウドブームの初期にはそこそこ存在感のあったGoogle App Engine（GAE）ですが、PaaSの不人気というか、本格的なクラウド時代が到来してAmazon Web Services に代表されるIaaSの前にすっかり影が薄くなっています。
当のGoogle自体も明らかにIaaSサービスのComputeEngine（GCE）に力を入れているようです。日本のGAEユーザーが熱望したアジアデータセンターはGCEにはあっさり来たのに、GAEには来ないままです。ちなみに最近、GAEに新しいデータセンターが追加されたと思ったら、米東南部のサウスカロライナ州でした。
GAE大好き人間としては、改めてGAEの良さを知ってもらい、再びGAE熱を高めていきたい。そしてGAEアジアデータセンター開設の追い風とすべく、GAEの良さを熱く語ってみたい(台湾、東京とアジアのデータセンターは来ました)。ちなみにHerokuとかParseとか、Firebaseとか他のPaaSは使ったことないので、比較はできません。AWSを使っている観点からになります。
ちなみにGAEはStandardとFlexibleの2種類ありますが、ここではもっぱらStandardのことを書いてます。また、Standardにはもともとあった1st generationとgVisorをベースにした2nd generationがあって、ここでは主に1stのほうについて書いています。
PaaSへの流れ再び
IBMさんMicrosoftさんOracleさんが頑張る←ベンダーロックイン AWSががんばって色々なPaaS出す←素敵～！きゃ～！ ﾅﾆｺﾉﾁｶﾞｲ？ #IT業界あるある七不思議
— 秋山 泉 (@iakiyama) 2015, 10月 9
こんなツイートがありましたが、AWSはマネージド・サービス=PaaS的サービスをどんどん投入してきてますね。IaaSは既存システムとの互換性が高いものの、IaaSばかりでシステムを組んでも、クラウドの良さは活かせません。コスト面からも見ても、障害対策等のインフラ運用面から見てもPaaSをうまく活用したほうが、効果的です。
ちなみにロックインの指摘はよくありますが、結局開発体制次第のような気はしますね。内製開発で、内部構造を常に変えていけるような体制なら、心配することはないと思います。外注しているような場合は、そもそもメーカーさん（SIerさん）に頼んだ時点でロックインなので、ロックインを気にしてもしょうがないかと思います。
注意点としては、GAEは1年前の廃止告知（Deprecated）で、機能・サービスの廃止をする可能性があります。ただ実際にはそんなにすぐに廃止するわけではなくて、例えばBlobstoreのFile APIではDeprecatedから廃止まで2年かけています。
GAEの良い所
さて、本題のGAEの良い所を挙げていきます。
瞬間スケールアウト
画像は https://speakerdeck.com/googlecloudjapan/deep-dive-into-google-cloud-technology より引用
仕事では、やむなくAWSを使っているのですが、ここが圧倒的に違いますね。Dockerのコンテナーがだいぶ流行ってきて、仕事でも使い始めましたが、Dockerが出てくる前からコンテナー技術を社内で使いまくってきたと言われているGoogle。GAEのコンテナーは、PythonやGo環境であれば、１秒足らずで増やすことができます。上記リンクの資料では40msecとなっていますね
秒間リクエストがピークとそれ以外で４倍以上差があるサービスの運用に使ったことがありますが、負荷があがってくるとコンテナーがさくさく増えて、負荷が下がるとまた戻ります。オンデマンドで、スケールアウト・スケールインするので、コスト効果はかなり高いです。
AWSもオートスケーリングの設定が可能ですが、仮想マシンを上げるので、１分とかそれぐらいはどうしてもスケールアウトにかかってしまいます。運用してたサービスでもありましたが、Twitterで急にバズってリクエストが突然増えたとしても、インスタンスがちゃんと増えて対応できます。
一般ユーザーからのリクエストを受けるような変動の多い部分で使うと非常に効果的だと思います。
バージョン = 「Blue-Green」デプロイメント
画像は https://speakerdeck.com/naoya/korekarafalseweb-kuraudosisutemu より引用
「Blue-Green」デプロイメントって、かっこいいですよね。新しい環境をデプロイして、問題なければLBとかでごっそり入れ替える。それを特別な設定なしにできるようになっているのがGAEのすごいところです。
GAEの必須の設定ファイルに、versionという項目があって、そこを変更してデプロイすればいいだけです。違うバージョンでデプロイした場合には、すぐにそれが有効になるわけではなく、管理コンソールの画面もしくは、コマンドで切り替えができます。
例えば、下のような app.yaml の場合、デフォルトのアプリは myapp.appspot.com でアクセスできますが、新しいバージョンをつけたものは alpha-001.myapp.appspot.com のようなドメインでアクセスできます。
application: myapp
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true
なので、新しいバージョンを付けてデプロイし、e2eテストとかでその動作を確認。その上でバージョンを切り替えれば、Blue-Greenデプロイメントのできあがりなのです。逆に、ロールバックもバージョンを戻すだけで一瞬でできます。
ちなみに、自分で使ったことがないのでおすすめできるのかわかりませんが、まるっと切り替えるだけじゃなくて、指定の割合でバージョンごとにリクエストをわけてA/Bテストのようなこともできるようです。
権限管理はGoogle アカウントにお任せ
サイトやツールを作るときにログインや管理者機能を付けることがあると思うのですが、それをGAE上のアプリでGoogleアカウントでやる場合は、GAEの設定ファイルに書くだけですみます。
下はGAE/Goの場合の例ですが、この場合 /admin/ 配下のパスにはGCPプロジェクトの管理コンソールで指定した管理者以外の人はアクセスできません。あとはこのパスの配下にREST APIでも生やして、JSのクライアントを書けば簡単にCRUD機能を実装できて、しかも管理者以外は触れないようにできます。
- url: /admin/.*
script: _go_app
login: admin
secure: always
さっくり、ツールを作りたいようなときに便利です。login: required を設定しつつもそれをGSuiteのユーザーに限定することも可能です。
例えば、iOSのAppStoreのレビューをSlackに通知するツールを作る際に、Rest APIを用意して、そこのアクセス制御はGoogleアカウント連携に任せて楽をしてます。
https://github.com/yosukesuzuki/goisky-tools
CDN機能のedge cache
こちらのエントリーに詳しく書いてあるので、割愛しますがCDNが簡単に利用できるってことですね。
http://qiita.com/sinmetal/items/37c105a098174fb6bf77
GAEの問題はレイテンシーなのですが、edge cacheをうまく使えば、レイテンシーの問題を軽減できます。
前に某放送局の方の話を勉強会で聞きましたが、音楽番組のライブと連携するウェブアプリ（アプリ本体のJSやHTMLのほうで、データはGCEから配信だった気がする）の配信を、edge cacheを活用してやったところ、お小遣い程度の超低コストで配信できたと言ってました。
GAEでは1万ファイルまでであれば、静的ファイルをアップロードすることが可能です。例えば以下のリンク先でサンプルを作っていますが、HUGOでファイルを生成してedge cacheを使って高速でスケーラブルで低コストな静的ファイル配信サーバーとして使うということも可能です。AWSのS3の静的ファイルホスティングと同じようなことですね。
https://github.com/yosukesuzuki/hugo-gae
画像配信
GAEのBlobstoreもしくはGoogle Cloud Storageに入れた画像に対して、画像のリサイズや正方形の切り取りが簡単にできてかつGoogleの画像配信CDNから配信されるという機能が用意されています。
画像URLはpythonの場合では
from google.appengine.api.images import get_serving_url
image_url = get_serving_url(obj.blob_key.key()
のようにすると、以下の様なURLを取得できます。
このURLの後ろに、長辺の画像サイズを=s320のようにつけると、リサイズした画像を返してくれます。
=s320-c のように-cをつけると正方形の切り取りが可能です。この辺のパラメータは他にも-pとかがあるようです。
https://lh3.googleusercontent.com/X3c0jAiFsXSWaXNEVXNvrnTfxx0M9Ib1lEA5bqdcLBO1f8PEbpOyCRqDKtxVs5PjcfvFPIsfb8OaulkC4g=s320-c
例えば、スマホのクライアントは画面サイズや解像度がまちまちなので、クライアント側でサイズを決めて、適切なものを呼ぶといった使い方が可能です。
ただし、この機能を使った場合は画像がパブリックになってしまうという点は注意が必要です。
Taskque
AWSのLambdaにPythonが来て、ヤッホーイという感じですが、そもそもそれと同じことはGAEでできてます。
TaskqueはAWSのSQSとLambdaが合体したようなやつで、キューに処理を放り込んでおけば、失敗した時のリトライも含めて勝手にやっておいてくれます。詳しくはないですが、Celeryみたいなやつだと思います。
Datastore
メンテナンスフリーのKVSとしては非常に優秀だと思います。かつクエリーできるKVSみたいな感じでしょうか。クエリーはそこまで早くはないですが、何百万件入っても速度の劣化はありません。
GAEは当初、Datastoreが障害になることが多かったようですが、High-Replicationというタイプが出てからは障害はほとんどありません。クエリーの遅さは、アクセスが多いようなところはMemcacheに予め放り込んでおくような対策もできます。
インフラ担当者がいらない ＝＝ 運用コストがほぼゼロ
何かシステムを作ろうと思った時に、インフラ、サーバーサイド、フロントとエンジニアが複数人必要になるパターンがありますが、GAEを使えばインフラエンジニアはいりません。スタートアップや小さいアプリ、当たるか当たらないかわからないようなサービスの立ち上げ時にはかなりいいと思います。アプリケーション領域に集中できます。
通常のインスタンスをAWSで立てると、たいてい何らかのメンテナンスは必要になってしまいます。例えばインスタンスの再起動が必要になるとか。そこについてPaaSのいいところというか、インフラまわりはまったく何もしなくていいです。ステートレスなアプリケーションしか作れないですし、ステートを持つためのDatastoreも全くメンテナンスがいりません。
残念なところ
レイテンシー
※東京リージョンが使えるようになっていますので、こちらは米国リージョンを使うときの話になります。
GAEにはAppStatというプロファイリング機能が用意されていて、それも素敵なのですが、AppStatで見てサーバー側で20msecぐらいでレスポンス返したとしても、日本からだと行き帰りでどうしても200msecは乗ってしまいます。
例えば、実際のAppStatsの画面で見てみると177msecで返していることになっていますが、このリクエストをChromeのdev toolで見ると497msecかかっていました。+300msecってところですね。
スマホアプリとかでいい感じに、非同期処理できれば軽減されると思うのですが、AWS東京リージョンと比べて圧倒的なデメリットです。これはアプリケーションや設計でどうにもならないのでアジアデータセンターはよ、というわけです。台湾あたりなら、相当レイテンシーは減るのかと思います。
2016.4.3 追記
GCPの東京データセンターの開設が発表されました。AppEngineがいつ来るのかはわかりませんが、期待したいところです。
2016.11.1 追記
GCP東京リージョンが解説され、AppEngineも来ました！！！同時に来るとは思わなかった。
Datastoreの互換性
Datastoreはメンテナンス不要で、特に細かい設定しなくてもモデル定義していけばすぐ使えるので、とても便利です。ただ、どうしても既存のフレームワークがそのまま動きません。PythonのDjangoならDjangaeというAppEngine実装があって、なかなか良さそうですが、そのままとは言えません。
既存のフレームワークをそのまま使えないと、アプリのポータビリティーの面からマイナスです。GAEに乗っかることでアプリケーションに集中できて生産性が高まりますが、一方で世の中にあるアプリケーションやフレームワークの資産がそのまま使えないのは生産性を下げてしまう部分もあります。
その他、雑感
Googleのクラウドは特殊なシステム
Google のクラウドサービスは、BigQueryとRedshiftを使い比べた時にわかりましたが、AWSはあくまで既存システムのインフラの置き換えの延長線にあるのに対して、Googleのクラウドは特殊なシステムということです。Redshiftは大きなPostgreSQLで、普通にDBとしてたたけます。BigQueryはDELETEやUPDATEができないという制約があるけど、処理速度はどんなSQLでもけっこう早いという特徴を持っています。
他のGAEの機能についても特殊性はやはりあります。これらのシステムにどっぷり乗ってしまえば、むしろとても便利なのですが、他ではノウハウが生きにくいのがあまり人気が出ない理由かもしれません。
ManagedVMsに移行するのか（しなそう）
どうも、関係者の話を総合するとAppEngineはやめないまでも、あまり力は入ってない模様。AppEngine的にコンテナーを走らすManagedVMsに移行していきたいようです。でも、そうするとコンテナーの立ち上げ速度は下がってしまいます。それは残念なので、ぜひAppEngineも改善していってもらいたいところです。
※2016.12.18変更
ManagedVMsはFlexible Environmentに名前が変わってます。これを本当に、GAEの主力にしたいのかどうかはイマイチわかりません。ユーザーベースでいうと、これを使うよりもGKEにする人のほうが多いような気がしますね。
2018.7.31追記
ManagedVMsは結局不人気なままで、かわってgVisorという新しいコンテナの仕組みに移行しつつ、新しい言語をサポートをしていく方針のようです。すでにJava8やNodeの環境がgVisorで動いていると言われています。
2018.12.28追記
gVisorベースのApp Engineは2nd generationと呼ばれています。バッテリーインクルードな感じがなくなった代わりに、プラットフォームで動かせるライブラリなどの制約がほとんどなくなりました。まだ、出たばかりなので、こちらについては評価しきれませんがが、Google App Engine自体は2nd generationのほうに移っていく方向と思われます。