golang.tokyo#6に参加しました

2017年6月1日(木)に行われた、golang.tokyo#6にブログ枠で参加してきました。
golang.tokyo #3以来の2回目の参加になります。

golangtokyo.connpass.com

 

会場は株式会社ディー・エヌ・エーさん

 

今回のはソーシャルゲームプラットフォームと現地時間の5月15日にアメリカで開催されたGopher Fest 2017がメインコンテンツとなる会でした。

 

メインセッション

Gopher Fest 2017 参加レポート

tenntenn / 株式会社ソウゾウ

www.slideshare.net

概要

Gopher Fest 2017の中の The State of Go 内容についてお話でした。

またGopher Fest2017のセッションの動画はアップロードされているみたいです。

golangの開発状況

  • go1.9は5/1コードフリーズしており、8月上旬にリリース予定

言語仕様の変更が1点. 型のエイリアスを定義できるようになる

  • 完全に同じ型として扱える
  • キャスト不要
  • エイリアスの方にはメソッド定義はできない
  • 例:  type Applicant = http.Client  でApllicantはhttp.Clientとして同様に扱える

標準ライブラリの変更

  • math/bits => ビット演算に便利なライブラリ
  • sync.Map => スレッドセーフなマップ
  • html/template => スクリプトのインジェクトがエラーになるようになり、より安全に
  • os.Exec => 重複する環境変数を削除するように一番後ろのものを優先する.直感的になった
  • https://tip.golang.org/pkg/ のようにtipをつけてアクセスすると、最新のmasterのドキュメントを見ることができる

ランタイムの改善

ツール類の改善

  • コンパイルのエラーメッセージの改善
  • コンパイル速度の改善
  • go testの改善
    • 複数パッケージの場合にはvendorを無視
    • テスト関数一覧を表示可能に
  • go doc フィールドにリンクが貼れる


感想

スレッドセーフなマップなど便利そうだし、go testの改善でvendor配下を無視してくれるのも良いですね。ベンチの結果もよくなっているということなのでgo1.9のリリースが楽しみになりました。

 

初めてGolangで大規模Microservicesを作り得た教訓

村田雄一 / 株式会社ディー・エヌ・エー

スライドが公開されたら追記します

概要

実際のプロダクションにおいて、Golangで大規模なMicroservices構成のAndAppを作ったときに得た教訓の紹介でした。

1. フレームワークにこだわらない

  • 洗練されたnet/httpがあり、その足らずはライブラリで補完すれば大丈夫
  • 言語仕様がシンプルかつgofmtがあるので、コーティングスタイルは似てくる

2. interfaceを尊重する

  • 独自エラー型を利用する場合にNilには型があるという罠が踏んだ経験から、素直に他の関数のようにerrorインターフェースに統一したほうがよかったという
  • interfaceの定義されてたものは積極的に使用したほうが標準ライブラリとの連携がシンプルになる
  • Interfaceで定義されてるものはInterfaceを維持する

3. regex compile / reflection は遅い

  • gojsonschemaを使って、バリデーションのたびに毎回regexコンパイルしていたことやrelectionの多用をしていたためバリデーションをかけるとかなり遅くなった
  • チューニングした結果2倍以上の改善
    • regexマッチのキャッシュ
    • reflection多用部のロジックチューニング(無くすことはできないので、ロジックの無駄を省く)
  • gojsonschemaをチューニングするより、go-jsval段違いに速かった

4. 非対称暗号は遅い

  • 非対称鍵の署名が重い
  • opensslと比べてGoのcrypt/rsaが貧弱
    • 対象鍵の署名: 0.37msec
    • 非対称鍵の署名(Goのcrypt/rsa): 486msec程度
    • 非対称鍵の署名(openssl): 50msec程度
  • cgoを使ったopensslのバインディングも存在.(ただApp Engineのサンドボックス環境の都合で利用できない)
  • goの最新版(1.7)でもあまり改善されていない様子

まとめ

  • 困った時にはGoの哲学に帰りシンプルなアプローチを取る
  • Goを過信せずにパフォーマンスに気を配る


感想 

非対称鍵の署名処理部分を(PHP + openssl)で外出してhttpリクエストしたほうが早いということがすごく印象に残りました。他にも独自のエラー型のことやパフォーマンスのことも参考になりました

 

