六本木にて開催されたGo Conference 2018 Autumnに参加してきました
was updated last. 2 months ago
Go Conference 2018 Autumnに参加しました

六本木で開催されたGo Conference 2018 Autumnに参加してきました。
今回参加は初めてでしたが、コミュニティの仲間も多く参加していたので、謎の安心感に溢れてました。

セッションについて

セッションは複数のルームに分かれて並列で行われた為、私はRoomAに留まっていました。
例の如く全てのセッション内容を綺麗に纏められなかったので、いくつか興味のあったセッションについて書きます。

1. Microservices実装ガイド in Go at Mercari

メルカリさんのGoで実装されたマイクロサービスがどのように成り立っているかの話でした。
Protocol Buffersと呼ばれるスキーマ言語でgRPCインタフェースを定義しているとの事。

色々定義を書いてpushしてCIが動くと、言語ごとの環境構築が立ち上がって後は実装するだけの状態になる、すごい・・!
サービスのユーザーはprotoファイルを読むだけでAPIインタフェースを知る事ができる

echoと呼ばれているマイクロサービス開発に必要な機能を備えている何かがある。
ロギング周り等の機能を持っていて、開発者はその恩恵を受けることができるようになっている。

メルカリさんならではというか、たくさんのエンジニアがチームとして集まり、
マイクロサービスによって開発フローを回していく考えられた体制が感じられました。

2. よくあるJava IT企業で新規プロジェクトをGoで立ち上げてみてる話

いつもお世話になっているメディアドゥさんのスポンサーセッションでした。
Javaを使い続けている大企業で、新規のプロジェクトでGo言語を採用して、軌道に乗せていく話が聞けました!

構文がシンプルなGo言語でこその、学習コストの低さや普通にプログラミングができるようになるまでのハードルの低さを感じました。
メディアドゥさんの社内勉強会(TechDo)では、私も外部講師としてお手伝いをさせて貰っています。

3. Profiling Go Application

スライドはコチラ

説明がものすごくスムーズで着いていくのが精一杯でした><
意外と普段使いまくっているツールやライブラリが完璧なパフォーマンスを出せている訳ではないというところに気づきがありました。

スライスの範囲チェックではBCEによって不要な範囲チェックは消える事を利用して、処理の高速化を測った。
ちゃんとベンチマークを取ることで、速度の改善前と後で比較して速くなっている事を確認するべき。

必要のないチューニングはしなくていい、必要になったらチューニングすれば良い。
いつ必要になるかはわからないから、チューニングができる環境は整えておきましょう。

4. Reading Source code of Biscuit (GO OS)

スライドはコチラ

凄い!go本体のソースコードをそのままコピーで取り込んでいて、実装されているオペレーティングシステム。

https://github.com/mit-pdos/biscuit

使ってみたくてmakeしてみたのだけど、起動ができずに諦めた、、デモ見たかったなー

5. フィードバック制御によるGoroutine起動数の最適化

タイトルで凄く楽しみだったのですが、聞いてみると少しだけ思っていた話と違いました。
内容には着いていくのがやっとな発表内容でしたが、Elastic-Channelsは凄いと思った!

バッファの容量変えようなんて思ったこともなかったまる

https://github.com/npat-efault/musings/wiki/Elastic-channels

6. Practical Go Concurrency Design Patterns

最後に聞いたセッションでした。
一番聞きたかったセッションでもあり、せっかくなのでメモの内容を全て残します。
(メモが長すぎて纏めるのが大変!)

とにかくわかりやすくて、最高でした。
最後に少し触れられたブロードキャストの実装は個人的にもタイムリーな話で興奮しました。

  • goの並行処理をどう実践的にするか?

  • 基礎的な内容

  • process

  • ある操作の集合体

    • 操作だけではなく制御のためのシーケンス
    • コントロールシーケンス
  • 他のプロセスによって開始される(一番最初のプロセス以外)

  • mainゴルーチン

  • 他のプロセスと関係なく独立して同時並行的に動く

  • Resources

    • 構造体の中の変数だったりとか
    • OS上のフィアルシステムの中の何かを表す
  • Race Conditions

    • 複数のプロセスが同時に同じリソースにアクセスしたとき
    • ロックによって解決される
    • 同じタイミングでリソースにアクセスされる事を防ぐ
  • Locks

    • シリアライズとは?
      • 重なってしまうかもしれなかった操作を重ならないようにする(直列に並べる)
    • cont’d
      • ロックされているかされていないかの2通り
      • あるプロセスがロックしているなら他のプロセスはロックを取得できないようにする
      • sync.Mutexによってロックを実現できる
        • sync.Mutexが他の言語と違う点が1つある
          • ロックの所有権を表すsync.Mutex
          • 普通はロックを取得したスレッドでないとアンロックはできないようになっている
          • ロックを取得したゴルーチンでない別のゴルーチンでもアンロックすることができる
    • Counting Semaphore
      • signal/wait
    • Producer-Consumer Problem
      • バッファがいっぱいだったら、送信側はブロックしてほしい
      • バッファが空だったら、受信側はブロックしてほしい
      • Go: Just use channels -> Goのチャネルがどのように実装されているかwikiを見よう
    • Reader-Writer Problem
      • Writerがリソースを変更しようとしているとき、Readerが触れないようにしてほしい
      • Writerがリソースを変更しようとしているとき、Writerが触れないようにしてほしい
      • Readerが多すぎる問題
        • 全てのReaderの制御にロック制御が入ってしまう問題(本来やる必要はないロック)
      • Go: Just use sync.RWMutex
    • Monitors and Condition Variables
      • 状態の変化を伝えたい
        • wait, signal, broadcast
      • Mesa semantics
        • シグナルが通知されてから、処理が起きている間も、次の通知が来る可能性がある
      • Hoare semantics
        • シグナルが通知されてから、処理が起きている間、次の通知が来ないことが保証されている
        • 実装的にはこっちのほうが複雑になる・・?
      • select/defaultを組み合わせて使うこと
      • ブロードキャストはcloseを使っている
        • closeすると全てのチャネルが起きて、0値を返す
        • 構造体を用意して、チャネルを同梱する
  • Use synchronization primitives / constructs

    • sync.*を使う
    • アービトラージゴルーチン is nazo?
    • 構造体にsync.Mutexを同梱する方法
  • Acces to a shared variable

    • 共有変数のアクセスへの排他制御?
    • v1,v2という変数に対して取得とセットする操作がある
    • それぞれに対応するチャネルを用意する(v1setchan, v1getchan)
  • 並行処理には選択肢があるので、それらをちゃんと理解して最適な選択をするべき

まとめ

今回、残念ながらCfPは落選してしまい登壇のチャンスには恵まれなかったのですが、
募集の当日に駅で電車を待ちながら手に入れた先着枠(1分くらいで埋まった気がする)で参加できて本当に良かったと思いました。

来年は登壇できるようにがんばろうー

GoのマスコットのGopherの原作者はRenee Frenchさんです。
Gopherのイラストはtenntennによるものです。