피그마(Figma)는 급격한 사용자 증가에 따른 데이터베이스 부하 문제를 해결하기 위해 단일 Postgres 인스턴스에서 분산된 Vitess(MySQL 기반) 클러스터로 전환하는 대규모 샤딩 프로젝트를 성공적으로 완수했습니다. 이 과정에서 피그마 엔지니어링 팀은 서비스 중단 없이 테라바이트급 데이터를 이전하기 위해 정교한 실시간 복제 및 검증 시스템을 구축했습니다. 결론적으로 이들은 인프라의 한계를 미리 예측하고, 애플리케이션 계층의 수정을 최소화하면서도 수평적 확장이 가능한 데이터 아키텍처를 확보하게 되었습니다.

수직적 확장의 한계와 샤딩의 필연성

초기 피그마는 단일 AWS RDS Postgres 인스턴스에 의존했으나, 트래픽이 급증하며 가장 큰 인스턴스 크기로도 쓰기 부하를 감당할 수 없는 임계점에 도달했습니다.
수직적 확장(Vertical Scaling)과 읽기 복제본(Read Replicas) 추가만으로는 쓰기 성능 문제를 해결할 수 없음을 인지하고, 데이터를 여러 노드에 나누어 저장하는 수평적 확장(Sharding)을 결정했습니다.
자체적인 샤딩 솔루션을 구축하는 대신, 유튜브 등에서 검증된 오픈소스 데이터베이스 클러스터링 시스템인 Vitess를 도입하여 운영 복잡성을 관리하기로 했습니다.

Postgres에서 Vitess로의 대규모 이관 전략

기존 Postgres 환경에서 MySQL 기반의 Vitess로 전환하는 것은 데이터 모델과 쿼리 호환성 측면에서 큰 도전이었으며, 이를 위해 'FDB(Figma Database)'라는 중간 레이어를 구축했습니다.
Shadow Writing(새도우 라이팅): 모든 쓰기 작업을 기존 DB와 새 Vitess DB에 동시에 수행하여 데이터 정합성을 실시간으로 확인했습니다.
Logical Replication(논리적 복제): 기존 데이터를 중단 없이 옮기기 위해 CDC(Change Data Capture) 기술을 활용하여 소스 데이터베이스의 변경 사항을 실시간으로 Vitess에 반영했습니다.

무중단 컷오버와 정합성 검증

데이터 이전의 신뢰성을 확보하기 위해 'Consistency Checker'를 가동하여 기존 DB와 새 DB의 레코드를 지속적으로 비교하고 불일치를 해결했습니다.
Query Replay: 실제 운영 트래픽을 복제하여 대상 시스템에 미리 실행해 봄으로써 성능 병목 지점과 쿼리 호환성 문제를 사전에 파악했습니다.
최종 전환 시에는 아주 짧은 읽기 전용(Read-only) 시간을 가진 후, 트래픽의 방향을 Vitess로 돌리는 방식을 통해 사용자 경험에 영향을 주지 않고 성공적으로 전환했습니다.

개발자 경험 보존을 위한 쿼리 라우팅

샤딩된 환경에서도 개발자들이 개별 샤드의 위치를 신경 쓰지 않고 개발할 수 있도록 투명한 쿼리 라우팅 시스템을 구현했습니다.
크로스 샤드 조인(Cross-shard join)과 같이 분산 환경에서 성능이 저하될 수 있는 쿼리들을 모니터링하고, 필요에 따라 스키마 설계를 최적화하여 분산 시스템의 성능 이점을 극대화했습니다.
애플리케이션 코드의 대대적인 수정 없이도 샤딩된 데이터베이스를 활용할 수 있게 함으로써 피쳐 개발 속도를 유지했습니다.

급격히 성장하는 서비스에서 데이터베이스 확장은 피할 수 없는 과제이며, 이를 위해 서비스 초기부터 데이터 간의 관계(Entity Groups)를 명확히 정의해두는 것이 추후 샤딩 난이도를 낮추는 데 결정적인 역할을 합니다. 또한, 대규모 인프라 변경 시에는 완벽한 자동화보다는 단계적인 검증과 새도우 트래픽 테스트를 통해 데이터 유실 리스크를 최소화하는 보수적인 접근 방식이 권장됩니다.