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 분산은 정책 문제 가까이 두는 것보다 어떤 일관성을 포기할지 먼저 정해야 합니다.
분리 비용
아키텍처 패턴은 성장의 훈장이 아니라 비용입니다. 단순한 구조로 감당 가능한 동안은 단순성이 이기고, 명확한 병목과 실패 비용이 확인될 때 분리하는 편이 안전합니다.