LT

ゲーム開発には欠かせない?!あれをシュッと見る

Ryosuke Yabuki (@Konboi) / 株式会社カヤック

speakerdeck.com

概要

CSVビューアを作成した時のお話でした。

GitHub - Konboi/csviewer: csv viewer command

背景

  • マスターデータがCSV, Excel, SpreadSheet
  • カラムとデータの関連性が見辛い、空欄が辛いなどなど、CSVで困ることがあったので作成

使用したライブラリの紹介

感想

便利なライブラリの紹介だったのでcliツールを作る際には役立てたいですね 

マスタデータの管理がcsv等なのはどこにでもあるのだと改めて感じることができる回でした...

 

Go Review Commentを翻訳した話

鎌田健史 (@knsh14) / KLab株式会社

speakerdeck.com

概要

Go Review Commentsを翻訳することで得た学びを紹介でした。

Code Review Comments (CodeReviewComments · golang/go Wiki · GitHub) とは?

  • コードレビューする些細に見るべき箇所をいい感じにまとめたもの
  • effective GOをさらに簡単にしたもの

その日本語訳を書いた (#golang CodeReviewComments 日本語翻訳 - Qiita)

内容は大きく4つの種類がある

  • コードの見た目を改善 => 大体はツールで解決
  • コメント、文章の体裁 => コード内の文章の書き方のアドバイス
  • tips系  => より良い方法を紹介
  • 設計の指針 => レシーバタイプの考え方など

翻訳を書くきっかけ

  • Goコードをレビューしてもらった時に大量の指摘を受けた
  • その時にCode Review Commentsを渡せれる
  • 読んだ証拠に自分で翻訳

翻訳してよかった点

  • 正解パターンを勉強できるのが効率が良かった
  • 英語の勉強にもなり、他の英語書籍への挑戦するハードルも下がった

まとめ

  • Code Review Commentは目を通してほしい
  • 良いドキュメントの翻訳は勉強になる

感想

Code Review Commentは把握していなかったので、これを気に読んで翻訳された日本語訳のものから読み、自分のコードやレビュー時をよりよくしていきたいです。

ScalaからGo

James / 株式会社エウレカ

www.slideshare.net

概要

Scalaの人がGoに移ってきた時のお話です。

  • 関数型開発はGoできますか? => No
  • 関数型開発のコンセプトはGOで使えますか => Yes
  • 関数型開発の考え方
    • 関数型開発は副作用がない開発
    • 関数の副作用があるとテストしにくしバグの原因になる
    • コードとしてだと例として部分適用
  • どちらが好きか?
    • 個人的にはscala => scalaの長期成長が楽しい 
    • 会社としてはGoがいいかもしれない => 初心者でも綺麗なコードを書いやすい

感想

副作用があるのかないのかはっきりさせるということは、Goでも関数型でも同じだと思うので、普段のコードから考えて書いてみようと思えました。今までは正直意識できていなかったので。。。

 

Crypto in Go

Kengo Suzuki / マネーフォワード

paper.dropbox.com

概要

暗号化のお話でした

  • Goにおける暗号アルゴリズムを利用
  • AES
    • 固定長しか扱えない
    • 任意の長さの平文に暗号化するためにECBを始め、様々なモードがある
  • AES + PKCS7パティング + HMAC
    • 実装するのに行数が多く面倒
  • AES + GCM
    • アメリカ国立標準技術研究所(NIST)にも標準として認められている
    • とてもシンプルに実現

 

最後に

最新のgo1.9の話や実プロダクトでの知見だけでなく、他言語からの視点,暗号の話など様々な有意義な内容に触れることができ、楽しい会でした。

運営の皆さんありがとうございました。またぜひ参加したいです

golang.tokyo#3に参加しました

先日golang.tokyo#3にブログ枠で参加してきました。
ブログ枠で参加したのは、自分のアウトプットを向上させるためです。

アウトプット初心者の拙い文章ですがご容赦ください。

ちなみにこの golang.tokyoは今回で3回目の開催ですが、自分自身は初参加です

golangtokyo.connpass.com

 

メインセッション

久保達彦(@cubicdaiya) / 株式会社メルカリ

Accelerating real applications in Go

使用されているchoconとgaurnを題材にしたパフォーマンスでの工夫点のお話です。

chocon - Persistent connector between multi datacenters

  • メルカリの日本とアメリカとヨーロッパという3つの離れたネットワークのレイテンシーを抑えるためのプロキシサーバ
  • プロキシサーバはサーバでありクライアントなので、両方の最適が必要.
  • 特にのクライアントの方が必要で net/http/transport.go の3つの値が大切になる
  1. MaxIdleConns (デフォルト値: 100)
  2. MaxIdleConnsPerHost (デフォルト値: 2)
  3. 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 / 楽天株式会社

slides.com

goでどうこうといった話ではなく、開発現場に当てはまるお話でした。

概要

  • 価値を共有し、最適にはきちんと計測を行う
  • 開発者 > サーバコスト
  • The Twelve-Factor App 

  • 何事も失敗することを前提に冗長性を確保する
  • リカバリはプレイブックではなく、自動化する。だけどすべてを自動化しようとは言わない
  • コードを読む時間 > コードを書く時間。読むほうが10倍時間を使う。だからこそシンプルであるべき
  • 読みづらい速いコード < 読みやすい遅いコード。開発者 > リソースコストなので、読みやすいコードを優先するべき
  • KISS (Keep It Siimple, Stupid)
  • 目的を1つにして、分離/可視化する
  • シンプルに保ち、すべてを計測し、問題を最適化する

感想

シンプルにすることや目的を1つにするなど、今一度気を引き締めて実践していたいとと思います。twelve-factorは聞いたことはあったもののきちんと読んでいないので、この機会に読んでみます。日本語に翻訳されているものもあるようです。The Twelve-Factor App (日本語訳)

そして、このセッションは自分の英語力の足りなさを痛感する回でした...もっと聞き取れるともっと吸収できることがあったんだろうにと、英語ができないともったいないと改めて実感しました 。

 

LT

辻 純平 (@jun06t) / AWA株式会社

slides.com

Streamを使うことでのメリットとその実装例を示したTipsの話です。

概要

  • ioutil.ReadAll()をつける癖をなくし、Streamを使う
  • 多くの標準パッケージがstreamをサポートしているので、bytesの変換しないくても良い
  • ベンチ結果からもstreamを使う方がbyte変換する場合に比べ、メモリの消費量やアロケーション回数が少なくなっている

実装例

  • json.Unmarshal => json.NewDecoder
  • io.Copy, io.CopyBuf
  • bytes.Buffer =>  io.Pipe
  • io.Reader 

感想 

自分が書いたものを見返すとjson.NewDecoderで記述していた部分があったのですが、正直先輩たちが書いているのを参考にして書いており、恥ずかしいながら自分自身パフォーマンスの差のことを理解せずに使っていました... 

streamと使う場合と[]byteでの場合の2つ方法の違いがわかったので、自分も意識して活かしていこうと思います。「推測するな、計測せよ」自分も実践していかないと

 

Ryosuke Yabuki (@Konboi) / 株式会社カヤック

speakerdeck.com

git-schemalexを用いたマイグレーションとその開発の流れのお話です。

概要 

Rails方式のマイグレーション (都度SQL等を記述していく形式)

  • アプリケーションと同じ言語で記述できる
  • DSLを覚えるコストがかかる
  • コンフリクトが起きやすい

git-schemalexを用いたマイグレーション(スキーマの差分からSQLを生成する)

  • sqlのみ書ければ良い (DSLを覚えなく良い)
  • コンフリクトが起きづらい

schemaファイルをgoのstructから自動生成するddl-makerを作成

開発の流れ

  1. struct定義
  2. ddl-makerでschemaファイルを生成
  3. schemalexでDBに反映

感想

schemalexのマイグレーションとstruct定義からの自動生成はスキーマの管理に便利そうで興味深かったです。自分が関わるプロジェクトではgooseを使い、都度変更点のsqlを記述し実行する形を取っていますが、実行時などで他のメンバとの前後関係でうまく実行できないということも実際に体験したことがあります。

自分自身Rails方式以外のマイグレーション方式は試したことないので、今回のschemalexから試してみようと思います。

 

高橋 明 (@Talos208) /  株式会社スプラウト

www.slideshare.net

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シャツをもらえなかったのは、残念でした...