こんにちは、ぷらす(@p1ass)です。
先日開催された Go Conference 2019 Spring に Wantedly さんのスカラシップ枠として参加させていただきました！
LINE Developer Day 以来、半年ぶりの大きめのカンファレンスだったのですが、Go 固有の話をこれだけ聞く機会は今までなかったので、とても有意義な時間を過ごすことができました。
スカラシップ枠とは
本題に入る前にスカラシップ枠について少し紹介したいと思います。
Go Conference 2019 Spring では、地方に住む学生のために交通費や宿泊費が援助されるスカラシップ枠が用意されています。今回は Wantedly さんの他に、メルカリさんやメディアドゥさんも用意されていました。
僕は元から Go Conference には興味を持っており、自費でも行くつもりだったので、とりあえず申し込んだら受かりました。
為になったセッション
エラー設計について/Designing Errors
メルカリのmorikuni さんによるエラー設計に関するセッションです。
Go は Java など他の言語に実装されている例外がありません。すべてのエラーは戻り値によって返し、そのエラーハンドリングは各実装者に任されています。そのため、人によってエラーハンドリングの設計が異なり、ベストプラクティスがはっきりとしていませんでした。
僕が Go でなにかを実装するときは、 「pkg/errorsでとりあえず Wrap しとく」 らいの適当な感じで行っていたのですが、このセッションを聞いたことでしっかりとしたエラー設計ができそうに思えました。
特に「関係者によってエラーに求める情報が異なる」という点について今まで考えたことがなく、各関係者がそれぞれ欲している情報を適切にエラーに含めることができるような設計を心がけるべきだと感じました。
また、morikuni さんが作られた morikuni/failure と Go1.13 から正式に実装される予定の xerrors の違いに関する話もされており、用途に応じて適切な package を使っていきたいです。
Go による外部プロセス起動ベストプラクティス及び timeout パッケージ徹底解決
こちらはsongmu さんによるセッションです。Go 界隈では有名な方ですね。
簡単な CLI アプリケーションなら作れるのですが、外部プロセスを扱う方法を理解していなかったので、セッションを聞きに行きました。
プロセスのシグナル周りを丁寧に解説されており、exec.CommandContextでは SIGKILL が送られてしまうので孫プロセスを止められない、といった標準 package のデメリットなども紹介されていました。
また、コマンドの出力に golang.org/x/text/transformの Transformer を使ってタイムスタンプをつけるテクニックは他にも色々な用途で使えそうだと思いました。
io.Readerを使えるので汎用性が高い点も良いです。
Expand observability in Go
Google Cloud で Developer Advocate をされているymotongpoo さんのパフォーマンスチューニングに関するセッションです。個人的に今回の Go Conference で一番良かったセッションでした。
![[shared] 20190518 Expand observability in Go](https://lh7-us.googleusercontent.com/docs/AHkbwyJv5dE_Igl_W0JKF4_19sUsRTTWE21iX0MJtXKOtUaTgK0hPM9M7SyEqo4-rCkt_frltSZTvUEXAGe3UQaiBlb_1ziXp_ybjwKYKaoLN8MPKv3GWkju=w1200-h630-p)
学生が趣味レベルでコードを書く場合、パフォーマンスチューニングを行うほどの性能を求められることはほとんどありません。そのため、net/http/pprofや net/http/httptrace は名前を聞いただけでほとんど実践したことがありませんでした。
このセッションでは、サンプルコードを例にパフォーマンスチューニングのやり方を丁寧に解説されていました。
Process for Performance Tuning1. Collect as many metrics as possible2. Dig into the repeat and specify the roote cause3. Write and benchmark4. Modify the implementation5. 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
メモリに保持しているデータを JSON にシリアライズして返すだけの単純な API なので、runtimeや net/http が支配的で、問題になりそうな部分は見当たりませんでした。
これが ISUCON の参考実装であれば、明確に遅い部分が見つかると思うので、今後試していきたいです。
終わりに
僕は Go をほとんど独学で勉強してきましたが、Go Conference はまだ知らないことを知るとても良い機会でした。 日本で一番大きな Go に関するカンファレンスということもあり、レベルの高い話が多く、Gopher なら絶対に行くべきイベントだと思います。
来年は自分が登壇する側に回れるように頑張りたいです 💪
最後になりますが、このような機会を設けてくださった Wantedly さん本当にありがとうございました！
おまけ
メルカリのスカラシップで来ていた人のうち、2 人が元から Twitter の FF でした。世間は狭いですね。
おわり