MSA (Microservice Architecture)
I. 개요
- 정의: 하나의 애플리케이션을 독립적으로 배포 가능한 작은 서비스들의 집합으로 구성하는 아키텍처. 각 서비스는 자체 프로세스로 실행되고, 경량 통신(주로 HTTP/REST, 메시징)으로 협력한다.
- 배경 / 필요성: 모놀리식(단일 거대 애플리케이션)은 부분 수정에도 전체 재배포가 필요하고, 확장·기술 선택이 경직된다. 클라우드·DevOps 확산으로 빠른 배포·독립 확장이 요구되며 MSA가 부상했다.
II. 개념도 · 구성요소
[API Gateway] ← 단일 진입점(라우팅·인증·집계)
├─ 주문 서비스 ─ 주문 DB
├─ 결제 서비스 ─ 결제 DB
└─ 회원 서비스 ─ 회원 DB
[Service Discovery] [Config Server] [메시지 브로커]
| 구성요소 | 설명 |
|---|---|
| API Gateway | 외부 요청의 단일 진입점, 라우팅·인증·속도제한 |
| Service Discovery | 서비스 위치(인스턴스)를 등록·조회 |
| Config Server | 설정 중앙 관리 |
| 메시지 브로커 | 비동기 이벤트 통신(Kafka 등) |
| 서비스별 DB | Database per Service — 서비스마다 전용 DB |
III. 핵심 원칙 / 패턴
- 독립 배포·독립 확장: 서비스 단위로 배포·스케일
- 분산 데이터 관리: 서비스마다 DB 소유 → 조인 대신 API/이벤트로 연계
- Saga 패턴: 분산 트랜잭션을 보상 트랜잭션으로 처리
- Circuit Breaker: 장애 전파 차단(한 서비스 장애가 전체로 번지지 않게)
- API Gateway / BFF: 진입점 단일화
IV. 특징 · 장단점
| 구분 | 내용 |
|---|---|
| 장점 | 독립 배포·확장, 기술 다양성, 장애 격리, 팀 자율성 |
| 단점 | 분산 시스템 복잡도, 데이터 일관성 난이도, 운영·모니터링 부담, 네트워크 지연 |
| 고려사항 | 서비스 경계(DDD) 설계, 분산 추적·로깅, 조직 구조(콘웨이 법칙) |
V. 비교 — 모놀리식 vs MSA
| 구분 | 모놀리식 | MSA |
|---|---|---|
| 배포 | 전체 한 번에 | 서비스 단위 |
| 확장 | 전체 복제 | 필요한 서비스만 |
| DB | 단일 공유 | 서비스별 전용 |
| 장애 | 전체 영향 | 격리 가능 |
| 초기 복잡도 | 낮음 | 높음 |
VI. 적용 · 실무 관점
- 대규모 트래픽·빠른 릴리스가 필요한 서비스에 적합. 작은 서비스/초기 단계엔 모놀리식이 오히려 유리(모듈러 모놀리식 → 필요 시 MSA 전환).
- 보안 관점: 서비스 간 통신 인증(mTLS), API Gateway 인증·인가, 제로트러스트와 결합. 공격면이 늘어나므로 서비스 메시(Istio 등)로 통제.
VII. 결론
- MSA는 민첩성·확장성을 얻는 대신 분산 복잡도를 감수하는 선택이다.
- 조직·운영 역량(DevOps·관측성)이 받쳐줄 때 효과가 크다. 관련: 컨테이너·쿠버네티스