ClickHouse Managed Postgres가 백업 중 쿼리 지연을 낮췄다

ClickHouse Managed Postgres는 백업이 데이터베이스의 페이지 캐시를 밀어내지 않도록 Direct I/O를 적용하고, RAID0 구성의 NVMe 드라이브 수에 맞춰 읽기 크기와 동시 읽기 수를 조정했다. 회사 측 테스트에서는 467GB 데이터베이스를 백업할 때 메모리에 있던 40GiB 테이블이 유지됐고, 백업 중 쿼리 지연 시간 증가도 완충 읽기 방식보다 작았다.

같은 드라이브를 쓰는 백업과 쿼리

ClickHouse Managed Postgres는 데이터베이스 파일과 백업을 위한 읽기가 같은 로컬 NVMe 드라이브를 사용한다. 기본적인 리눅스 읽기는 페이지 캐시에 데이터를 복사한다. 백업은 데이터를 한 번 읽어 업로드하고 다시 사용하지 않지만, 이 과정에서 페이지 캐시가 차면 커널이 데이터베이스가 사용하던 캐시 데이터를 내보낼 수 있다. ClickHouse는 서비스에서 로컬 디스크를 사용하는 이유와 WAL 아카이브 처리 방식을 별도 글에서 설명했다.

Direct I/O는 읽기 데이터가 페이지 캐시에 들어가지 않게 한다. 하지만 커널의 미리 읽기(readahead)도 사용하지 않으므로, 작은 읽기는 RAID0의 일부 드라이브만 이용할 수 있다. ClickHouse의 배열은 드라이브마다 512KiB 단위로 데이터를 나눈다. 기본 Direct I/O 읽기 크기인 128KiB는 한 드라이브의 청크 안에 들어가므로, 읽기 요청 하나만 보면 나머지 드라이브가 쉬게 된다.

ClickHouse는 드라이브마다 4KiB 블록 256개, 즉 1MiB를 읽도록 설정하고, 배열의 드라이브 수에 따라 요청 크기를 정한다. 네 개 드라이브에서는 한 요청이 4MiB가 된다. 동시 디스크 읽기 수는 하드웨어에 맞춘다. Direct I/O를 쓰는 고밀도 NVMe 인스턴스와 vCPU가 2개 이하인 서버에서는 vCPU 수만큼 읽기를 병렬 처리하고, 그 밖의 경우에는 vCPU 절반을 사용한다.

테스트에서 확인한 차이

테스트는 AWS us-east-1의 i8ge.12xlarge에서 진행했다. 서버는 48 vCPU, 메모리 384GiB, 인스턴스 스토리지 NVMe 네 개를 사용했고, 데이터베이스는 Postgres 18.6과 upstream wal-g v3.0.9로 구성한 467GB pgbench 데이터베이스였다. 실행 중에는 조회 작업을 계속했고, 백업 전 메모리에 읽어 둔 뒤 사용하지 않은 40GiB 테이블이 얼마나 남는지도 측정했다.

ClickHouse가 비교한 설정과 결과는 다음과 같다.

완충 읽기에서는 백업 시작 20초 뒤 40GiB 테이블 중 0.3GiB만 메모리에 남았다. 백업이 끝난 뒤에도 캐시가 다시 채워지는 동안 쿼리 p99 지연 시간은 기준치의 세 배 수준으로 2분 30초 동안 높게 유지됐다. Direct I/O를 적용한 세 설정에서는 테이블이 유지됐고, 백업이 끝나자 지연 시간이 기준치로 돌아왔다. 백업 중 p99 지연 시간은 완충 읽기에서 기준치보다 4.7배 높아졌고, Direct I/O에서는 1.5배 높아졌다.

ClickHouse는 같은 테스트에서 완충 읽기 중 전체 CPU 사용률이 65%, 4MiB Direct I/O 읽기에서는 60%였다고 밝혔다. 이는 같은 백업을 수행하는 데 약 1,000코어초 대신 약 860코어초를 사용한 것으로, 약 14% 적은 CPU 사용량에 해당한다. 다만 작은 Direct I/O 읽기는 배열을 80% 바쁘게 사용하면서 초당 5.8GB를 읽었고, 4MiB 읽기는 56% 사용률에서 초당 7.4~7.7GB를 읽었다. 백업 시간은 기본 128KiB 읽기에서 96초, 4MiB 읽기와 48개 읽기에서 71초, 24개 읽기에서 75초였다.

운영 적용과 한계

설정은 서버의 vCPU 수, 메모리, 드라이브 수, NVMe 인스턴스 유형을 바탕으로 생성되며 /etc/postgresql/wal-g.env에 저장된다. Direct I/O 지원이 포함된 wal-g와 새 머신 이미지가 적용된 서버에서 사용되며, 백업 일정과 복구 경로는 바뀌지 않았다. ClickHouse는 Direct I/O 설정을 끄고 완충 읽기로 돌아가는 기능 플래그와 wal-g 기본값으로 되돌리는 기능 플래그도 제공한다고 설명했다.

백업은 데이터베이스와 CPU와 드라이브를 공유하므로 Direct I/O만으로 경합이 사라지는 것은 아니다. ClickHouse는 백업 프로세스를 별도 cgroup에서 실행하고 CPUWeight=25를 설정해, 시스템이 바쁠 때 기본 가중치 100인 Postgres가 더 큰 CPU 몫을 받도록 한다. 업로드 버퍼는 메모리의 5% 이내로 제한하고, 압축에는 lz4를 사용한다. 회사는 현재 변경된 페이지만 읽고 업로드하는 증분 백업을 시제품으로 개발 중이라고 밝혔다. 이 기능은 아직 개발 단계이며, 이번 테스트는 전체 백업을 대상으로 했다.

ClickHouse Managed Postgres의 페이지 캐시와 프로세스 자원 관리에 관한 설명은 huge pages 관련 글, 지원 프로세스 예산 관련 글, 백업 개선 사항 안내에서 확인할 수 있다. 제품 정보는 ClickHouse Managed Postgres에서 볼 수 있다.