Go言語で苦労したポイントの事例

http://da-data.blogspot.jp/2013/10/experience-with-epaxos-systems-research.html

1 comment | 0 points | by Jshiike 4年弱前


Jshiike 4年弱前 | ▲upvoteする | link

Go言語についての記事をまとめていて困るのが、特にHacker Newsでは熱狂的な賛成派と執拗な反対派が感情的に戦っていて、Go言語の何がいいのかはわかるが、まだ改善すべき余地のあることが実際どれほどの支障になるのかについては、議論からは判別しづらいことです。


カーネギーメロン大のDavid Andersonが、分散アルゴリズムEPaxosをGo言語でインプリしたときの経験について”Huge Positive” “It proved a huge win” としていながら、苦労したポイントを挙げています。このような具体的な事例がもった蓄積していくと参考になるのではないかと思います。



Go言語による開発で苦労したのは、Zookeeper等の既存のシステムと遜色ないパフォーマンスをだすための最適化に手間がかかったこと。


Go RPCのパフォーマンスがダメで、最初のボトルネックなった。実際のコミュニケーションやメソッドの呼び出しではなく、マーシャリングとアンマーシャリングが問題であった。そこで、自分たちでマーシャリング & RPCコンパイラーを書き直すことで改善した。[変更ポイントの参考: ePaxos message format / automatically-generated marshaling code]


ePaxosでは、キューを小さくするため、古いコマンドから有線優先して処理するようにしているが、これをインプリするのがかなりトリッキーで、selectループを複製するしかないかと思った。最終的には、Russ Coxのアドバイスで、同じselectを2回実行するが、channelのアサイメントを変更することで対応できるとわかった。


ガベージを減らすためにどうすればよいのか推測するのが非常に難しかった。また、いくつかのマップがその最終的なサイズに到達するまでの間待つ時間が長く、パフォーマンスに影響がでた。これらの点についてはGo言語だけでおこる問題ではないし、EC2を利用している影響もあったかもしれないが、本プロジェクトの改善ポイントであったので指摘してみた。


Goroutineがうまくスケジュールされる(されない)によって、説明できないパフォーマンスのアップ/ダウンがあった。スレッドをどう明示的に管理するかは考えなくて済むにこしたことはないが、この分散システムのパフォーマンスアップのためには必要であった。


最終的には、クラスタあたり、バッチなしで5万件/秒のオペレーションができるようになった。また、5msのコマンドバッチで、遅延はでるが、40万件を超すことができた。


このプロジェクトのソースは、Githubで公開されています



D言語とGo言語


Go : 盛り上がり感 (hype) を実力にすることが重要


Goプログラミング: Rob Pike and Andrew Gerrand [The Changelog]



#golang #開発スタイル

Back