Golang Cafe #32 まとめ Go Conference 2014 spring を読む。

Go

2014/06/01に開催された「Golang Cafe #32」についてのまとめです。

今回は2014/05/31に開催されたGo Conference 2014 springの発表内容が公開されているので、こちらを読んでいくことになりました。
ちなみにGolang Cafeに参加のメンバーは誰も参加できませんでした。


公開されている資料は+Yoshifumi YAMAGUCHI氏のブログから参照できます。
その中から以下のものを読んでみました。（順不同）

詳しい内容はそれぞれの資料を読んでいただくこととし、ポイントのみまとめておきます。

300万人をGoで捌いた話

Go+Redisでnet/httpを使用。フロントにNginxを配置。
サーバー周りはgorilla/muxパッケージを使用。（dockerでも使っている）
DB周りはGorp。
I/Oが発生する部分をgoroutine化する。
データアクセス部分をgoroutineでキャッシュしておく。channel経由でメイン側とやりとりする。後の発表でもあるが私もgoroutine間で共有メモリを使用したデータのやりとりは推奨しない。キャッシュ側は定期的にリフレッシュ。
MQの用にgoroutineを使用する。channelへの書き込みをトリガーにgoroutine側でタスクを実行する。

Do not communicate by sharing memory

Go言語に限ったことではなく、一般的に複数スレッドを使用した処理を行う場合に理解しておきたい内容。
先にも書いたとおりgoroutine間でも共有メモリの使用は気をつけなくてはならない。（そもそも余程のことがない限り私は使用を控えている）
所謂CountDownLatchがGo言語ではWaitGroupとして実装されている。

Go in Production at Mackerel.io

Go言語で実装されているMackerel.ioのお話。
複数のgoroutineを使ったタイマーの実装とさらにそこからの処理の実行。
複数のgoroutineの終了待ちはWaitGroupで。
バッファありのchannelをキューとして使う。
Buildはmakeで。
dockerを使う。
メモリリークの調査はruntime/pprofで。（私も実際に試してまとめてます）
Go言語のいいところ、いけてないところで、文字処理が今ひとつみたいな内容がありましたが（実際の発表ではどうだったかわかりません）、今のところ文字処理でそんなに困ったことはないような気がします。

Martini - Web framework for Go

以前+TakashiYokoyama氏が紹介していたMartiniのお話。（forkしてそのままになってます。。。）
RESTFulなAPIサーバーなら簡単に構築できそう。
ルーティングはすべて定義する必要がありそう。
reflection使いすぎってことでNegroniというのがあるらしい。
ここにはgorillaというキーワードが。

pt&Goroutines

スライドの内容から受け取れるメッセージとしては、「goroutineとchannelを使用して処理を高速化しよう」。
channelはデータの受け渡しだけではなく、goroutineをブロックされることもできる。
Concurrency is not parallelismに書いてあるとは思いますが、並行性というのがちょっと気になりました。

まとめ

どの内容も非常に興味深く、現地で聞けなかったことが悔やまれます。
しかしあのスケジュールでは調整しきれませんでした。（GoCon開催発表の時点で先約がありました）
次回こそはぜひ参加したですね。

余談

  • Golang Cafe #31については、私の不注意でPCを壊したため参加できなかったのでまとめはありません。
  • シダは手強い