Day 21 GoとAWSと私 - HDE Advent Calendar 2014

クラウドプロダクト開発部のたなべです。同僚にタイル型ウィンドウマネージャを布教したのが私です。

私はMacBookを購入してはMac OS Xを隅に追い出し、Gentoo Linuxを入れるほどの熱心なLinuxデスクトップユーザーでしたが、社会人になってMacBookPro Retinaを購入して以降はLinuxのデスクトップ環境は使っていません (当時はデュアルGPUや解像度の問題があり、社会人になった身には辛かった)。

最初にGoと私(とHDE)について話します。最後にGoとAWSの最近の情勢などを記していきます。

Goと私

最近、私が社内布教に力を入れているのがGo言語です。先日開催されたGo Conference 2014 Autumにも参加してきました。懇親会でGoの父であるRob Pike氏と英語で会話できたのが思い出です。英語でなんとか会話が成立するようになったのも日頃の成果(海外からのインターンシップ生とのやりとりなど)だと感じています。

昨年の10月にとあるプロダクトをよりクラウドに適したアーキテクチャに再設計するミッションをひとり寂しく開始しました。もともと、このプロダクトではパフォーマンスが必要な部分(ネットワークサーバ)にC++が使われていました。 C++が必要な理由は明確ですが、私自身はC++がわかりません。保守するために書かざるを得ない場面がありましたが、あまりに複雑で自分には向いていないと感じていました。

C++がわかる人がプロジェクト内で同僚1人だけな状況で、かつ、C++が必要なのはネットワークサーバ部分だけだとプロジェクト内での知識およびコードの再利用性が低いため、このままC++を続けるべきだろうかと悩んでいました。

そんなとき、私はGoに出会いました。チュートリアルをすべて終え、海外のプロダクション採用例を読み、私はGoを採用することを決めました。すごくよいタイミングだったと思います。たぶん、Goに出会っていなければPythonで頑張っていたかもしれません。

私が「Goいいよ」「Goいいよ」「Goいいよ」とCTOをそそのかしていたら、その後、別サービスでもプロダクションの一部をPythonからGoで書き直すプロジェクトが始まりました。

なぜGoを採用したのか？それは先日のGoConでのRob Pike先生のキーノートですべて語られていました。まだスライドがアップされていないようですが、以下のレポートはとても参考になると思います。

私が気にいっているのは『正しい言語機能とは「機能のための機能」ではなく，「隙間を埋める機能」』という部分です。どのプログラミング言語にもそれぞれよいところと悪いところがあります。 Goは『予想したとおりに作用する直交する機能で，単純に動作する単純な機能』を組み合わせているため、複雑性に溺れることはありません(これはランタイムがこの手の複雑性を引き受けているからでもあります)。

現在、我々のチームではGoを

受信に特化したSMTPサーバ
REST APIサーバ
SQS worker

などで利用しています。プロダクション投入に向って開発中です。 Goやりたい人はいいタイミングだと思いますよ！

AWSとGo

弊社ではほぼAWS上でサービスを提供しています。GoでAWSサービスを使いたいすべてのGopherの頭痛の種が「goamzフォークありすぎだし、それぞれにAPIが微妙に違うし、品質もあまりよくなくて困ってる」問題です(勝手に命名)。

Googleでgoamzを検索すると…

google-goamz

ちなみに、本家はCanonicalです。かろうじて4番目ですね…。フォークがたくさん発生しているため、golang-nutsでもたまに話題になります。

私はlaunchpadのためだけにbzr大変だし、launchpadも使ったことがないのでcontributeの障壁は高いと感じています。 Canonicalの人達はGithubへ移したり、拡張性を高める変更を計画しているようですが、今のところ特に動きはありません。

今のプロジェクトでは最低でもS3, DynamoDB, SQSが必要です。 S3は本家にもともとあるため問題ありません。 DynamoDBはgodynamoとcrowdmob/goamz/dynamodbがあります。 godynamoはJSONの設定ファイルが必要だったり、ディレクトリ構成や名前の付けかたが特殊すぎて候補から外しています。 (もし、idiomaticに修正しようとすると修正量が膨大になるし、おそらくPull Requestを出しても拒否されるだけです。)

crowdmob/goamz/dynamodbは名前やディレクトリ構成は一般的なGoのプロジェクトだったので実装が多少イケてなくてもあとから修正できるだろうと思い、ひとまず採用しました。 …しかし、ほとんど動いていなかった、マージ時のコードレビューがない、travis-ciも動いていない(ビルドが失敗していてもマージ)とプロジェクト的にはかなり不健康でした。私もちょっとcontributeし、一応はintegrationテストも入り、動くようになりました。

最近、メインのメンテナが交代したらしく、travis-ciも復活し、一時よりも健康を取り戻した感じです。なので、現状は問題ありません。しかし、これからのことを考えると、よくも悪くも現状のAPIを維持したままの機能追加やリファクタには限界を感じていて、私はこれ以上contributeするのは辛いかなという判断をしています。

aws-goすごいぞ

そんななか、つい先週stripe/aws-goが彗星のごとく登場しました。みてください、このスターの数…

goamz/goamz

mitchellh/goamz

crowdmob/goamz

stripe-aws-go

開発者たちの高い期待感の表れだと思います。 goamzと何が違うかというと、botocore(つまりAWS公式!!!)に含まれるAPI定義から go generateしてGoのコードを自動生成 (めっちゃイケてるやん…)している点です。

すごくいい感じなんですが、今のところREADMEにあるように highly untested です。あくまでコードは自動生成されているだけなので、動くかどうかは本当に実行してみるまでわからないという意味です。

実際、弊社小椋がDynamoDBを試した時はCreateTableができていませんでした。作者もすごくアクティブに開発しているため、この不具合はすぐに直っています。

また、aws-go自体はHTTPのRPCをそのままGoに落し込んだだけなので、単体では使い辛いと思います。実際にはaws-goをベースにしたラッパーライブラリが登場するものと思われます。私は今後SQSとDynamoDBあたりを叩いていって使えるようにしていきたいと考えています。

まとめ

弊社ではGoの機運が高まっています。来年のGopherCon India 2015にも弊社から2名参加予定です。ついでにスポンサーもしています。

海外のカンファレンスへの参加・スポンサーシップは英語化の一環でもあります。英語上達への道はまず英語環境へ身を置くことからです。

GoとAWSについては、短期的にはgoamzでプロジェクトを進めつつ、こつこつaws-goを叩いて使いものにしていきたいと考えています。みなさんにもぜひcontributeして頂いて使いものになるようにしていきましょう！！AWS公式Go SDK欲しいっ！！！！！！！！

以上です。