플래닛스케일(PlanetScale)이 샤딩된 Postgres 데이터베이스 'Neki'를 플랫폼 프리뷰로 공개했다. 이 회사는 지난 8년간 세계 최대 규모의 샤딩 MySQL 클러스터를 운영하며 초당 수백만 건의 쿼리를 처리하는 티어 0 워크로드를 다뤄왔고, 그 경험을 이번 제품에 담았다고 밝혔다. 1년 반 전 PlanetScale Postgres를 내놓은 뒤 수천 곳의 고객을 온보딩하는 과정에서, 많은 팀이 단일 머신 Postgres의 성능 한계에 부딪히는 상황을 반복적으로 목격한 것이 개발 배경이다. 더 큰 인스턴스로 옮기는 방법은 시간을 벌어줄 뿐, 결국 충분히 큰 머신이 존재하지 않는 지점에 도달한다는 것이 회사의 진단이다.
한계에 다다른 단일 머신 Postgres
빠르게 커지는 Postgres를 운영해 본 실무자라면 익숙한 문제들이 있다. 트래픽에 영향을 주지 않고는 배큠(vacuum)이나 인덱싱을 돌리기 어려울 만큼 커진 테이블, 몇 시간씩 걸리는 백업, 커넥션 수 제한, 스키마 변경을 위한 점검 창(maintenance window), 그리고 트랜잭션 ID 랩어라운드 같은 이슈들이다. 코어와 IOPS를 늘려도 이런 문제는 선형적으로 완화되지 않는다는 점이 핵심이다.
기존 해법은 저마다 무언가를 포기하게 만든다는 것이 플래닛스케일의 문제 인식이다. 애플리케이션 레벨 샤딩은 라우팅 로직을 애플리케이션 코드로 밀어넣고, 이른바 'Postgres 호환' 분산 데이터베이스는 샤드 키를 감추고 확장(extension) 사용을 제약하며 디버깅하기 어려운 복잡성과 지연을 더한다는 것이다. 그래서 Neki는 'Postgres를 우회하거나 흉내 내지 않고 그대로 고수한다'는 원칙을 가장 앞세웠다.
네 개의 구성 요소
Neki의 구조는 네 부분으로 나뉜다. 첫째, 애플리케이션은 Neki 라우터에 접속한다. 라우터는 표준 Postgres 와이어 프로토콜을 구사하므로 기존 드라이버와 ORM, 커넥션 문자열을 그대로 쓸 수 있다. 라우터는 완전한 Postgres 쿼리 파서와 분산 쿼리 플래너, 쿼리 버퍼링 기능을 갖추고 있어 쿼리를 해석해 어떤 샤드가 실행할지 계획을 세우고, 결과를 하나의 스트림으로 합쳐 돌려준다. 라우터는 수직·수평 양쪽으로 확장 가능해 특정 라우터가 병목이 되지 않도록 설계됐다.
둘째, 각 샤드는 프라이머리 1대와 최소 2대의 리플리카로 구성된 진짜 Postgres 클러스터이며, 3개 가용 영역(AZ)에 분산 배치된다. 변형된 스토리지 엔진이 없기 때문에 확장, SQL 지원, 성능이 모두 Postgres 본래대로 동작한다. 샤드는 샤드 그룹으로 묶여 서로 다른 테이블이나 워크로드를 다른 샤드 집합에 둘 수 있고, 각 그룹은 인스턴스 크기·리플리카 수·스토리지·파라미터·확장을 정의한 설정 프로필로 독립적으로 사이징된다. 셋째, 모든 Postgres 인스턴스 옆에는 사이드카가 함께 돈다. 회사는 이 부분이 단순히 PgBouncer를 앞에 두는 것과의 결정적 차이라고 설명한다. Neki가 라우터 쪽과 Postgres 쪽 연결을 모두 통제하기 때문에, 외부에서 추정하는 대신 각 인스턴스가 실제로 감당할 수 있는 규모에 맞춰 커넥션 풀을 정할 수 있다는 것이다. 넷째, 컨트롤 플레인이 모든 노드의 상태를 추적하고 계획된 전환과 예기치 못한 페일오버, 그리고 리샤딩·스키마 변경·버전 업그레이드 워크플로를 조율한다.
이 모두를 엮는 것이 데이터 토폴로지다. JSON 설정으로 논리 테이블을 물리 샤드에 매핑하며, Neki가 라우팅에 쓰는 컬럼과 해싱 방식을 정하는 샤드 인덱스, 그리고 테이블 집합이 몇 개의 어떤 샤드에 퍼질지 정하는 샤드 그룹을 정의한다. 라우터는 이 토폴로지를 캐시해 두고 계획을 세울 때마다 참조한다.
온라인 운영과 프리뷰 단계의 한계
실무적으로 눈여겨볼 대목은 운영 방식이다. 평소 점검 창을 잡아야 했던 작업들이 Neki에서는 내장 워크플로로 실행된다. 워크플로는 새 대상 노드를 프로비저닝하고 리플리케이션으로 따라잡게 한 뒤 __neki 메타함수로 트래픽을 전환하고 옛 노드를 회수하는데, 이 과정이 애플리케이션이 쓰는 것과 같은 psql 연결을 통해 이뤄진다. 스키마 변경, 버전 업그레이드, 계획·비계획 페일오버, 임포트, 리샤딩이 모두 이 온라인 모델로 처리된다. 또한 Insights, 스키마 추천, 브랜칭, MCP 등 기존 PlanetScale 기능도 함께 제공된다. 첫날부터 샤딩할 필요는 없다는 점도 도입 부담을 낮추는 요소다. 리플리카를 둔 단일 프라이머리 형태로 먼저 운영하며 개선된 커넥션 풀링과 온라인 DDL, 무중단 업그레이드, 상태 모니터링을 누리다가, 한 머신을 넘어서는 시점에 리샤딩을 하나의 워크플로로 실행하면 된다.
다만 현시점의 위치를 분명히 할 필요가 있다. 플래닛스케일은 Neki가 플랫폼 프리뷰 단계이며 이 기간에는 프로덕션 워크로드를 올리지 말라고 명시했다. 제품이 아직 변화 중이고 그 변화 가운데 일부는 하위 호환을 깨뜨리는 성격이라는 것이다. 결국 지금 단계의 Neki는 대규모 Postgres 확장에 대한 플래닛스케일의 설계 방향과 운영 모델을 검증해 볼 수 있는 대상이지, 당장 기간계에 투입할 대안은 아니다. 단일 머신의 천장에 근접한 팀이라면 자사 스키마와 쿼리 패턴을 기준으로 샤딩 전략을 미리 가늠해 보는 용도로 접근하는 것이 현실적이다.