Go Conference 2019 Spring 参加レポート

こんにちは、ぷらす(@p1ass)です。

先日開催されたGo Conference 2019 SpringにWantedlyさんのスカラシップ枠として参加させていただきました!

LINE Developer Day以来、半年ぶりの大きめのカンファレンスだったのですが、Go固有の話をこれだけ聞く機会は今までなかったので、とても有意義な時間を過ごすことができました。

スカラシップ枠とは

本題に入る前にスカラシップ枠について少し紹介したいと思います。

Go Conference 2019 Springでは、地方に住む学生のために交通費や宿泊費が援助されるスカラシップ枠が用意されています。今回はWantedlyさんの他に、メルカリさんやメディアドゥさんも用意されていました。

Go Conference 2019 Spring (2019/05/18 09:30〜)
## 会場 / Venue リクルートライフスタイル本社 東京都千代田区丸の内1-9-2 グラントーキョーサウスタワー Recruit Lifestyle 41F 1-9-2 Marunouchi, GranTokyo South Tower, Chiyoda-ku, Tokyo, Japan ## イベントページ / Event website 詳細はイベントページを御覧ください。 / For further details, please refer to our official website. https://gocon.jp/ ## Call for Pr...
Go Conference 2019 Spring (2019/05/18 09:30〜)

僕は元からGo Conferenceには興味を持っており、自費でも行くつもりだったので、とりあえず申し込んだら受かりました。

スカラシップ枠でGo Conferenceに参加しませんか? #gocon by Wantedly, Inc.
他のテックカンファレンスでも好評だった学生応援プログラムを今年はGo Conference #gocon でも行います! 【概要】 ...
スカラシップ枠でGo Conferenceに参加しませんか? #gocon by Wantedly, Inc.

為になったセッション

エラー設計について/Designing Errors

メルカリのmorikuniさんによるエラー設計に関するセッションです。

Go Conference 2019 Spring - Google Slides
エラー設計について / Designing Errors Go Conference 2019 Spring 2019/05/18
Go Conference 2019 Spring - Google Slides

GoはJavaなど他の言語に実装されている例外がありません。すべてのエラーは戻り値によって返し、そのエラーハンドリングは各実装者に任されています。そのため、人によってエラーハンドリングの設計が異なり、ベストプラクティスがはっきりとしていませんでした。

僕がGoでなにかを実装するときは、pkg/errorsでとりあえずWrapしとく」くらいの適当な感じで行っていたのですが、このセッションを聞いたことでしっかりとしたエラー設計ができそうに思えました。

特に「関係者によってエラーに求める情報が異なる」という点について今まで考えたことがなく、各関係者がそれぞれ欲している情報を適切にエラーに含めることができるような設計を心がけるべきだと感じました。

また、morikuniさんが作られたmorikuni/failureとGo1.13から正式に実装される予定のxerrorsの違いに関する話もされており、用途に応じて適切なpackageを使っていきたいです。

morikuni/failure
failure is a utility package for handling application errors. - morikuni/failure
morikuni/failure

Goによる外部プロセス起動ベストプラクティス及びtimeoutパッケージ徹底解決

こちらはsongmuさんによるセッションです。Go界隈では有名な方ですね。

簡単なCLIアプリケーションなら作れるのですが、外部プロセスを扱う方法を理解していなかったので、セッションを聞きに行きました。

プロセスのシグナル周りを丁寧に解説されており、exec.CommandContextではSIGKILLが送られてしまうので孫プロセスを止められない、といった標準packageのデメリットなども紹介されていました。

また、コマンドの出力にgolang.org/x/text/transformTransformerを使ってタイムスタンプをつけるテクニックは他にも色々な用途で使えそうだと思いました。 io.Readerを使えるので汎用性が高い点も良いです。

Expand observability in Go

Google CloudでDeveloper Advocateをされているymotongpooさんのパフォーマンスチューニングに関するセッションです。個人的に今回のGo Conferenceで一番良かったセッションでした。

[shared] 20190518 Expand observability in Go - Google Slides
Expand observability in Go Go Conference 2019 Spring May 18th, 2019 Yoshi Yamaguchi (@ymotongpoo) https://bit.ly/20190518-gocon-spring
[shared] 20190518 Expand observability in Go - Google Slides

学生が趣味レベルでコードを書く場合、パフォーマンスチューニングを行うほどの性能を求められることはほとんどありません。そのため、net/http/pprofnet/http/httptraceは名前を聞いただけでほとんど実践したことがありませんでした。

このセッションでは、サンプルコードを例にパフォーマンスチューニングのやり方を丁寧に解説されていました。

Process for Performance Tuning
1. Collect as many metrics as possible
2. Dig into the repeat and specify the roote cause
3. Write and benchmark
4. Modify the implementation
5. Repeat 3 & 4 until the benchmark result get improved

Goでは↑の各ステップを行うための様々なツールが用意されており、それらを使えば簡単に計測を行える点がとても魅力的に感じました。

実際にやってみた

翌日、自分が建てているAPIサーバに対して実際にProfileを取ってみました。 このAPIサーバーはginを使って建てていたので、pprofの設定はgin-contrib/pprofで行いました。

APIサーバーに対する負荷はGo製の負荷テストツールであるtsenart/vegetaを使って行い、秒間100リクエストを10秒間与え、その間の5秒をpprpfで計測しました。

echo "GET  http://localhost:8080/json" | vegeta attack -rate=100  -duration=10s | tee result.bin
go tool pprof -http=":8888" http://localhost:8080/debug/pprof/profile 

結果は以下のようになりました。

pprofのFrame Graph pprofのFrame Graph

メモリに保持しているデータをJSONにシリアライズして返すだけの単純なAPIなので、runtimenet/httpが支配的で、問題になりそうな部分は見当たりませんでした。

これがISUCONの参考実装であれば、明確に遅い部分が見つかると思うので、今後試していきたいです。

終わりに

僕はGoをほとんど独学で勉強してきましたが、Go Conferenceはまだ知らないことを知るとても良い機会でした。 日本で一番大きなGoに関するカンファレンスということもあり、レベルの高い話が多く、Gopherなら絶対に行くべきイベントだと思います。

来年は自分が登壇する側に回れるように頑張りたいです💪

最後になりますが、このような機会を設けてくださったWantedlyさん本当にありがとうございました!

おまけ

メルカリのスカラシップで来ていた人のうち、2人が元からTwitterのFFでした。世間は狭いですね。

おわり