Architecture Patterns

DB 아키텍처 패턴은 병목을 분리하는 대신 운영 비용을 늘린다

많은 신규 서비스에서는 단일 DB가 가장 단순한 출발점입니다. 이후에는 읽기, 쓰기, 저장량, 지역 지연, 장애 범위 중 무엇이 실제 병목인지에 따라 구조를 분리합니다.

1

Single DB

App
↓
Primary DB

트랜잭션과 운영 판단이 단순합니다. 병목이 명확하지 않다면 단순성이 큰 장점입니다.

2

Primary + Replica

Primary
↓ 복제
Read 1
Read 2
Read 3

조회 부하를 분산합니다. 대신 복제 지연과 읽기 최신성 정책을 함께 설계해야 합니다.

3

Sharding

Router
key 기준 분배
Shard A
Shard B
Shard C

저장량과 쓰기량을 나눕니다. 샤드 키, 재분배, 분산 조인이 새 비용입니다.

4

Multi-region

KR
US
EU
정책으로 동기화
Consistency

지연과 장애 범위를 줄일 수 있습니다. 일관성, 데이터 주권, 비용이 함께 커집니다.

읽기 병목 Replica가 첫 후보 목록, 대시보드, 조회 API가 먼저 느려지면 읽기 분리를 검토합니다.
쓰기·용량 병목 Shard는 명확한 기준이 필요 어떤 키로 나눌지 설명하지 못하면 샤딩은 문제를 키울 수 있습니다.
지역·장애 병목 Region 분산은 정책 문제 가까이 두는 것보다 어떤 일관성을 포기할지 정하는 일이 더 중요합니다.
주의
아키텍처 패턴은 성장의 훈장이 아니라 비용입니다. 단순한 구조로 감당 가능한 동안은 단순성이 이기고, 명확한 병목과 실패 비용이 확인될 때 분리하는 편이 안전합니다.