클라우드 서버에는 메모리만 남는 것이 아닙니다. 한 자원이 먼저 소진되면 다른 자원이 남아도 새 가상머신을 받을 수 없습니다. 이 HotOS 논문이 인용한 Microsoft Azure 측정에서는 SSD 용량의 평균 54%, NIC 대역폭의 29%가 서버 안에서 쓰이지 못한 채 남습니다.[1] 하드웨어 풀링은 이 자원을 회수할 수 있지만, 큰 PCIe 스위치는 자체 비용이 있고 장애 영역을 넓히며 포트 구성을 고정합니다.

논문은 다른 방법을 제안합니다. 데이터센터가 DRAM 효율을 위해 CXL 메모리 풀을 이미 도입한다면, 그 공유 메모리를 원격 PCIe 장치의 데이터 경로로도 쓰자는 것입니다. NIC, SSD, FPGA는 서버 한 대에 물리적으로 연결된 상태를 유지합니다. 다른 서버는 장치와 요청 호스트가 모두 접근할 수 있는 CXL 메모리에 I/O 버퍼를 둡니다. PCIe 링크를 하드웨어로 바꾸는 대신 메모리 위에 소프트웨어 간접 경로를 만드는 방식입니다.

이 글은 완성된 운영 시스템 논문이 아니라 HotOS 포지션 페이퍼입니다. 가치는 구조를 다르게 보는 관점과 첫 번째 반론을 확인한 프로토타입에 있습니다. 따라서 측정한 결과, 계산으로 예상한 범위, 아직 구현하지 않은 오케스트레이터의 역할을 분리해 읽어야 합니다.

서버 내 유휴 자원의 풀링 필요성

로컬 장치 구성은 CPU, DRAM, SSD, NIC 대역폭의 비율을 서버를 살 때 고정합니다. 실제 작업은 이 자원을 같은 비율로 쓰지 않습니다. 한 항목이 가득 차면 다른 항목의 여유를 이웃 서버에 제공할 수 없습니다. 논문은 수요가 독립적이라는 조건에서 서버 8대를 풀링하면 SSD의 남는 용량이 54%에서 19%, NIC의 남는 대역폭이 29%에서 10%로 줄 수 있다고 계산합니다.

이 값은 제안한 시스템을 배치해 측정한 결과가 아닙니다. 관측한 평균과 수요 독립성에 기반한 용량 상한 분석입니다. 가용 영역, 배치 제약, 동시에 발생하는 트래픽은 피크를 서로 연관시킬 수 있습니다. 중요한 판단은 더 좁습니다. 랙의 절반 정도만 묶어도 독립적인 순간 수요에 필요한 예비 용량을 줄일 수 있으므로, 소프트웨어 풀이 랙 전체에 도달하기 전에도 가치가 생길 수 있습니다.[2]

PCIe 풀링은 장애 대비 방식도 바꿉니다. NIC 하나만 가진 서버는 NIC가 고장 나면 접근할 수 없습니다. 공유 풀은 모든 서버에 예비 NIC를 하나씩 넣는 대신 다른 NIC로 작업을 옮길 수 있습니다. 사용 빈도가 낮은 가속기도 적합합니다. FPGA나 스마트 SSD 하나를 서버 16대가 나눠 쓰면 모든 호스트를 PCIe 스위치에 연결하지 않고도 장치 활용률을 높일 수 있습니다.

원격 PCIe를 대체하는 공유 버퍼

CXL.mem을 이용하면 CPU와 장치가 장치 메모리에 load/store와 DMA를 수행할 수 있습니다. 제안한 경로는 송수신 버퍼를 공유 CXL 주소 구간에 할당합니다. 서버 A에 연결된 NIC가 이 구간에 DMA하고, 서버 B의 응용이 CXL 링크를 통해 같은 버퍼를 읽거나 씁니다. 장치 펌웨어와 PCIe 엔드포인트는 바꾸지 않습니다. 사용자 공간 I/O 스택의 할당기만 달라집니다.

평가한 장치에는 여러 호스트 사이의 하드웨어 캐시 일관성이 없으므로 소프트웨어가 이를 관리합니다. CPU 쓰기는 비시간적 저장(non-temporal store)을 사용해 데이터가 개인 캐시에 남지 않고 풀에 도달하게 합니다. 제어 메시지는 CXL 메모리에 둔 64바이트 슬롯 링으로 전달합니다. 원격 MMIO 요청과 이벤트를 장치가 실제로 연결된 호스트에 보내는 채널입니다.

