MSA
여러 개의 작고 독립적인 서비스로 시스템을 구성하는 아키텍처 스타일로, 각 서비스는 독립적으로 배포·확장됩니다.
구조
클라이언트
│
API Gateway
(인증 · 라우팅 · LB)
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ 사용자 │ │ 주문 │ │ 결제 │
│ 서비스 │ │ 서비스 │ │ 서비스 │
└────┬───┘ └────┬───┘ └────┬───┘
│ │ │
┌──┴──┐ ┌───┴─┐ ┌───┴──┐
│ DB │ │ DB │ │ DB │
└─────┘ └─────┘ └──────┘
핵심 특징
- 서비스 독립성: 각 서비스는 독립 빌드 · 배포 · 확장
- DB 분리: 서비스별 독립 DB — Polyglot Persistence 가능 (MySQL, Redis, MongoDB 혼용)
- API 통신: REST, gRPC, 이벤트 메시징으로 서비스 간 통신
- API Gateway: 클라이언트 단일 진입점
서비스 간 통신
| 방식 | 프로토콜 | 특징 |
|---|---|---|
| 동기 | REST, gRPC | 즉각 응답이 필요할 때 |
| 비동기 | Kafka, RabbitMQ | 응답을 기다리지 않아도 될 때, 느슨한 결합 |
[동기 통신]
주문서비스 ──(HTTP)──→ 결제서비스 ──→ 응답 기다림
[비동기 통신]
주문서비스 ──(이벤트 발행)──→ Kafka ──→ 결제서비스 (독립 처리)
장점
- 서비스별 독립 배포 → 배포 리스크 감소
- 특정 서비스만 scale-out → 비용 효율
- 기술 스택 유연성 — 서비스마다 다른 언어/DB 선택 가능
- 장애 격리 — 서킷 브레이커로 전파 차단
단점
- 분산 트랜잭션: 여러 서비스에 걸친 데이터 정합성 어려움 → Outbox 패턴, Saga 패턴으로 보완
- 운영 복잡성: 수십 개 서비스의 배포 · 모니터링 · 로깅 관리
- 네트워크 지연: 서비스 간 API 호출로 레이턴시 증가
- 개발 환경 복잡: 로컬에서 여러 서비스 동시 실행 필요 (Docker Compose 등)
언제 적합한가?
- 팀이 충분히 크고 도메인이 명확히 분리될 때
- 서비스별 트래픽 차이가 클 때 (검색 서비스만 10배 증설)
- 배포 독립성이 중요할 때
- 이미 모놀리식이 한계에 부딪혔을 때 (배포 지연, 결합도 폭발)