Phase 2레슨 10
Microservices
Service Boundary, API Contract, Service Discovery, Saga, Circuit Breaker
💡ELI5·
Microservices를 푸드코트에 비유하면
Client / Gateway
↓
주문 서비스 | 결제 서비스 | 재고 서비스 | 배송 서비스
↔ ↔ ↔ ↔
Service Discovery + Load Balancer
↓
각 서비스별 독립 DB💡 비유 — Microservices = 푸드코트 (각 음식점이 독립 운영, 한 곳이 망해도 다른 곳은 정상). Monolith = 대형 레스토랑 (하나의 주방에서 모든 음식, 주방 문제 시 전체 중단).
🔬Deep Dive·
Service Boundary & Domain Boundary
Service Boundary: 독립 배포 단위인 서비스의 경계. Domain Boundary: 비즈니스 도메인(주문, 결제, 재고)의 경계. 이 둘이 일치해야 한다. 기술 계층(presentation/service/data)이 아니라 도메인 단위로 서비스를 나눈다.
💡 비유 — 푸드코트를 '한식·중식·일식'으로 나누는 것(도메인 경계)이지, '주방·홀·계산대'로 나누는 것(기술 계층)이 아니다.
🔬Deep Dive·
Saga Pattern — 분산 트랜잭션
| 방식 | 동작 | 장점 | 단점 |
|---|---|---|---|
| Choreography | 각 서비스가 이벤트를 발행/구독하여 자율적으로 진행 | 중앙 조정자 없음, 결합도 낮음 | 플로우 파악 어려움, 디버깅 복잡 |
| Orchestration | 중앙 Orchestrator가 각 서비스 호출 순서 제어 | 플로우 명확, 디버깅 용이 | Orchestrator SPOF, 결합도 증가 |
주문 생성 → 결제 → 재고 차감 → 배송 시작
↓ 실패
재고 보상(복원) → 결제 보상(환불) → 주문 취소🔬Deep Dive·
Circuit Breaker
Closed (정상) → 실패 누적 → Open (차단)
↓ 시간 경과
Half-Open (테스트)
↓ 성공 → Closed
↓ 실패 → Open서비스 장애가 지속되면 Circuit을 Open하여 호출을 차단. 차단된 동안 호출자는 즉시 폴백 응답을 받아 장애 전파를 막는다. 일정 시간 후 Half-Open으로 복구를 테스트한다.
⚖️Trade-off·
Microservices vs Monolith
| 구분 | Monolith | Microservices |
|---|---|---|
| 배포 | 전체 한 번에 | 서비스별 독립 |
| 확장 | 전체 확장 | 개별 확장 |
| 데이터 일관성 | 단일 DB, 간단 | 분산, Saga/2PC 필요 |
| 관측성 | 단일 프로세스 | 분산 추적 필요 |
| 팀 구조 | 소규모 적합 | 대규모, 독립 팀 |
| 복잡성 | 낮음 | 높음 (네트워크, 배포, 관측) |
Golden Rule: 유행하는 아키텍처를 목표로 하지 마라. 가장 단순한 구조로 요구사항을 만족시키고, 필요한 시점에만 복잡성을 추가하라.
❓ 체크포인트 질문
- 1.Service Boundary와 Domain Boundary가 일치해야 하는 이유는?
- 2.Database per Service 패턴의 장단점은?
- 3.Saga 패턴에서 Compensation(보상)이란?
- 4.Circuit Breaker가 장애 전파를 막는 원리는?
- 5.Microservices가 항상 정답이 아닌 이유는?