데이터 경로는 하나가 아니라 둘입니다. 패킷과 블록 데이터는 공유 버퍼를 지나지만, 원격 CPU는 다른 루트 컴플렉스 아래 장치에 직접 MMIO할 수 없으므로 제어 연산은 장치 소유 호스트에서 실행합니다. 올바른 구현은 두 경로의 순서를 맞춰야 합니다. 버퍼 내용이 다른 호스트에 보이기 전에 완료 플래그가 먼저 관찰되어서는 안 됩니다.

소프트웨어 PCIe 풀링의 개념 하드웨어 도판입니다. 서버와 주변 장치는 물리 연결을 유지하고, 공유 CXL 메모리 장치가 원격 호스트와 DMA 장치에 모두 보이는 I/O 버퍼를 보관합니다. 재질 렌더링은 제품 사진이나 제조 도면이 아니며 역할 표시는 코드로 합성했습니다. 이 글을 위해 새로 만든 도판.

100Gbps 프로토타입이 확인한 것

평가는 소켓 2개 서버, 100Gbps Mellanox ConnectX-5 NIC, 여러 호스트가 연결되는 CXL 포드를 사용합니다. CPU마다 PCIe 5.0 x8 링크로 풀에 닿습니다. NIC는 소켓 0에 연결하고, 수정한 Junction 사용자 공간 네트워크 스택은 소켓 1에서 실행합니다. Junction은 TX/RX 버퍼만 CXL 메모리에 할당하고 큐 구조는 옮기지 않습니다. 두 번째 서버는 100Gbps 네트워크 스위치를 통해 UDP 트래픽을 만듭니다.

75바이트, 1,500바이트, 9,000바이트 페이로드 모두에서 로컬 DDR5 버퍼와 CXL 버퍼의 지연-처리량 곡선 차이는 무시할 수준입니다. PCIe 5.0 x8 경로 두 개가 100Gbps NIC를 포화할 대역폭을 제공하므로 최대 처리량도 줄지 않습니다. 수백 ns 늘어난 메모리 지연이 패킷 전체 지연에 그대로 더해지지는 않는다는 결과입니다. 배치, 큐잉, 네트워크 시간이 더 크기 때문입니다.

제어 링의 단방향 메시지 지연 중앙값은 약 600ns입니다. CXL 쓰기 한 번과 읽기 한 번을 더한 이론적 하한에 가깝고, 하드웨어 일관성 없이도 1µs 아래입니다. 원격 이벤트 전달의 가능성을 보여 주지만, 이 결과는 ping-pong 마이크로벤치마크입니다. 연결 마이그레이션, 큐 재구성, 재전송 상태, 소유 호스트 장애는 포함하지 않습니다.

저자들은 소켓당 PCIe 5.0/CXL 레인 64개를 제공하는 Xeon 6에서 200Gbps NIC는 x8, 400Gbps NIC는 x16으로 풀링할 수 있다고 계산합니다. 레인 대역폭으로 가능한 범위를 계산한 것과 400Gbps NIC 두 개를 실제로 측정한 것은 다릅니다. 루트 컴플렉스의 피어 트래픽, 읽기와 쓰기 비대칭, DMA 순서, 공유 풀 경합 때문에 실제 대역폭은 낮아질 수 있습니다.

실제 시스템의 핵심인 오케스트레이터

제안한 제어 계층은 호스트마다 풀링 에이전트를 두고, CXL 포드 안에 관리 컨테이너를 실행합니다. 장치 목록과 사용률, 상태를 확인하고 호스트에 장치를 배정하며 과부하나 장애가 생기면 작업을 옮깁니다. 요청 호스트에 임계값 아래의 로컬 장치가 있으면 이를 쓰고, 없으면 접근 가능한 장치 중 사용률이 가장 낮은 것을 선택합니다.

포지션 페이퍼에는 충분한 설명이지만 실제 운영에 큰 영향을 주는 선택은 남아 있습니다. NIC 상태에는 큐, 도어벨, 플로 스티어링, 혼잡 제어, 전송 중 패킷이 포함됩니다. SSD에는 네임스페이스, 제출·완료 큐, 쓰기 순서, 내구성 상태가 있습니다. 가속기는 로컬 메모리에 응용 상태를 보관할 수 있습니다. 공유 버퍼 포인터만 바꾼다고 이 상태까지 이동하지는 않습니다.

