Deepthi Sigireddi는 25년 넘게 소프트웨어 개발자로 일하며 MySQL과 Postgres의 샤딩 프로젝트를 맡아 왔다. 현재 Supabase에서 데이터베이스 조직을 이끌며, Multigres와 OrioleDB의 개발 현황과 데이터베이스 운영 경험을 이야기했다.
Sigireddi는 고등학교에서 공유하던 IBM PC로 컴퓨터를 처음 접했고, BASIC으로 두 수를 입력받아 더한 뒤 결과를 출력하는 프로그램을 만들었다. 2000년 무렵 소매업체의 공급망 계획 솔루션을 개발하면서 데이터베이스 분야에 들어섰다. 당시 데이터가 32비트 유닉스 서버의 메모리 한도인 4GB를 넘어서자 데이터베이스를 분할하고, 데이터를 나눈 뒤 여러 서버에서 실행을 병렬화하는 해결책을 공동으로 고안했다. 이를 계기로 데이터베이스 확장 문제를 15년가량 다뤘다.
Vitess와 Multigres
Sigireddi는 2020년부터 2025년까지 PlanetScale에서 Vitess 프로젝트를 이끌었다. 당시 유지관리팀은 기능 개발과 버그 수정뿐 아니라 릴리스, 문서, 웹사이트 관리, 성능 벤치마크와 홍보까지 담당했다. 팀은 되돌릴 수 있는 온라인 스키마 변경, 쿼리 호환성 개선, 고가용성을 위한 장애 조치 감지·복구 시스템 통합, 외래 키 지원, 분산 트랜잭션 등을 진행했다. Sigireddi는 기술 방향과 범위를 정하고 설계 논의를 이끌었으며, 복잡한 운영 장애를 디버깅하기도 했다.
그는 Vitess와 Multigres가 데이터베이스 자체와 다른 문제를 푼다고 설명했다. 데이터베이스는 단일 서버에서 ACID 속성을 제공하는 데 특화된 반면, 두 프로젝트는 분산 시스템을 다룬다. 분산 환경에서 ACID 속성을 보장하기는 매우 어렵다. Spanner, Yugabyte, TiDB 같은 NewSQL 데이터베이스가 이 문제에 도전했지만, 전통적인 Oracle·MySQL·Postgres만큼 폭넓게 채택되지는 않았다는 것이 그의 견해다.
Postgres의 장점이자 단점으로는 확장 기능 시스템을 꼽았다. 강력한 만큼 잘못 사용하기 쉽다는 설명이다. 가장 큰 장점은 오픈소스 커뮤니티라고 덧붙였다. MySQL은 운영하기 비교적 쉽고 대규모 운영 경험이 축적돼 함정이 잘 알려져 있지만, 준오픈소스 성격 때문에 버그 수정을 상류 버전에 반영하기가 매우 어렵다고 말했다.
Multigres와 Vitess는 관심사를 분리하는 아키텍처가 비슷하지만, 세부 설계에는 차이가 있다. Vitess는 절차적·휴리스틱 방식으로 장애 조치를 수행하고, Multigres는 리더 선출에 더 포괄적인 합의 방식을 쓴다. Sigireddi는 Multigres가 아직 초기 단계이며, 샤딩은 물론 샤드 간 트랜잭션도 지원되지 않는 것으로 안다고 밝혔다. 샤딩 지원 시점에 대해서는 “2027년”이라고 답했다.
Vitess의 샤드 간 트랜잭션은 처음에는 한 샤드에 장애가 생기면 일관성이 깨질 수 있는 최선 노력 방식이었다. 이후 2단계 커밋(2PC) 기반으로 개선했지만 격리성은 제공하지 않았다. Sigireddi는 샤드 간 격리성을 구현하는 일이 일관성을 보장하는 것보다도 어렵고, 이를 제대로 구현하는 데 수년이 걸릴 수 있어 다른 우선순위 높은 작업을 택했다고 설명했다. Multigres에서 격리성을 지원할지는 아직 열린 문제라고 덧붙였다.
그가 공유한 운영 장애 사례에서는 vtgate가 어떤 복제본이 쓰기 가능한지 오래된 정보를 보는 문제를 고치려 했다. 변경 사항을 승인해 프로덕션에 배포한 뒤, vtgate는 정상 데이터베이스가 하나도 없다고 판단했고 모든 쿼리가 “no healthy tablet” 오류를 반환했다. 시스템은 24시간 넘게 중단됐다. 그는 변경 사항에 마음에 걸리는 점이 있었는데도 충분히 테스트됐을 것이라 믿고 우려를 넘겼다며, 직감을 믿고 경계심을 유지해야 한다고 말했다.
OrioleDB와 Supabase 운영 규모
Sigireddi에 따르면 OrioleDB는 진공 처리와 테이블 비대화를 거의 없앤다. 업데이트가 잦은 테이블이 있는 작업 부하에서 특히 이점이 크지만, 읽기 중심 작업 부하에도 도움이 될 수 있다. Supabase는 OrioleDB 벤치마크를 dbarena.com에 공개했다. 그는 벤치마크 방법론과 소스가 공개돼 있어, AI 지원을 활용하면 결과를 재현하거나 원하는 작업 부하를 표준 Postgres와 비교하기 쉽다고 말했다.
Supabase의 OrioleDB는 베타 단계다. 정식 출시 시점은 기능 구성보다 신뢰성과 정확성 지표에 달렸으며, Sigireddi는 2027년을 예상했다. 장기적으로는 Supabase의 Postgres 서비스에서 기본 저장 엔진으로 삼되, 사용자가 선택적으로 쓰지 않을 수 있게 하는 것이 목표라고 밝혔다.
Supabase는 활성 데이터베이스를 1,000만 개 이상 운영하고 있으며, 일시 중지 상태인 데이터베이스는 그보다 많다. Sigireddi는 수천 개를 운영할 때와 수백만 개를 운영할 때의 문제가 전혀 다르다고 말했다. 인프라 관리의 비효율은 규모가 커질수록 확대되고, 수천 개 규모에서 몇 분 걸리던 작업이 수백만 개에서는 몇 시간이 걸릴 수 있다. 한 병목을 해결하면 다음 병목이 나타나므로 시스템의 모든 부분을 최적화해야 한다고 설명했다.
Postgres 18에서 OrioleDB가 비동기 I/O와 어떻게 작동할지 기대하고 있으며, Postgres 19에서는 MySQL보다 거의 10년 늦게 도입되는 WAIT FOR 기능이 흥미롭다고 말했다. Supabase에서 지켜볼 분야로는 Compute, AI 평가, Turso와 SQLite를 꼽았다. 앞으로는 대규모 데이터베이스를 최대한 활용하도록 돕는 방법과, 에이전트가 더 많은 소형 데이터베이스를 만드는 데 따라 생길 부담을 모두 살펴보고 싶다고 밝혔다.
관련 프로젝트: MySQL, Postgres, PlanetScale, Supabase.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요