Go Conference 2018 Autumn に参加してきました。
だいぶ時間が経ってしまいましたが、Go Conference 2018 Autumnに参加してきましたので簡単にまとめておきたいと思います。
自分は普段Javaでコードを書くことが多いのですが、DockerやKubernetesといったプロダクトでもGoが採用されていたり、実際に触ってみると言語仕様が小さかったり、クロスプラットホームな実行バイナリが簡単に生成できたりで非常に使い心地がいいなと思っていました。
実際にプロダクション環境で利用されている方たちの話を聞いてみたいと思い今回参加させて頂いたわけですが、Goだけではなくてパフォーマンスチューニングの話だったり、gVisorといったコンテナランタイムだったり、マイクロカーネルの実装だったり盛り沢山で非常にエンジニア意識を高めてくれる最高のカンファレンスでした！！
このような素晴らしいカンファレンスを開催していただいた関係者の皆様には感謝の念しかありません。本当にありがとうございました！！（遅い）
以下は簡単なメモと感想です。参考になれば幸いです。
Keynote
Google App EngineのGo Runtimeのメンテナの方のセッションでした。 英語でのセッションだったのでほとんど理解できなかったのですが、gVisorのことを話していたのでドキュメント読んでたりしてました。
gVisorはユーザー空間のカーネル的な位置づけのソフトウェアであり、アプリケーションから発行されたシステムコールをキャッチしてゲストOSであるかのように振る舞うが、すべてのシステムコールを実装しているわけではないそうなので一部実行できないシステムコールもあるとのこと。
このセッションをきっかけにコンテナのランタイムについて非常に興味を持ったのでもう少し詳しく調べていけたらなと思いました。 また、英語でのセッションにもついていけるようにせめて何を言っているかわかるぐらいにはリスニング力もつけたいなと。
Microservices実装ガイド in Go at Mercari
メルカリさんでのマイクロサービスの実装のお話でした。
実装の流れとしては、Protocol Buffersの定義をしてから、サービスの実装をするという流れらしく、プロトコルファイルは専用のリポジトリで管理し、また、マイクロサービスの実装に必要なテンプレートプロジェクトを準備しており、git clone -> rm -rf .git -> git init -> 実装 という開発の流れがある程度決まっているとのこと。
開発者からしてみたらあるサービスの実装を始める時に何も考えずにプロジェクトテンプレートを持ってきて、インターフェースを考えて実装するという流れが決まっているのはやりやすいだろうなと思いました。
OpenCensusによるAPMの実現と、未来
OpenCensusを利用したアプリケーションパフォーマンスの可視化についてのお話でした。
APMとはApplication Performance Managerment の略で、要求されるサービスレベルを維持するためにパフォーマンスの継続的な監視と管理を行うことで、そのためにはデータの収集と可視化する基盤を構築する必要があるとのこと。
APMで取り扱うデータは大きく分けて以下の4つ。
- Tracing
- Metrics
- Logging
- Error Report
これらのデータを収集する際にはアプリケーションコードに収集用のコードを記述しなければならないが、その際に収集・可視化するバックエンドのサービスと密結合になってしまうということを懸念し、OpenCensusを利用する方針をとった。
この話を聞いていてアプリケーションのパフォーマンスの可視化に対するアプローチは大きく分けて2つあるかなと考えていました。
一つはOpenCensusといったコードにデータを収集するコードを書いてバックエンドに送信する方法。
もう一つはエージェントといったデータ収集用のデーモンを利用する方法。（APPDYNAMICSみたいな）
どちらもアプリケーションパフォーマンスを可視化するという目的は一緒なのだけど、採用する組織の目的や文化によってどちらのアプローチを取るか変わってくるだろうなとも思った。また、CNCFといった中でココらへんの実装も増えてきて、選択できるバリエーションが豊富になってくると思うので、目的にあった技術選択ができるようになっておきたいという思いも強くなりました。
アプリケーションとバックエンドサービスの密結合を避けるという観点は自分の中にはなかった発想だったので、そういう気づきを得られたのも非常に良かったです。
Profiling Go Application
自前で実装した画像変換サーバやkubelet、go-swaggerに対してパフォーマンス改善を行った結果やそのプロセスに関するお話でした。
プロファイルを取得し、処理のボトルネックを発見し、コードの修正前後でベンチマークを取得し改善結果を把握するという当たり前のことを当たり前にやることの重要性を再度認識させられたセッションでした。
言葉にしてしまうと簡単そうに思えてしまいますが、プロファイルやベンチ結果といったデータを見てどのように判断するかはプログラマのスキルに依りますし、また、ボトルネックの箇所の特定にしたって、場所を特定してもその実装を見てどこがネックになっているかを判断するのもプログラマのスキルだと思います。
そういった意味で非常に学びのあるセッションでしたし、自分も見習っていこうと思いました。
Reading Source Code of Biscuit
Goで実装されたモノリシックカーネルであるBiscuitのソースコードを読んでみようという内容のセッションでした。 DockerやKubernetesといったプロダクトもGoで書かれていますが、まさかカーネルまで実装されているとは驚きでした。
いきなりLinuxのソースコードを読むのも良いかもしれませんが、カーネルの挙動を理解するためにまずこのBiscuitのコードから読んで見る、というのも良いかなと。
フィードバック制御によるGoroutine起動数の最適化
自分の中の知識が足りずにあまり理論や実装についてはついていけなかったのですが、フィードバックループを回すことにより設定値を最適化していくという考え方は非常に良いなと思っていて、どうにか応用できないかなと考えながら聞いていました。
自律的なシステム=人間の手が入らずともその時その時のシステムの状況を学習することで最適な状態に落ち着くことができるシステム、というのがあれば人間の運用負荷が下がるなとなんとなく考えていて、それにフィードバック制御が利用できるのではないかと。
ただ考えているだけなので、モノクロメガネさんの実装だったり論文だったりもう少し踏むこんで調べていきたいなと思います。
最後に
こういったカンファレンスに参加することの良さって、自分が普段所属する会社だったりコミュニティだったりから離れてみて、また別の視点を得られることだなと参加してみて思いました。自分や会社が抱えている課題に対してこうやって解決しているからそれを応用できないかとか、初めて触れる概念を応用することができないかとか。
だいぶ長くなってしまいましたが、めっちゃ楽しかったのでまた来年行こうと思います。ありがとうございました！！
