Figma가 데이터베이스의 부하를 개선해나간 과정을 정리한 글입니다. Figma는 Amazon RDS에서 단인 Postgres 데이터베이스를 2020년까지 사용하고 있었다고 합니다. 당시 CPU

Figma가 데이터베이스의 부하를 개선해나간 과정을 정리한 글입니다. Figma는 Amazon RDS에서 단인 Postgres 데이터베이스를 2020년까지 사용하고 있었다고 합니다. 당시 CPU 사용률이 65%나 되었기 때문에 개선이 필요했다고 하는데 정확한 사용자수와 데이터의 양은 모르지만 2020년이어도 꽤나 Figma가 인기를 얻던 시기인데 당시에도 단일 데이터베이스를 쓰고 있었던 것 만으로도 인상적입니다. 이 문제를 개선하기 위해 일단 읽기 리플리카를 만들어서 데이터베이스 부하를 분산하고 PgBouncer를 사용해서 연결 수를 제어해서 이어진 개선 작업까지의 시간 여유를 만들었다고 합니다. Figma의 데이터베이스 부하는 대부분 쓰기와 관련되어 있었고 복제 지연시간은 감당할 없는 읽기도 많았기 때문에 읽기 리플리카로는 문제를 제대로 해결할 수 없었다고 합니다. 해결 방법을 고민하면서 수평 확장이 가능한 NoSQL이나 Vitess도 고려했지만 애플리케이션의 수정이 많이 필요한데다가 해당 데이터베이스에 대한 경험도 없었기 때문에 직접 운영하는 데에 대한 부담때문에 이러한 선택은 제외하고 기존의 매니지드 솔루션을 그래도 사용하기로 했습니다. Figma가 선택한 방법은 데이터베이스에서 테이블별로 수직 분할해서 테이블 그룹별로 여러 데이터베이스로 옮기는 것이었습니다. 이러한 수직 파티셔닝은 기존 데이터베이스에 대한 부하는 줄이면서도 향후 테이블의 하위 집할을 다시 수평으로 샤딩할 수 있는 장점이 있는 것으로 결과적으로 알게 되었다고 합니다. 이 수직 파티셔닝을 위해 Ruby의 ActiveRecord에서 사용할 수 있는 런타임 유효성 검사기를 만들어서 같은 테이블 그룹을 참조하는 쿼리와 트랙잭션을 기록해서 파티셔닝 그룹의 후보를 구성하고(테이블이 다른 데이터베이스로 분리되면 조인 등을 할 수 없으므로...) 마이그레이션 목포는 가용성 영향을 1분 미만으로 하면서 반복해서 실행할 수 있고 문제가 있을 경우 파티션을 다시 취소할 있도록 잡았기 때문에 직접 만들어서 할 수 밖에 없었다고 합니다. 첫 작업에서 2개의 테이블을 옮겼는데 2022년 10월에는 50개의 테이블을 옮겨서 제일 큰 데이터베이스 사용률도 10%까지 낮추었다고 합니다. https://www.figma.com/blog/how-figma-scaled-to-multiple-databases/