[Concurrency] NUMA (Non-Uniformed Memory Access)

NUMA는 현재 컴퓨터 구조, 특히 멀티코어에 있어서 핵심적인 구성 논리 중 하나다.

CPU <> RAM 간의 멀티코어 처리를 최적화하기 위해 고안된 하드웨어 스펙 & 소프트웨어 계층이라고 할 수 있다.
서버급 초고성능 장비에서 최적화를 할 경우에는 NUMA를 통해서 메모리 처리량을 극대화하는 것이 요즘에는 매우 당연하다.

따라서 대규모 병렬 워크로드를 돌릴 필요가 있거나, 고성능 인프라 관리를 할 일이 있다면 알아둬야 하는 내용이다.

UMA (Uniformed Memory Access)

원래는 구조가 단순했다. 그냥 CPU와 RAM이 버스를 통해 직통으로 연결된 구조였고, 이를 UMA라고 부른다.

이 방식의 단점은, 코어가 늘어날수록 병목이 심해진다는 것이다.
여러 코어가 단일 메모리와 버스를 통해 액세스하기 때문에, 단일 병목지점이 존재하고, 코어가 늘어남에 따라서 부하가 커진다.

이런 문제를 완화하고, 더 높은 성능을 위해서 메모리 영역을 분할하고 코어마다 거의 독립적인 성능을 가져갈수 있도록 해주는 것이 NUMA다.

다만 NUMA가 나왔다고 해서 기존의 UMA 방식이 버려지거나 한 것은 아니다. 대부분의 일반급 장비들은 UMA를 쓰고, 보통은 그게 더 효율적이다.

NUMA (Non-Uniformed Memory Access)

NUMA는 RAM을 논리적으로 분할하고 CPU의 소켓(NUMA NODE)마다 RAM 영역을 할당하는 기법이다.

RAM 자체의 순수한 하드웨어 병목은 어쩔 수 없지만, 여러개의 메모리 채널로 메모리에 접근하기 때문에 순수한 대역폭 향상이 크게 일어난다. 이것만 해도 꽤 강력하다.
게다가 CPU가 더 좁은 메모리 영역을 동일하게 사용하기 때문에 캐시 히트 확률도 더 증가한다는 부수적인 장점이 있다.

AMD가 2003년에 처음 시도했고, Intel은 2007-8년 쯤에 시작했다. 의미있는 도입이 시작된 것은 인텔 Nehalem 아키텍쳐 제온에 NUMA가 들어가고부터다.

NUMA의 단점과 한계

하지만 이게 항상 효율적인 것은 아니다.
NUMA의 뛰어난 성능은 병렬화가 이상적으로 되어있다는 가정 하에 완성되는 것이다. 그러니까 메모리 공유를 하지 않거나, NUMA 노드에 속한 코어끼리만 메모리 공유를 하는 경우다.

스레드가 다른 스레드에서 할당한 메모리를 훔쳐서 사용하거나, 거대한 공유 메모리 풀을 놓고 접근하는 패턴이 빈번하다면 오히려 NUMA를 쓰는 것이 더 느려질 수 있다.

만약 다른 NUMA에 연결된 메모리에 접근해야 한다면 CPU 간 인터커넥트(다른 말로 Remote Memory Access)를 통해서 메모리에 접근해야 하는데, 이게 상당히 느리고 비효율적이다.

넷마블의 사례: https://netmarble.engineering/single-process-programming-numa-effect/
넷마블 블로그에서 퍼온건데, 이게 모든 코어가 동일 메모리를 공유해서 한쪽 NUMA 그룹에만 remote access가 폭주-리소스가 낭비된 현상이다.

사실 그래서 스레드 간 공유가 빈번한 일반적인 응용프로그램들은 NUMA에 잘 맞지 않는다.
스레드리퍼가 코어를 30-100개씩 쳐박는 서버급 사양인데도 기본값이 NUMA OFF인 이유가, 일단 표면적으로는 목적이 상용 CPU이기 때문이다.
이런 경우에는 NUMA를 아예 끄거나, INTERLEAVE 옵션 등을 활용하는 편이 좋다.

NUMA가 효과적인 경우

일단 코어를 잘 쥐어짜고, 메모리 접근이 지역적인 경우에는 대부분 NUMA가 매우 효과적이다.

이 효과를 잘 받는 것이 PostgreSQL 같은 데이터베이스 시스템이다. 그래서 실제 워크로드에서 DB를 튜닝할때 들어가는 최적화 수단 중 하나가 NUMA다.
그리고 MapReduce 같은 대형 분산시스템이나 Spark 같은 병렬 워크로드에도 효과가 있다.

이외에도 가상화를 통해 프로세스를 독립적으로 분할하는 VM 서비스나, k8s 등도 꽤 잘 맞는다고 할 수 있다.

NUMA 상태 확인하기 (LINUX)

