멀티코어 서버, 메모리도 '가까운 메모리'가 따로 있어요
요즘 서버 한 대에 코어가 수십 개, 백 개씩 박혀 있잖아요. 그런데 코어를 무작정 늘린다고 성능이 비례해서 오르지 않아요. 발목을 잡는 게 바로 메모리거든요. 이번 글이 다루는 NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)가 정확히 이 지점의 이야기예요. 제목 그대로 "코어와 메모리, 그리고 그 사이의 거리"가 핵심이에요.
옛날엔 모든 코어가 하나의 메모리 버스(통로)를 같이 썼어요. 이걸 UMA(균일 접근)라고 하는데, 어느 코어가 접근하든 메모리까지 거리가 똑같았죠. 문제는 코어가 많아질수록 이 하나뿐인 통로 앞에 줄을 서게 된다는 거예요. 마치 큰 사무실에 직원은 백 명인데 복사기가 딱 한 대만 있는 느낌이에요. 다들 그 앞에서 대기하니 일이 안 굴러가죠.
그래서 메모리를 코어 곁에 나눠 붙였어요
NUMA의 발상은 단순해요. 메모리를 한곳에 몰아두지 말고, CPU 소켓마다 자기 전용 메모리를 곁에 붙여주자는 거예요. CPU 하나와 거기 붙은 메모리 묶음을 "NUMA 노드(node)"라고 불러요. 이러면 각 코어는 자기 노드에 붙은 "로컬 메모리"에 아주 빠르게 접근할 수 있어요. 복사기를 부서마다 한 대씩 놔준 셈이죠.
근데 여기서 "비균일"이라는 이름이 왜 붙었는지 드러나요. 1번 소켓의 코어가 자기 로컬 메모리를 읽는 건 빠른데, 2번 소켓에 붙은 메모리(원격 메모리)를 읽어야 할 때가 있거든요. 이땐 두 소켓을 잇는 고속 통로(인터커넥트, 예를 들어 AMD의 인피니티 패브릭이나 인텔의 UPI)를 한 번 건너가야 해요. 옆 부서 복사기를 쓰러 걸어가는 거랑 같아요. 분명 되긴 되는데 더 느려요. 이렇게 어디 메모리냐에 따라 접근 속도가 들쭉날쭉해서 비균일 접근이에요.
그래서 소프트웨어가 신경 써야 해요
하드웨어가 이렇게 생겼으니, 소프트웨어가 멍하니 있으면 손해를 봐요. 예를 들어 어떤 스레드가 1번 노드에서 돌다가 메모리를 잔뜩 할당했는데, OS가 그 스레드를 갑자기 2번 노드로 옮겨버리면, 이제 그 스레드는 매번 원격 메모리에 접근하느라 느려지는 거예요. 데이터는 1번 동네에 있는데 일꾼은 2번 동네로 이사 간 꼴이죠.
그래서 리눅스에선 numactl 같은 도구로 "이 프로세스는 이 노드에 붙어서 그 노드 메모리만 써라" 하고 묶어줄 수 있어요(이걸 핀닝, pinning이라고 해요). 메모리 할당 정책도 "항상 로컬에 잡아라", "여러 노드에 골고루 흩뿌려라" 같은 식으로 조절할 수 있고요. numactl --hardware를 쳐보면 내 서버에 노드가 몇 개고 노드 간 거리 점수가 얼마인지도 볼 수 있어요.
업계 맥락
이 주제는 AMD 에픽(EPYC)이나 인텔 제온 같은 멀티소켓·칩렛 구조가 대세가 되면서 더 중요해졌어요. 요즘 CPU는 한 소켓 안에서도 칩렛(작은 다이 조각)이 여러 개라 사실상 소켓 안에 또 NUMA가 생기기도 해요. 데이터베이스(PostgreSQL, MySQL), JVM, 고성능 캐시, AI 추론 서버 같은 메모리를 많이 쓰는 소프트웨어일수록 NUMA 인식 설계가 성능을 좌우해요. 반대로 작은 1소켓 서버나 클라우드의 소형 인스턴스라면 별로 체감 안 될 수도 있어요.
한국 개발자에게
온프레미스 고사양 서버를 다루거나, 클라우드에서 큰 베어메탈·대형 인스턴스를 쓰는 분이라면 NUMA를 꼭 알아두세요. "코어는 많은데 왜 기대만큼 안 빠르지?" 싶을 때 범인이 NUMA 원격 접근인 경우가 정말 많거든요. 우선 numactl --hardware로 내 장비 구조부터 파악하고, 핵심 서비스는 노드에 핀닝하는 것부터 시도해보면 좋아요.
한 줄 요약: 코어와 메모리 사이엔 '거리'가 있고, 그 거리를 무시하면 성능이 줄줄 샌다. 여러분은 운영 중인 서버의 NUMA 구조를 한 번이라도 확인해본 적 있으세요?
🔗 출처: Hacker News