RDMA는 커널과 원격 CPU를 일반적인 데이터 전송 경로에서 제외하지만 스케줄링까지 없애지는 않습니다. 스케줄링은 내부 자원이 소프트웨어에 거의 보이지 않는 네트워크 인터페이스로 이동합니다. 두 애플리케이션이 서로 다른 큐 페어(QP)를 사용해도 같은 사용자 접근 영역(UAR), 컨텍스트 캐시, 처리 파이프라인, 물리 포트를 두고 경쟁할 수 있습니다. 지연이 늘어났을 때 동작 요청 인터페이스는 완료 상태로 증상을 보여 줄 뿐, 어느 공유 자원이 원인인지 알려 주지 않습니다.
SwiftRDMA는 이 불투명성을 자원 관리 문제로 정의합니다[1]. 새로운 전송 프로토콜을 추가하지 않고 상용 RNIC 위에 소프트웨어 스케줄러를 둡니다. 스케줄러는 하드웨어와 애플리케이션 신호를 관찰해 경합 지점을 찾고, 큐 페어 재배치, 연결 재사용 또는 추가, 요청 제출 속도 조정, 트래픽 클래스 배정과 같은 동작을 실행합니다. 장기 목표는 p99 지연을 일정 값 아래로 유지하라는 운영자의 요구를 이러한 저수준 제어로 변환하는 것입니다.
이 논문은 8쪽 분량의 워크숍 논문입니다. 완성된 프로덕션 스케줄러나 선언형 정책 언어, 클러스터 전체 평가를 제시하지 않습니다. RNIC 간섭을 더 정확히 설명할 수 있는 자원 지도를 만들고, 네트워크 문제처럼 보이는 현상 중 일부가 패킷이 케이블에 들어가기 전에 시작된다는 점을 보여 준 데 의미가 있습니다.
동작 요청 인터페이스 뒤의 다섯 공유 자원
첫 번째 경합 지점은 UAR입니다. 애플리케이션은 RNIC가 매핑한 페이지를 통해 도어벨을 울리고 BlueFlame 레지스터를 사용합니다. 논문이 분석한 Mellanox ConnectX-6 장치 컨텍스트는 UAR 페이지를 16개만 노출합니다. 큐 페어는 무작위 또는 라운드 로빈에 가까운 정책으로 이 페이지에 배치됩니다. 서로 다른 CPU 코어가 구동하는 큐 페어가 같은 페이지에 놓이면 잠금으로 접근이 직렬화됩니다. 링크 대역폭이 남아 있어도 데이터 경로가 느려질 수 있습니다.
두 번째는 RNIC 컨텍스트 캐시입니다. 작업 요청을 실행할 때 큐 페어 상태와 메모리 변환 항목이 필요합니다. 활성 큐 페어가 많거나 작은 페이지를 등록하면 캐시 미스가 늘어납니다. RNIC는 PCIe를 통해 호스트 메모리에서 메타데이터를 가져오며, 그동안 처리 장치가 멈춥니다. 논문이 인용한 마이크로벤치마크에서는 캐시 미스율이 17.2%에서 49.1%로 높아질 때 처리량이 96.6Gbit/s에서 48Gbit/s로 낮아졌습니다. 연결 수는 소프트웨어 핸들의 개수가 아니라 제한된 온디바이스 캐시를 소비하는 값입니다.
세 번째 자원은 제어, 송신, 수신 처리 파이프라인입니다. 각 파이프라인은 독립적으로 포화될 수 있습니다. 특히 수신 경로가 밀리면 완료 처리가 늦어지고, 송신 카운터가 정상이어도 애플리케이션에 역압력이 전파될 수 있습니다. 네 번째는 큐 페어 내부와 큐 페어 사이의 경합입니다. 하나의 큐 페어를 공유한 요청은 FIFO 순서를 따르므로 우선순위가 낮은 전송이 지연 민감 전송을 막을 수 있습니다. 큐 페어를 분리하면 선두 막힘은 피하지만 포트에서 다시 경쟁합니다. 마지막으로 물리 링크와 우선순위 큐가 총수요가 회선 속도에 도달했을 때 어떤 트래픽을 먼저 보낼지 결정합니다.
자원들은 서로 영향을 줍니다. 큐 페어를 재사용하면 컨텍스트 캐시 압력은 줄지만 관련 없는 트래픽이 같은 FIFO를 공유할 가능성이 커집니다. 큐 페어를 늘리면 지연 등급을 분리할 수 있지만 캐시와 UAR 항목을 더 사용합니다. 큰 메모리 페이지는 변환 항목을 줄이는 대신 메모리 관리의 유연성을 바꿉니다. 유용한 스케줄러는 한 카운터만 최대로 만들 수 없습니다. 작업의 서비스 수준 목표(SLO)에 맞는 동작점을 골라야 합니다.
제어 동작과 연결된 관찰 신호
SwiftRDMA의 핵심 원칙은 소프트웨어가 실행할 동작이 있을 때만 신호를 노출하는 것입니다. UAR 압력은 큐 페어 배치, 페이지별 활동, 처리량으로 추정할 수 있습니다. 스케줄러는 큐 페어를 UAR 페이지 사이에 다시 배치하거나 균형화합니다. 컨텍스트 캐시 압력은 QP 컨텍스트와 메모리 변환 캐시 미스, 활성 객체 수, 완료 지연으로 확인합니다. 큰 페이지를 사용하거나 연결을 합치고, 캐시 압력이 낮지만 큐 지연이 늘면 큐 페어를 추가할 수 있습니다.
파이프라인 활용률과 큐 깊이는 처리 장치 경합을 보여 줍니다. 소프트웨어는 요청 제출 속도를 조절하거나 동작을 묶고, 제어 경로 사용 특성이 다른 작업을 분리할 수 있습니다. 큐 페어 내부 경합은 대역폭 활용률과 큐 지연, 꼬리 지연을 함께 봐야 합니다. 활용률이 낮은데 p99 지연이 늘면 포트 포화보다 FIFO 선두 막힘일 가능성이 큽니다. 이때는 작업별 가중치를 바꾸거나 다른 큐 페어로 분리합니다. 포트가 포화됐다면 트래픽 클래스와 속도 제어가 더 적절합니다.
이 연결은 텔레메트리의 흔한 문제를 줄입니다. 대시보드가 높은 캐시 미스율만 보여 주면 운영자는 큐 페어를 늘릴지 줄일지 판단하기 어렵습니다. SwiftRDMA는 RNIC를 제어 가능한 자원의 집합으로 봅니다. 관찰 값은 안전한 동작의 범위를 좁히고, 각 동작이 다른 자원에 만드는 비용까지 고려합니다.
두 사례가 보여 준 개선 범위
UAR 평가는 Intel Xeon CPU 32개, 메모리 128GB, 100Gbit/s Mellanox ConnectX-5 RNIC를 갖춘 서버로 진행했습니다. 가장 나쁜 UAR 배치를 기준으로 사용했습니다. UAR 경합은 키·값 저장소 GET 처리량을 최대 57% 낮췄습니다. SwiftRDMA가 큐 페어를 여러 UAR 페이지에 균형 있게 배치하자 처리량은 해당 기준의 최대 2.22×가 됐습니다. 패킷이 혼잡 제어 대상이 되기 전에 호스트의 도어벨 경로에서 막힌 문제를 해결한 결과입니다.
포트 경합 평가는 지연 민감 키·값 작업과 지속적인 64KB 최선형 트래픽을 함께 실행했습니다. 기본 구성에서는 두 작업이 같은 트래픽 클래스를 사용합니다. SwiftRDMA는 키·값 큐 페어에 더 높은 RNIC 트래픽 클래스를 배정했습니다. 함께 실행한 기본 구성보다 평균 지연은 최대 35%, p99 지연은 최대 25% 줄었습니다. 격리 실행에 가까운 지연을 회복해, RNIC에 이미 있는 우선순위 기능도 소프트웨어가 작업의 목적과 올바르게 연결해야 효과가 생긴다는 점을 보여 줍니다.
논문은 정책의 예도 제시합니다. 지연 민감 작업, 처리량 민감 작업, 두 목표를 함께 가진 작업을 운영자 의도에 따라 정렬합니다. 포트 활용률이 80% 아래인데 꼬리 지연과 큐 지연이 임계값을 넘으면 지연 민감 작업의 태스크 큐 가중치를 올립니다. 포트 활용률이 높다면 더 높은 트래픽 클래스를 배정합니다. 이 구분을 통해 실제로는 하나의 FIFO 안에서 막힌 요청에 링크 우선순위를 잘못 적용하는 일을 피할 수 있습니다.
수치 결과는 개별 동작을 검증한 것이며 전체 피드백 루프를 검증한 것은 아닙니다. 컨텍스트 캐시 미스율 30%나 활성 큐 페어 512개 같은 임계값은 평가한 하드웨어에 맞춘 예입니다. 다른 세대의 RNIC는 카운터, 캐시 크기, 스케줄링 방식이 다를 수 있습니다. 이식 가능한 정책 시스템에는 하나의 공통 임계값 표보다 장치 기능 탐색과 제조사별 어댑터가 필요합니다.
정책 컴파일과 안정성에 남은 과제
SwiftRDMA는 정책 컴파일, 가벼운 연속 모니터링, 적용 비용, 여러 경합이 동시에 발생할 때의 처리를 후속 과제로 남겼습니다. 이들은 단순 구현 문제가 아닙니다. 카운터마다 샘플링 주기가 다르고 짧은 버스트를 놓칠 수 있습니다. 제어 동작이 그 동작을 고를 때 사용한 신호 자체를 바꿀 수도 있습니다. 큐 페어 재배치와 트래픽 클래스 변경은 순서, 공정성, 격리에 영향을 줍니다. 안정적인 제어기는 여러 구성 사이에서 반복적으로 흔들리지 않아야 합니다.
평가 범위는 한 머신과 한 RNIC입니다. AI 집단 통신은 여러 RNIC, 스위치, GPU 프로세스에 걸쳐 있고 클러스터 스케줄러가 배치와 연결 수를 계속 바꿉니다. 로컬 스케줄러가 한 호스트를 개선하면서 혼잡을 패브릭으로 옮길 수 있습니다. 논문도 집단 통신 및 계층형 클러스터 스케줄링과의 결합을 후속 방향으로 제시합니다. 실제 적용에는 애플리케이션 런타임, 컨테이너 또는 가상머신 계층, RNIC 드라이버, 네트워크 정책 사이의 조정이 필요합니다.
신뢰 경계도 정해야 합니다. 제어 기능을 테넌트에 그대로 노출하면 다른 작업에 피해를 줄 수 있고, 모든 동작을 권한이 있는 에이전트에만 두면 애플리케이션별 정보가 부족해집니다. 테넌트가 선언할 수 있는 목표와 중앙에서 강제할 동작을 운영자가 구분해야 합니다. 트래픽 클래스 수는 제한적이며, 컨텍스트 카운터는 다른 테넌트의 활동을 간접적으로 드러낼 수 있습니다.
링크 대역폭에 더할 RNIC 작업 집합
클라우드 입장 제어는 CPU 코어, 메모리, GPU, 링크 대역폭을 주로 계산합니다. SwiftRDMA는 RNIC 작업 집합도 포함해야 한다고 말합니다. 각각 20Gbit/s를 요구하는 두 작업이라도 하나가 수천 개의 큐 페어를 열고, 4KB 페이지를 등록하며, 제어 요청을 많이 만든다면 같은 자원 요구가 아닙니다. 컨텍스트 캐시 사용량과 UAR 배치가 다른 테넌트의 지연 목표를 결정할 수 있습니다.
운영자가 바로 할 수 있는 일은 미완성인 SwiftRDMA를 배포하는 것이 아닙니다. 호스트 RNIC 경합과 네트워크 혼잡을 구분하는 신호를 수집하고, 연결 수, 등록 페이지 크기, 트래픽 클래스, 큐 배치를 입장 제어 변수로 만드는 것입니다. 실행 동작과 되돌리기 조건이 분명한 몇 가지 제한된 정책부터 시작할 수 있습니다.
RNIC 제조사에는 성능 카운터만 제공해서는 부족하다는 의미입니다. 각 카운터가 나타내는 자원을 문서화하고, 소프트웨어가 변경할 수 있는 안전한 제어 지점을 제공하며, 제어 중에도 격리를 유지해야 합니다. 프레임워크 개발자에게는 큐 페어를 늘리는 일이 비용 없는 동시성 확장이 아니라는 뜻입니다. 모든 연결은 제한된 온디바이스 작업 집합의 일부입니다.
커널 우회는 자원 관리를 제거하지 않습니다. 기존에 관리하던 구성 요소를 지나칠 뿐입니다. RDMA가 여러 작업이 공유하는 클라우드 기능이 되면서 애플리케이션 의도와 RNIC 상태가 만나는 경계에 스케줄링이 다시 필요해졌습니다. SwiftRDMA는 초기 단계지만 그 경계를 구체적으로 보여 줍니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 분석입니다. 원문의 메커니즘, 측정 결과, 후속 과제를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 재수록하지 않았고 이 페이지의 도판은 모두 새로 만들었습니다. 원문은 ACM DOI에서 확인할 수 있으며 CC BY 4.0으로 공개되었습니다. 저작권은 저자에게 있습니다. 2025.