MSA

왜 쓰는지

모놀리식은 배포와 운영이 단순하지만, 규모가 커질수록 한 기능의 장애와 변경이 전체 서비스에 영향을 줄 수 있습니다. MSA는 시스템을 여러 작은 서비스로 나누어 독립적으로 개발, 배포, 확장하기 위한 방식입니다.

핵심: MSA는 기능을 작은 서비스로 나누는 것이 아니라, 데이터 소유권과 배포 책임까지 분리하는 아키텍처입니다.

member-service    -> 회원 데이터 소유
order-service     -> 주문 데이터 소유
payment-service   -> 결제 데이터 소유
inventory-service -> 재고 데이터 소유

서비스 경계는 테이블 수나 코드 양이 아니라 업무 책임과 데이터 소유권을 기준으로 나눕니다.

방식	설명	사용 예
동기 호출	요청 후 응답을 기다림	주문 화면에서 회원 정보 조회
비동기 이벤트	이벤트 발행 후 각 서비스가 처리	주문 완료 후 알림/재고 차감

order-service
  └─ OrderCreated 이벤트 발행
       ├─ payment-service
       ├─ inventory-service
       └─ notification-service

MSA에서는 서비스마다 DB를 분리하는 경우가 많습니다. 그래서 단일 DB 트랜잭션으로 여러 서비스의 데이터를 한 번에 묶기 어렵습니다.

주문 생성
  -> 결제 요청
  -> 재고 차감
  -> 실패 시 보상 처리

이런 흐름은 Saga, Outbox, 멱등성 같은 패턴을 함께 고려합니다.

각 서비스가 자신의 데이터를 소유합니다. 다른 서비스가 직접 DB를 조회하지 않고 API나 이벤트로 협력합니다.

order-service -> order_db
payment-service -> payment_db

API 스펙, 이벤트 스키마, 에러 포맷이 계약이 됩니다. 계약 변경은 소비자에게 영향을 주므로 하위 호환성을 고려해야 합니다.

서비스가 많아질수록 로그, 메트릭, 트레이스가 없으면 장애 원인을 찾기 어렵습니다.

여러 서비스가 즉시 같은 상태가 되지 않을 수 있습니다. 비즈니스가 허용하는 지연 시간과 보상 정책을 정해야 합니다.

작은 조직에서 성급하게 MSA를 도입하면 운영 비용이 더 큽니다.

서비스 수만큼 배포, 장애 대응, 모니터링, 테스트 복잡도가 증가합니다.

공유 DB는 서비스 분리 효과를 크게 떨어뜨립니다.

여러 서비스가 같은 테이블을 직접 읽고 쓰면 배포와 변경이 다시 강하게 묶입니다.

동기 호출 체인이 길어지면 장애가 전파됩니다.

타임아웃, 재시도, Circuit Breaker, 비동기 이벤트를 함께 설계해야 합니다.

관련 파일: - 아키텍처 패턴 — 모듈러 모놀리스와 계층 구조 - Kafka — 비동기 이벤트 통신 - 아웃박스 패턴 — 이벤트 발행 정합성