기존 모노리스 프로젝트만 개발하던 나에게 MSA는 꽤 충격적으로 다가왔다. 수많은 table들이 관계를 형성하고, 형성하다 못해 관계를 위한 관계테이블까지 추가하며 개발해왔던 방식에만 익숙했던 나는 MSA 방식이 너무나 신기했다.
우선 Spring App이 유일하지 않다는 점과
모든 서비스들 간에 table이 유일하게 존재한다는 것
물론 table 내부에 별도의 관계를 가지는 것도 있었지만
관계를 가진다고 해서 무조건 이득이 아니듯이 각각의 서비스에 독립성을 보장해주는 느낌이었다.
추가로 신기했던 부분은 바로 Gateway였다. 모든 API 요청 응답을 처리하는 App이 별도로 존재한다는 것
table 수가 너무나도 많았던 것(참조를 할 필요가 줄어드니 각 서비스가 필요로 하는 데이터를 계속해서 공유하는 것)
또 커다란 착각 중 하나는 관계를 형성하지 않으면 JPA나 Join 방식이 어려울 것이라는 생각이었다. 모노리스 방식에 익숙했던 탓이기도 하지만 나의 기본기 부족 문제도 있었다.
1. MSA란?
MSA(Microservices Architecture, 마이크로서비스 아키텍처)**는 하나의 애플리케이션을 작고 독립적인 서비스 단위로 나누어 개발·배포하는 아키텍처
- 각 서비스는 독립적으로 배포 가능
- 서비스 간 통신은 주로 HTTP REST, gRPC, 메시지 큐 등으로 수행
- 기존 Monolithic(단일 애플리케이션) 방식과 대비됨
장점
- 유연한 배포
- 서비스 단위로 배포 가능 → 일부 서비스만 업데이트 가능
- 확장성
- 트래픽 많은 서비스만 독립적으로 스케일 아웃 가능
- 개발 효율
- 팀 단위로 서비스 분리 → 병렬 개발 가능
- 기술 선택 자유
- 서비스마다 다른 언어, DB, 프레임워크 사용 가능
단점 / 고려사항
- 서비스 간 통신 복잡
- 모니터링, 로깅, 배포 자동화 필요
- 데이터 관리가 분산 → 트랜잭션 관리 어려움
2. MSA 구성 요소
구성 요소 설명
| API Gateway | 클라이언트 요청을 각 서비스로 라우팅, 인증, 로깅 담당 |
| Service Registry / Discovery | 동적으로 서비스 위치 관리 (예: Eureka, Consul) |
| Configuration Server | 분산 환경에서 설정 관리 (예: Spring Cloud Config) |
| Load Balancer | 트래픽 분산, 서비스 인스턴스 간 부하 조절 |
| Messaging / Event Bus | 비동기 통신, 이벤트 기반 연동 (Kafka, RabbitMQ 등) |
| Monitoring / Logging | 서비스 상태 추적, 오류 분석 (Prometheus, ELK 등) |
3. MSA 설계 핵심 개념
- 서비스 분리 기준
- 도메인 단위 → 주문, 결제, 회원, 상품 등
- 기능 단위 → CRUD, 외부 연동 등
- 데이터베이스 분리
- 각 서비스별 DB 소유 → DB 단일화 금지
- 필요 시 이벤트 기반 데이터 동기화
- 통신 방식
- 동기식: REST API, gRPC
- 비동기식: 메시지 큐, 이벤트 스트리밍
- 트랜잭션 처리
- 분산 트랜잭션보다 Saga 패턴 추천
- 이벤트를 통한 상태 보상(Compensation) 처리
4. MSA 적용 예시
[Client] → [API Gateway] → [User Service] → [DB]
→ [Order Service] → [DB]
→ [Payment Service] → [DB]
- 회원가입 → 주문 → 결제 흐름을 각 서비스가 독립적으로 처리
- 이벤트 기반 통신 가능: 주문 생성 이벤트 → 결제 서비스가 구독 후 처리
1인 개발로 msa의 특징을 얼마나 학습할 수 있는지 모르겠지만 스스로 개발을 이어나가고 꾸준히 학습해야 익숙해질 것 같다.
또 MSA에서 JPA의 작동방식과 transaction의 동작 주기가 어떤 식인지도 알아봐야 하겠다.