RingCore, io_uring 기반 minimal async runtime을 실무에 도입하기 전에 볼 것들

io_uring 위에 얇게 올라간 minimal async runtime이 눈에 들어온다는 건, 단순히 새 라이브러리가 하나 더 나왔다는 뜻이 아니다. 그 신호 뒤에는 대개 같은 고민이 숨어 있다. Rust 서비스는 이미 빠른데, 왜 tail latency는 여전히 튀고, 왜 I/O가 몰리는 구간에서 스레드 수와 wake-up 비용이 계속 신경 쓰이며, 왜 범용 runtime의 편의가 때로는 너무 많은 정책까지 함께 들고 오는가.

문제를 줄이려면 런타임도 작아져야 할 때가 있다

대부분의 서버는 CPU보다 I/O에서 더 자주 멈춘다. 디스크 flush, 파일 read, 네트워크 socket readiness, timer, cancellation, backpressure가 한꺼번에 얽히면 “비동기”라는 말 하나로는 설명이 끝나지 않는다. 특히 범용 runtime은 넓은 사용처를 위해 scheduler, task model, timer wheel, blocking fallback, cooperative yielding 같은 판단을 내부에 많이 품는다. 그 덕분에 개발은 빨라지지만, 반대로 어떤 지점에서 비용이 생기는지 추적하기 어려워진다.

minimal runtime이 주는 가치는 바로 여기서 나온다. io_uring이 제공하는 completion 기반 I/O 경로를 최대한 그대로 드러내고, 그 위에 필요한 만큼만 추상화를 얹는 방식이다. “얇다”는 말은 기능이 부족하다는 뜻이 아니라, 비용이 어디서 생기는지 더 잘 보인다는 뜻에 가깝다. 실무에서는 이 투명성이 성능 자체만큼 중요하다.

얇은 런타임이 잘 맞는 장면은 의외로 좁지만 분명하다

모든 백엔드가 이런 선택을 할 필요는 없다. HTTP API 서버 하나를 빠르게 만들고 운영 안정성을 우선한다면 이미 검증된 범용 runtime이 더 나은 경우가 많다. 반면 파일 I/O가 크고 자주 일어나는 서비스, 로그 수집기, object storage gateway, message broker의 persist layer, 대량의 connection을 다루되 task 모델을 단순하게 유지하고 싶은 시스템에서는 이야기가 달라진다.

이런 서비스는 보통 두 가지 패턴을 보인다. 첫째, syscall 수보다 completion 처리 방식이 더 중요해진다. 둘째, application logic보다 I/O 파이프라인의 압력이 latency를 결정한다. 이때 io_uring 기반 minimal runtime은 thread-per-core 전략, submit/completion batching, user-space 큐 관리와 더 자연스럽게 맞물릴 수 있다. 핵심은 “비동기 기능이 많아서”가 아니라 “I/O 경로를 직접 통제해야 해서” 선택하는 것이다.

도입 단위는 런타임 전체가 아니라 I/O 경계여야 한다

실무에서 가장 안전한 접근은 서비스 전체를 한 번에 갈아타지 않는 것이다. 먼저 I/O가 가장 뜨거운 경계를 분리한다. 파일 read/write 계층, append-only log, spooler, uploader 같은 부분이다. 이 경계에 runtime 의존성을 가두면, 성능 실험도 쉬워지고 실패했을 때 rollback 비용도 낮아진다.

pub trait BlobIo {
    async fn read(&self, key: &str) -> std::io::Result<Vec<u8>>;
    async fn write(&self, key: &str, data: &[u8]) -> std::io::Result<()>;
}

pub struct RingBlobIo {
    // io_uring 기반 구현체가 들어가는 자리
}

impl BlobIo for RingBlobIo {
    async fn read(&self, key: &str) -> std::io::Result<Vec<u8>> {
        // submit/completion, batching, retry 정책을 이 안에 한정
        todo!()
    }

    async fn write(&self, key: &str, data: &[u8]) -> std::io::Result<()> {
        todo!()
    }
}

이 구조의 장점은 단순하다. 비즈니스 로직은 BlobIo를 바라보고, 실험군만 RingBlobIo로 바꿔 끼운다. 런타임 교체가 아니라 I/O 전략 교체로 보이게 만드는 것이다. 운영에서는 이 차이가 매우 크다. 장애가 나도 “서비스 전체 async 모델”을 의심하지 않고, 특정 I/O 계층의 queue depth, completion delay, retry burst만 먼저 보면 된다.

