데브허브 | DEVHUB | How Figma Scaled To 10 Million UsersHow Figma Scaled To 10 Million Users
- Figma는 2020년 100배 성장 후 단일 PostgreSQL DB의 CPU 과부하로 실시간 협업 위기에 직면했습니다. 🚨
- 초기에는 AWS 최대 인스턴스 업그레이드, 읽기 복제본, 신규 기능별 DB, PG Bouncer 도입으로 임시적인 성능 개선을 시도했습니다. ☕
- DB 트래픽 분석 결과, 쓰기 요청이 주요 부하 원인이며 읽기 복제본은 즉각적인 일관성 요구 기능에 부적합하다는 한계를 발견했습니다. ✍️
- 장기적 해결책으로 관련 테이블 그룹 전체를 전용 DB로 이동하는 수직 파티셔닝을 도입하여 원본 DB 부하를 줄이고 향후 수평 샤딩 기반을 마련했습니다. 🧩
- 파티셔닝 마이그레이션 시, 논리적 복제 중 인덱스 업데이트 비효율 문제를 해결하기 위해 인덱스를 제거하고 데이터 복사 후 재구축하여 복사 시간을 며칠에서 몇 시간으로 단축했습니다. ⚡
- PG Bouncer를 활용한 2단계 배포 전략으로 애플리케이션 연결 경로를 안전하게 업데이트하고 라우팅 정확성을 확인하여 마이그레이션 위험을 최소화했습니다. 🛡️
- 2022년 말, 개별 테이블이 수 테라바이트로 커지면서 파티셔닝의 한계에 도달했고, PostgreSQL vacuum 문제 및 RDS IOPS 한계로 수평 샤딩의 필요성이 대두되었습니다. 📈
- 수평 샤딩 준비를 위해 실제 데이터 이동 없이 샤딩 로직을 테스트할 수 있는 PostgreSQL 뷰 기반의 논리적 샤딩을 구현했습니다. 🧪
- 효율적인 데이터 분산과 핫스팟 방지를 위해 사용자 ID와 같은 샤드 키를 공유하는 관련 테이블을 그룹화하고, 샤드 키를 해싱하여 분산시키는 전략을 사용했습니다. 🔑
- 애플리케이션과 PG Bouncer 사이에 Golang으로 구축된 DB 프록시를 도입하여 쿼리에서 샤드 키를 식별하고 해당 샤드로 라우팅하거나, 모든 샤드에 쿼리하여 결과를 취합하도록 했습니다. 📡
- 2023년 9월, 첫 물리적 샤드 분할을 성공적으로 완료하여 10초의 부분적 가용성 영향만으로 가장 복잡한 고트래픽 테이블의 확장 한계를 극복했음을 입증했습니다. ✅