概要
クラウド環境において、インスタンスのスペック（vCPU/メモリ）をスケールアップしていく過程で、OS側から**NUMA（Non-Uniform Memory Access）**構成が露出する。仮想化技術によってハードウェアは抽象化されているが、大規模データベース等のメモリ集約型アプリケーションを運用する場合、この物理構造を無視した設計はパフォーマンス劣化やプロセス停止（OOM Killer）を招くリスクがある。本稿では、クラウド上のNUMAの正体とその対策について論理的に解説する。
1. NUMA（Non-Uniform Memory Access）の本質
NUMAとは、複数のCPUソケットを持つマルチプロセッサシステムにおいて、CPUごとに専用のメモリ領域（NUMAノード）を割り当てるアーキテクチャである。
- Local Access: 自ノードのメモリへのアクセス（高速）。
- Remote Access: 他ノード（他CPU配下）のメモリへのアクセス（低速）。
プロセッサの多コア化・大容量メモリ化に伴い、単一のメモリバスへのアクセス集中（UMAの限界）を避けるために採用されている物理構造である。
2. クラウド（AWS EC2）におけるNUMA
クラウド環境（特にAWS Nitro System）においても、物理ハードウェアの性能を最大限に引き出すため、**vNUMA（Virtual NUMA）**としてこの構造がOSに透過的に見せられる。
物理サーバをまたぐことはない
1つのインスタンスが複数の物理サーバ（筐体）をまたいでデプロイされることはない。NUMA問題が発生するのは、1つの筐体内の**「複数のCPUソケット」にまたがって**リソースが割り当てられる場合である。
インスタンスサイズによる境界
AWSでは、物理サーバの1ソケットが持つスペック（例：r5インスタンスなら32 vCPU程度）を超えたサイズを選択した際、OSからは複数のNUMAノードとして認識される。
3. なぜ「隠蔽されたクラウド」でNUMAを意識すべきか
「他者のVMとのリソース共有（ノイジーネイバー）がある以上、自インスタンス内の構造最適化は無意味ではないか」という懸念は、以下の論理的背景から否定される。
- メモリリソースの予約性: AWS等の高性能インスタンスでは、メモリは他VMと共有（オーバーコミット）されず、起動時に物理的な位置が固定される。
- ノード間通信の物理法則: 自身のvCPUから自身のメモリへアクセスする際の「物理的な距離」は、他者の状況に関わらず遅延（レイテンシ）として一貫して発生する。
- 可用性の担保: パフォーマンス以上に深刻なのが、特定のNUMAノード内でのメモリ枯渇によるOOM Killerの発動である。
4. NUMA不均衡によるOOM Killerのメカニズム
OS全体のメモリが潤沢であっても、NUMAを意識しないプロセスが特定のノードに偏ってメモリを消費すると、Linuxカーネルはそのノード内でのメモリ回収を試みる。回収が間に合わない場合、他ノードのメモリが空いているにもかかわらず、当該プロセスを強制終了（OOM Killer）させる場合がある。これが大規模サーバにおける「原因不明のプロセス停止」の代表的な要因の一つである。
5. 推奨される設計指針
大規模なデータベース環境を構築する際は、以下の最適化を検討すべきである。
OSレベルのパラメータ最適化
-
vm.zone_reclaim_mode = 0: 特定ノードのメモリ不足時、自ノード内での過度なページ回収を行わず、他ノードのメモリを柔軟に使用させる設定。RHEL等では標準的な推奨値とされることが多い。 -
tunedプロファイルの適用:throughput-performanceや各データベース製品に特化したプロファイルを適用し、NUMAバランシングを最適化する。
ミドルウェアレベルの設定
- NUMA Awareness設定の有効化: 多くの商用・オープンソースデータベースには、基盤のNUMA構成を認識するための設定が存在する。これを有効化することで、各ノードのCPU・メモリをバランスよく利用し、特定ノードへの負荷集中を回避する。
-
プロセスのバインド（必要に応じて）:
numactl等を用い、特定のプロセスを特定のノードに固定、あるいは全ノードに均等に割り振る（Interleave）運用を検討する。
結論
クラウドは物理層を隠蔽するが、ハイパフォーマンスと高可用性が求められる設計においては、ハードウェアの物理構造であるNUMAを無視することはできない。インスタンスのスケールアップに伴い、**「仮想的なリソース空間の中に物理的な境界線が存在する」**ことを前提とした設計が、システムの安定稼働には不可欠である。