CXL 인터커넥트 기술 연구개발 동향

CXL 프로토콜은 다음과 같은 세 가지 서브 프로토콜로 이루어져 있다(그림 2): CXL.io, CXL.cache, CXL.mem. 각 서브 프로토콜에 대한 설명은 다음과 같다.

그림 2

CXL 프로토콜 구조

• CXL.io: CXL.io 서브 프로토콜은 장치 탐색(Device Enumeration), DMA(Direct Memory Access) 등 PCIe와 유사한 기능을 제공하는 서브 프로토콜이다. 또한, PCIe의 기능 외에도 CXL.io에서 추가된 기능을 통해 CXL 장치 접근 시 PCIe 대비 낮은 접근 지연 시간을 보장한다. CXL.io는 모든 CXL 장치 유형에서 공통으로 사용되는 서브 프로토콜이다.

• CXL.cache: CXL.cache 서브 프로토콜은 호스트의 캐시 메모리와 CXL 장치의 캐시 메모리 간 일관성을 유지하는 데 사용된다. CXL.cache는 비대칭형 프로토콜로서 호스트 프로세서가 캐시 일관성에 대한 책임을 지고 캐시 일관성이 훼손되는 경우 snoop 트랜잭션을 통해 일관성을 유지하는 구조이다. 이때, 일관성 유지 프로토콜은 MESI(Modified, Exclusive, Shared, Invalid)를 사용한다.

• CXL.mem: CXL.mem 서브 프로토콜은 호스트 프로세서가 캐시 라인 단위(i.e., 64byte)로 메모리 접근법(load/store)을 통해 주변장치의 메모리에 접근할 수 있게 하는 기능을 제공한다. 이를 통해 호스트 프로세서는 주변장치의 메모리를 자신의 로컬 메모리처럼 사용할 수 있다.

CXL 프로토콜 구조는 그림 2와 같다. CXL의 물리 계층은 PCIe의 PHY 계층에 CXL logical PHY를 추가한 형태이다. 물리 계층의 상단에는 CXL.io 프로토콜의 트랜잭션과 CXL.mem, CXL.cache 프로토콜의 트랜잭션을 구분하기 위한 MUX가 위치하며, MUX 상단에는 각 서브 프로토콜에 해당하는 링크 계층과 트랜잭션 계층이 위치한다.

CXL 장치는 장치가 사용하는 서브 프로토콜의 조합에 따라 그림 3과 같이 총 세 가지의 장치 유형으로 구분할 수 있다.

그림 3

CXL 장치 유형

우선, 유형 1 CXL 장치는 호스트 CPU의 캐시 메모리와 coherent한 캐시를 가지지만, 호스트가 관리하는 메모리를 가지지는 않는 장치 유형을 뜻한다. 유형 1 CXL 장치의 대표적인 예시로는 NIC(Network Interface Card) 및 호스트가 관리하는 메모리를 가지지 않는 가속기를 들 수 있다. 유형 1 CXL 장치에서 사용되는 CXL 서브 프로토콜은 CXL.io 및 CXL.cache의 D2H(Device to Host) 요청 및 H2D(Host to Device) snoop 트랜잭션 등이 있다.

유형 2 CXL 장치는 CXL.io, CXLcache, CXL.mem 세 가지 서브 프로토콜을 모두 사용하며, 호스트와 fully coherent한 캐시를 가지는 동시에 호스트가 관리하는 장치 메모리를 가지는 유형이다. 유형 2 CXL 장치의 예시로는 HBM(High-Bandwidth Memory) 같은 메모리를 내장한 GPU(Graphic Processing Unit) 카드 또는 메모리를 내장한 FPGA(Field Programmable Gate Array) 보드를 예로 들 수 있다. 유형 2 CXL 장치는 호스트의 메모리에 coherent하게 접근할 수 있으며, 호스트 프로세서 또한 장치 메모리에 coherent 또는 non-coherent하게 접근할 수 있다. 유형 2 CXL 장치는 가속기 유닛과 장치 메모리 간 넓은 대역폭을 이용하여, atomic 연산만 가능한 유형 1 CXL 장치 대비 더욱 복잡한 연산을 처리할 수 있다[2].

