Go Conference 2024 参加レポート

2024-06-09

Go Conference 2024

6/8にGo Conference 2024に行ってきたのでレポート(というかメモ)

今年はサイバーエージェントさんのAbema Towerでオフライン開催でした。
昨年のGo Conferenceが自分の初参加だったのですが、その時にはオンラインでした。
オフラインどんな感じなんだろうな〜ととても楽しみにしていたので来れてよかったです。

撮影スポット

名札。名前やプロフィール画像だけでなく、お気に入りのGoパッケージも表明できる。

スポンサーブース

受付の近くにスポンサーブースが設置されており、ブースに寄ってスタンプを5個集められれば景品がもらえます。
私はセッションを聞くのに必死だったので、everyさんのブースしか寄れませんでした…
セッションとスポンサーブースが同じフロアにあるとありがたいかなと思いましたが、会場の事情もあったとは思います。

スタンプ用紙とeveryさんのブースでもらったコーヒー。

いれたコーヒー。美味しかったが入れるお湯が多かったようで、味が薄くなってしまった。

イテレータによってGoはどう変わるのか(tenntenn)

途中から聞いていた
プレゼン資料が手元でもリアルタイムで見れるのでいい感じでした
- 自分が発表する時も使ってみたい
  https://x.com/penpen_77777/status/1799259998595490263
Go1.23で導入されるイテレータ中心の話
イテレータでインタフェースを定義する形にすると、channelとかの後方互換性を考える必要が出てくる
- 後方互換性を気にしながら言語を開発するの大変
イテレータのユースケース
- データ構造へのアクセス
- 一連の処理の結果をまとめる
- Rustでイテレータを使っていてこの辺り便利だと感じるので、是非導入されてほしい
エラーツリー
- errors.Join
- splitができないのが不満
- errors.Asは深さ優先探索して調べて、はじめに見つかったエラーだけ返す
- AllAsで全て引っ張れる
- エラーツリーについてちゃんと学んでいかなければ

転職ドラフトのデータから見るGoトレンド

リブセンスさん
- 転職ドラフトなど様々なサービスを展開されている企業さん
プロダクト
- 転職会議
- batonn(Go)
  - バックエンド(swaggerなど)・映像処理(ffmpegによる変換)
- knew
- 転職ドラフト
Goの採用事例
- 画像プロキシサーバーfanlin
- SaaS移行でURL変更に対応するためのリダイレクトツール
- Q by Livevsense
転職ドラフトから見たGoの転職状況
- 1970年から使っている人がいる(？)
- Goのプロジェクトを持つユーザーは600→700万に上昇
- コンテナ
  - Dockerが圧倒的に強い
  - k8sとterraformは同じくらいだがterraformの方が若干優勢
- フレームワーク
  - echo→ginに逆転
- goを求める企業
  - 2016年から上昇(ピークは約300社)
GopherとGoを求める企業はたくさんいる
- 安心してGoをやっていこう

Dive into gomock

gomockは業務で扱ったことがあったので、知見を深めることができたらいいなと思いながら参加
インターフェースの気持ち
さまざまモックする用のライブラリがある
どうやって実現されているか？
- source mode
  - 指定されたファイルのinterface定義を静的解析・モック実装を生成
  - 高速
  - 生成単位はファイル単位のみ
- reflect mode
  - パッケージのコンパイルが必要
  - 生成対象のinterfaceを柔軟に選択できる
  - 他ライブラリのインターフェースのモックも作れる
  - reflect modeは知りませんでした
mockgenが作るコードを覗いていこう
Matcher
- Matches 条件を調べる
- String 文字列表現かどうか
- 組み込み
  - Any　任意の引数を受理
  - nil nilを受理
  - Eq xに等しい引数を受理
  - All Matherの合成
  - AnyOf 引数のいずれかに一致するなら受理
  - Len 引数のlenが一致するなら受理する
  - Not xでないなら受理
  - Cond 関数に渡してtrueが帰るなら受理する
  - AssignedTypeOf 方
  - InAnyOrder 順番を気にせず受理
  - Regex 正規表現
- 引数をWrapしなければEqでラップされる
- 組み合わせれば柔軟にできる
- Matcherをラップする関数
  - WantFormatter
    - 期待する引数をフォーマットする
  - GotFormatterAdopterでWrapするのが簡単
  - 実装がテクいらしい
gomock.Controller(テストの中心)
EXPECTで何が起きているか
- RecordCallWithMethodType
  - スレッドセーフ
gomock.Call
- メソッド呼び出しそのものを表す型
- Times ちょうどn回
- AnyTimes 呼ばれなくても良い
- SetArg n番目の引数をvalueに代入する(渡された引数を別の場所で使える)
- After、InOrder 呼び出し順を定義できる
  - InOrderはAfterを順に呼び出している
時間内に理解し切るのは難しそうなので、後日資料と照らし合わせながらライブラリの中身を読んでいこうと思います

Go1.21から導入された Go Toolchainの仕組みをまるっと解説

toolchain追加
- toolchainって何だろう
Go 1.21より前のバージョンのGoを使用した場合
- 任意のバージョンのgoがコードをビルドしようとする
  - 古い場合はエラーが出る時がある
- ローカルにすでにインストールしているgoを使用する
  - go directiveが新しすぎてもできるだけ多くのコードをビルドできるようにするため
  - ビルドできるならビルドでき、できない場合はエラー
