作って理解するGOCACHEPROG / Go Conference 2025(Workshop)

Go 1.24でリリースされたGoコマンドの機能にGOCACHEPROGがあります。
この機能を利用することでGoのコンパイル時のキャッシュを自作プログラムでカスタマイズでき、端末を跨いでキャッシュを共有することなどが可能になります。
一方で、GOCACHEPROGバックエンドの実装は愚直な実装ではオーバーヘッドが大きく、場合によってはキャッシュが存在しない場合よりもコンパイルが多くなってしまうことすらあります。
本ワークショップでは、実際にGOCACHEPROGバックエンド実装を行うことでGOCACHEPROGについて理解を深めます。そして、オーバーヘッドを減らすために必要な工夫を議論・理解することで、実用に耐えるGOCACHEPROGバックエンド実装を行うことができるようになります。

Transcript

1. 作って理解するGOCACHEPROG Go Conference 2025 @mazrean
2. mazrean ▪ Goでツール等を作っている • DIツールKessoku • GOCACHEPROG実装GoCICa ▪ SRE @DeNA @mazrean22 マズリーン 2
3. mazrean ▪ Goでツール等を作っている • DIツールKessoku • GOCACHEPROG実装GoCICa ▪ SRE @DeNA @mazrean22 マズリーン 3 今日はこの話
4. go buildしたことある 🙋
5. GOCACHEPROG知っている🙋
6. ビルドキャッシュ Goのコンパイル時にはキャッシュが存在する ▪ ディスク上に保存 ▪ 1ビルドで数千個キャッシュが作成・利用 6
7. GOCACHEPROG ビルドキャッシュをカスタムできる環境変数(1.24~) ▪ go build時、指定パスの実行ファイル起動 ▪ キャッシュread/writeのリクエストがくる • 通信はjson+base64の独自形式 7 GOCACHEPROG=./my-cache-prog
8. GOCACHEPROGによるキャッシュ共有 マシン間でのキャッシュ共有 が可能 ▪ 外部ストレージ にキャッシュ保存 ▪ ディスク上になければ外部ストレージ参照 8
9. GOCACHEPROGによるキャッシュ共有 マシン間でのキャッシュ共有 が可能 ▪ 外部ストレージ にキャッシュ保存 ▪ ディスク上になければ外部ストレージ参照 9 これを作る
10. 実装物詳細 ▪ キャッシュ保存部分 を実装していく • リクエスト処理部分は実装済み ▪ S3互換ストレージ を使用 • 運営側で準備済み 10 ここを作る
11. 全体の流れ 1. ディスクの利用 2. S3互換ストレージの利用 3. 高速化方法の検討 11
12. Step 1: ディスクの利用 ▪ ディスクへのキャッシュ保存・取得を実装 ▪ 最低限のGOCACHEPROG実装が動作 12 Step 1
13. Step 2: S3互換ストレージの利用 ▪ S3へのキャッシュ保存・取得を実装 ▪ マシン間のキャッシュ共有が可能になる 13 Step 2
14. Step 3: 高速化方法の検討 ここまでの実装は実行速度が非常に遅い → 計測結果をもとに高速化の方法を議論 14 Step 3
15. 15 自己紹介 (名前・所属・Go歴・好きな標準package) アイスブレイク(5分)
16. 目次 1. ディスクの利用 2. S3互換ストレージの利用 3. 高速化方法の検討 16 Step 1
17. ActionとOutput goコマンドでのキャッシュ管理の概念 ▪ Action: コンパイルの段階 • 各パッケージのコンパイルなど • Actionごとにキャッシュ ▪ Output: Actionの成果物 • パッケージのコンパイル結果など • キャッシュの実体データとなる 17
18. Get・Putの入出力 ▪ Get(取得): ActionをもとにOutputを取得 • 入力: ActionID • 出力: Outputの保存ファイル ▪ Put(保存): Actionに対応するOutputを保存 • 入力: ActionID、Output • 出力: Outputの保存ファイルなど 18
19. データの保存方法 2種類のデータを保存 ▪ メタデータ: Actionに関する情報 • ActionIDでファイル名決定( {{ActionID}}-a.json ) • 中身はActionに紐づくOutputのIDなど • 今回はjsonで保存 ▪ キャッシュデータ: Outputの本体データ • OutputIDでファイル名決定( {{OutputID}}-d ) • 中身はキャッシュデータ本体 19
20. Getの処理の流れ 20
21. 実装箇所 cacheprog.go の2関数を実装 21
22. 実装してみよう！ リポジトリのstep 1説明を見て実装する 1. PutHandler 実装 2. GetHandler 実装 3. 動作確認 4. 発展1:リクエスト・レスポンスを見る 5. 発展2: リクエストのパースの処理を読む 22
23. 23 The Power of PowerPoint - thepopp.com 15:30まで Step 1実装
24. 目次 1. ディスクの利用 2. S3互換ストレージの利用 3. 高速化方法の検討 24 Step 2
25. 実装してみよう！ 変更内容はシンプル(簡単とは言っていない) ▪ Put: S3にも2種類のファイルを保存 ▪ Get: S3にフォールバック 25
26. Getの処理の流れ 26
27. やること リポジトリのstep 2説明を見て実装する 1. PutHandler 実装 2. GetHandler 実装 3. 動作確認 4. 発展1: 実行時間を比較する 5. 発展2: 速度のボトルネックを調査する 27
28. 28 The Power of PowerPoint - thepopp.com 15:55まで Step 2実装
29. 目次 1. ディスクの利用 2. S3互換ストレージの利用 3. 高速化方法の検討 29 Step 3
30. Step 2の実装は遅い キャッシュなし の通常ビルドより遅い ▪ キャッシュを使う意味がない → 高速化が必須 30 GOCACHEPROGなし(キャッシュなし ) GOCACHEPROGあり(ディスク上キャッシュ有り )
31. 推測するな、計測せよ 計測してボトルネックを見つける 1. ハードウェア のリソースは足りているか？ 2. ロジック的に詰まる要素はないか？ 31
32. ハードウェアのリソースは足りているか？ OSごとのプロセス監視ツールで確認 32 CPU メモリ ネットワーク ディスクI/O
33. ロジック的に詰まる要素はないか？ ▪ go標準の計測ツールで計測 • pprof の mutex ▪ 計測を自分で仕込む • 今回で言うと request.txt 33
34. やること 1. 個人での調査: 5分 • ハードウェアリソース足りているか？ • 内部的に詰まっている箇所はないか？ 2. ボトルネック議論: 5分 • 1人1分弱で思ったことを1人ずつ言っていく • ボトルネックを1つに絞り込む 3. 改善案議論: 5分 • 2. で見つけたボトルネックの解決策を議論する 34
35. 35 The Power of PowerPoint - thepopp.com 16:15まで Step 3作業
36. ボトルネック go buildからのリクエスト数 がボトルネック ▪ 同時に$GOMAXPROCS個のみ • request.txt の動きが不自然 ▪ 歴史的経緯でこのようになっている • GOCACHEPROG以前はCPUが処理のネック • コア数以上の並列数があっても意味がない 36
37. 解決策 ▪ $GOMAXPROCSを大きくする • 簡単 • 代わりにCPUの効率低下 ▪ リクエスト の先読み • おすすめ • 実装はかなり大変 37
38. 解決策: 先読みdownload Get順序はPush順序を元に予測可能 → バックグラウンド で先にダウンロード 1. キャッシュの有無をロード 2. Push順序の早いものからダウンロード • hitなら、完了までリクエスト返答待機 • missなら即時に返答 38
39. さらなる高速化 ネットワーク・S3周りが詰まる ▪ ネットワーク使用量削減 • zstd圧縮 ▪ S3の認証削減 • 単一オブジェクト化 39
40. まとめ ▪ GOCACHEPROGの実装は大変 • 正直、コスパは最悪 ▪ でも、面白い • ツール開発のISUCON 40
41. GoCICa GitHub Actions用のGOCACHEPROG実装 ▪ 自分では作りたくない人にはお勧め 41 https://github.com/gocica-go/gocica
42. アンケート ご協力よろしくお願いします！ 42 https://forms.gle/sRnqAYCD7LxoqrSW8