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·관측성)이 받쳐줄 때 효과가 크다. 관련: 컨테이너·쿠버네티스