最近、NFV基盤をCPUピニングなしの環境へ移行する議論を見ていて、根本的に論点がズレていると感じたので整理する。
結論から言うと、この話は「性能が出るかどうか」ではない。
アーキテクチャの問題であり、サービス定義の問題である。
問題の本質
CPUピニングとは、単に速くするためのチューニングではない。
- CPUピニングあり → 専有実行（deterministic）
- CPUピニングなし → 共有実行（probabilistic）
つまり、これは「性能差」ではなく、実行モデルの差である。
さらにHugePageも外す場合、
- メモリ効率・TLB・ページ管理
- DPDKなどの前提
も同時に崩れる。
したがってこれは、
CPUとメモリの両方で「決定性前提」を捨てる変更
になる。
検証で判断すべきか？
「検証してみないと分からない」という意見もあるが、この場合は適用できない。
なぜなら：
- CPU共有 → スケジューラ介入
- 実行タイミング → 非決定
- 他VM影響 → 回避不可
これらは構造的に確定している性質であり、検証結果に依存しない。
検証で見えるのは、
- たまたま問題が出なかったケース
だけであり、本質的な成立性は判断できない。
NFVとして成立しているのか？
NFVの本質は、
汎用基盤上で、専用装置と同等の性能特性を維持すること
である。
CPUピニングやHugePageは、そのための実装手段に過ぎないが、
これらを外す場合は次のどちらかになる。
- 性能要件を維持できない
- 性能要件を変更している（ベストエフォート化）
つまり、
「ピニング不要」という主張は、性能要件の変更を伴わない限り成立しない
AWSの例が示しているもの
クラウド（例：AWS）でもNFV的な構成は存在するが、
- CPUは共有
- 決定性は保証されない
その代わり、
- スケールアウト
- 上位での吸収
で成立させている。
これは、
キャリアグレードNFVではなく、ベストエフォート型NFV
である。
一番の問題：通知なし移行
ここが最も重要。
もし現在のサービスが、
- CPUピニング前提
- HugePage前提
- 安定性前提
で成立しているなら、それを
- 非ピニング
- 非HugePage
に変更するのは、
サービス特性の変更
である。
それにもかかわらず通知しない場合、
- ユーザーは旧前提で利用
- 実際は新前提で動作
となり、
「安定していたはずのものが不安定になる」
という形で問題が顕在化する。
まとめ
この議論は非常にシンプルに整理できる。
- CPUピニングの有無は性能ではなく実行モデルの差
- HugePageの有無はメモリ前提の差
- これを同時に外すのはアーキテクチャ変更
- したがってサービス仕様変更
最後に一行でまとめる。
CPUピニングとHugePageを外すなら、それは同じサービスではない。
CPUピニングを外した瞬間、それはもう別のサービスである
