GoランタイムとNUMA：マルチソケットサーバーの性能を「物理」から引き出す最適化術
現代のクラウドインフラやオンプレミスのハイエンドサーバーにおいて、CPUソケットが複数存在するマルチノード構成は一般的だ。しかし、多くのGoエンジニアは「Goのランタイムが自動的にスケジューリングしてくれる」という幻想を抱き、NUMA（Non-Uniform Memory Access）が引き起こす隠れたレイテンシの罠を見過ごしている。
なぜ、あなたのアプリケーションは高負荷時に突如としてP99レイテンシが跳ね上がるのか。それは、GoのM（OSスレッド）とP（プロセッサ/コンテキスト）が、NUMAノードを跨いでメモリにアクセスし、QPI/UPIバスの競合で窒息しているからだ。
今日は、OSの深淵を覗き込み、Goのランタイムを物理アーキテクチャに「物理的に」固定する極致を解説する。
—
1. NUMAの呪縛：なぜ遠隔メモリアクセスが性能を殺すのか
NUMAアーキテクチャでは、各CPUソケット（ノード）がローカルのメモリコントローラーを持っている。ローカルノードのメモリへアクセスするのは高速だが、リモートノードのメモリへアクセスする場合、バスを介する必要があり、レイテンシは跳ね上がりスループットは激減する。
Goのランタイムは賢いが、NUMAを意識したメモリ配置までは自動化されていない。`GOMAXPROCS`をCPUコア数に設定し、OSがスレッドを自由にマイグレーションさせると、ある時はノード0で、ある時はノード1でメモリ確保が行われ、キャッシュコヒーレンシの維持コストがアプリケーションの足を引っ張る。
—
2. 実装レベルの最適化：runtime.LockOSThread の真価
Goの `runtime.LockOSThread` は、単にスレッドを固定するだけではない。これをNUMAトポロジーと組み合わせることで、特定のCPUノードで特定のタスクを完結させることができる。
NUMAピンニングを実現する設計パターン
package main
import (
“runtime”
“syscall”
“golang.org/x/sys/unix”
)
// ピン留めしたいNUMAノードのCPUマスクを定義
// ここではノード0に属するCPUコア(0-15)を想定
func pinToNode0() {
// 現在のOSスレッドを現在のGに固定
runtime.LockOSThread()
// CPUマスクを作成（コア0〜15を有効化）
var mask unix.CPUSet
for i := 0; i < 16; i++ {
mask.Set(i)
}
// 現在のプロセス/スレッドを特定のCPUセットに制限
// sched_setaffinityを直接叩くことでOSレベルのマイグレーションを阻止
err := unix.SchedSetaffinity(0, &mask)
if err != nil {
panic(err)
}
}
この手法を、高頻度でメモリをアロケートするバックグラウンドルーチンに適用せよ。これにより、GoのGCがスキャンするメモリ範囲が物理的に局所化され、スループットが劇的に向上する。
---
3. Docker環境での完全自動化：Kubernetes NUMA Managerとの連携
Kubernetes環境であれば、人間が手動でコードに書くよりも、`Static` CPU Managerポリシーを活用するのが定石だ。これにより、コンテナは特定のCPUコアに排他的に割り当てられ、ノードレベルのメモリ局所性を担保できる。
CI/CDパイプラインとマニフェストの最適化
コンテナのデプロイ時に、NUMAトポロジーを考慮したリソース要求を自動付与する。
deployment.yaml
spec:
containers:
- name: go-app
resources:
requests:
# CPUを整数値で要求することで、KubeletのCPU Managerが
# 物理コアへの排他割り当てをトリガーする
cpu: “8”
memory: “16Gi”
limits:
cpu: “8”
memory: “16Gi”
env:
- name: GOMAXPROCS
value: “8” # リソース要求と一致させることでコンテキストスイッチを最小化
DevOps的知見: これを自動化するには、CIパイプライン内で `lscpu -e` を解析し、ターゲットノードのトポロジーに応じて `ResourceQuota` を動的に生成するスクリプトをCI/CDの最終ステージに組み込むのが最高峰のプラクティスだ。
—
4. 内部アーキテクチャのハック：メモリ配置の可視化
ツールとして `numastat` を活用し、Goアプリが「リモートメモリ」をどれだけ消費しているかを監視せよ。
1秒おきにNUMAのヒット/ミスを監視
numanode_misses が増加し続けているなら、それは最適化の余地があるサイン
watch -n 1 numastat -p $(pgrep go-app)
この数値が安定しない場合、GoのGC設定（`GOGC`）とアロケーションパターンを再考すべきだ。特に `sync.Pool` を活用し、ヒープアロケーションを極限まで減らして、ローカルノードのキャッシュ内にデータを留める工夫が必要となる。
—
結論：物理レイヤを制する者が、Goの性能を制する
Go言語は抽象化の塊だが、その実行環境はあくまで物理的なシリコンの上にある。NUMAアーキテクチャを理解し、ランタイムに「どこで実行し、どこにメモリを確保すべきか」を教え込むことは、もはや単なる最適化ではない。それは、大規模システムにおけるエンジニアリングの誠実さそのものだ。
- `GOMAXPROCS` は物理コア数と一致させる。
- `runtime.LockOSThread` でCPU親和性を制御する。
- K8sの静的CPU割り当てで物理的な隔離を担保する。
この3つの柱を完璧にコントロールできた時、あなたのGoアプリケーションは、マルチソケットサーバーの真の力を解き放つだろう。次のデプロイでは、単にコードを動かすのではなく、そのコードが「どのCPUで、どのバスを通ってメモリを叩いているか」を想像してみてほしい。そこにこそ、伝説的なパフォーマンス改善の鍵がある。