마지막으로, 유형 3 CXL 장치는 CXL.io와 CXL. mem 서브 프로토콜을 지원하며, 호스트가 관리하는 메모리로 구성된 장치 유형이다. 유형 3 CXL 장치의 대표적인 예시로는 DRAM(Dynamic Random Access Memory) 또는 비휘발성 메모리(예: Flash 메모리)로 구성된 메모리 확장장치를 들 수 있다. 유형 3 CXL 장치의 확장 메모리는 이기종 메모리들로 구성될 수 있으며(예: 휘발성 메모리 + 비휘발성 메모리), 호스트 프로세서는 해당 메모리에 load/store 명령을 통해 메모리 시맨틱하게 접근하여 이를 NUMA(Non Uniform Memory Access) 노드의 메모리로써 자신의 로컬 메모리처럼 사용할 수 있다.

CXL 표준은 2019년 인텔에서 제안한 1.0 버전을 시작으로, 현재 1.1, 2.0, 그리고 3.0 버전까지 공개되었다.

우선, CXL 1.0 및 1.1 버전의 경우 이기종의 자원 간 유연한 연결 및 메모리 용량/대역폭 확대 수요를 충족시키기 위해 등장했다. 이들은 PCIe 5.0의 기능에 더해, 일관성 유지 메커니즘 및 메모리 시맨틱 접근 메커니즘을 추가한 것을 가장 큰 특징으로 한다.

다음으로 CXL 2.0 버전의 경우 여러 컴퓨팅 노드들이 pooling 된 자원에 CXL 스위치를 통해 접근하는 메커니즘을 제공함으로써 메모리 또는 가속기를 pooling하여 사용할 수 있도록 하였다. 이를 통해 메모리 또는 가속기를 단일 컴퓨팅 노드가 과다하게 구성할 필요 없이 pooling 된 자원을 활용하여 일시적인 수요에 대응할 수 있다. 이는 메모리 오버프로 비저닝과 같은 문제를 효과적으로 해결할 수 있는 수단으로, 데이터 센터와 같이 다수의 컴퓨팅 노드들을 운영하는 주체의 TCO(Total Cost of Ownership)를 크게 줄일 수 있다. 또한, CXL 2.0 버전의 pooling 기능은 기존의 단일 컴퓨팅 노드 수준에서의 메모리 시맨틱 접근 메커니즘을, 랙(Rack) 수준의 메모리 시맨틱 접근이 가능하도록 기능을 확장하였다.

마지막으로, CXL 3.0 버전은 PCIe 5.0을 기반으로 한 이전 버전들과 달리 PCIe 6.0을 기반으로 하며, PAM4[9] 신호 전송 메커니즘을 도입하여 기존 대비 통신 대역폭을 두 배로 증가시킨 동시에 같은 통신 지연 시간을 제공한다. 또한, CXL 3.0 버전은 CXL fabric 및 개선된 라우팅 메커니즘을 통해 최대 4,096개의 호스트 프로세서와 CXL 장치 간 연결을 가능하게 한다. 기존 CXL 2.0 버전에서는 단일 계층으로만 CXL 토폴러지를 구성할 수 있었지만, CXL 3.0 버전에서는 스위치 간 연결이 가능하여 다계층의 스위치 토폴러지 구성이 가능하다. 이를 통해 CXL 2.0 버전에서 지원하는 랙 수준의 연결 규모를 더욱 확장할 수 있다.

CXL 표준이 제정된 이후 산업계에서는 PoC(Proof of Concept) 수준의 제품에서부터 상용 제품에 이르기까지 CXL을 지원하는 다양한 제품이 출시되고 있다. 이 절에서는 CXL을 지원하는 하드웨어들을 소개하고자 한다.

우선, CXL을 지원하는 호스트 프로세서로는 인텔의 서버용 프로세서인 Xeon 시리즈와 AMD의 서버용 프로세서인 EPYC 시리즈가 있다. 표 1은 CXL을 지원하는 프로세서 목록을 정리한 표이다. 표 1의 Sapphire Rapids[10]와 Genoa[11]가 현재 상용으로 출시된 호스트 프로세서이며, 두 프로세서 모두 CXL 1.1을 지원한다.

