[Daily morning study] NUMA (Non-Uniform Memory Access) 아키텍처

13 Oct 2026 in Daily morning study / Operating System

#daily morning study

---

NUMA란?

NUMA(Non-Uniform Memory Access)는 멀티프로세서 시스템에서 메모리 접근 시간이 CPU와 메모리 간의 물리적 위치에 따라 달라지는 아키텍처다.

현대 서버에는 수십 개의 CPU 코어와 수백 GB의 RAM이 탑재되어 있는데, 모든 메모리를 하나의 버스로 연결하면 병목이 심해진다. NUMA는 이 문제를 해결하기 위해 메모리를 CPU에 가까운 로컬 메모리와 원격 메모리로 나눠 관리한다.

UMA vs NUMA

UMA (Uniform Memory Access)

CPU0 -- CPU1 -- CPU2 -- CPU3
              |
         공유 버스
              |
        단일 메모리 풀

모든 CPU가 동일한 버스를 통해 메모리에 접근한다. CPU 수가 늘어날수록 버스 경합이 심해져 확장성이 떨어진다.

NUMA

[NUMA Node 0]            [NUMA Node 1]
  CPU0  CPU1               CPU2  CPU3
    \   /                    \   /
  로컬 메모리  <-- Interconnect --> 로컬 메모리

각 CPU(또는 CPU 그룹)는 자신의 로컬 메모리를 가진다. 다른 노드의 메모리(원격 메모리)에도 접근할 수 있지만, 인터커넥트(예: QPI, UPI, Infinity Fabric)를 거쳐야 하므로 추가 지연이 발생한다.

NUMA 노드(Node)

NUMA에서 노드는 CPU와 그 CPU에 직접 연결된 메모리의 묶음이다.

구분	설명
로컬 메모리 접근	같은 노드의 메모리 — 지연 낮음
원격 메모리 접근	다른 노드의 메모리 — 인터커넥트 경유, 지연 높음
NUMA ratio	원격 vs 로컬 메모리 접근 비용 비율 (보통 1.5~3배)

리눅스에서 NUMA 확인

# NUMA 토폴로지 확인
numactl --hardware

# 출력 예시
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 32768 MB
node 0 free: 28000 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 32768 MB
node 1 free: 27500 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

node distances의 숫자가 메모리 접근 비용의 상대적 지연이다. 같은 노드(10)보다 원격 노드(21)가 약 2배 느리다.

NUMA 문제: Remote Memory Access

프로세스나 스레드가 자신이 실행 중인 CPU 노드가 아닌 다른 노드의 메모리를 자주 접근하면 성능이 크게 저하된다.

프로세스가 Node 0의 CPU에서 실행 중인데
할당된 메모리가 Node 1에 있다면?
→ 모든 메모리 접근이 원격 접근 = 성능 저하

이를 NUMA miss 또는 NUMA imbalance라 부른다.

리눅스 NUMA 정책

리눅스 커널은 메모리 할당 시 NUMA 정책을 통해 어느 노드에서 메모리를 가져올지 결정한다.

정책	설명
default	현재 실행 중인 CPU의 로컬 노드에서 우선 할당
bind	특정 노드에서만 할당, 없으면 OOM
preferred	특정 노드 선호, 없으면 다른 노드에서 할당
interleave	여러 노드에 라운드로빈 방식으로 분산 할당

numactl 명령으로 특정 정책을 지정해 프로세스를 실행할 수 있다.

# Node 0의 CPU와 메모리만 사용
numactl --cpunodebind=0 --membind=0 ./my_app

# 두 노드에 메모리를 분산
numactl --interleave=0,1 ./my_app

NUMA-aware 메모리 할당

C에서 NUMA 친화적인 메모리 할당이 필요하면 libnuma를 사용한다.

#include <numa.h>

// Node 0에 1MB 메모리 할당
void *ptr = numa_alloc_onnode(1024 * 1024, 0);

// 특정 노드 선호 설정
numa_set_preferred(0);

// 할당 해제
numa_free(ptr, 1024 * 1024);

NUMA Balancing (자동 마이그레이션)

리눅스 커널은 NUMA Balancing 기능을 통해 주기적으로 메모리 접근 패턴을 분석하고, 원격 접근이 많은 페이지를 해당 CPU의 로컬 노드로 이동시킨다.

# NUMA Balancing 활성화 여부 확인
cat /proc/sys/kernel/numa_balancing
# 1이면 활성화

# 비활성화
echo 0 > /proc/sys/kernel/numa_balancing

단, 페이지 마이그레이션은 비용이 있으므로 마이그레이션 오버헤드가 접근 지연 절감보다 크면 오히려 성능이 나빠질 수 있다.

NUMA 성능 모니터링

# NUMA 통계 확인
numastat

# 출력 예시
                           node0           node1
numa_hit               50000000        45000000   # 로컬 노드에서 성공적 할당
numa_miss               2000000         3000000   # 원격 노드에서 할당된 횟수
numa_foreign            3000000         2000000   # 다른 노드로 넘어간 할당
interleave_hit           100000          100000
local_node             49000000        44000000
other_node              3000000         4000000

numa_miss가 높다면 NUMA 불균형이 있다는 신호다.

실무에서의 NUMA 최적화 전략

1. CPU와 메모리를 같은 노드에 바인딩

데이터베이스, 캐시 서버처럼 메모리를 많이 쓰는 프로세스는 특정 노드에 고정해 로컬 접근을 극대화한다.

numactl --cpunodebind=0 --membind=0 redis-server

2. 메모리 인터리빙

다수의 스레드가 고르게 메모리를 접근하는 워크로드(예: 대규모 행렬 연산)는 인터리빙으로 대역폭을 고르게 활용한다.

numactl --interleave=all ./matrix_multiply

3. JVM 애플리케이션

JVM은 기본적으로 NUMA를 인식하지 못하므로 -XX:+UseNUMA 옵션으로 NUMA 친화적 힙 할당을 활성화한다.

java -XX:+UseNUMA -XX:+UseParallelGC -jar app.jar

4. Docker/Kubernetes에서의 NUMA

컨테이너 환경에서는 cpuset cgroup을 통해 특정 노드의 CPU와 메모리만 사용하도록 격리할 수 있다. Kubernetes의 Topology Manager가 이를 자동으로 처리한다.

NUMA와 False Sharing

멀티코어 환경에서는 NUMA 외에도 False Sharing 문제를 함께 고려해야 한다. 서로 다른 CPU 코어가 같은 캐시 라인에 있는 서로 다른 변수를 수정하면 불필요한 캐시 무효화가 발생한다. NUMA 토폴로지를 잘 설계하더라도 False Sharing이 있으면 성능 이점이 상쇄된다.

요약

개념	핵심 내용
NUMA	메모리 접근 시간이 CPU-메모리 물리적 거리에 따라 달라지는 아키텍처
로컬 vs 원격 접근	로컬은 빠르고, 원격은 인터커넥트를 거쳐 느림
NUMA 정책	default / bind / preferred / interleave
NUMA Balancing	커널이 원격 접근 페이지를 자동으로 마이그레이션
최적화 방향	CPU·메모리를 같은 노드에 바인딩하거나 인터리빙으로 대역폭 분산

서버 성능 튜닝 시 NUMA 토폴로지를 이해하고 있으면 메모리 접근 패턴을 최적화하여 예상치 못한 지연을 줄일 수 있다.