서비스별 데이터베이스(Database per Service) 패턴은 각 마이크로서비스가 전용 데이터베이스를 소유하는 아키텍처 원칙이다. 서비스 간 느슨한 결합과 독립적 확장을 가능하게 한다.
핵심 원칙
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 주문 서비스 │ │ 사용자 서비스│ │ 상품 서비스 │
│ │ │ │ │ │
│ PostgreSQL │ │ MongoDB │ │ Elasticsearch│
└──────────────┘ └──────────────┘ └──────────────┘
규칙:
- 다른 서비스의 DB에 직접 접근 금지
- 데이터 접근은 반드시 서비스 API를 통해
- 각 서비스는 DB 기술을 자유롭게 선택
다양한 격리 수준
1. 서비스별 DB 서버 (완전 격리)
장점: 완전 독립, 장애 격리
단점: 비용, 운영 복잡도
2. 서비스별 DB 스키마 (같은 서버)
장점: 비용 절감, 여전히 논리적 분리
단점: 노이즈 이웃 문제
3. 서비스별 테이블 (최소 격리)
장점: 이행 용이
단점: 여전히 결합 위험
데이터 일관성 전략
1. 이벤트 기반 일관성 (Eventual Consistency)
OrderService: 주문 생성 → "OrderCreated" 이벤트
InventoryService: 이벤트 소비 → 재고 차감
2. 사가 패턴 (분산 트랜잭션)
코레오그래피: 이벤트 체인
오케스트레이션: 중앙 사가 오케스트레이터
3. 아웃박스 패턴으로 이벤트 안전 발행
조회 문제 해결
문제: 여러 서비스 데이터 결합 조회
해결:
1. API 컴포지션: 게이트웨이에서 결합
2. CQRS Read Model: 비정규화 뷰 유지
3. GraphQL Federation: 스키마 통합
CQRS Read Model 예시:
각 서비스 이벤트 → Read Service 소비
→ 비정규화 테이블에 미리 조합
→ 단순 SELECT로 빠른 조회
관련 개념