격리도 중요합니다. 공유 물리 주소는 새로운 DMA 신뢰 경계가 됩니다. 테넌트별 주소 보호, 재배정 후 접근 철회, 속도 제한, 임대가 끝난 뒤에도 DMA를 계속하는 장치에 대한 차단이 필요합니다. 풀의 패브릭 관리자와 호스트 IOMMU가 소유권 변경에 동의해야 합니다. 그렇지 않으면 소프트웨어의 유연성이 하드웨어 PCIe 스위치보다 더 넓은 장애 범위를 만들 수 있습니다.

HotOS 제안의 근거와 한계를 나눈 도판입니다. Microsoft Azure 데이터에서는 SSD 용량 54%, NIC 대역폭 29%가 남았습니다. 프로토타입은 약 600ns 메시지 전달과 100Gbps NIC 한 대의 성능 유지에 성공했지만, 운영 환경의 장애 전환과 고대역폭 가속기는 평가하지 않았습니다. 이 글을 위해 새로 만든 도판.

적용 우선순위가 높은 장치

범용 네트워크와 저장 장치가 첫 적용 대상으로 적합합니다. 전체 I/O 연산 시간이 CXL의 추가 load 지연보다 길고, 호스트별 사용률 변화도 큽니다. 논문도 HPC와 머신러닝 장치에는 신중합니다. GPU와 고속 가속기는 수백 GB/s를 사용하고, 플랫폼마다 제약이 다른 피어 투 피어 경로와 더 엄격한 완료 의미를 요구합니다.

이 아이디어는 메모리만으로도 CXL 풀의 투자 효과가 양수라는 전제에 기대고 있습니다.[3] PCIe 스위치를 없애기 위해 CXL을 새로 구축하면 비용식이 달라집니다. 반대로 여러 포트가 달린 메모리 장치나 Octopus 같은 희소 포드[4]를 이미 운영한다면 링크, 주소 변환, 패브릭 관리 계층을 재사용하므로 추가 소프트웨어 경로의 비용이 낮아집니다.

운영 수용 시험에 필요한 항목

첫 시험은 두 호스트가 동시에 트래픽을 만들고 세 번째 작업이 메모리 대역폭을 포화한 상태에서 논문의 UDP 결과를 재현해야 합니다. p50, p99, p99.9 패킷 지연, CXL 읽기·쓰기 트래픽, 루트 컴플렉스 카운터, 로컬 사용자와 원격 사용자 사이의 공정성을 함께 보고해야 합니다. 고립된 NIC 한 대의 선속도보다 DMA와 CPU 접근이 섞일 때 예측 가능성이 유지되는지가 중요합니다.

두 번째 시험은 활성 연결이 있는 상태에서 장치 소유 호스트를 중단합니다. 장애를 감지하고 버퍼를 동결하거나 무효화하며, 다른 위치에서 장치 상태를 복원하고 오래된 메모리를 노출하지 않은 채 트래픽을 재개해야 합니다. SSD에서는 확인이 끝난 쓰기의 내구성과 순서도 검증해야 합니다.

마지막은 접근 철회 시험입니다. 테넌트가 장치를 반납한 뒤 예전 프로세스와 장치가 대기 중인 DMA를 이용해 재배정된 주소에 접근할 수 없어야 합니다. 이 시험을 통과해야 논문의 효율적인 데이터 경로가 운영 시스템이 됩니다. 현재 근거로 내릴 수 있는 결론은 CXL 풀이 PCIe 버퍼를 효율적으로 전달할 수 있다는 것이지, PCIe 스위치를 이미 대체했다는 것은 아닙니다.

출처와 저작권 안내

이 글은 Silicon & Systems가 작성한 편집 분석입니다. 원문의 논지를 우리 표현으로 다시 썼으며 문장, 표, 도판을 복제하지 않았습니다. 본문 도판 두 장은 독립적으로 제작했습니다. 원문은 ACM SIGOPS HotOS 2025, DOI 10.1145/3713082.3730393에서 확인할 수 있습니다. 저작권은 소유자와 저자들에게 있습니다. (c) 2025.