Sapphire Rapids의 경우 유형 1 및 유형 2 CXL 장치를 지원하며, 메모리 확장 기능을 제공하는 유형 3 CXL 장치는 공식적으로는 지원하지 않는다. 하지만, 지금까지 개발된 유형 3 CXL 장치(예: CXL Memory Expander[12])들을 테스트한 환경 대다수가 Sapphire Rapids였음을 고려하면, 유형 3 CXL 장치를 지원하도록 설계되었지만, 안정성 문제 등으로 인해 공식적으로는 지원하지 않는다고 발표한 것으로 보인다. Genoa의 경우 유형 3 CXL 장치만을 지원하며, CXL 1.1의 메모리 확장 기능에 더해 2.0의 일부 기능(Tiered Memory 기능, 비휘발성 메모리에 대한 메모리 확장 기능)을 추가로 지원한다. CXL 2.0 및 3.0을 지원하는 호스트 프로세서에 대한 대략적인 계획은 표 1에서 확인할 수 있으며, 2024년 하반기에 이르러서야 CXL 2.0을 지원하는 호스트 프로세서가 출시될 것으로 보인다.

다음으로 CXL 장치들을 소개한다. 현재 가장 활발하게 개발되고 있는 CXL 장치 유형은 메모리 확장 기능을 제공하는 유형 3 CXL 장치이다. 유형 3 CXL 장치는 주로 메모리 벤더들에 의해 개발되고 있으며, 대표적으로 삼성전자의 CXL Memory Expander[12], SK 하이닉스의 CXL 2.0 Memory[13], 그리고 Micron의 CXL Memory Expansion Module[14]이 있다. 해당 제품들은 모두 CXL 2.0 버전을 지원하며, 제품에 따라 96GB에서 512GB의 확장 메모리 용량을 지원한다. 세 가지 제품 모두 대용량 스토리지에서 쓰이는 EDSFF(Enterprise & Data Center Standard Form Factor) 폼팩터를 사용하며, 이를 통해 컴퓨팅 노드의 PCIe 슬롯에 add-in 카드 형태로 제품을 장착하여 손쉽게 컴퓨팅 노드의 메모리 용량을 확장할 수 있다. 삼성전자와 SK 하이닉스에서는 자사 CXL 메모리 확장장치를 위한 SDK(Software Development Kit)를 개발하였다[2]. 현재 삼성전자의 SDK는 깃허브를 통해 공개되어 있으며[15], SK 하이닉스의 SDK 또한 가까운 시일 내에 공개될 것으로 보인다.

또 다른 유형 3 CXL 장치로는 Astera Labs의 Aurora[16]가 있다. Aurora는 CXL 컨트롤러가 배치된 PCB 위에 DIMM 슬롯 4개가 있는 add-in 카드 형태로, CXL 2.0 버전을 지원하면서 최대 2TB의 확장 메모리를 지원할 수 있다. 메모리 벤더에서 공개한 메모리 유형 3 CXL 장치들의 경우 아직 상용화되지 않았지만, Aurora의 경우 상용 제품으로 현재 구매가 가능하다는 특장점이 있다.

CXL 2.0 및 3.0 버전의 주요 특징인 리소스 pooling을 위해서는 CXL 스위치가 필요하다. CXL 스 위치를 구현한 제품으로는 XConn사에서 개발한 Apollo[17]가 있다. Apollo는 CXL 2.0과 PCIe 5.0을 지원하는 스위치로서 유형 2 및 유형 3 CXL 장치를 연결하기 위한 256개의 레인과 32개의 포트를 제공한다.

상기 소개한 CXL 장치들 외 PoC 수준에서 CXL의 기능을 검증하고 활용하기 위한 다양한 제품이 논문을 통해 공개되고 있으며, 이들에 대한 설명은 Ⅲ장 2절에서 후술한다.

가. 유형 3 CXL 장치 관련 연구

