마이크로서비스 없이 PostgreSQL 스케일링: Notion의 480 샤드에서 얻은 교훈

Source: Dev.to

TL;DR: Notion의 모놀리스를 확장하기

• 애플리케이션‑레벨 샤딩 – 480개의 논리 샤드를 더 작은 물리 노드 집합에 매핑.
• 샤드 라우터 – space_id % 480을 사용해 즉시 요청을 라우팅하도록 TypeScript로 구현.
• PgBouncer – 트래픽 컨트롤러 역할을 하며, 연결을 풀링해 과부하를 방지.
• 무중단 마이그레이션 – “Shadow Write” 전략으로 수십억 행을 이동하면서 애플리케이션을 계속 운영.

Chapter 1: 모놀리스의 문제점

Notion 초기 아키텍처에서는 Node.js 백엔드가 단일 PostgreSQL 인스턴스와 짝을 이루었습니다. 시간이 지나면서 다음과 같은 문제에 직면했습니다:

• CPU 포화 – 일일 스파이크가 정기적으로 90 % 이상 사용량을 기록.
• Vacuum 문제 – Autovacuum이 따라가지 못해 Transaction ID 랩어라운드 위험이 발생, 이는 데이터 무결성을 보호하기 위해 쓰기를 중단시킴.

Chapter 2: 왜 마이크로서비스가 아닌가?

일반적인 마이크로서비스 논리는 “코드를 나누고, 부하도 나눈다”는 것입니다. Notion은 데이터 레이어를 확장하면서도 모놀리식 코드베이스를 유지하는 다른 길을 선택했습니다.

Chapter 3: 480‑샤드 설계도

논리 샤드

• 파티션 키 – space_id를 사용해 워크스페이스의 모든 데이터가 함께 보관되도록 하여 빠른 조인을 가능하게 함.
• 구성 – 480개의 독립 스키마(논리 샤드)를 32개의 물리 AWS RDS 인스턴스에 분산 배치.

장점

• 서버가 과부하될 경우, 논리 스키마를 새로운 서버로 옮겨 선형적인 확장성을 제공할 수 있음.

Chapter 4: 위대한 “Shadow” 마이그레이션

백필

• 기존 데이터를 백그라운드에서 새로운 샤드로 이동.

이중 쓰기

• 새로운 변경 사항을 기존 데이터베이스와 새로운 샤드에 동시에 기록.

전환

• 비교 엔진이 데이터 일치를 검증한 후, 트래픽을 새로운 샤드로 전환하여 무중단으로 전환 완료.

향후 개선 사항

• 96 노드로 확장 – 물리 노드 수를 늘려 부하를 더욱 분산.
• 블록 전체 적용 – 모든 콘텐츠를 블록으로 취급해 보다 세밀한 샤딩을 지속.
• 데이터 레이크 & 연결 허브 – 중앙 집중형 분석 및 통합 포인트 탐색.

댓글에 여러분의 생각을 자유롭게 공유해주세요!