builderscon1 日目に行ってきたので、忘れる前に参加レポートです。 builderscon は弊社からもスポンサーをしており、その招待チケットを頂いたので builderscon に行くことにしました。
builderscon は**「知らなかった、を聞く」**をテーマとした技術を愛する全てのギーク達のお祭りです。
builderscon の発表は最大 5 並列で行われ、ジャンルは組み込み系から Web フロントエンドまで様々です。 今年は（今年も？）ゲストスピーカーが豪華で Netflix や Lyft のエンジニアなども招待されてました。 1 日目の全体的な所感として、Kubernetes やマイクロサービスなどのモダンなインフラの話が熱い印象で、人が入り切らず途中で締め切るセッションも続出しました。
builderscon の参加は初めてだったのですが、一言で表現すると最高でした。 以下、自分が参加したセッションと簡単な感想を述べてゆきたいと思います。
Envoy internals deep dive
まず 1 発目はmattklein123氏による発表でした。
この発表は Lyft がどのようにしてマイクロサービスを構築して、なぜ Envoy の開発に至ったかという話に始まりました。 そしてタイトルにもあるように、Envoy の内部アーキテクチャや設計についても踏み込みました。
Lyft がマイクロサービスを構築したとき、いろいろな問題が発生しました。 サービス間のリトライ・タイムアウト処理が一部しか適用できてなかったり、可観測性の低下などです。 それらを統一するためのライブラリを作るには、各サービスで利用してる言語やフレームワーク、プロトコル毎に実装する必要もあります。 そこでライブラリではなくプロキシとして、Envoy を開発・導入しました。 Envoy の設計でRead-copy-updateやThread-local storageをどのように使ってるかや、スケールするスレッドモデルの紹介がありました。
Envoy の名前は知ってたのですが、その必要があった背景などを知って、マイクロサービスで発生する課題も知ることができました。 余談ですが、この発表が終わった後ちょこっと Envoy のコードを除いてみたのですが、非常にキレイに書かれている印象でした。 また暇があればコードを追ってみたいと思います。
Building and operating a service mesh at mid-size company
2 つめはtaiki45氏による発表でした。
このお話は Cookpad がどのようにサービスメッシュを構築したのかというお話と、Envoy の導入事例です。 1 本目の発表でもあったとおり、マイクロサービスでは言語毎にライブラリを提供するのは大変です。 そのため Cookpad でも Envoy を導入しました。
Cookpad ではサービスメッシュ全体の適用を更新するために、開発者は生の Envoy の設定ではなく容易なシンタックスで記述します。 それを GitHub Enterprise に Push すると、CI が Envoy の設定に変換して適用します。 Envoy とそのデプロイシステムを構築することで、簡易なトラブルシュートや素早いデプロイが可能になったそうです。
極限まで自動化して開発効率を上げたり、新しいことにチャレンジする姿勢は Cookpad らしくてワクワクしました。 今後のインフラの進化にも期待です。
事前知識なしで理解する、静的検査のいろは
3 本目はKuniwak氏の発表でした。
この発表はソースコードの静的解析はどのように動作してるかのお話でした。 実際 Kuniwak さんは、静的検査を使って、コードレビューのコストを減らしたり、モジュール間の依存関係を可視化したりと、実業務でも有効に活用してるそうです。 今回の説明では抽象構文木を再帰下降法をどのように設計・実装するかのお話でした。
構文解析の知識自体は学生時代に履修してたのですが、スライドもキレイで非常に分かりやすかったです。 またこの話を聞きながら「業務でもおんなじ観点でレビューすることが何回もあるなー」と思って聞いてました。 Go や Python ではすでに標準ライブラリに構文解析器があるので、暇があったら遊んでみたいと思います。
イノベーションを止めずに、端末管理と運用を行う方法
4 本目はkenchan0130氏による発表でした。
この発表では、社内のコンピューターや携帯端末をどのように管理すればよいかというプラクティス集でした。 Mac OS や Windows、そして iOS と Android の端末を、ユーザー（従業員）が快適かつ安全に利用できる管理体制と仕組みづくりのお話でした。
普段自分が快適に開発を進めれるのも、自分の知らないところで情シスが環境を整備してくれてるからだろうなーと思いました。 また従業員が増えても大丈夫なようにスケールする管理方法を模索してるのが、インフラ管理と似ているなーと思いながら聞いてました。
Web サービスの品質とは何か？アラート地獄と監視の失敗、サービスレベル目標設計から学んだ 3 つの答え
5 つめは Takuya Onda 氏による、アラートにまつわるお話です。
eureka ではアラートをアラートであるために、つまり「本当の異常事態」を知らせるものにするために、システムと運用方針を変えました。 そのためにアラートの対象は本当にアクションが必要なものを対象とし、即座に対応が可能なアーキテクチャも構築しました。 また管理を楽にするために、AWS のマネージドサービスをフルに活用して、複数環境の構成も同じ技術スタックで統一しました。
健全なアラートが開発・運用者だけでなく組織としても必要だというのが印象的でした。 また全体的に AWS を前提としたアーキテクチャでしたが、オンプレミスなデータセンターでもすぐに代替の計算資源が確保できるのが良いのかなと思いました。
lld − 開発ツールの主要コンポーネントの 1 つをスクラッチから作成した話
1 日目最後はrui314さんが、LLVM のリンカ実装である LLD を書き直したという話です。
以前の LLD の実装は複数のプラットフォーム対応のためにコードの共有化をしており、それがパフォーマンスやメンテナンス性に影響してました。 リライトの結果として GNU Gold というリンカ実装よりも、少ないコード量で高いパフォーマンスを実現できました。 リライトするかどうかメーリングリストでは賛否両論だったそうですが、リライトしてパフォーマンスやメンテナンス性が向上したことで新しいメンテナが増えたそうです。
LLD に限らず、全体的にソフトウェアエンジニアとしてためになる話でした。 レガシーソフトウェア改善ガイドではソフトウェアのリライトはデメリットが大きいとありましたが、LLD はその例外だったようです。 自分もソフトウェアをリライトしたいと思うことは度々ありますが、それによって何が得られるかなどを考えて手を打とうと思います。
1 日目まとめ
まだ 1 日目ですが、どのセッションも面白い内容ばかりでした。 聞きたいセッションもパラレルに開催されていて、全部聞けなかったのが残念ですが、体は 1 つなので仕方がないですね。 明日も聞きたい発表がいっぱいあるので楽しみにしてます！