io_uring이 libaio를 추월한 순간, 그리고 아무도 예상 못 한 IOMMU 함정

디스크 I/O 성능, 왜 아직도 이야기하나요?

데이터베이스를 운영하다 보면 결국 병목은 디스크 I/O로 귀결되는 경우가 많아요. 아무리 CPU가 빠르고 메모리가 넉넉해도, 디스크에서 데이터를 읽고 쓰는 속도가 느리면 전체 시스템이 느려지거든요. 그래서 리눅스에서는 오래전부터 비동기 I/O(Async I/O)라는 기술을 제공해왔는데요, 최근 YDB 팀이 리눅스 커널 버전별로 io_uring과 libaio의 성능을 정밀 비교한 결과를 공개했어요. 결론부터 말하면, io_uring이 확실히 앞서기 시작했고, 그 과정에서 예상치 못한 IOMMU 관련 함정도 발견했다고 해요.

먼저, libaio와 io_uring이 뭔지 알아볼게요

libaio는 리눅스에서 오랫동안 사용되어온 비동기 I/O 인터페이스예요. 이게 뭐냐면, 프로그램이 디스크에 "이 데이터 읽어줘"라고 요청을 던져놓고 다른 일을 하다가, 나중에 결과가 준비되면 받아오는 방식이에요. 식당에서 주문하고 진동벨 받아서 기다리는 것과 비슷하다고 생각하면 돼요. libaio는 안정적이지만 설계가 꽤 오래되었고, 제약사항도 있어요. O_DIRECT 플래그(운영체제의 캐시를 거치지 않고 디스크에 직접 접근하는 옵션)로만 제대로 동작하고, 버퍼 I/O에서는 사실상 동기 방식으로 폴백되는 문제가 있거든요.

io_uring은 2019년에 리눅스 5.1 커널에 등장한 비교적 새로운 인터페이스예요. 이름의 'ring'은 링 버퍼(ring buffer)에서 따왔는데요, 커널과 사용자 프로그램이 공유하는 두 개의 원형 큐(제출 큐와 완료 큐)를 통해 소통해요. 기존 방식에서는 I/O 요청 하나마다 시스템 콜을 해야 했는데, io_uring은 여러 요청을 한꺼번에 제출하고 결과도 한꺼번에 가져올 수 있어요. 편의점에서 물건 하나 살 때마다 계산하는 게 아니라, 장바구니에 담아서 한 번에 계산하는 느낌이라고 보면 돼요.

YDB 팀의 벤치마크 결과가 흥미로워요

YDB는 러시아에서 개발된 분산 데이터베이스인데요, 이 팀이 리눅스 커널 4.19부터 최신 커널까지 버전별로 libaio와 io_uring의 성능을 비교했어요. 초기 커널에서는 사실 io_uring이 libaio보다 느린 경우도 있었다고 해요. 새로운 기술이라고 무조건 빠른 건 아니었던 거죠. 하지만 커널 버전이 올라가면서 io_uring의 최적화가 꾸준히 이루어졌고, 특히 커널 5.10 이후부터는 io_uring이 libaio를 확실히 앞서기 시작했어요.

성능 차이가 나는 핵심 이유는 시스템 콜 오버헤드의 차이예요. libaio는 요청 제출과 완료 확인에 각각 시스템 콜이 필요한 반면, io_uring은 공유 메모리 링 버퍼 덕분에 시스템 콜 없이도 요청을 처리할 수 있거든요. I/O 요청이 수만, 수십만 건이 되면 이 차이가 눈에 띄게 벌어져요.

아무도 예상 못 한 IOMMU 함정

그런데 벤치마크 도중 정말 예상치 못한 문제가 발견됐어요. 특정 서버 환경에서 io_uring과 libaio 모두 성능이 갑자기 뚝 떨어지는 현상이 나타난 거예요. 원인을 추적해보니 IOMMU 때문이었어요.

IOMMU가 뭐냐면, CPU에 가상 메모리(virtual memory)가 있는 것처럼 I/O 장치에도 가상 주소 공간을 제공하는 하드웨어예요. 보안과 메모리 격리를 위해 사용되는데요, 문제는 IOMMU가 활성화되면 DMA(Direct Memory Access, 장치가 CPU를 거치지 않고 메모리에 직접 접근하는 기술) 요청마다 주소 변환 오버헤드가 추가된다는 거예요. 특히 NVMe SSD처럼 매우 빠른 저장장치를 쓸 때, 이 오버헤드가 전체 I/O 성능의 병목이 될 수 있어요.

YDB 팀은 BIOS에서 IOMMU를 비활성화하거나 패스스루(passthrough) 모드로 설정하면 성능이 극적으로 회복되는 걸 확인했어요. 가상화 환경이 아닌 베어메탈 서버에서는 IOMMU가 꼭 필요하지 않은 경우가 많은데, 기본값으로 켜져 있어서 모르고 성능 손해를 보는 경우가 꽤 있을 수 있다는 이야기예요.

업계에서의 위치

io_uring은 이제 고성능 I/O가 필요한 거의 모든 프로젝트에서 주목받고 있어요. 대표적으로 PostgreSQL도 io_uring 지원을 실험적으로 도입하기 시작했고, RocksDB, ScyllaDB 같은 데이터베이스들도 io_uring 백엔드를 적극 활용하고 있어요. 네트워크 쪽에서도 Nginx나 Envoy 같은 프록시 서버들이 io_uring 도입을 검토하거나 이미 적용한 상태예요.

다만 보안 관련 논란도 있어요. io_uring은 기능이 워낙 강력하다 보니, 과거에 여러 보안 취약점이 발견된 적이 있거든요. 구글은 한때 프로덕션 서버에서 io_uring을 비활성화하기도 했어요. 그래서 io_uring을 도입할 때는 커널 버전을 최신으로 유지하고, seccomp 프로필 같은 보안 설정도 함께 점검하는 게 중요해요.

한국 개발자에게 주는 시사점

만약 여러분이 고성능 데이터베이스나 스토리지 관련 시스템을 운영하고 있다면, 커널 버전 업그레이드와 함께 io_uring 도입을 진지하게 검토해볼 시점이에요. 특히 NVMe SSD를 사용하는 환경이라면 IOMMU 설정도 한번 확인해보세요. 서버 BIOS 설정 하나가 I/O 성능을 수십 퍼센트 좌우할 수 있거든요.

또한 직접 저수준 I/O를 다루지 않더라도, 여러분이 사용하는 데이터베이스나 메시지 큐가 내부적으로 어떤 I/O 방식을 쓰는지 이해해두면 성능 튜닝할 때 큰 도움이 돼요.