α・β・κ

カッパ的視点からものごとをまとめます。

Go オールスターズに行ってきた

以前、mercariのブログ

tech.mercari.com

を読んでGoが気になっていたのだが、著者の@cubicdaiya さんが渋谷でお話しされるということで行ってきた.

Go オールスターズ

dotsさんで開催されたイベントです。渋谷のイベントスペースは駅からも近いし、すごく綺麗なのでいいですね!

eventdots.jp

Push通知 worker

詳細は冒頭のブログに詳しいので割愛するが、自分が運用しているサービスでも諸々存在するworkerの中で、APNs/GCMを利用したpush通知関連のwokre群はスループットの要求水準がかなり高い。また、APNs/GCM側の問題でQueueが詰まってしまったり、といろいろと頭を悩ませることがしばしばあった。

なのでGoで改善できたらいいなー、と思っている。

具体的には

  • Go実装に切り替えることでどの程度スループットが改善するのか
  • APNs/GCMが落ちてるときとか、worker自体が落ちたときの復旧とか実際どうしてるのかなあ、という運用のノウハウ

の2点が気になっていた。

Go のメリット

@cubicdaiya  さんはじめ登壇者の方はGoのメリットについて以下の3つを挙げている。

1. 単一バイナリ: buildが簡単. deployも簡単.

2. Go Routine/Channel: マルチコアを利用した並行プログラミングが容易に書ける.

3. システムプログラミングができるのに書きやすい: C, Shell Script, LLの代替としてほぼ機能する

自分はGo初心者だが、この3つだけでもGoの人気の理由は分かった気がした。push通知のworker系は要求されるスループットや可用性の水準が非常に高い。このため、キュー処理だったり、並行処理だったり、リカバリ処理だったりをまじめに実装しなければならないのだが、理屈的にもGoのメリットがぴったりマッチする。 

とにかくPerlとかでプロセスたくさん立てて並列数を稼ぐのは、メモリ等諸々リソースのオーバーヘッドが大きい。これをGo Routinesで書き換えるだけでかなり良くなるよ、とのことでした。面白かったのが、Goの並行処理は非常に堅牢で、CやらPerlやらで並行処理を実装したときよりもworkerがクラッシュすることは少ない、とのこと。ブログで紹介されているリカバリ機構はあるけど、なにせ堅牢なので半年運用してて一度も使ってない、というような話をしていてすごいなと思った。