데이터브릭스, 레이크베이스 포스트그레스 컴퓨트 캐시 개선 사항 공개
데이터브릭스는 대형 레이크베이스 컴퓨트 노드에서 포스트그레스의 공유 버퍼를 늘리고 새로운 거대 페이지 메모리 지원을 추가해 지연 시간과 CPU 사용량을 줄였다고 밝혔다. 실제 프로덕션 테스트에서는 처리량이 최대 2배까지 향상된 것으로 나타났다.
한 줄 답
Databricks는 Lakebase Postgres 컴퓨트 캐시 개선과 관련해 무엇을 발표했나요?
데이터브릭스는 CU 80 이상의 대형 고정 크기 레이크베이스 컴퓨트 노드에서 포스트그레스의 공유 버퍼를 DRAM의 75%까지 늘리고 전용 거대 페이지 메모리 지원을 추가했다고 밝혔다. 이는 공유 버퍼를 약 1GB로 제한했던 기존의 로컬 파일 캐시 방식을 대체한 것이다. 회사 측은 프로덕션 환경에서 처리량이 최대 2배 향상되고 스토리지 읽기 횟수가 줄었으며 CPU 사용량과 지연 시간도 낮아졌다고 밝혔다.
핵심 요약
- 데이터브릭스는 CU 80 이상의 대형 고정 크기 레이크베이스 컴퓨트 노드에서 포스트그레스의 공유 버퍼를 기존 약 1GB 상한에서 가용 DRAM의 75%까지 늘리고, 해당 노드에서는 로컬 파일 캐시를 비활성화했다고 밝혔다.
- 해당 업체는 더 큰 공유 버퍼로 인해 발생하는 메모리 변환 오버헤드를 줄이기 위해 가상머신 인프라 전반에 전용 2MB 휴지페이지(huge-page) 메모리 지원을 도입했다고 밝혔다.
- 데이터브릭스가 진행한 벤치마크 테스트에 따르면 거대 페이지 도입으로 테일 읽기 지연 시간이 최대 약 40% 줄고 CPU 사용률이 최대 약 30% 감소한 것으로 나타났다.
- 데이터브릭스가 제시한 실제 운영 사례를 보면, 한 엔드포인트에서는 접근 블록 처리량이 약 두 배로 늘어난 반면 스토리지 계층 읽기는 약 5분의 1로 줄었고, 다른 엔드포인트에서는 CPU 사용량이 20코어에서 4코어로 감소했다.
- 데이터브릭스는 이번 게시물이 나온 2026년 9월 10일보다 몇 주 앞서 지역별로 순차 도입을 시작했으며, 공유 버퍼 자동 확장 작업을 다룰 후속 게시물을 계획하고 있다고 밝혔다.
Databricks의 발표 내용
Databricks는 2026년 9월 10일 블로그 게시물을 통해 자사의 Lakebase Postgres 서비스가 컴퓨트 노드에서 데이터를 캐싱하는 방식을 어떻게 변경했는지 설명했다. 시리즈 첫 번째 편으로 소개된 이 게시물은 David Wein, Sunil Kamath, Haoyu Huang이 작성했다. Databricks는 이번 변경의 목표가 Postgres의 가장 빠른 메모리 계층에 더 많은 데이터를 유지함으로써 Lakebase 컴퓨트에서 사용 가능한 DRAM을 더 효율적으로 활용하는 데 있다고 밝혔다.
캐싱 구조의 배경
Databricks에 따르면 Lakebase Postgres는 분산 스토리지 모델을 사용하며, 캐싱은 분산 스토리지와 컴퓨트 노드 자체 양쪽에서 이루어진다. 표준 Postgres 배포에서는 데이터베이스가 셰어드 버퍼(shared buffers)라는 인메모리 영역에 데이터를 캐싱하는 동시에, 운영체제도 별도로 동일한 페이지를 자체 페이지 캐시에 캐싱한다. Databricks는 이런 구조가 이중 버퍼링을 일으켜 1GB의 캐시된 데이터가 결국 2GB의 RAM을 소비하게 될 수 있다고 설명한다. 또한 Postgres의 셰어드 버퍼는 통상 정적 설정 값이라 변경하려면 데이터베이스를 재시작해야 하는데, 이는 서버리스 자동 확장 시스템에서 어려운 과제라고 회사는 지적한다.
이를 해결하기 위해 Databricks는 로컬 파일 캐시(LFC)를 구축했으며, 이는 출시 이후 모든 Lakebase 컴퓨트에서 계속 가동되어 왔다고 밝혔다. LFC는 컴퓨트 노드의 로컬 NVMe 스토리지에 위치해 셰어드 버퍼 뒤의 2차 계층 역할을 하며, Databricks는 그간 셰어드 버퍼를 보수적으로 조정해 컴퓨트의 전체 메모리 크기와 무관하게 약 1GB로 제한해 왔다.
셰어드 버퍼 확대와 huge pages
Databricks는 이제 대형 고정 크기 컴퓨트 노드에 대해 약 1GB였던 이 상한선을 없앴다고 밝혔다. CU가 80 이상인 컴퓨트의 경우 LFC를 비활성화하고 Postgres 셰어드 버퍼를 가용 DRAM의 75%로 설정해, 자주 액세스되는 페이지를 더 느린 로컬 캐시로 내려보내는 대신 가장 빠른 메모리 계층에 유지한다고 회사는 설명했다. Databricks에 따르면 고객은 Postgres 연결에서 "show shared_buffers"를 실행해 이 설정을 확인할 수 있으며, 80 CU 엔드포인트에서는 20971520이라는 값이 반환될 것으로 예상된다.
셰어드 버퍼가 커지면 Postgres의 프로세스별 연결 구조에서 메모리 변환 오버헤드가 늘어나기 때문에, Databricks는 가상 머신 인프라 전반에 걸쳐 전용 2MB huge-page 메모리 지원도 도입했다고 밝혔다. 이때 최선형 방식인 transparent huge pages에 의존하는 대신 명시적인 HugeTLB 페이지를 채택했다. 회사에 따르면 이를 구현하려면 호스트 수준부터 하이퍼바이저, 게스트 커널에 이르기까지 일관된 지원이 필요했다. 고객은 "show huge_pages"를 실행해 이 설정을 확인할 수 있으며, Databricks는 80 CU 엔드포인트에서 "on"이 반환되어야 한다고 밝혔다.
보고된 성과
Databricks는 벤치마크 테스트 결과 huge pages 도입으로 테일 읽기 지연 시간이 최대 약 40% 줄고 CPU 사용률이 최대 약 30% 감소했다고 밝혔다. 회사에 따르면 이번 롤아웃은 게시물 발표 몇 주 전부터 지역별로 순차 진행되었으며, 컴퓨트 재시작 이후 측정한 세 가지 프로덕션 사례를 근거로 제시했다. 한 대형 엔드포인트에서는 초당 액세스된 Postgres 블록 수가 두 배로 늘고, 스토리지 계층에서의 초당 읽기 횟수는 약 8,000회에서 약 1,500회로 줄었으며, 해당 고객은 전날·전주·전월 대비 p50 및 p99 지연 시간이 낮아졌다고 보고했다. 두 번째 엔드포인트에서는 처리량이 약 43% 증가했고 컴퓨트 캐시 적중률은 거의 100%에 도달했다. 세 번째 사례에서는 CPU 사용량이 변경 전 20코어에서 4코어로 줄어드는 동시에 처리량은 두 배로 늘었다고 회사는 밝혔다.
Databricks는 현재 적용된 변경 사항이 고정 크기 컴퓨트에 한정된다고 설명했다. 셰어드 버퍼가 아직 동적으로 확장될 수 없기 때문이며, 시리즈의 예정된 두 번째 게시물에서는 셰어드 버퍼 자동 확장을 위한 작업을 다룰 예정이라고 밝혔다.
출처: Databricks Blog, "Improving Lakebase Postgres compute cache," 2026년 9월 10일 게재.
자주 묻는 질문
- 데이터브릭스가 발표한 레이크베이스(Lakebase) 포스트그레스 컴퓨트 캐시 변경 사항은 무엇인가요?
- 데이터브릭스는 CU 80 이상의 대형 고정 크기 컴퓨트 노드에서 포스트그레스의 공유 버퍼를 가용 DRAM의 75%까지 늘렸다고 밝혔다. 이는 공유 버퍼를 약 1GB로 제한하고 보조 로컬 파일 캐시에 의존했던 기존 방식을 대체한 것이다.
- Databricks는 어떤 성능 개선을 보고하고 있나요?
- 데이터브릭스는 처리량이 약 1.3배에서 2배까지 늘어난 프로덕션 사례와, 한 엔드포인트에서 스토리지 계층 읽기가 최대 5분의 1로 줄어든 사례, 또 다른 엔드포인트에서 CPU 사용량이 20코어에서 4코어로 감소한 사례를 제시했다.
- Databricks는 더 큰 공유 버퍼로 인한 오버헤드를 어떻게 해결했을까?
- 회사 측은 가상 머신 인프라 전반에 전용 2MB 거대 페이지 메모리 지원을 추가했으며, 자체 벤치마크 테스트에서 테일 읽기 지연 시간이 최대 약 40%, CPU 사용률이 최대 약 30% 감소했다고 밝혔다.
- 이 변경 사항은 모든 Lakebase Postgres 컴퓨트에 적용됩니까?
- 데이터브릭스는 확대된 공유 버퍼 구성이 현재 CU 80 이상의 고정 크기 컴퓨트에만 적용되고 있으며, 자동 확장 컴퓨트에 대해서는 계획 중인 후속 게시물에서 다룰 예정이라고 밝혔다.