연결을 끊지 않는 Lakebase Postgres의 오토스케일링

Lakebase Postgres는 실행 중인 VM의 CPU와 메모리를 조정해 데이터베이스 연결을 끊지 않고 용량을 늘리거나 줄임. Neon의 프로덕션 데이터베이스는 평균적으로 월 32,016회, 약 81초마다 컴퓨트 크기가 바뀜 컴퓨트와 스토리지의 분리가 실시간 크기 조정의 기반임. 컴퓨트가 영속 상태를 소유하지 않아 데이터베이스를 옮기지 않고도 시작, 중지, 이동, 크기 변경이 가능함 오토스케일링 알고리듬은 CPU 부하, 메모리 사용량, 작업 집합 크기가 각각 요구하는 용량 중 최댓값을 선택하고, 사용자가 설정한 최소/최대 범위로 제한함 CPU 사용률이 낮아도 캐시가 부족하면 쿼리는 느려질 수 있음. 시간 정보를 추가한 HyperLogLog로 최근 반복 접근하는 데이터의 양을 추정해 필요한 캐시 용량을 계산함 스케줄러의 자원 승인과 VM 내부 메모리 검사로 확장과 축소를 조율함. 현재 노드에서 확장할 여유가 없으면 VM을 다른 노드로 라이브 마이그레이션하며 기존 연결을 유지함 컴퓨트와 영속 스토리지를 분리한 구조 워크로드를 알기 전에 인스턴스 크기를 정하면 컴퓨트를 낭비하기 쉬움. Neon 데이터베이스인 Lakebase Postgres는 오토스케일링으로 사전 크기 산정 과정을 없앰 Neon의 오토스케일링 통계에 따르면 프로덕션 데이터베이스의 평균 크기 변경 횟수는 월 32,016회, 약 81초당 한 번임 전통적인 Postgres는 실행과 영속 상태를 같은 머신과 디스크에 묶어 두므로 머신 교체나 크기 변경 자체가 데이터베이스 작업이 됨. Lakebase 아키텍처는 두 책임을 분리함 컴퓨트 계층은 Postgres와 쿼리를 실행하고 RAM과 로컬 NVMe로 낮은 지연 시간의 접근을 지원하지만, 영속 상태는 소유하지 않음 스토리지 계층은 내구성과 이력을 담당함. SSD에서 실행되는 safekeeper가 WAL을 복제하고, SSD 기반 pageserver가 페이지 버전을 재구성하며, 객체 스토리지가 장기 불변 기록을 보관함 스토리지의 세부 구조는 별도 심층 분석에서 확인할 수 있음 이 분리 덕분에 컴퓨트는 데이터베이스를 옮기지 않고 시작, 중지, 이동, 크기 변경을 수행할 수 있음. 오토스케일링 구현은 용량을 바꿀 시점과 목표 크기를 결정하는 알고리듬, Postgres를 멈추지 않고 변경을 적용하는 실행 계층으로 나뉨 CPU와 메모리로 목표 용량 계산 알고리듬은 cpuGoalCU, memGoalCU, lfcGoalC...