CA Reward

Tech Blog

Tech Blogトップに戻る

golang.tokyo #3

2017.02.07

  • このエントリーをはてなブックマークに追加
  • Pocket
kotaking
kotakingエンジニア

こんにちは、開発部の小高です。今回は先日行われた golang.tokyo#3 についてレポートしたいと思います。

golang.tokyo#3

はじめに

CAリワードではGoを採用し始めて約2年程経ちました。 最近ではGoを採用〜運用している企業様が増えてきましたね。

CAリワードではGunosy、エウレカ、メルカリ様と共同でgolang.tokyoを開催し、Goの良い点、気をつけるべき点、実際に使ってみてハマった事などを、ブログ・勉強会を通じて発信しています。 golang.tokyoも無事3回目を迎え、今回は渋谷マークシティのCyberAgent本社で開催させていただきました。ご足労いただいた皆様、改めてありがとうございました。

テーマ

golang.tokyo#3 のテーマは「パフォーマンス」。 Goといえばやはりその速さ。みなさん待ちに待ったテーマではないでしょうか(笑)

タイムテーブル

19:35 ~ 20:05 メルカリ 久保達彦さん
20:05 ~ 20:35 楽天 Mr. Carlo Alberto Ferraris
21:05 ~ 21:15 CyberAgent AWA株式会社 辻純平さん
21:15 ~ 21:25 面白法人KAYAC高橋さん
21:25 ~ 21:35 株式会社スプラウト Tarosさん

会場入り

マークシティのエレベーターを昇っていくと、癒しキャラGopher君がお出迎え。

20170126<em>golangtokyo3</em>001

今回は80名の定員に対し、過去最多の169名の方に応募いただきました。Goの人気はうなぎ昇りです!

20170126<em>golangtokyo3</em>007

勉強会スタート

メルカリ 久保さん

20170126<em>golangtokyo3</em>005

最初のトークはメルカリ久保さん アプリケーション高速化のためのリバースプロキシをGoで書いた話をしていただきました。

Go標準の net/http はそれなりに高性能ではあるが、細かいチューニングをするには net/http/client、net/http/transport を使うとの事。

  • ネットワークのレイテンシを下げる為のチューニング
    • MaxIdleConns
    • MaxIdleConnsPerHost
    • IdleConnTimeout
  • clientとtransportは使い回す事が推奨されている
  • chocon
    • host headerをみて、リクエスト先のプロクシを決める
  • gaurun
    • 高性能なAPNS機能

golang-tokyo.slide#1

楽天 カルロさん

20170126<em>golangtokyo3</em>006

楽天でエンジニアリーダーをやられているカルロさん。今日はパフォーマンスと最適化についてトークしてくれました。

  • THEORY != PRACTICE
    • 理論と実践は同じではない
  • SHARED VALUES
    • プロジェクトの価値を共有・合意
  • KISS (Keep It Simple, Stupid)
    • コードのリードライトの比率(R:W = 10:1)
    • 性能を犠牲にするか可読性を犠牲にするかの選択
    • 人件費はサーバコストより高いよ(笑)
  • SCALE-OUT ELASTICALLY
  • KEEP THINGS SIMPLE
  • MEASURE EVERYTHING
  • OPTIMIZE WHAT MATTERS

休憩

前半のトークイベントが終わり、ビュッフェ形式での休憩タイム。お酒と食事を片手にエンジニア同士が情報交換などをし、交流を深める時間になりました。みんなGoが大好きで楽しそうに話していたのが印象的。

20170126<em>golangtokyo3</em>008

LTの部

第二部はLT形式の発表です。「Streamの扱い方」「DB migrationの紹介」「DB Connection pool」について、それぞれ発表いただきました。

AWA株式会社 辻さん

20170126<em>golangtokyo3</em>010

メモリの浪費を抑えるために、byte変換ではなくStreamの利用を推奨する話。実例を交えて解説していただきました。

  • ioutil.ReadAllでbyteに変換するとメモリを多く消費する
  • アロケーションやGCに依る速度低下が起きる
    • json.Unmarshal → json.NewDecoder を使う
    • io.Copy を使う
    • bytes.Buffrer → io.Pipe を使う

KAYAC高橋さん

20170126<em>golangtokyo3</em>012

  • migration tool

    • github/gh-ost
    • mattes/migrate
    • rubenv/sql-migrate
    • elwinar/rambler
    • DavidHuie/gomigrate 上記のうち、gh-ost以外はRails方式
  • Rails方式

    • migration の都度ファイルを生成
    • up/downでrollback可能
    • DSLで定義し実行

スプラウト Tarosさん

20170126<em>golangtokyo3</em>014

  • DBハンドルは複数のgoroutine間で共有する事を意図しているため、db closeはしない
  • sql.Open()で返却される構造体はconnection poolを持っている
  • 接続時はpoolの空きコネクションから使用
  • sql.Open()は起動時に1回だけ呼ぶ
  • DB.close()は最後に1回だけ呼ぶ

まとめ

Goといえばやはりパフォーマンス面での恩恵が大きいので、今回のパフォーマンス・チューニングの話はとてもためになりました。というのも、Goは速いと言われますが、書き方によっては意図したパフォーマンスが得られない事があるのも事実です。今回、多岐に渡るパフォーマンス改善の話が聞けたので、今後の開発の参考にしようと思いました。今回会場にお越しできなかった方のためにも、引き続きGo勉強会の内容についてアウトプットしていくので、お楽しみください。