MSA
하나의 거대한 애플리케이션을
독립적으로 개발 · 배포 · 확장 가능한 작은 서비스 단위로 나누는 아키텍처
- “하나의 큰 서버” → “역할별로 나뉜 여러 서버”
- small services, each running in its own process(스스로 돌아 갈 수 있는 작은 서비스) 와, independently deployable(독립적 배포 가능)
왜 MSA가 나왔을까?
모놀로식 구조의 현실적인 문제
하나의 서버에 모든 기능이 들어있는 경우:
- 회원, 주문, 결제, 알림이 한 프로젝트
- 코드가 커질수록
- 수정 → 전체 테스트
- 배포 → 전체 재배포
- 특정 기능 트래픽 폭증 시
- 서버 전체가 느려짐
- 한 기능 장애 → 전체 서비스 장애
예시
- 회원 기능 오류
- 서버 재시작
- 주문 / 결제 / 알림 전부 중단
⇒ 대규모 서비스에서 치명적
서버 구축 방식 비교
모놀로식 아키텍처 (Monolithic)
특징
- 하나의 프로젝트
- 하나의 서버
- 모든 비즈니스 로직 포함
장점
- 구조가 단순
- 개발·배포가 쉬움
- 소규모 서비스에 적합
단점
- 규모 커질수록 유지보수 어려움
- 부분 장애가 전체 장애로 확산
- 확장(Scale)이 비효율적
MSA (Microservice Architecture)
특징
- 기능(도메인)별로 서비스 분리
- 각 서비스는 독립적인 서버
- API를 통해 서로 통신
예시 구조
[Gateway]
↓
[회원 서비스]
[주문 서비스]
[결제 서비스]
[알림 서비스]
MSA의 핵심 개념
1) 독립 배포
- 회원 서비스 수정 → 회원 서비스만 배포
- 다른 서비스 영향 없음
2) 독립 확장 (Scale)
- 주문 트래픽 폭증 → 주문 서비스만 확장
- 비용 효율적
3) 장애 격리
- 알림 서비스 장애
- 주문/결제는 정상 동작
MSA 장단점
장점
- 서비스별 독립적인 스케일링
- 서비스별 다른 기술 스택 사용 가능
- 회원: Spring
- 실시간 알림: Node.js
- 장애 전파 최소화
- 빠른 기능 개선 및 배포
단점
- 초기 설계 난이도 높음
- 서비스 간 통신 복잡
- 네트워크 비용 발생
- 운영/모니터링 부담 증가
- 데이터 관리가 어려움
그래서 MSA는 무조건 좋은 구조가 아니다
→ 규모가 커질 때 선택하는 구조
MSA에서 반드시 같이 고려해야 할 요소들
1) 서비스 간 통신 방식
- REST API (HTTP)
- 비동기 메시지 (Kafka, RabbitMQ)
예시
- 주문 서비스 → 결제 서비스 호출
- 네트워크 실패 가능성 존재
- 예외 처리 필수
2) 장애 대응 (Fault Tolerance)
- 특정 서비스가 느리거나 죽었을 때
- 전체 장애 방지 필요
대표 기술 개념:
- 타임아웃
- 재시도
- 서킷 브레이커
(Spring Cloud Resilience4j)
3) 데이터 관리
❌ 하나의 DB를 여러 서비스가 공유하면 안 됨
✅ 서비스별 DB 분리
- 회원 서비스 → 회원 DB
- 주문 서비스 → 주문 DB
⇒ 데이터 정합성은 이벤트 기반으로 해결
MSA에서 데이터 정합성은 하나의 트랜잭션으로 보장하지 않고 이벤트를 통해 각 서비스가 상태를 맞춰가는 방식으로 해결
MSA 구성 요소 전체 그림
Bello! NewOld velog~