Figma 데이터베이스 팀이 대 (새 탭에서 열림)
Figma는 데이터베이스 규모가 2020년 이후 약 100배 성장하면서 단일 Postgres와 수직 분할만으로는 한계에 도달했다. 먼저 캐시, 읽기 복제본, 수직 파티셔닝으로 확장 여유를 확보했지만, 수 테라바이트 규모의 테이블과 급격히 증가하는 쓰기량 때문에 수평 샤딩이 필요해졌다. Figma는 새로운 데이터베이스로 전면 이전하기보다 기존 RDS Postgres 전문성과 데이터 일관성을 유지하는 점진적 수평 샤딩을 선택해 약 9개월 만에 확장 기반을 마련했다. ## 급격한 성장과 수직 파티셔닝의 한계 - Figma는 2020년 AWS의 가장 큰 물리 인스턴스에서 단일 Postgres를 운영했다. - 2022년 말에는 다음과 같은 분산 구조로 발전했다. - 캐시 - 읽기 복제본 - 약 12개의 수직 분할 데이터베이스 - “Figma 파일”, “조직”처럼 연관된 테이블 그룹을 별도 데이터베이스로 분리해 점진적으로 확장했다. - 수직 파티셔닝은 CPU 사용량을 낮추고 빠르게 확장 여유를 확보하는 데 효과적이었다. - 그러나 수직 분할의 최소 단위는 테이블 하나이므로, 하나의 테이블 자체가 지나치게 커지는 문제는 해결하지 못했다. ## 데이터베이스 병목을 정량적으로 측정 - Figma는 CPU뿐 아니라 다음 지표를 함께 모니터링했다. - 디스크 I/O - 테이블 크기 - 기록되는 행 수 - 데이터베이스별 처리 한계 - 과거 운영 데이터와 부하 테스트를 조합해 각 데이터베이스와 샤드의 “남은 확장 여유”를 예측했다. - 수 테라바이트와 수십억 개의 행을 가진 테이블에서는 Postgres의 `VACUUM` 작업이 안정성에 영향을 주기 시작했다. - `VACUUM`은 트랜잭션 ID 고갈을 방지하는 필수 백그라운드 작업이지만, 대형 테이블에서는 처리 부담이 커진다. - 쓰기량이 가장 많은 테이블은 AWS RDS가 제공하는 최대 IOPS에 곧 도달할 상황이었다. - 이 문제는 테이블을 다른 데이터베이스로 옮기는 수직 분할만으로는 해결할 수 없어 수평 샤딩이 요구됐다. ## 확장 설계의 목표 Figma는 단순히 데이터를 여러 데이터베이스에 나누는 것보다, 운영과 애플리케이션 변경 위험을 최소화하는 것을 중요하게 봤다. - **개발자 영향 최소화** - 기존의 복잡한 관계형 데이터 모델을 최대한 유지한다. - 애플리케이션 개발자가 대규모 데이터 접근 코드를 전면 수정하지 않도록 한다. - **투명한 확장** - 최초에 샤딩 호환성을 확보한 뒤에는, 향후 샤드를 추가할 때 애플리케이션 변경을 최소화한다. - **대규모 백필 회피** - 수개월이 걸릴 수 있는 전체 테이블 백필이나 전체 데이터 마이그레이션을 피한다. - **점진적 적용** - 빠르게 증가하는 테이블부터 단계적으로 적용한다. - 각 단계에서 위험을 검증해 대규모 장애 가능성을 낮춘다. - **롤백 가능성 확보** - 물리적 샤딩 이후에도 문제가 생기면 이전 상태로 되돌릴 수 있어야 한다. - **강한 일관성 유지** - 다운타임과 일관성 위험을 유발할 수 있는 이중 쓰기 방식을 피한다. - 거의 무중단에 가까운 확장을 목표로 한다. - **기존 역량 활용** - 이미 축적한 RDS Postgres 운영 경험과 도구를 활용해 새로운 저장소의 불확실성을 줄인다. ## 대체 데이터베이스 검토 - Figma는 수평 확장을 지원하는 여러 기술을 검토했다. - CockroachDB - TiDB - Spanner - Vitess - 그러나 새 데이터베이스로 전환하려면 기존 Postgres와 새 저장소 사이의 복잡한 데이터 마이그레이션이 필요했다. - 데이터 일관성과 안정성을 확보하면서 핵심 기능을 모두 이전하려면 상당한 시간이 필요했다. - Figma는 이미 RDS Postgres를 안정적이고 성능 좋게 운영하는 전문성을 갖고 있었으므로, 새로운 데이터베이스로 바꾸면 이 역량을 다시 구축해야 했다. - 성장 속도가 매우 빨라 남은 확장 여유가 수개월뿐이었기 때문에, 새로운 저장소를 도입하는 것은 기술적으로 가능하더라도 일정과 위험 측면에서 적합하지 않았다. ## NoSQL을 선택하지 않은 이유 - NoSQL은 기본적으로 수평 확장을 제공하지만, Figma의 데이터 모델과는 잘 맞지 않았다. - Figma는 복잡한 관계형 데이터와 여러 테이블 간 관계를 Postgres 위에서 활용하고 있었다. - NoSQL API만으로는 이러한 관계형 질의와 데이터 모델의 유연성을 동일하게 제공하기 어려웠다. - 따라서 애플리케이션 구조를 대규모로 재설계하는 대신, 기존 관계형 모델을 유지하면서 Postgres를 수평 확장하는 방향을 택했다. ## 실용적인 결론 데이터베이스 확장은 처음부터 수평 샤딩으로 시작하기보다, 캐시·읽기 복제본·수직 파티셔닝으로 단기 여유를 확보한 뒤 실제 병목을 측정하며 단계적으로 진행하는 것이 현실적이다. 특히 기존 데이터베이스에 대한 운영 역량과 강한 일관성이 중요하다면, 새로운 저장소로 전면 이전하기보다 현재 시스템을 유지한 채 점진적으로 샤딩하는 전략이 위험과 개발 비용을 줄일 수 있다.