유형 3 CXL 장치를 통해 CXL 메모리에 접근하는 경우, 네트워크에 연결된 원격 메모리에 접근하는 경우 대비 매우 낮은 지연 시간을 보인다(200ns vs 4μs). 하지만, 여전히 메인 메모리에 접근할 때 발생하는 지연 시간(100ns)에 비하면 많은 시간이 소요된다[18]. 이처럼 CXL 기반 확장 메모리를 컴퓨팅 노드의 메인 메모리와 함께 사용하는 경우, 상대적으로 느린 접근 시간으로 인해 성능 저하가 발생할 수 있다. 최근에는 이러한 성능 저하 수준을 확인하고 CXL 메모리를 효과적으로 활용하기 위한 다양한 연구들이 진행되고 있다.

선행연구[19]에서는 데이터 집약적 작업을 수행할 때 발생하는 메모리 부족 문제 및 이와 동시에 발생할 수 있는 메모리 오버프로비저닝 문제를 지적하면서, CXL 메모리 풀을 사용하는 환경에서 실시간 메모리 요구량에 따라 동적으로 CXL 메모리를 할당하는 DCS(Dynamic Capacity Service)를 제안했다. 이들은 CXL 메모리의 할당 상태 등을 기록하고 관리하기 위한 DCS 엔진을 FPGA를 통해 구현하였고, DCS를 사용하기 위한 SW 프레임워크 및 API(Application Programming Interface)를 구현하였다. CXL 메모리 풀에 연결된 컴퓨팅 노드들에 정적으로 CXL 메모리를 할당한 경우와 DCS를 통해 노드의 메모리 요구량에 따라 동적으로 CXL 메모리를 할당하는 경우 간 메모리 사용률을 비교했을 때, DCS를 사용하는 경우 20% 높은 메모리 사용률을 보였다.

선행연구[20]에서는 CXL.mem 프로토콜을 통해 호스트 프로세서와 CXL 메모리 풀을 연결하는 기술인 DirectCXL을 제안하였다. 이들은 RISC-V를 기반으로 CXL을 지원하는 호스트 프로세서, FPGA를 기반으로 한 CXL 컨트롤러, 그리고 CXL 스위치를 설계 및 구현하여 환경을 구성하였다. 이를 통해 호스트 프로세서가 CXL 메모리 풀에 접근하여 이를 필요한 만큼 자신의 로컬 메모리처럼 활용할 수 있도록 하였다. 딥러닝 및 인-메모리 데이터베이스 벤치마크 등을 활용한 DirectCXL과 RDMA(Remote Direct Memory Access) 기반 메모리 시스템 간 비교 결과에 따르면, DirectCXL은 RDMA 기반 시스템 대비 3배 높은 성능을 보였다. 이는 DirectCXL이 1) 네트워크 인터페이스(예: InfiniBand)와 PCIe 간 인터페이스 변환 작업이 필요한 RDMA 기반 시스템과 달리, 호스트 프로세서와 원격 메모리가 CXL을 통해 직접 연결되었고, 2) DMA를 통해 메모리에 읽기/쓰기 작업을 수행해야만 하는 RDMA 기반 시스템과 달리 CXL.mem을 통해 낮은 접근 지연 시간으로 원격 메모리에 접근하기 때문이라고 저자들은 설명하였다.

상기 연구들 외에도 클라우드 환경에서 CXL 메모리 풀을 활용하는 경우 발생하는 성능 저하 수준 및 비용을 분석하고, CXL 메모리 풀을 효과적으로 클라우드에 적용하기 위한 연구 또한 수행되고 있다. 선행연구[21]에서는 CXL 메모리 풀을 클라우드 환경에 적용할 때 메모리 풀에 연결된 호스트 CPU의 개수에 따라 1) 지연 시간, 2) CXL 메모리 풀 활용에 따른 DRAM 비용 절약 수준, 그리고 3) CXL 메모리 풀 활용에 따른 시스템 비용 절약 수준 측면에서 분석을 진행하였다. 해당 연구의 분석 결과를 요약하면 다음과 같다: 1) 심각한 성능 저하를 방지하기 위해, User VM에 할당된 메모리 중 최소한 25% 이상은 CXL 메모리가 아닌 로컬 메모리로 구성되어야 한다. 2) CXL 메모리 풀에 연결된 호스트의 수가 많을수록 switching latency와 같은 요인들로 인해 메모리 접근에 필요한 시간이 더욱 빠르게 증가한다. 3) CXL 메모리 풀에 연결된 호스트의 수가 증가할수록 시스템에 요구되는 DRAM의 총량이 감소하는 경향을 보이지만, 일정 규모 이상부터는 이러한 효과의 영향이 감소한다. 4) CXL 메모리 풀 도입을 통해 긍정적인 ROI(Return On Investment)를 얻기 위해서는 메모리 풀의 크기, 토폴러지, 수행하는 작업의 특성 등을 모두 고려하여야 한다.

