피그마(Figma)는 단일 관계형 데이터베이스(RDS)의 물리적 한계에 직면하자, 이를 해결하기 위해 수직적 분할을 거쳐 최종적으로 수평적 샤딩(Horizontal Sharding) 체제로 전환했습니다. 이 과정에서 'Fidous'라는 자체 데이터베이스 프록시 계층을 구축하여 애플리케이션 코드의 복잡성을 줄이고 데이터 정합성을 유지했습니다. 결과적으로 피그마는 서비스 중단 없이 수백 개의 샤드로 데이터를 분산하며 가용성과 확장성을 획기적으로 개선하는 데 성공했습니다.

단일 데이터베이스의 한계와 임계점

피그마의 초기 성장은 단일 거대 RDS 인스턴스에 의존했으나, 트래픽 급증으로 인해 AWS가 제공하는 최대 하드웨어 사양(CPU, 메모리, IOPS)에 도달했습니다.
읽기 전용 복제본(Read Replicas)으로 조회를 분산했음에도 불구하고, 쓰기 작업의 부하와 복제 지연(Replication Lag) 문제가 전체 시스템의 안정성을 위협했습니다.
특히 특정 대형 조직의 데이터가 급증할 때마다 단일 DB의 성능 저하가 모든 사용자에게 영향을 미치는 구조적 취약점이 드러났습니다.

수직적 파티셔닝(Vertical Partitioning)을 통한 1차 대응

샤딩을 도입하기 전 과도기적 단계로, 특정 테이블들을 도메인별로 묶어 물리적으로 분리된 별도의 데이터베이스 인스턴스로 이동시켰습니다.
예를 들어 '사용자(Users)' 관련 테이블과 '파일(Files)' 관련 테이블을 서로 다른 DB 인스턴스로 분리하여 쓰기 부하를 분산했습니다.
이 방식은 당장의 급한 불을 끄는 데는 효과적이었으나, 가장 큰 테이블들이 여전히 단일 DB에 머물러 있어 근본적인 해결책은 되지 못했습니다.

수평적 샤딩(Horizontal Sharding)과 샤드 키 선정

데이터 행(Row)을 여러 DB에 분산 저장하는 수평적 샤딩을 최종 해결책으로 채택했습니다.
가장 중요한 결정은 '샤드 키(Shard Key)' 선정이었으며, 피그마는 대부분의 데이터가 조직(Organization) 단위로 액세스된다는 점에 착안해 org_id를 주요 샤드 키로 활용했습니다.
샤드 키가 없는 데이터나 여러 샤드에 걸친 쿼리를 처리하기 위해, Vitess의 개념을 차용한 자체 라우팅 레이어 'Fidous'를 개발하여 쿼리 라우팅과 트랜잭션 관리를 수행하게 했습니다.

무중단 마이그레이션: 라이브 백필과 섀도우 쓰기

수 테라바이트에 달하는 데이터를 서비스 중단 없이 새로운 샤드 체계로 옮기기 위해 다단계 마이그레이션 전략을 사용했습니다.
기존 DB에서 새로운 샤드로 데이터를 복제하는 '백필(Backfill)' 과정을 거친 후, 실시간 쓰기 작업을 양쪽 모두에 수행하는 '섀도우 쓰기(Shadow Write)'를 통해 정합성을 검증했습니다.
'데이터 정합성 검사기(Consistency Checker)'를 상시 가동하여 기존 DB와 샤딩된 DB 간의 오차를 0으로 만든 후, 트래픽을 단계적으로 전환(Cutover)했습니다.

피그마의 사례는 데이터베이스 확장성 문제를 해결할 때 처음부터 복잡한 샤딩을 도입하기보다, 수직적 분할로 시간을 벌고 그 사이 견고한 라우팅 인프라를 구축하는 단계적 접근이 중요함을 시연합니다. 특히 애플리케이션 계층과 데이터베이스 사이에 추상화 레이어를 두는 것은 장기적인 운영 효율성과 마이그레이션의 안정성을 확보하는 핵심 요소입니다.