課題の背景とコンテキスト
Go 1.26 のリリース告知では、ベースラインの cgo オーバーヘッドが約 30% 削減されたことや、コンパイラがスライスのバッキングストアをスタック上に配置するケースが増加したことが報告されています。この面接での質問はパーセンテージの暗記テストではなく、呼び出し頻度、メモリ所有権、エラー伝播、そして Go と C を跨ぐ再現可能な実験をどのように制御するかを評価するものです。
面接官が評価するポイント
- cgo の固定コスト、ならびにスレッド、スケジューラ、ポインタのルールを説明できるか。
- バッチ処理、長時間実行される C 呼び出し、またはデータレイアウトによって境界を跨ぐ回数を削減できるか。
- メモリ所有権、ライフタイム、並行性、キャンセルのセマンティクスを定義できるか。
- 単一の幸運な実行結果ではなく、ベンチマーク、プロファイル、本番メトリクスによって改善を証明できるか。
最初に明確にすべき質問
C の呼び出しが微小かつ頻繁なものなのか、長時間実行されるバッチなのか、データのサイズやフォーマットが安定しているか、コピーが許容されるか、そして C ライブラリがスレッドセーフであるかを確認します。また、対象プラットフォーム、コンパイラ、CGO_ENABLED、競合検出（race detector）、ロールバックの選択肢を明確にします。
30秒で答える要約
呼び出し形状を最適化する前に、境界とベースラインを定義します。微小で頻繁な呼び出しはバッチ化し、Go と C の所有権およびエラー変換を明確に規定し、長いタスクにはワーカーや長寿命のコンテキストを使用します。ベンチマークでは、代表的なハードウェアとフラグ上で Go 1.25 と 1.26 を比較しながら、エンドツーエンドのレイテンシ、スループット、メモリ割り当て、CPU、テールレイテンシを測定します。本番環境のカナリアリリースにより、コピーやロック競合によって成果が相殺されていないことを確認します。
ステップごとの詳細解説
1. FFI 境界の設計
Go のループ内で境界を跨ぐのではなく、C の機能をいくつかの粗粒度な関数にラップします。長さ情報付きバッファ、ハンドル、ステータスコードを渡し、Go ポインタを含む複雑なオブジェクトを C に直接渡さないようにします。長時間かかるタスクでは、Go が結果を待機またはポーリングする間、C のコンテキスト内にリソースを保持させることができます。
2. メモリとライフタイムの制御
誰がメモリを割り当てて解放するのか、また C 側がポインタを保持し続けることが許可されているかを定義します。コピーについてはバイト数と方向を記録し、ゼロコピー経路の場合はアライメント、読み取り専用の挙動、ライフタイムを検証します。エラー時も含め、C のすべての割り当てには対称となる解放パスが必要です。スライスに変換したからといって、言語間ポインタが安全になるわけではありません。
3. 並行性とキャンセルの設計
C のスレッドセーフ性とグローバルロックの有無を確認し、多数の goroutine が直列化された C のクリティカルセクションに集中しないようワーカー数を制限します。キャンセル処理は C API まで到達させる必要があります。ライブラリを中断できない場合は、タイムアウトとリソース制限を設けた回収可能なワーカーまたはプロセス境界内に呼び出しを分離します。
4. 証拠チェーンの構築
go test -bench を使用して入力とウォームアップの挙動を固定し、CPU、メモリ、ブロッキングプロファイルを用いて境界コストを特定します。同一のコンパイラ、リンカーフラグ、ハードウェアを用い、単一呼び出し、バッチ、エンドツーエンドのテスト全体で Go 1.25 と 1.26 を比較します。カナリアリリースでは、ロールバックスイッチを用意した上で、p95/p99、クラッシュ、C のエラー、割り当ての変化を監視します。
優れた回答例
約 30% という数値をそのままビジネス上の利益と同等とは見なしません。まず呼び出しパターンを分類します。微小で高頻度な関数の場合はバッチ形式の C API を公開し、長時間のタスクの場合は Go が非同期で待機する間、C にコンテキストを所有させます。長さ情報付きバッファ、ハンドル、ステータスコードを渡し、割り当て、解放、コピー、ポインタのライフタイムを文書化します。
証拠を得るために、入力、ハードウェア、コンパイラ、リンカーフラグを固定し、単一呼び出し、バッチ、エンドツーエンドのベンチマークを測定し、CPU、メモリ、ブロッキングプロファイルを使用して差分を説明します。カナリア運用の間は、テールレイテンシ、メモリ割り当て、クラッシュ、C エラーを監視して、ロックやコピーによるコストを検知します。キャンセル不可能な C 呼び出しはすべて、分離、タイムアウト、ロールバック計画が必要です。
よくある間違い
- ベースライン、ハードウェア、または呼び出し形状を考慮せずに 30% という数値を繰り返す。
- コピーを避けるために C 側に Go ポインタを無制限に保持させ、ライフタイムのルールに違反する。
- グローバルな C ロックや直列のボトルネックを隠すために安易に goroutine を追加する。
- エンドツーエンドのテールレイテンシ、クラッシュ、クリーンアップを無視して、マイクロベンチマークのみを測定する。
フォローアップの質問と回答
バッチ処理によってパフォーマンスが悪化するのはどのような場合ですか？
バッチ化のための待機時間は、リクエストごとのキューイングとメモリピークを増加させます。データが小さい場合、レイテンシ要件が厳しい場合、あるいは C 側がすでに内部でバッチ処理を行っている場合は、改善効果が失われることがあります。バッチサイズはエンドツーエンドの p99 とスループットを総合して決定します。
C ライブラリによるリソースリークをどのように防ぎますか？
ハンドルを冪等な Close を持つ Go の明示的なライフタイムオブジェクトにラップし、エラー、タイムアウト、キャンセルの際にも解放されるようにします。長時間実行テストやネイティブツールを使用して、ハンドル、ヒープ、スレッドが継続的に増加していないことを確認する必要があります。
Go 1.26 でベンチマークは向上したものの本番環境で性能劣化が生じた場合はどうしますか？
まずコンパイラ、CGO_ENABLED、CPU 機能、リクエストの混在状況を揃え、次にコピー処理、ロック待機、GC、C 内部のタイミングを比較します。性能劣化が特定のプラットフォームに依存する場合は、プラットフォームごとにカナリア検証またはロールバックを実施し、再現可能なサンプルを保存します。