먼저 단일 서버로 버틸 수 있는지 보고, 그다음 읽기/쓰기 확장, 일관성 모델, 멀티 리전 운영 순서로 선택 범위를 좁힌다.
핵심 이해
핵심은 “분산이 멋져 보여서”가 아니라, 어떤 병목을 해결해야 하는지에 따라 레플리케이션, 샤딩, NewSQL, NoSQL이 갈린다는 점이다.
| 단계 | 판단 질문 | YES면 | NO면 |
|---|---|---|---|
| Q1 |
단일 서버로 감당 가능한가? 분산은 기본값이 아니다. 먼저 가장 단순한 구조가 유지되는지 본다. |
선택 분산 불필요 운영 복잡성을 늘리지 않고 단순성을 유지한다. | 다음 Q2로 이동 병목이 읽기인지부터 확인한다. |
| Q2 |
읽기 확장만 필요한가? 같은 데이터를 복제해도 해결되는 문제라면 구조를 크게 바꿀 필요가 없다. |
선택 레플리케이션 읽기 트래픽을 분산하고 가용성을 높인다. Master-Slave 구성이 대표적이다. | 다음 Q3로 이동 쓰기까지 분산해야 하는지 본다. |
| Q3 |
쓰기도 확장이 필요한가? 쓰기량과 저장량이 함께 커지면 데이터를 나눠 보관하는 구조가 필요하다. |
선택 샤딩 + 필요 시 레플리케이션 데이터를 분할해 쓰기 처리량과 저장 용량을 함께 확장한다. | 선택 레플리케이션으로 충분 읽기 확장만 해결하면 된다. |
| Q4 |
강한 일관성이 필요한가? 분산 후에도 트랜잭션과 SQL 일관성을 얼마나 지켜야 하는지가 제품군을 가른다. |
선택 NewSQL 예: CockroachDB, Spanner, TiDB | 선택 NoSQL 예: Cassandra, DynamoDB |
| Q5 |
멀티 리전 분산이 필요한가? 여러 지역에 걸쳐 운영하면 지연 시간과 장애 범위를 함께 고려해야 한다. |
선택 멀티 리전 지원형 채택 예: Spanner, CockroachDB, Cassandra | 선택 단일 리전 샤딩 지역 범위를 넓히지 않고도 확장은 가능하다. |