ビール、日本酒、お酒は何でも好きなエンジニアの弓山(akiray03)です。

クラウドワークスでは、サービス提供の基盤としてAmazon Web Services (AWS)を利用しています。今回の記事は、会社の業務から離れて、個人的に(趣味で)利用しているGoogle App Engineを紹介したいと思います。

クラウドワークスのエンジニアの中には、趣味でWebサービスを開発している人も多くいるのですが、その基盤としては、AWSやHerokuが好まれる傾向にあるようです（主観的意見）。Google App Engine の思想を通してGoogleの考えるアプリケーションインフラの形を知ることで、日常のアプリケーション開発に新たな気付きが得られれば幸いです。

Google App Engine (GAE) とは

GAEは、Google Cloud Platform (GCP) で提供される、PaaS (Platform as a Service) です。他社のサービスに例えると、Herokuが近いポジションでしょうか。

GAEの魅力を並べてみると...

PaaSなのでインフラのことは気にしなくて良い。Googleさんが自動でスケールしてくれる。
インスタンスの起動めっちゃ早い (特定言語の場合)
デプロイの仕組みとか気にしなくて良い。専用ツールでコードをアップロードしたらOK
遅延処理用のキュー、定期実行、メール送信API、外部URLの取得API、など、一通りの機能がSDKとして提供されている
ローカルの開発環境構築が簡単 (SDKをダウンロードして展開すれば、キュー等の処理もまとめて構築完了)

などが挙げられます。他にもたくさんあるのですが、今回は特に魅力に感じている6個について、ご紹介します。

安く(無料枠あり) パフォーマンスの良い環境が手に入る

GAEでは、Standard EnvironmentとFlexible Environmentの2種類の環境が提供されています。それぞれの環境で実行可能な言語には以下のような違いがあります。*1

	Standard Environment	Flexible Environment
利用可能な言語	Python, Java, PHP, Go	Node.js, Ruby, Custom Runtimes (Docker)
起動時間	ミリ秒	分
最大リクエスト処理時間	60秒	24時間
バックグラウンド・スレッド	制限有りで可	可
バックグラウンド・プロセス	不可	可
SSH接続によるデバッグ	不可	可
スケーリング・ポリシー	Manual, Basic, Automatic	Manual, Automatic
ローカルディスクへの書き込み	不可	可 (VM起動時に初期化される)
サービス提供Stackのカスタマイズ	不可	可 (Dockerfileにより)
サードパーティのバイナリインストール	不可	可
料金	安い(毎日の無料枠あり)	Compute Engine の価格

この違いは、ベースにしているコンテナエンジンに由来するものです。Standard Environmentでは Borg を基盤にしていることから、制限が強いもののパフォーマンスや価格面での優位性があります。対して、Flexible EnvironmentではDockerを基盤にしており、起動時のパフォーマンスなどはやや劣るものの、自由度が高い構成となっています。

個人的には、自由度が低いのを我慢してでもStandard Environment (言語はPython, Java, PHP, Go) を選ぶことをおすすめします。Standard Environmentを選ぶことで、数ミリ秒から遅くとも数秒でインスタンスが起動できるようになり、それに適した自動のオートスケール・アルゴリズムがリクエスト数の増加に対応して適切に制御してくれます。また、インスタンスが不要になった場合にも速やかにシャットダウンされるため、余分なコストがかかりません。

なにより、Standard Environmentの場合には、毎日無料枠が付与されており、趣味プログラミングの環境として最適です（笑） *2

Blue/Greenデプロイがボタン１つで実現できる

GAEでは、1つのアプリケーションに複数の異なるコードをデプロイして動かすことができます。GAEでは「バージョン」と呼ばれています。異なるバージョンにアクセスするには、URLを少し工夫して http://VersionName-dot-YourAppName.appspot.com/ のように、バージョン名とアプリ名を -dot- で繋いだURLにアクセスするだけです。

そして、バージョン名を省略したURLにアクセスする時の接続先を切り替えるのは、以下のような画面でポチッとするだけというお手軽さ。

f:id:akiray03:20160601121541p:plain

さらに、IPアドレスベース、クッキーベースで、一定比率で異なるバージョンにアクセスを振り分けることも可能です。これによってA/Bテストを行ったり、少しずつ新しいロジック・UIを提供していくことが簡単に実現できます。

f:id:akiray03:20160601120224p:plain

このような仕組みが整備されていると、サービス実装に集中することができるので嬉しいですね！

データ量が増えてもパフォーマンス劣化しない Datastore

GoogleのGmailやYouTubeといった多くのサービスを裏で支えているBigTableというKey-Valueデータベースがあります。これをほんの少し使いやすくしたのがGoogle App Engine の Datastore です。

普段のアプリケーション開発で使っているRDBと比べると、以下のような制限があります。