- go.modのgoディレクティブ周りの挙動の問題
期待
- go.modが直感に従った設定になる
- インストールされているgoのバージョンを意識する必要が薄れた
- forループの仕様変更を行うためにgo toolchainのリリースを前提とした
実現
- ローカルのバージョンが勝手に変わることはない
- 必要なバージョンを勝手にダウンロードしキャッシュ
  - カレントディレクトリを移動するだけでバージョンが自動的に変わる
使用例
- GOTOOLCHAIN環境変数でバージョン強制
- 2回目はキャッシュを使用
- $HOME/go/pkg/mod/golang.orgにダウンロードされたgoは保存されている
ディレクティブの挙動がどう違うのか気になった
- goディレクティブとtoolchainディレクティブ
- もうちょっと調べていきたい

Cleanup handling in go

motivate
- 適切な終了処理(=cleanup)
- 良いパターンを知ろう
「クリーンアップ」とは
どういう実装があるか？
- defer
  - スタック形式
- net/httpのRegisterOnShutdown(常にGraceful shutdownではない)
  - 登録した関数の実行の完了を待ってくれるわけではない
  - FIFOかつ並行実行
  - 実行完了を待たない
- Cleanup
  - deferとほぼ同じ
- context func AfterFunc
  - ctxが終了した時に登録した関数fを実行
  - stopが帰ってくる
  - exampleがあるので見てみよう
  - RegisterOnShutdownに近い
クリーンアップの手法
- パッケージ横断→context
  - アーキテクチャの破壊もしにくい
- 実行待ち
  - sync.waitgroup errgroup.Group
donegroupを作った
なかなか便利そうなので頭の中に入れておこうと思います

Goにconst型修飾を期待しなくて良い理由

不変性を求める声があるが、不変性にもいくつもレベルがあってそこからGoではなぜconst修飾がないかという話
- Rustの所有権周りでこの辺りの話をやったので、発表を聞きながらここってそういう意味だったのかという再発見があった

Unified Diff 形式の差分から Go AST を構築して feature flag を自動計装する

feature flagの良さがあまりよくわからなかったが、トランクベース開発をすれば理解できるようになるかな…
git diffの結果を使ってコードを自動的に書き換える手法は面白いなと思った

試してわかるGo ModulesとMinimal Version Selection

他の発表と異なり例題を示しながら進められていたので、とても理解しやすかった
Sem Verをきちんと管理するのは大事

Guide to Profile-Guided Optimization: inlining, devirtualining, and profiling

Profile-Guided Optimization(PGO)
- プロファイルを取得
- 最適化を進める
関数インライニング
- 呼び出している箇所を中身に置き換える
- 関数呼び出しのオーバーヘッドが不要
- 条件
  - leaf function
    - 中で他の関数を呼び出していない
  - small function
    - budgetが80未満であればok
  - 特定のタグがついていない、外部関数ではないなど
Devirtualization
- インターフェースメソッドの呼び出しを具体的な関数呼び出しにした
- goでは通常動的ディスパッチ
- 単なるメソッド呼び出しになるので、さらに最適化を進められる
- 条件
  - 具体的型が静的に定まる場合のみ
さらに最適化できないか？
- Profile-Guided Optimization
プロファイルの取得
- pprofフォーマットで表現
- DataDog
  - dd-trace-go/dog
- datadog-pgo
- apmから取るのは面倒
  - 30以上取りたい場合は…
pgoで色々いける
実行時間で比較してどれくらい高速化できたのかも気になりましたが、pgo自体をあまり知らなかったので見直してみようと思います

DELISH KITCHENにおけるマスタデータのキャッシュ戦略とその歴史的変遷

料理体験をよくする
基本機能の話
マスターデータはなるべく積極的かつ長期的にキャッシュしておきたい
1次キャッシュ戦略
- 全テーブル・全レコードをメモリに格納
- データ更新遅延を避けるため定期的に再読み込み処理
- 問題
  - キャッシュにデータがあるという前提
    - 管理ツールだと使いたくないとかだと処理を流用できない
  - テスト実装次にデータをキャッシュにもDBにも入れる
2次キャッシュ戦略
- 普通のキャッシュに立ち返りたい
- テーブル単位で実装→進捗が遅い
- 一気に切り替えると転送量の問題
- 仕事が単調で担当者が退職
次世代
- Hazelcast
  - インメモリデータベース
  - MySQL binlogによる同期機構
- リモートキャッシュ・ローカルキャッシュの多段構成
  - あまりうまく動かなかった
- Pyroscopeを用いた付加計測&地道な改善
- キャッシュ構築次にgocraft/dbr がCPUを消費している箇所があった
  - 実装をハードコード
  - Sync.poolを用いてオブジェクトの再利用
  - 全て置換したらCPU負荷が半減
第三次キャッシュ戦略
- Remote Cache Loader
- gzip圧縮
- 問題
  - 転送量が多い
    - N+1になっているが、オンメモリで問題なかった

運用管理ツールが大変
新規プロジェクト用のテンプレートリポジトリを構築する取り組み
- ライブラリ/FWだとメンテナンスが大変
意思決定はADRで管理

LTリレー

Making Sense of How Rangefunc Works: Just 1 Tip in 5 Minutes
- マーベルを知らなかったのでイマイチ例え話を理解できず…

大文字の表現を!で代替することで大文字小文字を無視するファイルシステムでの問題を回避
panic

Predeclared identifiers
- 主にdocumentation用途