스토리지 서버마다 요청이 고르게 들어간다고 해서 고객 간 간섭이 줄어드는 것은 아닙니다. 소수의 작업이 짧은 시간에 많은 I/O를 만들면 부하 분산이 그 요청을 여러 서버에 동시에 전달할 수 있습니다. 총 요구량이 처리 여유를 넘는다면 분산이 잘될수록 여러 서버가 함께 대기열을 쌓는 상황도 생깁니다.
Alibaba Cloud와 칭화대의 NSDI 2026 논문은 실제 블록 스토리지에서 관측한 이 문제를 다룹니다[1]. 이미 여러 단계의 부하 분산을 적용했지만 긴 지연이 남았고, 연구진은 가상 디스크의 일부 세그먼트에서 발생한 버스트가 평상시 요청까지 지연시키는 원인을 확인했습니다. 해결책은 배치를 다시 바꾸는 것보다 짧은 시간에 어떤 요청을 허용할지 정하는 데 있습니다.
한편 부하가 낮을 때에는 다른 원인이 나타났습니다. 프록시의 이벤트 루프에서 I/O와 직접 관계없는 작업이 새 요청의 처리를 늦췄습니다. 이 논문은 과부하와 한산한 상황을 같은 원인으로 묶지 않고 각각의 제어 방법을 제시합니다. 버스트를 막는 장치만 추가해도 낮은 부하의 지연이 모두 해결되지는 않는다는 뜻입니다.
부하 분산 이후에도 남는 고객 간 간섭
대상 시스템은 컴퓨트, 프록시와 영속 스토리지를 분리합니다. VM이 보낸 블록 요청은 프록시에서 하부 분산 파일시스템의 연산으로 변환됩니다. 프록시는 단순히 패킷을 전달하는 역할뿐 아니라 인덱스와 유지보수 작업도 수행하므로, 내부 처리 순서가 최종 지연에 영향을 줍니다.
가상 디스크는 여러 프록시가 담당할 수 있는 세그먼트로 나뉩니다. 작은 논리 블록을 세그먼트들에 분산해 국소적인 접근을 흩뜨리되, 메타데이터 객체 수가 과도하게 늘지 않도록 합니다. 따라서 세그먼트는 배치와 제어의 단위이며 반드시 하나의 연속된 주소 범위와 같은 의미는 아닙니다.
본문의 대표 분석에서 프록시 간 요청률의 변동계수는 평균 0.12로 비교적 고른 편입니다. 그런데도 버스트가 충분히 크면 전체 서버가 적정 처리율을 넘습니다. 이 경우에는 어느 서버로 옮길지가 아니라, 공통 자원이 잠시 부족해졌을 때 누구의 요청을 먼저 처리할지가 중요해집니다.
고객별 사용량 집중도도 영향을 줍니다. 표본 클러스터에서는 상위 세 고객이 평균적으로 트래픽의 63%를 차지했습니다. 이들이 의도적으로 방해하지 않아도 행사나 업무 패턴에 따라 수요가 함께 증가하면 다른 고객의 평상시 요청도 밀릴 수 있습니다. 개별 고객의 요청률이 일정하다는 사실이 공유 자원의 지연까지 일정하게 만들지는 않습니다.
이 분포는 Alibaba의 표본에서 관측한 값입니다. 다른 클라우드에서도 같다고 전제하기보다 고객 식별자, 디스크 배치와 버스트 시각을 연결해 확인해야 합니다. 클러스터 평균 활용률만 보면 어떤 집단이 부하를 만들고 어떤 집단이 간섭을 받는지 놓칠 수 있습니다.
고객 전체 제한과 데이터 이동의 한계
고객별 고정 상한은 버스트를 줄일 수 있지만 여유가 있을 때 쓸 수 있는 성능도 제한합니다. 논문에서는 강한 대역폭 제한을 적용한 시험에서 프록시 용량의 27%가 평균적으로 사용되지 않았다고 보고합니다. 큰 고객의 가상 디스크 안에서도 일부 세그먼트만 뜨거울 수 있으므로 고객 전체를 같은 방식으로 제한하는 것은 지나치게 넓은 제어가 될 수 있습니다.
다른 클러스터로 옮기는 방식은 지속적인 불균형에 적합하지만 짧은 버스트와 시간 규모가 맞지 않습니다. 본문에서 설명한 클러스터 간 이동은 약 20분이 걸리는 반면, 관측한 버스트 상당수는 100ms보다 짧습니다. 요청이 몰릴 때마다 이동을 시작해도 해당 버스트를 제때 처리하기 어렵습니다.
연구진은 기본 서비스로 보장하는 I/O와 이를 넘는 최선형 버스트 요청을 구분합니다. 목표는 큰 고객을 일괄적으로 불리하게 만드는 것이 아니라, 추가 수요가 평상시 서비스에 필요한 자원을 모두 차지하지 못하게 하는 것입니다. 큰 고객에게 속한 세그먼트라도 안정적인 요청을 내고 있다면 보호 대상이 될 수 있습니다.
세그먼트별 감시기는 짧은 구간의 요청률을 보고 상태를 분류합니다. 한 번 낮아졌다고 바로 평상시 상태로 돌아가게 하지 않고 일정 기간 기준 아래에 머무는지 확인해 흔들림을 줄입니다. 분류 기준과 관측 기간은 어떤 요청에 보호를 제공하는지 결정하므로 실제 서비스의 보장 조건에 맞게 설정해야 합니다.
별도 토큰으로 보호하되 추가 용량으로 착각하지 않는 구조
제어기는 모든 세그먼트가 사용할 수 있는 기본 토큰과 평상시 세그먼트만 사용할 수 있는 보조 토큰을 관리합니다. 정상 상황에서는 기본 토큰으로 요청을 처리합니다. 버스트가 기본 토큰을 빠르게 소모하면 평상시 요청은 보조 토큰을 사용해 같은 대기열 뒤에 오래 머무는 것을 피합니다.
저장 계층에 남은 여유를 활용해 첫 구간에서는 정규 예산보다 조금 더 허용할 수 있습니다. 다만 이 초과 허용을 계속 유지하지 않습니다. 다음 토큰 공급에서 보조 몫을 먼저 채운 뒤 나머지를 기본 풀에 제공하므로, 버스트가 지속되면 뜨거운 세그먼트가 사용할 수 있는 몫이 줄어듭니다.
보조 토큰은 SSD의 물리적 처리량을 새로 만드는 장치가 아닙니다. 어떤 요청이 제때 진행할 수 있는지와 버스트를 흡수하는 시점을 바꾸는 장치입니다. 초기 초과분의 제한과 이후 상환이 없다면 프록시의 대기를 하부 스토리지로 옮기는 데 그칠 수 있습니다.
운영 설정의 구간은 10ms이며 보조 몫은 처음 20%로 설정하고 조정할 수 있다고 설명합니다. 모든 블록 스토리지에 적용되는 표준값은 아닙니다. 보조 몫을 늘리면 평상시 요청을 더 보호할 수 있지만, 뜨거운 요청이나 저장 계층에 부담이 커질 수 있습니다. 반대로 너무 작으면 보호하려던 지연이 그대로 남습니다.
짧은 관측으로 긴 지연을 추정할 때의 조건
99.999번째 백분위 지연을 안정적으로 측정하려면 많은 표본이 필요합니다. 밀리초 단위로 변하는 버스트를 기다렸다가 제어하기에는 너무 느릴 수 있습니다. 구현은 더 자주 관측할 수 있는 P95와 보정한 대기행렬 모델을 이용해 현재의 처리 여유를 추정합니다.
이는 관측이 쉬운 지표로 부하 상태를 추정하는 접근입니다. 실제 도착과 처리 시간이 이상적인 분포를 그대로 따르지 않으므로 보정과 안전 여유를 둡니다. 요청 크기, 가비지 컬렉션, 장치 상태와 동시성이 바뀌면 두 지표의 관계도 달라질 수 있습니다. 한 번 맞춘 모델을 모든 조건에 그대로 쓰기는 어렵습니다.
원문에 인쇄된 식에는 부호상 일관되지 않은 부분이 있습니다. 그대로 계산하면 양의 처리 여유와 0~1 사이 백분위에서 음의 시간이 나오므로, 이를 바로 실행 가능한 제어식으로 옮기지는 않습니다. 관측값으로 여유를 추정하고 보정해 토큰을 조절한다는 구현 취지와, 그대로 복사해 사용할 수 있는 수식은 구분해야 합니다.
다른 시스템에 적용할 때는 사용할 부하 범위에서 예측 오차를 확인하고 보수적인 대체 동작을 마련해야 합니다. 포화에 가까울수록 잘못된 초과 허용의 피해가 커질 수 있습니다. 안전한 예산은 평균 여유뿐 아니라 모델이 실제 상태를 잘못 추정할 가능성까지 포함해야 합니다.
한산한 프록시에서도 늦어지는 이벤트 처리
부하가 낮을 때에는 요청 허용보다 실행 순서가 문제가 됩니다. 이벤트 루프가 I/O와 모니터링, 통계 등 여러 작업을 한 차례에 처리하는 동안 새 요청이 기다릴 수 있습니다. 지속적인 용량 부족이 없어도 새 도착을 늦게 확인하면 응답은 느려집니다.
일부 배경 작업을 다른 스레드로 옮기는 것은 도움이 되지만, 중요한 자료구조를 공유하는 작업까지 쉽게 분리되지는 않습니다. 추가 동기화가 오히려 경쟁을 만들 수 있기 때문입니다. 논문은 실행 환경 전체를 교체하기보다 기존 이벤트 처리 구조에 제한적인 변경을 가하는 방향을 택합니다.
수정된 루프는 I/O 관련 작업과 무관한 작업을 나누고 I/O 큐를 먼저 처리합니다. 무관한 작업을 연속으로 수행하는 시간을 제한해 새 요청을 다시 확인할 기회를 만듭니다. I/O 큐가 비었을 때 수신 버퍼를 확인하는 위치도 조정해, 이미 도착한 요청이 불필요하게 다음 긴 순회를 기다리지 않도록 합니다.
10μs라는 기본 설정은 개별 요청의 지연 상한이나 하드웨어 선점 주기가 아닙니다. I/O 작업이 그 값을 넘었다고 강제로 중단하지 않으며, 실행 중인 작업 하나 때문에 루프가 더 길어질 수도 있습니다. 배경 작업이 다음 I/O 처리 기회를 늦추는 정도를 조절하는 예산으로 이해해야 합니다.
유지보수 작업을 계속 미룰 때의 위험
I/O만 무조건 우선하면 상태 확인과 관리 작업이 실행되지 못할 수 있습니다. 프록시가 실제 요청을 처리하고 있어도 건강 상태 보고가 지연되면 관리 시스템이 비정상으로 판단해 종료할 수 있습니다. 앞단 지연을 개선하려다가 서비스 가용성을 해치는 상황입니다.
이에 구현은 해당 루프에서 I/O에 사용한 시간에 따라 전체 허용 시간을 조정합니다. 전경 작업이 활발해도 무관한 작업이 진행할 여지를 남깁니다. 이 설정은 I/O 시간에 대한 상대적 예산이며, 서버 전체 CPU의 정확히 20%를 항상 별도로 예약한다는 의미는 아닙니다.
검증에서도 상태 확인이 얼마나 오래 밀렸는지, 미처리 유지보수가 얼마나 쌓였는지 직접 봐야 합니다. 낮아진 I/O 백분위만으로는 충분하지 않습니다. 필요한 일을 계속 뒤로 미뤄 얻은 지연 개선이라면 나중에 큰 정지나 재시작으로 되돌아올 수 있기 때문입니다.
결국 공유 서비스에서는 자원에 들어오는 요청의 양과 이미 들어온 작업의 순서를 모두 관리해야 합니다. 요청률 제한은 새 도착을 늦게 확인하는 이벤트 루프를 고치지 못하고, I/O 우선순위는 지속적인 과부하에서 하부 장치의 처리량을 늘리지 못합니다. 두 변경은 서로 다른 원인을 줄이는 보완 관계입니다.
제어 실험과 재생 시험, 실제 운영 결과의 구분
논문은 통제된 실험, 운영 트레이스 재생과 실제 배포 관측을 나눠 제시합니다. 통제 환경은 컴퓨트 노드 여덟 대와 스토리지 측 노드 열여섯 대를 사용하며, 32코어 CPU, 192GB 메모리와 이중 25G 연결을 갖춥니다. 저장 노드에는 엔터프라이즈 NVMe 장치가 있습니다. 읽기·쓰기 비율과 요청 크기를 바꿔 메커니즘을 반복 가능한 조건에서 확인합니다.
가장 큰 마이크로벤치마크 개선율을 운영 평균으로 옮기면 안 됩니다. 최대 97%라는 감소는 특정 버스트 시험에 해당합니다. 실제 운영에서 수집한 요청을 재생한 시험도 입력의 출처가 운영 환경일 뿐, 그 자체가 라이브 전체 클러스터 비교가 되는 것은 아닙니다.
배포 후 버스트 사례에서는 반복적으로 수요가 몰리는 시간대에 평상시 세그먼트의 P99.999 지연이 59.7% 줄었습니다. 낮은 부하의 연구는 같은 클러스터에서 선택한 프록시 두 대를 일주일간 관측하고 한쪽에 스케줄러를 켠 비교에서 22% 감소를 보고합니다. 두 결과는 조건과 대상 요청 집단이 다릅니다.
연구진은 여러 가용 영역의 수십 개 클러스터에서 3개월 넘게 운영하고 수백조 건의 I/O를 처리했다고 설명합니다. 이는 운영 경험의 범위를 보여주지만, 모든 그래프가 그 전체 집단을 무작위로 나눈 시험이라는 뜻은 아닙니다. 배포 범위와 개별 비교의 표본 범위를 따로 읽어야 합니다.
AI 인프라에서 먼저 확인할 실제 의존 경로
AI 서비스도 메타데이터, 상태 저장 데이터베이스, 모델 로딩 등에서 블록 스토리지에 의존할 수 있습니다. 해당 I/O가 동기적으로 기다리는 경로에 있다면 긴 지연이 서비스에 전달됩니다. 그러나 이 논문은 학습 스텝, GPU 활용률이나 LLM 처리량을 측정하지 않으므로 스토리지 개선율에서 이를 바로 추정해서는 안 됩니다.
먼저 느린 연산이 일부 세그먼트의 버스트와 겹치는지, 낮은 부하에서도 이벤트 루프에 머무는지 확인해야 합니다. 세그먼트별 기록은 특정 고객의 순간 수요와 전체 용량 부족을 구분하는 데 도움이 됩니다. 작업별 추적은 실제 I/O 실행과 무관한 작업을 기다린 시간을 분리해 줍니다.
이 연구의 실용적 가치는 여유 용량을 상시 버리지 않으면서 특정 서비스 보장을 보호하는 방법에 있습니다. 이를 위해서는 평상시 요청의 정의, 보정한 여유 추정, 제한된 초과 허용과 유지보수 진행 확인이 함께 필요합니다. Alibaba의 구현을 그대로 옮기기보다 자신의 시스템에서 요청을 제어할 위치와 실행 모델을 확인한 뒤 적용해야 합니다.
출처와 저작권 안내
이 글은 NSDI 2026 최종 논문을 바탕으로 독립적으로 작성한 편집 분석입니다. 저자 정보는 학회 표지의 목록에 더해 Shu Ma가 포함된 논문 본문 첫 페이지를 기준으로 기록했습니다. 원문 저작권은 USENIX 출판 조건에 따라 저자에게 있으며 © 2026입니다. 도판은 모두 새로 만들었고 원문의 그림, 표 배치와 문장을 복제하지 않았습니다.