선행연구[3]은 데이터 센터 하드웨어 비용 중 40~50%를 차지하는 DRAM이 런타임 중 최대 25%가 사용되지 않고 낭비되고 있음에 착안하여, CXL 메모리 풀을 통해 퍼블릭 클라우드 플랫폼의 하드웨어 비용을 줄이는 동시에 CXL 메모리가 NUMA 노드의 로컬 메모리와 비슷한 성능을 보이도록 하는 시스템 구조인 Pond를 제안하였다. Pond는 선행 연구[21]에서 분석된 결과와 같이 CXL 메모리 풀에 연결된 호스트의 수를 8~16개로 제한하여 CXL 메모리 풀에 접근할 때 발생하는 지연 시간을 최소화하였다. 또한, VM이 실행할 애플리케이션이 지연 시간에 얼마나 영향을 받는지에 따라 VM이 할당받을 메모리 중 CXL 메모리와 로컬 메모리의 비율을 결정하는 기계학습 기반 예측 모델을 사용하였다. 해당 모델을 통해 지연 시간에 영향을 덜 받는 VM의 경우 CXL 메모리 풀에서 메모리를 더 많이 할당하여 메모리 사용 효율을 올릴 수 있다. Pond는 앞의 방법들을 통해 로컬 NUMA 노드의 메모리를 사용하는 경우 대비 1~5%의 성능 하락만을 동반하며 클라우드 플랫폼에서 사용되는 DRAM의 양을 7% 감소시켰다.

나. NDP 기능을 탑재한 CXL 장치 연구

NDP(Near Data Processing)는 연산에 필요한 데이터와 가까운 위치에서 연산을 수행하여 데이터 이동에 소모되는 비용을 줄여, 시스템의 성능 및 전력 효율을 올리는 설계 방법이다. 이 절에서는 이러한 NDP 개념을 채용하여 CXL 메모리와 가까운 위치에 특정 애플리케이션에 특화된 가속 연산 유닛을 배치하여 성능 및 전력 효율을 향상하고자 한 연구들을 소개한다.

선행연구[22]는 유전체 분석 가속 모듈을 CXL 메모리 근처에 배치하여, NDP를 통해 유전체 분석 작업의 성능 및 에너지 효율 향상을 도모한 연구이다. 기존 DIMM 기반 NDP 가속기는 DIMM 모듈 간 낮은 대역폭 및 메모리 용량으로 인해 제한적인 성능을 보일 수밖에 없었으나, 해당 연구에서는 CXL의 넓은 대역폭 및 메모리 확장 기능을 통해 이러한 한계를 극복하고자 하였다. 해당 연구는 유전체 분석 작업(DNA seeding, K-mer counting 등)에 특화된 NDP 연산 모듈들을 CXL DIMM의 PCB 기판 위 또는 CXL 스위치에 배치하였다. 또한, CXL 메모리의 데이터 전송 단위와 유전체 분석 작업에 필요한 데이터 크기가 달라 발생하는 불필요한 데이터 전송을 없애기 위해 연산에 필요한 데이터를 모아서 전송하는 데이터 패킹 모듈을 배치하여 유전체 분석 작업에 사용되는 데이터 전송 효율을 높였다. 해당 연구의 시뮬레이션[23] 기반 실험 결과에 따르면, 1) CXL 기반 확장 메모리, 2) NDP 유닛, 그리고 3) 데이터 전달 메커니즘 최적화를 통해 기존 DIMM 기반 유전체 분석 NDP 가속기 대비 4배 이상의 유전체 분석 성능 향상을 이룰 수 있으며, 에너지 소모 또한 크게 줄일 수 있음을 밝혔다.

