golang.tokyo#3に参加しました
先日golang.tokyo#3にブログ枠で参加してきました。
ブログ枠で参加したのは、自分のアウトプットを向上させるためです。
アウトプット初心者の拙い文章ですがご容赦ください。
ちなみにこの golang.tokyoは今回で3回目の開催ですが、自分自身は初参加です
メインセッション
久保達彦(@cubicdaiya) / 株式会社メルカリ
Accelerating real applications in Go
使用されているchoconとgaurnを題材にしたパフォーマンスでの工夫点のお話です。
chocon - Persistent connector between multi datacenters
- メルカリの日本とアメリカとヨーロッパという3つの離れたネットワークのレイテンシーを抑えるためのプロキシサーバ
- プロキシサーバはサーバでありクライアントなので、両方の最適が必要.
- 特にのクライアントの方が必要で net/http/transport.go の3つの値が大切になる
- MaxIdleConns (デフォルト値: 100)
- MaxIdleConnsPerHost (デフォルト値: 2)
- IdleConnTimeout (デフォルト値: 90)
gaurun - Push notification provider
- プッシュ通知用サーバでHTTP/2でGCMとAPNsへのリクエストをプロキシする
- 30分以内に全ユーザへのプッシュを行うなどのために高い並列実行性が必要
- キューで受けてworkerがそれぞれプッシュ通知を行う。このworker数分のgoroutineを起動
- workerがそれぞれプールを持つことで worker × pool のプッシュ通知を送信することが可能になった
- ブロッキングしないために capとlenで channelの数とキュー数をモニタリング
- 全体の状態をモニタリングするためにメトリクスのエンドポイントをgo用とapp用にそれぞれ用意
感想
遠く離れたネットワークではないにしろ、マイクロサービスアーキテクチャなどで各サービス間での通信クライアントを作成することがあるので、興味深かったです。通信クライアント作成時にレイテンシを少しでも抑えるためにも自分でも標準パッケージについて理解を深めようと思います。
金子慎太郎( @kaneshin ) / 株式会社エウレカ
登壇予定だったのですが、体調不良で欠席とのことでした。
残念でしたが、また後日ブログで書くとの事だったので、楽しみにして待ってようと思います。
Carlo Alberto Ferraris / 楽天株式会社
goでどうこうといった話ではなく、開発現場に当てはまるお話でした。
概要
- 価値を共有し、最適にはきちんと計測を行う
- 開発者 > サーバコスト
- 何事も失敗することを前提に冗長性を確保する
- リカバリはプレイブックではなく、自動化する。だけどすべてを自動化しようとは言わない
- コードを読む時間 > コードを書く時間。読むほうが10倍時間を使う。だからこそシンプルであるべき
- 読みづらい速いコード < 読みやすい遅いコード。開発者 > リソースコストなので、読みやすいコードを優先するべき
- KISS (Keep It Siimple, Stupid)
- 目的を1つにして、分離/可視化する
- シンプルに保ち、すべてを計測し、問題を最適化する
感想
シンプルにすることや目的を1つにするなど、今一度気を引き締めて実践していたいとと思います。twelve-factorは聞いたことはあったもののきちんと読んでいないので、この機会に読んでみます。日本語に翻訳されているものもあるようです。The Twelve-Factor App （日本語訳）
そして、このセッションは自分の英語力の足りなさを痛感する回でした...もっと聞き取れるともっと吸収できることがあったんだろうにと、英語ができないともったいないと改めて実感しました 。
LT
辻 純平 (@jun06t) / AWA株式会社
Streamを使うことでのメリットとその実装例を示したTipsの話です。
概要
- ioutil.ReadAll()をつける癖をなくし、Streamを使う
- 多くの標準パッケージがstreamをサポートしているので、bytesの変換しないくても良い
- ベンチ結果からもstreamを使う方がbyte変換する場合に比べ、メモリの消費量やアロケーション回数が少なくなっている
実装例
感想
自分が書いたものを見返すとjson.NewDecoderで記述していた部分があったのですが、正直先輩たちが書いているのを参考にして書いており、恥ずかしいながら自分自身パフォーマンスの差のことを理解せずに使っていました...
streamと使う場合と[]byteでの場合の2つ方法の違いがわかったので、自分も意識して活かしていこうと思います。「推測するな、計測せよ」自分も実践していかないと
Ryosuke Yabuki (@Konboi) / 株式会社カヤック
git-schemalexを用いたマイグレーションとその開発の流れのお話です。
概要
Rails方式のマイグレーション (都度SQL等を記述していく形式)
- アプリケーションと同じ言語で記述できる
- DSLを覚えるコストがかかる
- コンフリクトが起きやすい
git-schemalexを用いたマイグレーション(スキーマの差分からSQLを生成する)
schemaファイルをgoのstructから自動生成するddl-makerを作成
開発の流れ
- struct定義
- ddl-makerでschemaファイルを生成
- schemalexでDBに反映
感想
schemalexのマイグレーションとstruct定義からの自動生成はスキーマの管理に便利そうで興味深かったです。自分が関わるプロジェクトではgooseを使い、都度変更点のsqlを記述し実行する形を取っていますが、実行時などで他のメンバとの前後関係でうまく実行できないということも実際に体験したことがあります。
自分自身Rails方式以外のマイグレーション方式は試したことないので、今回のschemalexから試してみようと思います。
高橋 明 (@Talos208) / 株式会社スプラウト
Database sql from 明 高橋
database/sqlの使用方法と設定値のお話です。
概要
- db.Closeを書きたくなるが、ドキュメントを読むと複数のgoroutine間で共有することを意図しているから、DBをcloseすることはほとんどないと記述されている
- ソースを読むと、都度open/closeすると接続/切断のコストがかかることがわかるので、sql.Openは起動時にDB.Closeは最後にそれぞれ1回呼ぶ
現場で起こった事例
- sql.OpenとDB.Pingは成功するが、DB.Queryの実行時にコネクションエラー
- go -> maxscale -> MariaDBという構成
- go -> maxscaleはコネクションが成功している
- maxscale -> MariaDB ここのコネクションがタイムアウト... サーバにはタイムアウトの通知がされない
- go1.6で導入されたsetConnMaxLifetimeで解決 (一定時間以上経過したコネクションは再利用しない)
感想
ここでも感じたのは、やはりググるだけではなく、標準パッケージのソースコードなどを読むということの重要性です。
自分の関わるプロジェクトでもdatabese/sqlのMaxIdleConnsの設定値を変えて改善したというものがありましたが、そもそも自分がコネクション周りの知識が足りていないのできちんと理解できていないと思うので、これを機にコネクション周りの勉強もしてみようと思います。
最後に
標準パッケージのことをもっとよく知ろうと思えた会でした。また、ググるだけでなく、golangのソースコードを読むことが重要だと感じることができました。
休憩時間も色々お話できて楽しかったです。次回もぜひ参加したいですね。
じゃんけんに負けてTシャツをもらえなかったのは、残念でした...
