golang.tokyo #44
- Goコミュニティの技術談義
- 今回はアンドパッド/GROWTH VERSE主催
- イベントURL
#1 Otel collector から学ぶ Plugin システムの実装
ラクス 竹田さん
OSSのOtel collector(OpenTelemetry Collector)について
- GoのOSS
- テレメトリデータの受信処理エクスポート
- 拡張性が売り
調べたきっかけ
- プラグインの実装方法
- カスタムコレクターが必要になった
拡張性
- 設定ファイルにコンポーネントを記載
- 自分のカスタムコンポーネントを選択可能
→ OCB(OpenTelemetry Collector Builder)とGo buildで実現
OCB
- 独自のコレクターを作るツール
- メモ https://zenn.dev/k6s4i53rx/articles/df59cb65b34ef8
- コード生成とGo Modulesを中核に構成
カスタムコレクター作成
- yamlにOCBの設定を書く
- OCB実行でgoのファイル一式ができる
- 必要な条件要素を書いてビルドする→完成
学べること
- 事前ビルドと配布による安全性
- コア部分のシンプルさ
- 動的な読み込みがない
- メモ
- fluentdとOpenTelemetry
- どちらも可観測性のOSS
- fluentdはログに特化
- より軽量なfluent Bit
- OpenTelemetryはトレース・メトリクス・ログ全て
- fluentdとOpenTelemetry
#2 Go でデータパイプラインを作ろう
uesmさん
- Sansanのサーバーサイド
- データ基盤の構築
ビッグデータを扱うパイプライン
- Apache Spark・Flinkなどなど
- javaやPythonが主流
- Goは少ない
Goで作りたい!
ApacheBeam
- 並列データ処理タイムラインを定義するためのオープンソースの統合モデル
- GoogleのDataflowがベース
- GoのSDKがある
- 同じパイプライン定義を様々な分散処理バックエンドで実行できる
SanSan Data intelligenceのマスターデータ構築で採用
- 企業の取引先データを最新正確に整えるデータ品質管理サービス
- 1000万件のデータ
- ApacheBeam
GCSからBQまでの流れ
運用としてどうか?
- ドメインコードをサービスとパイプランで共有化
- cgoでCライブラリ依存のコードも共通資産として使える
- パフォーマンスが必要な住所正規化の共通ライブラリ
- ローカルでテストできる
注意点
- 一分機能が未サポート
- どれもデータを分散処理するオープンソースのフレームワーク
- ApacheSpark
- 大規模バッチ・機械学習が得意
- ApacheFlink
- リアルタイム処理・低遅延処理が得意(イベント処理)
- ApacheBeam
- データ処理の書き方、記述モデル。パイプラインの共通化
- 実行エンジンにSparkやFlinkを使うこともある
#3 Goの形式検証ツール Gobra に decimal を検証させてみた!
太宰さん(warashi)
- finatext
- 証券ビジネスプラットフォーム
テストケースの網羅性や重複を気にしないようにしたい
- Go自動コード検証ツール
- あらゆる入力でなりたつか検証する
- 参考 golang.tokyo#33 Goのコードを数学的に証明する
題材
- 固定小数点 decimal
- 金融系の金額計算に必要
実装で有界のintと、意味としては溢れない整数としたい
Gobraにinteger型
- ゴースト専用の数学的整数
実装を仕様に結びつける
桁揃えていないのに証明が通るケース
オーバーフロー検査が既定では無効
Gobraの保証
- 実装が書いた仕様を満たしていること
- その仕様が欲しい性質を表しているかはわからない
- AIに書かせるためにも仕様を正しく書くことが大事
#4 Go 1.27 における memory allocation の高速化
Andpadのインターン unagam
東京科学大学M2
Go1.27でメモリ割り当てが高速化した
ヒープ割り当てが30%ほど早くなった
なぜ速くなったのか?
事前知識
- メモリの保存領域
- スタック
- 定義された関数内
- ヒープ
- 定義された関数が終わっても残る
- スタック
- メモリの保存領域
以後ヒープの話
メモリ割り当て:値は種類に応じて格納
- ランタイムでサイズを事前に設定
- 値のサイズを切り上げ
- 値のポインタ有無
- 区画に格納
従来
- メモリ格納前の判別作業のコストが重い
構造体定義から事前にわかるのでは?→コンパイラが担当すればよい
従来のコンパイル呼び出し→1.27のコンパイル呼び出し
コンパイル時点でサイズ特化関数を呼び出す!
80B以下に限定されている、なぜか?
- 同じ手順で高速化できそう
- 当初は512B
理由:メリットよりデメリットが大きくなる
- サイズが大きいと効果が小さい
- CPUキャッシュ圧迫によるアプリ全体に影響
- ベンチマーク結果をもとにサイズを変更した(はず)
- 公開スライドにconfidentialつけといていいのだろうか?
- 雛形の消し忘れだと思うが
#5 進化を続けるGo toolsの現在地
hond ほんでぃ
GROWTH VERSE
AI プロダクト
- AIマーケティング、電話など
AIが書くGo
- ちょっと情報が古い
- カットオフ
Go言語のTeamも認識
- AIが使いやすいようにしていきたい
GoのエコシステムがAIに寄っていっている
- gopls のMCP
- go fixの刷新
- pkg.go.dev API v1betaの公開←ここについて
pkg.go.dev
- Goの公式パッケージドキュメントサイト
- パッケージ情報について知りたいことが書いてある
pkg.go.dev API
- GETのエンドポイント
- OpenAPI仕様も公開
要望は2020年頃からあった→スクレイピングをやめたい
最近MCP専用Issueが開始して実装
AIとLLMインテグレーション
- 事前埋め込みでなく、JustInTimeで
利便性より正確性
- 曖昧なパッケージパスを勝手に解決しない
- APIは複数マッチするような時、候補と一覧を返すように
周辺ツールも強化 go fixなど
覚えさせず、問い合わせる
APIはまだv1beta
全体感想
- 質疑の時間がなかったが全体的に興味深いテーマで良かった
- 時間があるときにはオフラインの勉強会も参加していきたい