선행연구[24]는 CXL 메모리 카드 내부에 KNN(K-Nearest Neighbor) 연산에 특화된 NDP 모듈을 배치하여 연산 과정에서 소요되는 데이터 전송 오버헤드를 줄인 CMS(Computational CXL-Memory Solution)를 제안하였다. 해당 연구에서 저자는 메모리 집약적 작업을 처리하는 경우 여전히 부족한 CXL의 대역폭을 지적하며, 연산을 위한 데이터가 CXL을 거칠 필요 없이 호스트 프로세서가 NDP 모듈을 통해 계산된 결과만 바로 읽어갈 수 있도록 CMS의 구조를 설계하였다. 또한, CMS 내부 메모리 대역폭을 최대로 활용하기 위해 CXL 메모리의 채널을 효과적으로 인터리빙(Interleaving)하는 방법 및 성능 최적화된 MAC(Multiply and Accumulate) 구조, 그리고 CMS API를 제안하였다. Xilinx FPGA를 기반으로한 CMS 프로토타입상에서 진행된 실험에 따르면, CMS는 CPU만 사용하는 컴퓨팅 환경 대비 3.2배 높은 KNN 벤치마크[25] 성능을 보였으며, 34% 낮은 에너지 소모를 보였다.

다. CXL 관련 소프트웨어 연구

CXL 장치를 사용자 수준에서 효과적으로 사용하기 위해서는 이를 지원하는 소프트웨어가 필수적이다. 선행연구[2]에서는 유형 3 CXL 장치의 확장 메모리를 효율적으로 활용하기 위한 SMDK(Scalable Memory Development Kit)를 제안하였다[15]. SMDK는 CXL 메모리와 로컬 메모리를 구분하여 관리하기 위한 리눅스 커널의 VMM(Virtual Memory Management) 기반 SMDK.kernel과 CXL 메모리와 로컬 메모리로 구성된 계층 메모리(Tiered Memory) 구조에서 애플리케이션에 대한 메모리 할당을 담당하는 SMDK.allocator로 구성되어 있다. 사용자는 SMDK.allocator에 포함된 User API를 통해 CXL 메모리와 로컬 메모리 중 할당받을 메모리의 우선도, 목표 대역폭 및 용량 등의 선호도 옵션(User Preference)을 설정할 수 있다. SMDK와 CXL 유형 3 장치를 사용한 시스템과 DRAM 메모리만을 사용한 시스템 간 딥러닝 및 인-메모리 데이터베이스 애플리케이션 기반 성능 비교를 수행한 결과, SMDK를 사용한 시스템이 1.5~1.99배 더 좋은 성능을 보였다.

현재 CXL HW/SW 생태계가 안정화되지 않았기 때문에 선행연구[20]처럼 직접 모든 HW 및 SW를 구현하여 실험 환경을 구축하지 않는 이상 CXL 관련 연구를 진행하는 데 어려움이 있다. 이에 선행 연구[26]에서는 유형 3 CXL 장치를 시뮬레이션할 수 있는 CXL 시뮬레이터[27]를 제안하였다. 제안된 시뮬레이터는 호스트 프로세서에서 동작하는 사용자 프로그램의 trace를 기반으로 하여, 해당 프로그램을 사용자가 설정한 CXL 메모리 토폴러지상에서 실행하는 경우를 시뮬레이션한다. 해당 CXL 시뮬레이터는 native 환경 대비 평균 41배 느린 애플리케이션 수행 시간을 보였지만, 시스템 레벨 시뮬레이터인 Gem5 기반 CXL 시뮬레이터[28] 대비 평균 73배 빠른 수행 시간을 보였다. CXL 관련 생태계가 안정되지 않은 현재 상태에서, 이러한 시뮬레이터를 기반으로 CXL 관련 연구를 수행하는 것이 가능할 것이다.