複数テーブルのJOINができない
transactionが無い (実際にはあるのですが、限定的な範囲でしか使えません。RDBのカジュアルにtransactionを使う感じとは違います)
複雑な検索はできない (数値の比較演算は1カラムだけ可能。文字列は前方一致か完全一致だけ。ソート基準のカラムと比較条件のカラムは一致させなければならない...など、強い制約がある)
一度に大量のデータ取得できない (100件くらいまでが現実的なパフォーマンス。1000件以上になると応答時間伸びすぎる)
対象データの件数が多くなると、正確なCOUNTクエリが実行できない

一方で、これらの制限があることによって、高い可用性、大量アクセスに耐えるスケーラビリティ、そして、大量のデータが存在する場合でも一定の応答時間で動作するパフォーマンスが実現できている、、と考えれば、使いたくなってきませんか？

Datastoreのもう一つの魅力は、固定費がかからない、という点ですね。これは、趣味プログラマーにとっては非常に嬉しいポイントです。

簡単に使えるタスクキュー

GAEには非同期処理の仕組みとして「タスクキュー」が提供されています。このキューのワーカーは、専用のものがWebアプリケーションと別に存在しているわけではなく、enqueueされたジョブはWebアプリケーションの特定のURLに対してPOSTリクエストを発行することで、ジョブの実行を行います。

キューは大量のジョブを扱うようになった途端に、パフォーマンス面で問題が発生しやすい手間のかかる機能です。PaaSとして機能が提供され、管理画面から状況確認・操作が可能というのは、それだけでもインフラエンジニア的にはメリットになると思います。

加えて、キュー処理の専用のフレームワークを利用するのではなく、HTTPリクエスト経由でジョブ実行する仕組みなので、通常のHTTPリクエストと同様の処理実装を転用することが可能で、アプリケーションエンジニアにとっても嬉しい機能ではないでしょうか？

開発環境が簡単に構築できる

GAEの公式サイトから開発用SDKをダウンロードして、インストールするだけで開発環境の構築は完了です。GAEで利用可能な、Datastore、Memcache、タスクキュー、メールAPI、といったほぼ全ての機能がローカルで実行可能になります。データベースサーバや、キャッシュサーバを個別にインストール・設定する必要はありません。手軽にローカル開発環境を構築できるのも、GAEの大きな魅力です。

f:id:akiray03:20160601124442p:plain

Googleアカウント連携が簡単

さすがGoogleが提供しているPaaSだけあって、Googleアカウントとの連携はとてもスムーズです。各言語で提供されているSDKのusers APIを利用することで、Googleのアカウント情報を取得することができます。

また、GAEの設定画面から「Google Apps ドメイン」を選択すると、特定ドメインのユーザのみ利用可能なアプリケーションを作成可能です。アプリケーションの設定ファイル app.yaml に、 login: required と記載しておくだけで、アプリケーション本体に手を加えることなく、自社ドメインを保有しているユーザ限定のアプリケーションを簡単に作ることが可能です。

f:id:akiray03:20160601143036p:plain

デメリット(辛いところ)もあります...

ここまで魅力を紹介してきましたが、全てがHappyなわけでもありません。例えば、Datastoreまわりの辛いところを幾つか紹介すると...

更新の頻度に制限がある
- 1秒に1回くらい。それ以上更新するとエラーになりやすい
データの更新も、取得も、RDBに比べて桁違いに時間がかかる
- 対象データが増えても、クエリ時間が劣化しない、というのがDatastoreの魅力です
検索が貧弱
- Googleのサービスなのに！！って思っちゃいますが、そういうものと思いましょう。。
トランザクション無いのは(やっぱり)辛い
- 限定的な状況ではトランザクションを使えますが、トランザクションを活用できるようなデータ構造になるように、予め設計しておく必要があります
内部のデータ構造を理解していないと、最初はちんぷんかんぷん。。
集計できない
- RDBだとCOUNTや集計関数で一発なのに...と思ってしまう

などなど、キャッチアップしたり工夫しなければならない点も多くあります。

個人的には、これらのデメリットを上回るメリット（自分でアプリケーションサーバの維持・運用をしなくてよい）があると思っています。

まとめ

今回の記事ではGoogle App Engineの魅力をお伝えしてきました。魅力あるサービスであるものの日頃開発しているRails + RDBのような環境に比べると制限が厳しく、開発が難しそうな印象を持つ方も多いのではないでしょうか？

そのような制限は、Googleの「スケールしやすさ」を維持するために必要な "制約" ではないかと思っています。その "制約" を守ってアプリケーションを実装することで、将来、サービスが大きく成長したときにも慌てずにスケール可能な状態が維持できます。サービスを継続的に発展させていく上で、 "スケール可能な状態を保つ" ことは非常に重要な観点であり、GAEはその観点を学ぶのに最適なプラットフォームです。毎日の無料枠を活かして、ぜひ、週末プログラミングから始めてみませんか？