CA Beat エンジニアリーダーのヤマサキです。
デザイナーブログと比べて随分遅れてしまった感のあるエンジニアブログも、
本日ついにスタートすることができました。
これからよろしくお願いします！(｀・ω・´)
最初の記事に何を書くか随分悩んだのですが、
CA Beatのシステムのサーバーサイドをホストする、
Google App Engineの最近の動向について書くことにしました。
App Engineは登場してからもう4年以上経ちます。
登場から今日までの間にApp Engineは進化を続け、
以前はできなかったことも少しずつできるようになってきています。
以前にApp Engineについて調べた方の中には、
今も「○○ができないApp Engine」のイメージのままの方も多いと思いますので、
App Engineの特徴に加えて、最近の状況をまとめてみようと思います。
○近年弊社で提供してきたサービスはApp Engine上で運用しています
・FreeAppNow
・今だけ無料アプリ
・みんなの就活ニュース
・Playなう！
・みんなの無料ゲーム
・他関連システム多数
近年作成したほぼ全てのアプリのサーバーサイドはGoogle App Engineで運用しており、
先日 CA BeatのサイトもApp Engineに移行しました。
○App Engineの特徴
・スケーラビリティの高さ
トラフィック量に応じて自動でスケールアウトします。
アクセスが増えれば自動でWebサーバーのインスタンスが起動しますし、
アプリから意識しない形で分散されているDatastore(App Engineの標準的なデータ保存領域)は
大量のリクエストも捌いてくれます。
App Engine利用前には
Webサーバーを複数用意するのは当然として、
物理的なDBサーバー(定番はMySQL)を複数台用意して、
スキーマを垂直分割・水平分割し、
自前で作ったアプリのシステム基盤で自動的に接続先を切り替える、
等々していましたが、
App EngineのDatastoreはそれを内部的に自動でやってくれるイメージです。
と言えばコンシューマー向けアプリのサーバーサイドを作っている方には伝わりやすいでしょうか。
・一定の利用量まで無料
App Engineは利用に応じて料金を支払う従量制の環境ですが、
一定量の無料枠があるため、それほどアクセス数の多くないサイトは無料で運営できます。
課金の条件がインスタンス数だったり使用帯域だったり、
Datastoreの読み書きだったりと色々あるため、
単純にどのくらいのリクエスト数まで無料とは言えませんが、
弊社コーポレートサイトは絶賛無料運営中です。`,､('∀`) '`,､
・環境構築不要でアプリを載せるだけですぐに動かすことができる
eclipse上でApp Engineのプロジェクトを作成してeclipseプラグインからデプロイすれば、
基本的にサーバー環境の構築や設定なしにWebアプリを動かすことが可能です。
○できるようになった事
・全文検索
登場当初から、「Googleのクラウドなのに何でできないの？」という声をよく目にしました。
多くの方が独自実装を試行錯誤し、色々な方法が紹介されていましたが、
動作するコードが公開されていて実用レベルですぐ導入できる物は無かったように思います。
現在は公式の全文検索機能が提供されていて、形態素解析による全文検索を行う事ができます。
Search (Java) - Google App Engine — Google Developers
弊社では以前から自前でDatastoreに対する全文検索を実装していた名残で
現時点ではまだ利用していませんが、
今後機会があれば利用していこうと思っています。
・独自ドメインでSSLの利用
システムの種類によってはこれが原因で導入を見送ったケースも多々あるのではないでしょうか。
随分最近までできませんでしたが、比較的最近、独自ドメインでもSSLを使えるようになりました。
SSL for a Custom Domain - Google App Engine — Google Developers
・RDB(リレーショナル・データベース)の利用
私がエンジニアの面接をしている時にもよく聞くのですが、
Google App Engineの特徴として一番有名なのはおそらく
「RDBではなく、Datastoreと呼ばれる特殊なデータ保存領域を使っている」
という点でしょう。
多くの方はこれをApp Engineの大きな制限やデメリットとして捉えているように思いますが、
App Engineも現在はRDBを使用することができます。
個人的にはApp EngineのDatastoreを素晴らしい選択肢の一つであると考えていますし、
実際弊社では「スケールさせたい」という前提のもと、Datastoreしか使っていませんが、
システムの性質によってはRDBの方が適しているのも事実でしょう。
Google Cloud SQL — Google Developers
・トランザクション管理の強化
「App EngineのDatasroreはトランザクション管理ができない」と認識している方を見かけますが、
当初から一定の条件下(同一EntityGroup)においてトランザクション管理をすることができます。
その上で現在は
EntityGroupをまたがる「Cross Group Transaction」(通称XGTx)が追加されたことで、
さらにトランザクション管理できる範囲が広がり、設計の幅も広がりました。
App EngineでDatastoreを使う場合は「スケールアウトさせたい」が前提にあると思うので、
XGTxもEntityGroup同様、スケールアウトしづらくならないかを考慮した上で使用する必要があります。
Transactions - Google App Engine — Google Developers
・BigQueryと連携することでDatastoreのデータの集計・解析がしやすくなった
現在もApp EngineのDatastoreに対して直接複雑なクエリの実行をすることはできないのですが、
同じくGoogleのサービスである「BigQuery」と連携することによって
Datastoreからコピーしたデータに対してSQLライクなクエリを実行することが可能になります。
Google BigQuery — Google Developers
BigQueryについては別途ブログに書こうと思っていますが、
BigQueryで実行するクエリはDatastoreのクエリと違い、
「where句・order by句」の指定に関する制限はありませんし、
Joinもgroup byも集計関数も、UNIONだって使えます。
Query Reference - Google BigQuery — Google Developers
以前はApp EngineのDatastoreのデータを集計するために、
単純なクエリの実行だけでは足りず集計するためのプログラムを書いていましたが、
最近弊社ではBigQueryを使っています。
集計のためにプログラムを書く事が減った事も良かったですが、
「集計のためのインデックス」が不要になることはDatastoreの書き込みコスト減にも繋がります。
(しかも多くの場合、予め集計に使いそうな項目に貼っておくのでインデックスが多めになりがちだった)
現時点ではApp EngineからBigQueryにデータをコピーするためには
csvでDatastoreのデータをダンプしてからBigQueryにインポートする必要があり
データのコピーが若干面倒なのですが、
ちょうど今DatastoreのバックアップをBigQueryにコピーする機能の
一般公募のテストが行われています。
Google App Engine Blog: New Google BigQuery Launch includes Datastore Import for Trusted Testers
この機能が正式リリースされたらコピーの手間も軽減します。
・サーバーのインスタンスを起動したままにすることができる
App Engineの特徴として、
「負荷に応じて自動でサーバーが起動・停止する」というものがあります。
自動でスケールアウトする上に必要が無くなれば自動で停止するので
無駄なコストがかからなくて良いのですが、その代償として
「アクセスしたユーザーがちょうど運悪くサーバーの起動するタイミングに当たると、レスポンスを返すまでに時間がかかってしまう」
という現象が起こります。
この起動時の初期化処理のようなものを「スピンアップ」と呼びます。
安いコストと自動スケールと引き換えに発生するデメリットですが、
トラフィックの量が日々変わらないようなシステムにおいては単純にデメリットに映るかもしれません。
現在のApp Engineはサーバーのインスタンス数について、
「最低数と最大数」を設定することができるので、
リクエストを処理するのに十分なサーバーインスタンスを起動したままにしておくこともできます。
(もちろん起動したままにすればその分固定コストがかかることになりますが)
スピンアップに要する時間はアーキテクチャやフレームワークの選定にもよりますが、
普通は数秒以内です。
・データストアのバックアップが簡単・高速に取れるようになった
以前はバックアップと言えばコマンドを実行してローカルにcsvファイルをダンプする機能で
これがまた妙に時間がかかったのですが、
今は管理画面から簡単にGoogle Cloud Storage(AWSのS3同様のファイル置き場)に
独自形式のバックアップをできるようになっています。
速度も遥かに高速になりました。
・長時間のバッチ処理をしやすくなった
以前は長時間のバッチ処理を実装するためにはいくらかの工夫(＆手間)が必要でしたが、
「backends」という長時間実行可能なインスタンスの登場により、
時間のかかるバッチ処理やバックグラウンドの処理を以前より簡単に実装できるようになっています。
Backends Java API Overview - Google App Engine — Google Developers
・スレッドを使用可能になった
条件付きですが、リクエストを受けたスレッドの中で別のスレッドを生成することができます。
例えば同時に2つのクエリを別スレッドで実行し、
両方の結果取得を待ってからマージしてレスポンスを返す、といった事ができます。
ただし生成されたスレッドの生存期間はリクエストが終了するまでなので、
リクエスト内で全てのスレッドの終了を待つ必要があります。
主に高速化のための並列処理に使う機能と言えるでしょう。
リクエストとは別に非同期の処理を実行したい場合は、従来通り「Task Queue」を使います。
・Google Compute Engine(IaaS)が登場予定
こちらは現在公開テスト中のサービスで、AWSで言えばEC2に相当するサービスです。
Overview - Google Compute Engine — Google Developers
アプリを載せるだけで動くApp Engineはクラウドの中では
「PaaS」(Platform as a Service)という位置づけになります。
それに対し、OSレベルで管理する必要のあるEC2やCompute Engineは
「IaaS」(Infrastructure as a Service)という位置づけになります。
App Engineに限らず、「PaaS」はその手軽さの代償として
「○○ができない」という制限を持っているのが通常ですが、
「IaaS」は「PaaS」と比較して運用に手間がかかる分、制限は格段に少なくなります。
そのため、
「App EngineでできないことはCompute Engineを使うことにより補う」
という事ができるようになります。
今後はApp Engineだけで完結せず、
Frontendは自動スケールするApp Engine、
ファイル置き場はCloud Storage、
App Engineでできない処理をしたければCompute Engine、
データの集計はBigQueryで、
と、別のサービスとの連携も踏まえた上でシステム構成を考える事が前提になっていくでしょう。
○今もできない事
・クエリの制限
Datastore Queries - Google App Engine — Google Developers
多くの方にとって一番インパクトが大きいのはやはりこれでしょうか。
今でもDatastoreへのクエリは以前と同様の厳しい制限があります。
が、前述のように集計処理はBigQueryで行う事ができますし、
データ構造の工夫によって回避できるものもあるため、
慣れてくればアプリを作成する際に困ることは少なくなってきます。
・ホスト名無しのドメイン(ネイキッドドメイン)で独自ドメインを使用する
例えば弊社のコーポレートサイトのように「www.cabeat.co.jp」は使えますが、
「cabeat.co.jp」をApp Engineにマッピングすることはできません。
遥か昔はできたという話を聞いたこともありますが、現在はできません。
・外部サーバーとのソケット通信ができない
外部サーバーとの通信はHTTPとHTTPSのみになります。
弊社的にはこれを必要としたことはありませんが、現在も制限があります。
少し前に「外部のサーバーに対してSocket通信する機能」のテスターを募集していたので、
外部方向のSocket接続についてはそのうちできるようになるのかもしれません。
Google App Engine Blog: App Engine 1.7.2 Released
・一部のJava-APIの利用ができない
利用できるJavaの標準APIに制限があります。
JRE クラスのホワイト リスト - Google App Engine — Google Developers
弊社でもこの制限にぶつかった事が一度あります。
iPhoneへのPush通知のためのAppleのサーバーとの通信です。
クライアント証明書を使ったhttps通信なのですが、
このクライアント証明書の指定がAPI的に許可されておらず、できません。
こういう場合には、上述のようにその機能だけ別のサーバーに配置して、
App EngineからAPIを実行してその機能を利用する、という方式にして回避します。
これは上述の「App Engineでできない処理」の一例と言えるでしょう。
(iPhoneへのPush通知の方法についてはそのうち書きます)
できるようになった事、今もできない事、他にもあると思いますが、
スペースの都合もありインパクトの大きいもので印象に残っているものを中心に書いてみました。
他にも「これは書かなきゃダメだろう」的なものがありましたらご指摘いただけたら幸いです。
○でもお高いんでしょう？
たしかに去年にプレビュー版から正式版になって料金は上がりました。。
元があまりに安かったということもあるでしょうが、、えぇまぁ、かなり。。
でも、App Engineに関してはGoogleさんが「広告で稼ぐ」をできないから仕方ないんです、きっと。
それでもデータの更新頻度の少ないアプリなら今でも驚くほど安い値段で運用することができますし、
そうでなくても自前でハードウェア買って環境作って、
インフラ担当のエンジニアを雇って、
負荷が高くなったら夜中もずっと張り付いて監視して
・・・とするよりは安く済むのではないでしょうか。
App Engineで課金額を下げるための取り組みも今後このブログの中で紹介していく予定です。
○まとめ
App Engineでのシステム構築は、それまでの環境とは異なる知識やノウハウを要求されてきました。
また、システムの性質によって明らかに向き・不向きがありました。
今でもまだ特殊なところはありますが、そういった状況は徐々に緩和されてきています。
しかし、それらの改善点も必ずしも広く浸透しているわけではないでしょう。
これらはApp Engineの導入を難しくしている大きな要因になっていると考えます。
今後このブログを通じて導入障壁を少しでも取り除いていく手助けができればと思います。
私はApp Engineの「落ちる気がしない安心感」が何よりも大好きです
・・・と締めくくる形でこの記事を準備していたのですが、
日本時間で10/27夜～10/28未明の4時間ほど、久しぶりの大規模障害が起きてしまいました。(´・ω・｀)
2011年1月に「High Replication Datastore」を開始して以来初めての大きな障害だったそうです。
原因は一部ルーターの過負荷から始まった連鎖的な負荷の増大とのこと。
PublicKey:Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート
それでも「アプリケーション・データは失われていない」とのことで、
この点は本当に良かったと思います。
弊社でも現時点でデータの整合性の問題は発生していません。(少なくとも問題として発覚していません)
一年半以上大規模な障害が起きていなかった中での今回のトラブルは残念ですが、
今後のさらなる安定運用を期待したいところです。
○今後このブログは以下のCA Beat社員エンジニアを中心にお送りします
・オビナタ(Facebook)
App EngineどころかWebアプリもほとんど初めてなAndroidエンジニア。
テーマは「初めてのGoogle App Engine～GAEなんて怖くない～」
みなさんにApp Engine導入に踏み切る勇気を提供します。
気分次第でAndroidの記事も書くかも。
・イノウエ
App Engineで開発できる会社を探して
採用情報ページの彼です。
Google App Engineの機能の紹介と実践等を書く予定。
もしかしたら業務委託で弊社に来てくれているiPhoneエンジニア「Oさん」の飛び入りもあるかも・・・？
○オススメ書籍
このSlim3の本(社内での通称：青本)は
Google App EngineのDatastoreを理解する上で必須と言ってもよい本ではないでしょうか。
弊社では業務委託の方も含めて一人一冊ずつ行き渡るように用意しています。
オープンソース徹底活用 Slim3 on Google App Engine for Java/ひが やすを
￥2,730
Amazon.co.jp
内容についてのご意見・ご指摘等ありましたらご連絡ください。
あ、できれば優しくお願いします。(人ω・｀)
★宣伝★
CA BeatではTwitter、Facebookページの運営も行っております！
ブログの更新情報だけでなく、役立つスマホトピックニュースを
選りすぐって配信中♪
ブログ右サイドバーからぜひフォロー、いいね！してくださいねヽ(´▽`)ﾉ