GoランタイムとNUMA：マルチソケットサーバーの性能を極限まで引き出す「メモリ局所性」の最適化
大規模な高負荷システムを運用していると、単一ノードで「なぜかGoのパフォーマンスが頭打ちになる」「特定のコアだけ異常にレイテンシが高い」という現象に突き当たることがあります。多くの場合、その犯人はOSのスケジューラとGoランタイムの非対称な動き、そしてNUMA（Non-Uniform Memory Access）の特性です。
今日は、Goのランタイムがマルチソケットサーバーの物理構造に対してどう振る舞うべきか、そしてそれをどう制御して「レイテンシの崖」を回避するか、プロの実践的な知見を共有します。
—
1. NUMAアーキテクチャとGoランタイムの「すれ違い」
NUMA環境では、CPUは自身の直近にあるメモリ（ローカルメモリ）へのアクセスは高速ですが、別のCPUソケットに属するメモリ（リモートメモリ）へのアクセスは、バスを経由するため高いレイテンシを伴います。
Goのランタイム（特にスケジューラ）は非常に優秀ですが、デフォルト設定では「全CPUコアを等価に扱う」前提で設計されています。そのため、以下のような事態が発生します。
1. G（Goroutine）のマイグレーション: 実行中のGoroutineが別のソケットのコアへ移動し、それまでローカルメモリで確保していたヒープデータへのアクセスが急激に遅延する。
2. メモリの分散確保: GoのGCがヒープを再配置する際、物理メモリのトポロジーを考慮しない割り当てが行われ、バス帯域のボトルネックを誘発する。
これらを解決するには、「プロセスを特定のソケットに固定し、メモリの局所性を保つ」戦略が必要です。
—
2. 実践：NUMAフレンドリーな構成術
単にコードを書くだけではなく、OSとランタイムの連携を強制的に制御します。
GOMAXPROCSとCPU親和性の設定
`GOMAXPROCS`を物理コア数に合わせるのは基本ですが、マルチソケット環境では「ソケット単位」でプロセスを分割する戦略が最も有効です。
numactl を使い、特定のソケット（node 0）にプロセスを固定して起動する
これにより、メモリ確保が確実にローカルノード内で行われる
numactl –cpunodebind=0 –membind=0 ./bin/your-application
runtime.LockOSThread の適材適所
特定の計算リソースを多用するGoroutineには、`runtime.LockOSThread()`を使用して特定のOSスレッドに固定します。これにより、スケジューラによるコンテキストスイッチを最小化し、L1/L2キャッシュの破壊を防ぎます。
func criticalTask() {
// このGoroutineを現在のOSスレッドに固定
runtime.LockOSThread()
defer runtime.UnlockOSThread()
// 物理的なメモリ配置を考慮した高負荷処理を実行
// この中で確保されるメモリは、このOSスレッドが属するノードに局所化されやすくなる
}
—
3. チーム開発で「速さ」を標準化する：設定の共有化
アーキテクトとして、これらの複雑なチューニングを属人化させてはいけません。プロジェクトのルートディレクトリに `taskfile.yml` や `Makefile` を置き、環境ごとの起動設定をコード化します。
ベストプラクティス：設定のテンプレート化 (`deployment/numa-config.yaml`)
NUMA環境ごとの実行プロファイル
profiles:
high-performance-socket0:
cpunodebind: 0
membind: 0
gomaxprocs: 16 # ソケットあたりの物理コア数に合わせる
high-performance-socket1:
cpunodebind: 1
membind: 1
gomaxprocs: 16
—
4. 開発環境を加速させる「神ツール」と設定
優秀なエンジニアはツールに語らせます。Goのランタイム解析に欠かせない、導入必須のツール群を紹介します。
1. `perf` + `go tool pprof`
NUMAのボトルネックを探るには、CPUのキャッシュミスを追うのが最短ルートです。
キャッシュミスをサンプリング
perf stat -e cache-misses ./your-app
これを見て「キャッシュミスが異常に多い」場合、メモリ配置が散らばっているサインです。
2. VS Code用神設定：`settings.json`
チーム全体で統一すべきGoの開発体験です。特に `gopls` の設定を最適化し、ビルド時のインデックス作成コストを抑えます。
{
“go.languageServerFlags”: [
“-remote=auto”,
“-debug”,
“–rpc.trace”
],
“go.buildTags”: “production,numa”, // ビルドタグでOS依存コードを切り替える
“editor.formatOnSave”: true,
“go.lintTool”: “golangci-lint”
}
—
5. 最後に：アーキテクトからの助言
「NUMAを意識する」ということは、ハードウェアの物理的な制約をソフトウェアの論理構造で飼いならす行為です。
- まずは観測する: `lscpu` や `numastat` で自社のサーバーがどのようなトポロジーかを知ること。
- 過度な最適化を避ける: 最初からNUMAを意識しすぎると可読性が落ちます。パフォーマンス計測（`pprof`）で、メモリレイテンシがボトルネックとして明確に浮かび上がった時だけ、この「特効薬」を適用してください。
我々テックリードの仕事は、複雑な抽象化を提供することではなく、「どうすればボトルネックを論理的に排除できるか」という指針を示すことです。Goのランタイムは、適切に飼いならせば、並列計算において最強の武器となります。
さあ、今すぐ `numastat -p