자주 터지는 함정은 성능이 아니라 의미론이다

io_uring 도입 논의가 시작되면 사람들은 먼저 throughput 숫자를 기대한다. 그런데 운영에서 먼저 발목을 잡는 건 보통 의미론의 차이다. completion 기반 I/O는 readiness 기반 모델과 장애 양상이 다르다. 취소가 언제 실제로 반영되는지, timeout이 어느 층에서 보장되는지, buffer lifetime을 누가 책임지는지, fixed buffer나 registered file을 쓸 때 자원 회수가 어떤 순서로 일어나는지가 모두 중요해진다.

Linux kernel 버전 차이도 무시하기 어렵다. 같은 io_uring이라도 기능 안정성, edge case, 파일 시스템별 동작은 균일하지 않다. 개발 환경에서는 잘 돌던 코드가 운영 커널에서만 tail latency를 만들 수 있다. 컨테이너 환경이라면 seccomp, capability, host kernel 정책도 영향을 준다. “crate가 작다”는 건 학습량이 적다는 뜻이 아니라, 판단을 더 많이 직접 해야 한다는 뜻일 때가 많다.

또 하나의 함정은 관측 가능성이다. 범용 runtime은 이미 많은 계측 지점을 제공하지만, minimal runtime은 의도적으로 그런 장치를 덜 갖고 있을 수 있다. 그래서 도입 직후에는 오히려 더 느려졌는지, 단지 더 솔직하게 드러났는지 구분하기 어려워진다. 큐 적체 시간, in-flight operation 수, submit batch 크기, completion 처리 편차를 직접 봐야 한다.

운영에서 먼저 읽히는 신호가 있다

잘 들어간 시스템은 평균 latency보다 분산이 먼저 안정된다. p95, p99가 갑자기 벌어지지 않고, 디스크나 네트워크에 순간 부하가 와도 completion queue가 회복 가능한 범위에서 움직인다. 반대로 위험 신호는 thread 수 증가보다 queue 정체에서 먼저 나타난다. CPU가 한가한데 요청이 밀리거나, timeout이 burst 형태로 생기거나, 재시도가 특정 시점에 몰리면 런타임보다 I/O 압력 제어가 실패하고 있을 가능성이 높다.

특히 “blocking이 거의 없으니 괜찮다”는 판단은 자주 틀린다. storage layer의 flush, metadata update, page cache 상태, 파일 시스템 writeback은 애플리케이션이 보는 비동기 모델 바깥에서 tail을 만든다. minimal runtime은 이런 현실을 숨기지 않기 때문에, 숫자가 덜 예쁘게 보일 수도 있다. 하지만 장기적으로는 그 편이 낫다. 숨겨진 비용보다 관측 가능한 비용이 더 다루기 쉽기 때문이다.

도입 전, 숫자보다 먼저 맞춰야 할 조건들

검토 단계에서 꼭 확인할 항목은 화려하지 않다.

• 운영 커널 버전과 배포 환경이 io_uring 경로를 안정적으로 허용하는가
• 가장 뜨거운 I/O 경계가 어디인지 이미 지표로 확인했는가
• cancellation, timeout, shutdown semantics를 팀이 명확히 합의했는가
• 범용 runtime의 기능 중 실제로 버릴 수 없는 것이 무엇인지 알고 있는가
• 장애 시 fallback 경로나 우회 배치가 준비되어 있는가
• p50이 아니라 p95, p99, queue depth, in-flight 수를 중심으로 비교하고 있는가

결국 RingCore 같은 선택지가 던지는 질문은 하나다. 더 빠른 비동기를 원하느냐가 아니라, 더 적은 정책으로 더 명확한 I/O 제어를 원하느냐다. 그 질문에 “그렇다”고 답할 수 있는 서비스는 생각보다 많지 않다. 하지만 조건이 맞는 곳에서는, 작은 런타임이 오히려 큰 복잡도를 줄인다. 성능 최적화의 핵심이 마법 같은 가속이 아니라 비용의 위치를 바꾸는 일이라는 점을 이해하고 들어갈 때, 이런 도구는 실험용 장난감이 아니라 꽤 날카로운 운영 수단이 된다.

댓글

불러오는 중…