読者です 読者をやめる 読者になる 読者になる

プログラミング 美徳の不幸

Ruby, Rails, JavaScriptなどのプログラミングまとめ、解説、備忘録。

Google App Engine + Go の良い点・辛い点

ありがちなタイトルだが少しまとめてみます。 案件でAppEngineを使って3ヶ月程度になりますが、限られた用途においてベストパフォーマンスを発揮することは間違いないと思います。 しかしながらいくらかの不安点があるのも事実です。 自分の思考を整理するためにもまとめてみます。

Google App Engineの利点

1. ログやバッチ処理、ジョブの管理が容易

最大の魅力の一つと思いますが、ロギングやバッチ実行に対する管理コストが圧倒的に低いです。 そのほかメール送信や画像等のアップロードなどの機構を標準で持っています。

2. デプロイが容易

コードを書き始めてデプロイまであっという間です。Goの場合、デプロイは20秒程度で終わります。

3. スケーラブル

全く何も考えずにスケールするとまでは行きませんが、インフラに対して考慮すべき諸々から解放されます。 datastoreもスケーラビリティに優れています。バックエンドでCloud SQLを使用した場合はある程度DBがボトルネックになります。

Goの利点

1. 型安全である

これは説明するまでもないですがスクリプト言語に比べ型がある分、同じ処理をする場合に堅牢でしょう。 またコンパイラが厳密すぎるほど厳密なので、不必要なimportでもエラーを出します。go fmtで標準でコードフォーマットする機能もあります。

2. トレンドである

なんだかんだこれが大きいのですが、Goは体感として2010年以降に流行り始めた言語として最も勢いのある言語の一つだと思います。ほかはSwiftとかですかね。 トレンドであることは情報が多いとか枯れる速度が早いという実利もあるけど、人が集まってるほうが賑やかで楽しいと思います。

3. そのほかもいろいろ

goroutine便利らしいですね。ただ、appengineだとあまり出番ないです。使えないわけではないらしい あとAppEngineに関連してスピンアップが40msと非常に優秀なんですが、これは他も400msとかなのでそこまで優位かと言えば...

docs.google.com

Google App Engineの辛い点

トレンドに対する不安

App Engineは2008年からリリースされ、2012年くらいにはかなり下火になっていた印象です。 ただし近頃は時代が追いついた?のかGo人気と相まってGAE/Goの資料を良く見ます。

とはいえGoogleが本腰を入れているとはあまり思えない部分があります。 GAEで書いたコードはGAEで運用し続けるのが前提となるわけなのでリスクの大きさは否めません。

Datastoreの制約

スケーラビリティと可用性の恩恵を受ける分、RDBMSでは考えられない制約があります。 少し触った程度で次のような問題とぶつかりました。

LIKE検索ができない

search APIを使うしかない?

OR検索ができない

これは非常に辛く、クエリを分けるかOR検索せずに済むよう検索にマッチするためのindexを作っておく必要があります。 例として restaurant.cuisine = japanese or korean という発想ではなく restaurant.cuisine = asian とした上で、 restaurant.cuisine がリストで [asian, japanese] と複数持つ。

Go の辛い点

ジェネリクスがない

ジェネリクスがないため、定義したstructに対して似たようなコードをたくさん書く羽目になります。 reflect を使う手もありますがおそらくGo的なコードではないでしょう。

テンプレートが辛い

テンプレートエンジンとして標準の html/template がありますが、Railsの豊富な機構になれているといろいろな不自由があります。 Railsでいう partial はGoであらかじめ

tmpl, _ := template.New("").Funcs(funcMap).ParseFiles(paths...)

のように使用するpartialを全て ParseFiles の中に入れる必要があります。 そうすると render のネストのようなことをするときに controller のほうがあらかじめネストされたファイルまで関心を持たないといけません。 Railsのviewは非常に多機能なので render "category/#{@category.category_type}" のようなことも当然のようにできます。

同等のことはできるのかもしれませんが、実装のしわ寄せがviewの外側にできます。

このあたりから、結局同等のことをやるために段階を踏んで細かいコードをたくさん書いていく必要が出てくるのに気づきます

比較としてGoのほうがRubyよりバグが出ないかというと、このように最終的なゴールまでの過程が長くなる場合当てはまらないように感じています。 そしてRailsで簡単にできたことは、Goだと簡単にはできません。

総論; 堅牢性・保守性はメリットか?

GAE/Goを評価する論調として「LL言語より開発速度はやや遅くなるものの、それを超える保守性・堅牢性が得られる」と言われますが、私が携わるスタートアップ程度では開発速度は非常に重要なものですし、ユーザ数に上限があるサービスという前提を置くのは悪いことではない とも思います。

開発速度が求められるフロント部分はFlexible EnvironmentでRubyを、データベースにCloud SQLを主に利用した上で一部を GAE/Goで書く、などの利用もありなのではないかと感じ始めています。