io_uring — 리눅스 비동기 I/O가 epoll을 대체하게 된 구조적 이유

# io_uring — 리눅스 비동기 I/O가 epoll을 대체하게 된 구조적 이유

io_uring은 2019년 리눅스 커널 5.1에 합류했다. 이름에서 알 수 있듯 링 버퍼 두 개를 기반으로 하는 비동기 I/O 인터페이스다. epoll이 지배하던 고성능 서버 프로그래밍의 지형을 상당히 바꿔놓았는데, 왜 새로운 메커니즘이 필요했는지를 이해하면 구조가 훨씬 명확해진다.

## epoll의 한계

epoll은 I/O 준비 상태 알림 메커니즘이다. 파일 디스크립터가 읽거나 쓸 준비가 됐을 때 애플리케이션에 알려준다. 이걸 받아서 실제 read/write 시스템 콜을 호출하는 건 애플리케이션 책임이다.

문제는 시스템 콜 오버헤드다. 고빈도 I/O 환경에서는 커널-유저 공간 전환 비용이 누적된다. 10만 TPS를 처리하는 서버에서 각 요청마다 여러 번의 시스템 콜이 발생하면 컨텍스트 스위칭 비용 자체가 병목이 된다.

또한 epoll은 소켓·파이프 같은 파일 디스크립터에만 작동했다. 일반 파일(블록 디바이스 기반)은 POSIX AIO가 있었지만 구현이 복잡하고 제약이 많았다. 단일 인터페이스로 네트워크 I/O와 디스크 I/O를 동일하게 처리하는 건 실용적으로 어려웠다.

## io_uring의 핵심 설계

io_uring은 두 개의 링 버퍼를 커널과 유저 공간이 공유하는 구조다.

**Submission Queue (SQ)**: 애플리케이션이 요청을 쓰는 버퍼. I/O 작업 설명자(SQE, Submission Queue Entry)를 여기에 넣는다.

**Completion Queue (CQ)**: 커널이 완료 결과를 쓰는 버퍼. 애플리케이션은 여기서 완료 이벤트(CQE, Completion Queue Entry)를 읽는다.

핵심은 이 링 버퍼가 mmap으로 공유된다는 것이다. 요청 제출과 완료 수집 모두 시스템 콜 없이 메모리 쓰기/읽기로 처리할 수 있다. 실제 처리를 커널에 알리는 `io_uring_enter` 시스템 콜은 배치로 처리할 수 있고, `SQPOLL` 모드에서는 커널 스레드가 SQ를 폴링하므로 이 시스템 콜조차 생략 가능하다.

## Fixed Buffers와 Registered Files

시스템 콜 오버헤드 외에 또 다른 비용이 있다. 버퍼 매핑이다. 데이터를 커널에서 유저 공간으로 복사할 때 해당 메모리 페이지를 핀해야 한다. 이 핀 작업에 비용이 든다.

io_uring의 fixed buffers는 이 문제를 해결한다. 미리 버퍼를 등록해두면 I/O 작업마다 페이지 핀이 아니라 등록된 핀을 재사용한다. registered files도 비슷한 원리로 파일 디스크립터 참조 비용을 줄인다.

이 두 최적화는 단독으로도 유의미하지만, SQPOLL과 조합하면 극단적인 I/O 집약 워크로드에서 시스템 콜이 사실상 0에 가까운 경로가 된다.

## 실제 성능 비교

PostgreSQL 팀의 io_uring 실험, Redis의 비교 벤치마크, Nginx의 실험적 지원 등에서 공통적으로 나타나는 패턴이 있다: 소규모 연결에서는 차이가 미미하지만, 연결 수가 늘고 I/O 밀도가 높아질수록 io_uring의 이점이 커진다.

특히 디스크 I/O와 네트워크 I/O를 함께 처리하는 패턴 — 데이터베이스 서버, 파일 서버 — 에서 단일 인터페이스로 통합하는 코드 단순성도 부수적 이점이다.

## 주의점: 보안 이슈 역사

io_uring은 기능이 빠르게 확장되면서 복잡도가 높아졌고, CVE가 여럿 발생했다. Google은 안드로이드, ChromeOS 등 일부 환경에서 io_uring을 비활성화했다. 프로덕션에서 사용할 때는 커널 버전과 패치 이력을 확인하는 게 기본이다.

성능을 위해 io_uring을 채택하는 결정과, 해당 환경의 보안 위협 모델에서 이 트레이드오프가 수용 가능한지 평가하는 작업은 별개다.

io_uring — 리눅스 비동기 I/O가 epoll을 대체하게 된 구조적 이유

// COMMENTS

ON THIS PAGE