lscpu를 통해 CPU 정보와 함께 NUMA 정보를 볼 수 있다.
대개는 OS에서 NUMA와 관련된 세팅을 알아서 해준다. NUMA가 효율적인 하드웨어에 조합이라면 보통 알아서 NUMA를 적절히 깔아준다.

내 경우에는 NUMA Node가 1개뿐인데, 보통은 이게 정상이다.

NUMA 사용 조건

NUMA를 효율적으로 사용할 수 있고, NUMA가 셋업되게 하려면 크게 2가지 조건이 필요하다.

1. CPU가 멀티소켓을 지원하거나 멀티 NUMA 노드를 지원하는 경우

2. 메인보드의 지원 여부 (바이오스 설정, NUMA 개수를 원하는대로 조절 가능)

이 2가지가 충족되면 해당 NUMA 구성을 OS가 detect해서 사용한다.
그리고 RAM 자체에는 하드웨어 제한이 없다.

CPU 지원

NUMA를 지원하는 CPU 자체는 생각보다 제한적이다.
2 Socket을 지원하는 인텔 제온, AMD EPYC, AMD 스레드리퍼 같은 서버급 CPU들만이 multi NUMA를 사용할 수 있다.
그리고 스레드리퍼의 경우에는 NUMA를 사용할 수 있지만 단일 NUMA가 기본값으로 설정되기도 한다. 이 경우에는 바이오스에서 설정할 수 있다.

NUMA 튜닝

대개 NUMA를 OS가 자동으로 잡아주긴 하는데, 기본 옵션만으로는 불충분할 수도 있다.

그래서 NUMA 최적화는

1. 실제 NUMA 설정을 바꾸는 것 (OS나 바이오스)
2. 애플리케이션 수준에서 NUMA를 고려해서 작성하는 것

크게 2가지 정도로 분기된다.

이건 제대로 다루려면 지면이 한없이 길어지기에, 자주 사용하는 몇가지 일반적인 방향성만 적는다.

1. NUMA Node INTERLEAVING

메모리를 여러개의 NUMA에 분산시키는 기법이다. 이러면 스레드 간 데이터 공유가 빈번한 사용 패턴에 한해서 성능을 높일 수 있다. 대신 싱글스레드의 평균 성능은 좀 떨어진다는 단점이 있다.

2. CPU or Memory 고정

OS에서 제공하는 전용 도구(numactl 등)를 사용하면 특정 프로세스가 특정 NUMA만 사용하도록 고정할 수 있다.
경우에 따라서는 Remote Access를 최소화해서 유의미한 최적화가 될 수 있다.
여기서 특정 NUMA의 CPU에 고정하는 것을 CPU Affinity, 특정 NUMA의 메모리에 고정하는 것을 Memory Binding라고 부른다.
예를 들면, postgres 서버를 특정 NUMA에서만 실행되게 하려면 이렇게 할 수 있다.

# 0번 NUMA로 고정 
numactl --cpunodebind=0 --membind=0 postgres

3. In Kubernetes

쿠버를 쓸때도 NUMA는 꽤 중요한 주제다. 프로그램에 따라서는 이런저런 이유 때문에 특정 Pod가 동일한 NUMA의 하드웨어들로 실행되기를 원할 수 있기 때문이다.
그리고 쿠버네티스는 NUMA 튜닝을 위한 배치 옵션 등을 지원한다. cpuManagerPolicy, topologyManagerPolicy, memoryManagerPolicy 등을 사용하면 강제로 Pod가 특정 NUMA 노드상의 CPU/GPU/RAM에 고정되도록 조정할 수 있다.
이외에도 CPU Pinning, HugePages, Device Plugin 등 이런저런 튜닝 옵션들이 많은데, 너무 길어지므로 자세히 다루진 않겠다.

GPU와 NUMA

대-AI 시대, GPU 기반 프로그램에서도 NUMA를 기반으로 한 최적화가 꽤 중요하다.
NUMA Node가 여러개인 상황에서만 한정된다.

GPU 자체는 RAM과 직접적인 연결점이 없어서 NUMA란 개념이 없지만, GPU가 CPU와 소통하기 때문에 생기는 사항이다. CPU는 RAM을 통해 GPU에 추론할 값을 보내주는데, 이게 사실 내부 DMA을 통해서 처리된다.

근데 문제는 NUMA 환경에서 GPU가 DMA로 메모리를 빠르게 읽으려면 연결된 CPU와 동일한 NUMA에서 할당된 메모리여야 한다는 것이다.
그래서 CPU가 GPU에 빠르게 직통으로 보내려면 동일 NUMA NODE의 CPU <> GPU끼리만 함께 붙어서 상호작용을 하도록 해야 한다. 안그러면 중간에 불필요한 Remote Memory Access가 생긴다.

vLLM 같은 시스템도 내부적으로 이러한 최적화를 자동으로 처리한다.

참조
https://www.techplayon.com/what-is-numa-non-uniform-memory-access/
https://netmarble.engineering/single-process-programming-numa-effect/
https://en.wikipedia.org/wiki/Non-uniform_memory_access