저는 수년 동안 최전선에서 활동해 왔습니다. 처음에는 Web2 모놀리스(monoliths)를 확장하는 일부터 시작하여, 현재는 Web3의 분산된 환경과 현대적인 DevOps의 복잡성을 탐색하고 있습니다. 스택에 관계없이 항상 지속적인 고충이었던 점은 관계형 데이터베이스(relational databases), 특히 Postgres를 확장하는 일이었습니다. 우리는 Postgres의 견고함, 기능, 그리고 신뢰성 때문에 이를 사랑하지만, 트래픽이 임계점에 도달하면 선택지는 보통 읽기 복제본(read replicas), 수동 샤딩(manual sharding), 또는 완전히 다른 데이터베이스 패러다임으로 이동하는 악몽 같은 상황으로 변질되곤 합니다. 그렇기에 Supabase의 Multigres v0.1 Alpha 발표는 제 눈길을 즉시 사로잡았습니다.

핵심적인 문제: Postgres 확장(Scaling)의 과제

솔직해집시다. Postgres는 놀랍지만, 수평 확장(horizontal scaling)은 항상 아킬레스건이었습니다. 더 큰 사양의 머신을 투입할 수 있고(수직 확장 (vertical scaling)), 읽기 확장을 위해 복잡한 복제 체인(replica chains)을 구축할 수도 있지만, 쓰기(writing)에 있어서는 벽에 부딪히게 됩니다. 샤딩(Sharding)이 일반적인 해답이지만, 이는 엄청난 운영 부담을 초래합니다. 애플리케이션 레벨의 샤딩 로직을 다루고, 여러 데이터베이스 인스턴스를 관리하며, 샤드 간의 데이터 일관성(data consistency)을 보장하고, 리밸런싱(rebalancing)을 처리해야 합니다. 이는 전문 팀이 전담해야 하는 업무이며, 종종 기업들이 Vitess와 같은 복잡한 솔루션으로 눈을 돌리게 만듭니다. 하지만 Vitess 자체도 배포하고 운영하기에 매우 까다로운 존재입니다.

Supabase의 Multigres v0.1 Alpha는 이 문제를 정면으로 해결하겠다고 약속합니다. 그들은 이를 "Postgres를 위한 운영 체제(operating system)"라고 부르는데, 이는 매우 강력한 선언입니다. 핵심 아이디어는 "Vitess급의 수평 확장(horizontal scaling), 고가용성(high availability), 그리고 운영의 단순함을 Postgres에 가져오는 것"입니다. 만약 그들이 이 약속의 절반이라도 실현할 수 있다면, 이는 고트래픽 애플리케이션을 구축하는 모든 팀에게 엄청난 승리가 될 것입니다.

Multigres가 목표로 하는 것

제가 파악한 바로는, Multigres는 샤딩 (sharding) 및 고가용성 (high-availability)의 복잡성을 추상화하도록 설계되었습니다. 애플리케이션이 어떤 샤드에 데이터를 써야 하는지, 또는 장애 조치 (failover)를 어떻게 처리해야 하는지를 알 필요 없이, Multigres가 스마트 프록시 (smart proxy) 또는 제어 평면 (control plane) 역할을 수행합니다. 애플리케이션은 마치 단일한 모놀리식 (monolithic) Postgres 인스턴스인 것처럼 Multigres에 연결하며, Multigres는 쿼리를 올바른 하위 Postgres 샤드로 지능적으로 라우팅하고, 복제 (replication)를 관리하며, 장애 조치를 원활하게 처리합니다.

이렇게 생각하면 쉽습니다: 여러분은 여전히 Postgres를 사용하고 있지만, 더 이상 개별 인스턴스와 직접 상호작용하지 않습니다. 여러분은 여러분을 대신하여 Postgres 인스턴스 군단을 오케스트레이션 (orchestrate)하여, 이들이 하나의 거대하고 확장 가능한 데이터베이스처럼 보이게 만드는 시스템과 대화하는 것입니다. 이는 개발 속도 (developer velocity)를 유지하고 운영 오버헤드 (operational overhead)를 줄이는 데 매우 중요합니다. "Vitess급"이라는 비교가 의미 있는 이유는 Vitess가 세계에서 가장 큰 애플리케이션들(YouTube, Slack 등)을 확장하는 데 성능이 입증되었기 때문입니다. 이러한 수준의 정교함을 더 접근하기 쉬운 Postgres 네이티브 (Postgres-native) 솔루션으로 가져오는 것은 믿기지 않을 정도로 흥미로운 일입니다.

이것이 코드에 어떤 영향을 미치나요?

Multigres와 같은 시스템이 잘 구현되었을 때 가장 아름다운 점은 애플리케이션 코드에 미치는 영향이 최소화되어야 한다는 것입니다. 여러분은 여전히 Postgres 호환 인터페이스와 상호작용합니다. 이는 기존의 ORM, 쿼리 빌더 (query builder), 그리고 데이터베이스 클라이언트가 수정 없이 또는 거의 수정 없이 작동해야 함을 의미합니다. 복잡성은 견고하고 확장 가능한 시스템을 위해 마땅히 있어야 할 곳인 인프라 계층 (infrastructure layer)으로 밀려납니다.

다음은 Node.js pg 클라이언트를 사용한 간단한 예시입니다. 연결 문자열 (connection string)이 특정 Postgres 인스턴스가 아닌 Multigres 프록시를 가리키고 있다는 점에 주목하세요:

import pg from 'pg';
...