인메모리 데이터베이스에서는 DRAM 용량이 사업 제약으로 이어집니다. DIMM 슬롯이 부족하면 비싼 고용량 모듈을 사거나 데이터베이스를 더 많은 서버로 나눠야 합니다. CXL은 일부 용량을 CPU 소켓에서 떼어 내고 인스턴스가 필요할 때 할당하는 세 번째 방법을 제공합니다. 그러나 스위치가 경로에 들어가고 호스트 두 대가 메모리 박스를 공유하면 판단이 복잡해집니다.
EDBT Industrial & Applications 트랙에 실린 이 논문은 에뮬레이터가 아니라 상용 등급 CXL 메모리 박스를 사용했다는 점에서 중요합니다.[1] SAP과 Samsung 연구진은 XConn 스위치와 Samsung CMM-D를 Emerald Rapids 서버에 연결하고, HANA 프로토타입을 수정해 TPC-C, TPC-DS, 재시작, 임시 테이블을 평가합니다. 풀 메모리가 로컬 DRAM과 같다고 주장하지 않습니다. 어떤 HANA 구조가 풀을 견디고 어떤 구조는 견디지 못하는지 구분합니다.
이 프로토타입에서 동적 할당이 뜻하는 것
작은 토폴로지는 호스트 두 대와 XConn B2 CXL 스위치로 구성됩니다. 스위치는 최대 256개의 PCIe 5.0 레인을 지원합니다. 다운스트림에는 Samsung CMM-D 두 개가 있고, 장치마다 128GB DDR5-5200, 메모리 컨트롤러, CXL-DDR5 변환 ASIC, PCIe 5.0 x8 인터페이스가 들어갑니다. 호스트는 x16 업스트림 포트로 스위치에 연결되고 256GB 호스트 관리 장치 메모리(HDM) 구간을 봅니다.
패브릭 관리자는 업스트림 HDM과 다운스트림 장치의 매핑을 제어합니다. 원칙적으로 매핑을 바꿀 수 있지만, 평가는 안정성 문제 때문에 실행 중 스위치 재매핑을 사용하지 않습니다. 대신 Linux가 이미 매핑된 구간을 온라인·오프라인하고 NUMA 노드나 fsdax 장치로 노출합니다. 재부팅 없이 용량을 활성화했지만, HANA가 사용 중인 임의의 바이트 구간을 스위치가 다른 호스트로 옮긴 것은 아닙니다.
두 호스트의 주소 구간은 서로 겹치지 않습니다. 한 물리 박스에서 용량을 나눠 받지만 같은 테이블이나 임시 버퍼를 동시에 공유하지 않습니다. 호스트 간 일관성을 갖춘 공유는 향후 과제입니다. 여기서 풀링은 두 HANA 인스턴스가 공통 주소를 사용하는 방식이 아니라 호스트 사이에서 용량 파티션을 유연하게 정하는 방식입니다.
HANA 내부 메모리의 서로 다른 접근 방식
주요 컬럼 저장소는 크고 읽기 중심이며 순차 스캔이 많습니다. HANA 실행 힙에는 중간 실행 구조, 해시 테이블, 수명이 짧은 객체가 들어가며 무작위 쓰기가 많을 수 있습니다. SQL 스크립트가 만드는 임시 테이블은 동시 사용자 수에 따라 커집니다. 재시작 경로도 다릅니다. 주요 저장소를 메모리 구간에 유지하면 디스크에서 다시 읽는 작업을 줄일 수 있습니다.
이를 모두 데이터베이스 메모리 하나로 묶으면 핵심 결과를 놓칩니다. 순차 스캔은 프리페치로 긴 CXL 지연을 숨기고 전체 대역폭에 제한되는 경우가 많습니다. 무작위 힙은 추가 지연을 매번 노출하고 메모리 수준 병렬성을 충분히 만들지 못합니다. 임시 테이블은 크지만 접근량이 적을 수 있어 지연보다 용량이 중요합니다.
HANA 프로토타입은 실행 엔진에 NUMA를 고려하는 원거리 메모리 할당을 추가하고 선택한 임시 테이블을 특정 NUMA 노드에 둡니다. 저자들은 이 기능이 가까운 시기에 상용 HANA에 들어간다는 약속은 아니라고 명시합니다.
테이블 데이터와 실행 힙을 옮긴 결과
첫 장비는 48코어 Emerald Rapids 프로세서 하나, 하이퍼스레딩, 8채널 DDR5-4800 1,024GB를 사용합니다. CXL 박스에는 스위치 하나와 메모리 장치 두 개가 들어갑니다. 직접 연결 CXL과 스위치 풀 모두 원격 소켓 경로 뒤에 배치해 같은 NUMA 페널티에서 비교합니다.
창고 100개 TPC-C는 CXL 트래픽이 적고 동기화 비용이 큽니다. 따라서 테이블 메인 저장소나 일부 할당을 옮겨도 변화가 무시할 수준입니다. OLTP가 원거리 메모리를 선호한다는 뜻이 아닙니다. 이 구성에서는 메모리 지연이 제한 요소가 아니라는 결과입니다.
스케일 팩터 100의 TPC-DS에서는 차이가 드러납니다. 메인 저장소를 풀에 두면 병렬 스트림이 늘수록 성능이 낮아집니다. 순차 접근은 프리페치가 지연 대부분을 숨기므로 주요 제한은 대역폭입니다. 연구진은 Linux device mapper로 fsdax 장치 두 개를 인터리빙해 CXL 대역폭을 두 배로 늘렸습니다. 그 결과 전체 로컬 기준 대비 성능 저하가 한 자릿수 비율로 줄었습니다. 딕셔너리에는 무작위 접근이 일부 있어 로컬 소켓과 원격 소켓의 풀 배치에는 작은 차이가 남습니다.
실행 엔진의 HEX 힙은 옮기면 안 되는 사례입니다. 무작위 접근이 많은 이 힙을 CXL 메모리에 두면, 스위치 풀보다 지연이 짧은 직접 연결 장치에서도 50% 넘게 느려졌습니다.[2] 논문은 이를 실용적인 풀링 대상으로 보지 않습니다. 지연을 그대로 실행 정지 시간으로 바꾸는 구조에서는 용량 탄력성이 손실을 보상하지 못합니다.
빠른 재시작이 줄이는 시간
HANA는 재시작할 때 보통 영구 저장소에서 주요 테이블 데이터를 다시 읽습니다. 빠른 재시작 기능은 주요 저장소 조각을 영속 메모리 구간에 유지하고 서비스가 돌아오면 다시 연결합니다. 평가는 주요 저장소를 CXL 풀에 두고 정상 종료한 뒤, 미리 읽지 않는 경우, 빠른 재시작 없이 전부 읽는 경우, 빠른 재시작으로 전부 읽도록 설정한 경우를 정규화해 비교합니다.
데이터를 풀에 유지하면 미리 읽는 단계의 대부분이 사라집니다. 다만 도표는 초 단위 절대 시간이 아니라 정규화된 시간이고, 델타 저장소가 주요 저장소에 모두 병합되어 redo 시간이 무시할 수준이라고 가정합니다. 검증한 결론은 평가한 상태에서 영속 CXL 구간이 대량 재적재를 없앤다는 것입니다. 전원 상실, 패브릭 관리자 장애 전환, 정리되지 않은 델타 로그, 메모리 박스 장애에서의 복구 시간까지 입증한 것은 아닙니다.
호스트 두 대가 임시 테이블을 옮긴 결과
두 호스트 평가는 듀얼 소켓 Emerald Rapids를 사용합니다. 서버 A는 소켓당 로컬 DRAM 1TB, 서버 B는 512GB이고, 둘 다 같은 풀에서 128GB를 추가로 온라인합니다. 작업부하는 TPC-DS 질의 중 임시 테이블 크기가 가장 큰 5개를 바탕으로 만든 SQL 스크립트입니다.
임시 테이블을 로컬 DRAM, 원격 DRAM, CXL 풀에 둘 때 성능은 사실상 같습니다. 스크립트가 테이블을 주로 순차 접근하고 CXL 트래픽도 적어 큐가 포화하지 않기 때문입니다. 접근 빈도가 낮지만 큰 중간 결과를 로컬 메모리에서 빼내 OOM을 피할 수 있다는 운영상 의미가 있습니다.
두 호스트에서 작업을 동시에 실행해도 측정한 트래픽에서는 간섭이 무시할 수준입니다. 낮은 부하에서의 관찰이지 서비스 품질 보장은 아닙니다. 같은 논문도 대역폭을 많이 쓰는 작업은 장치와 스위치에서 경합할 수 있다고 경고하며, 선속도에 가까운 적대적 읽기·쓰기 조합은 평가하지 않습니다.
도입에 필요한 세 가지 규칙
첫째, 데이터베이스 객체 이름이 아니라 접근 패턴으로 분류해야 합니다. 테이블 컬럼, 딕셔너리, 임시 테이블, 실행 힙은 읽기·쓰기 비율과 지역성이 다릅니다. 배치 제어기는 모든 콜드 데이터를 원격으로 보내는 고정 규칙보다 측정한 대역폭, 캐시 미스, 수명을 사용해야 합니다.[3]
둘째, 용량 활성화와 성능 격리는 별개의 기능입니다. Linux가 재시작 없이 128GB를 온라인해도 다른 호스트가 공유 다운스트림 장치를 포화하면 쓸 수 없습니다. 실제 메모리 박스에는 호스트별 대역폭 관측, 수용 제어, 데이터베이스의 꼬리 지연이 SLO를 넘기 전에 할당을 이동하거나 제한하는 기능이 필요합니다.
셋째, 영속성은 장애 계약을 넓힙니다. HANA 재시작 뒤 주요 저장소를 유지하는 것은 유용하지만 스위치 재설정, 케이블 장애, 펌웨어 갱신, 메모리 장치 교체 중 무엇이 살아남는지 정의해야 합니다. 복제한 메타데이터와 저장소로 돌아가는 경로를 시험하지 않으면 풀이 단일 복구 의존점이 됩니다.
구매 전에 재현할 시험
운영 환경의 질의 조합으로 논문의 테이블 배치 6개를 먼저 재현해야 합니다. 처리량뿐 아니라 CXL 읽기·쓰기 대역폭, CPU 정지 카운터, p99 질의 지연을 함께 보고합니다. 링크 두 배 구성은 공짜 최적화가 아니라 비용이 추가되는 구성으로 계산해야 합니다.
다음에는 순차 대역폭 작업과 무작위 지연 민감 작업을 두 테넌트에서 동시에 실행합니다. 간섭이 나타날 때까지 트래픽을 늘리고 패브릭 관리자나 데이터베이스가 무작위 작업을 보호할 수 있는지 봅니다. 마지막으로 질의가 임시 상태를 할당하는 중에 용량을 반복해서 온라인·오프라인하고 링크 재설정을 주입한 뒤 영속 풀에서 데이터베이스를 복구해야 합니다.
이 논문의 가장 강한 기여는 CXL이 HANA를 빠르게 만든다는 주장이 아닙니다. 실물 스위치와 메모리 박스가 선택한 구조의 성능을 해치지 않으면서 용량을 탄력적으로 만들 수 있음을 보여 줍니다. 한계도 같은 무게로 중요합니다. 무작위 실행 상태는 CPU 가까이에 남겨야 하고, 공유 대역폭은 데이터베이스의 핵심 자원으로 관리해야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 분석입니다. 원문의 주장과 측정값을 우리 표현으로 다시 썼고 문장, 도판, 표를 복제하지 않았습니다. 본문 도판 두 장은 이 글을 위해 제작했습니다. 원문은 OpenProceedings EDBT 2026, DOI 10.48786/edbt.2026.58에서 CC BY-NC-ND 4.0으로 볼 수 있습니다. 저작권은 소유자와 저자들에게 있습니다. (c) 2026.