Postgres 18, 왜 기다려야 할까? 비동기 I/O로 클라우드 성능을 3배 끌어올린다

 

Postgres 18, 무엇이 달라졌을까?

PostgreSQL 18이 현재 베타 단계에 들어섰다. 그중에서도 가장 주목할 만한 변화는 바로 비동기 I/O(Asynchronous I/O) 기능의 도입이다. 이 기능은 단순히 내부 구현의 개선에 그치지 않는다. 특히 클라우드 환경에서 디스크 I/O 병목을 겪는 사용자에게는 실질적인 성능 향상을 제공할 수 있는 변화다.

이번 블로그에서는 Postgres 18의 비동기 I/O 기능이 어떻게 작동하는지, 기존 방식과 무엇이 달라졌는지, 그리고 이를 어떻게 설정하고 모니터링해야 하는지까지 상세히 알아본다.

반응형

---

Postgres 18에 도입된 비동기 I/O란?

기존 Postgres는 동기 I/O(sync I/O) 방식으로 동작해 왔다. 이 방식에서는 디스크에서 데이터를 읽을 때, 해당 작업이 완료될 때까지 CPU가 기다리는 블로킹(blocking) 방식이었다. 특히 EBS와 같은 네트워크 기반 스토리지를 사용할 경우, 높은 지연(latency)으로 인해 성능 병목이 빈번하게 발생했다.

Postgres 18에서는 비동기 I/O가 도입되면서 이러한 한계를 극복할 수 있게 되었다. 비동기 방식에서는 여러 디스크 읽기 작업을 병렬로 처리할 수 있으며, CPU 자원을 더 효율적으로 활용할 수 있다. 그 결과, 전체 처리량이 눈에 띄게 향상된다.

---

Postgres 17과 18의 차이: 비동기 기술의 진화

Postgres 17에서는 비동기 I/O에 대한 초석으로 read_stream API가 도입되었다. 이는 읽기 작업을 추상화하는 방식이었지만, 여전히 운영체제의 페이지 캐시에 의존했고, Postgres의 공유 버퍼(shared buffer)에는 직접 반영되지 않았다.

Postgres 18은 한 발 더 나아가 커널의 도움 없이 직접적으로 데이터를 비동기적으로 읽을 수 있게 되었다. 이를 통해 I/O 처리의 병목이 더 줄어들고, 실제 애플리케이션의 응답 속도가 개선된다.

---

새로운 설정값: io_method의 세 가지 선택지

Postgres 18에서는 postgresql.conf 파일에서 io_method를 설정할 수 있도록 했다. 선택지는 다음과 같다.

1. io_method = sync

기존 Postgres와 동일한 방식으로, 동기적으로 디스크 I/O를 처리한다. posix_fadvise() 기반의 읽기 선제 요청(prefetch)을 활용한다.

2. io_method = worker (기본값)

I/O 전담 워커 프로세스가 디스크 읽기를 수행하며, 메인 프로세스는 다른 작업을 계속 진행할 수 있다. 워커 수는 io_workers 설정을 통해 조정 가능하며, 기본값은 3개다.

3. io_method = io_uring

Linux 커널 5.1 이상에서 사용할 수 있는 고성능 인터페이스다. 워커 프로세스 없이도 커널과 직접 링 버퍼를 공유하며 비동기 읽기를 수행한다. 고성능을 제공하지만, 최신 커널과 파일시스템 환경이 요구된다.

---

실제 성능 벤치마크: io_uring, 얼마나 빠른가?

AWS c7i.8xlarge 인스턴스 환경에서 디스크 읽기 성능을 테스트한 결과는 다음과 같다.

설정	실행 시간 (ms)
Postgres 17 (sync)	15,831
Postgres 18 (sync)	15,071
Postgres 18 (worker)	10,052
Postgres 18 (io_uring)	5,723

io_uring 방식은 기존 동기 방식에 비해 최대 2.8배 빠른 성능을 기록했다. 특히 클라우드 환경에서 디스크 I/O 병목이 문제였다면, 이 변화는 매우 실질적인 개선이 될 수 있다.

---

튜닝 포인트: effective_io_concurrency

Postgres 18에서는 effective_io_concurrency 설정이 내부 비동기 read-ahead 요청 수에 영향을 미친다.

• 기본값은 1에서 16으로 상향되었다.
• 이 값은 io_combine_limit과 곱해 최대 읽기 범위를 결정한다.
• 고지연 환경에서는 높은 값이 유리하지만, 워크로드에 따라 직접 벤치마크 테스트를 해보는 것이 필요하다.

---

새로운 모니터링 도구: pg_aios

비동기 작업은 기존의 pg_stat_activity에서 명확하게 추적하기 어렵다. 특히 io_uring의 경우, 커널이 직접 작업을 처리하기 때문에 Postgres 레벨에서는 I/O 상태를 확인하기 어렵다.

Postgres 18에서는 이를 보완하기 위해 pg_aios 뷰를 제공한다. 이 뷰를 통해 현재 진행 중인 비동기 요청의 상세한 정보를 확인할 수 있다.

예시 쿼리:

SELECT * FROM pg_aios;

출력에는 다음과 같은 정보가 포함된다:

• 요청 상태(SUBMITTED, COMPLETED_IO 등)
• 대상 블록 번호
• 작업 유형 등

---

주의사항: EXPLAIN ANALYZE는 이제 다르게 봐야 한다

비동기 I/O를 사용할 경우 EXPLAIN ANALYZE에서 나오는 I/O Timings 정보는 더 이상 완전히 신뢰할 수 없다.

• 동기(sync) 방식에서는 I/O 시간 측정이 정확하다.
• 하지만 worker나 io_uring을 사용할 경우, 워커 프로세스 분산 및 병렬 처리로 인해 I/O 시간이 왜곡될 수 있다.

실제 I/O 성능을 판단하려면 shared read 버퍼 수, pg_aios 뷰, 그리고 실측 성능 테스트 결과를 함께 고려해야 한다.

---

728x90

Postgres 18은 클라우드에서 반드시 고려해야 할 변화다

Postgres 18의 비동기 I/O 기능은 단순한 내부 구조의 변화가 아니다. 특히 클라우드 환경, 그중에서도 디스크 I/O 병목이 발생하는 환경에서 체감 성능 향상을 제공한다.

그러나 동시에 새로운 설정, 모니터링 방식, 해석 기준의 변화도 동반된다. 이는 단순히 버전 업그레이드만으로 끝나는 문제가 아니다. 기능을 이해하고, 설정하고, 관찰하고, 튜닝해야 진짜 성능 향상을 체감할 수 있다.

향후 Postgres 19에서 비동기 쓰기까지 도입된다면, 데이터베이스 I/O는 새로운 단계로 진입할 것이다. 지금은 그 출발점에서 가장 중요한 전환점을 맞이하고 있다. Postgres를 주요 DB로 사용하는 조직이라면, 이 변화에 대비할 준비를 지금부터 시작해야 한다.

https://pganalyze.com/blog/postgres-18-async-io

Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O