하나의 거대한 애플리케이션이 팀 규모와 함께 성장하면, 배포 하나가 전체 시스템을 멈추는 순간이 온다. Microservices Architecture(MSA)는 이 문제를 서비스 단위의 독립 배포로 해결한다. 각 서비스는 자체 데이터베이스와 런타임을 갖고, 다른 팀과 무관하게 릴리즈된다.
[ Monolith ] [ Microservices ]
+---------------------------+ +----------+ +----------+
| User / Order / Payment | | User | | Order |
| ---------------------- | | Service | | Service |
| Single DB | | + DB | | + DB |
+---------------------------+ +----------+ +----------+
| \ /
Deploy +----------+
(전체 재배포) | Payment |
| Service |
| + DB |
+----------+
| 항목 | Monolith | Microservices |
|---|---|---|
| 배포 단위 | 전체 애플리케이션 | 개별 서비스 |
| 장애 전파 | 전체 중단 가능 | 부분 격리 |
| 기술 스택 | 단일 스택 | 서비스별 선택 가능 |
| 초기 복잡도 | 낮음 | 높음 |
| 팀 독립성 | 낮음 | 높음 |
서비스를 어떻게 나누느냐가 MSA의 성패를 결정한다. Domain-Driven Design(DDD)의 Bounded Context가 기준이 된다. 같은 언어(Ubiquitous Language)를 공유하는 도메인 개념을 하나의 서비스로 묶는다.
Bounded Context: 동일한 도메인 모델이 일관된 의미를 유지하는 경계. User 서비스의 "고객"과 Payment 서비스의 "고객"은 다른 속성을 가질 수 있다.
잘못된 경계는 서비스 간 과도한 동기 호출을 낳는다. 단일 요청에 5개 서비스를 순차 호출해야 한다면, 그 서비스들은 하나의 Bounded Context에 속할 가능성이 높다.
클라이언트가 각 서비스의 주소를 직접 알 필요가 없도록 API Gateway가 단일 진입점 역할을 한다.
Client
|
v
+-------------+
| API Gateway | -- 인증 / Rate Limiting / 라우팅
+-------------+
| | |
v v v
User Order Payment
Gateway는 인증(Authentication), 요청 라우팅, 응답 집계(Aggregation)를 담당한다. BFF(Backend for Frontend) 패턴에서는 클라이언트 유형(모바일/웹)별로 Gateway를 분리하기도 한다.
서비스 인스턴스는 오토스케일링으로 IP가 수시로 바뀐다. Service Discovery는 서비스의 현재 위치를 동적으로 찾는 메커니즘이다.
[ Client-Side Discovery ] [ Server-Side Discovery ]
Service A Service A
| |
+-> Registry (Consul/Eureka) +-> Load Balancer
| |
v (IP 목록 반환) +-> Registry
Service B (직접 호출) Service B (LB가 라우팅)
Service Registry: 실행 중인 서비스 인스턴스의 주소 목록을 관리하는 저장소. 각 인스턴스가 시작 시 등록하고 종료 시 제거된다.
동기 통신은 REST 또는 gRPC를 사용한다. 응답이 즉시 필요한 조회 요청에 적합하다.
비동기 통신은 Message Broker(Kafka, RabbitMQ)를 통한 이벤트 기반으로 동작한다. 서비스 간 결합도를 낮추고 장애 전파를 차단한다.
# Order 서비스가 발행하는 이벤트 예시
event:
type: order.created
payload:
orderId: "abc-123"
userId: "user-456"
amount: 15000
Payment 서비스는 이 이벤트를 구독해 독립적으로 처리한다. Order 서비스는 Payment의 처리 결과를 기다리지 않는다.
MSA는 팀 자율성과 독립 배포가 필요한 시점에 도입 효과가 크다. 반면 분산 시스템 특유의 네트워크 지연, 트랜잭션 일관성(Saga 패턴 필요), 운영 복잡도(서비스 수만큼 늘어나는 모니터링 대상)는 반드시 감수해야 할 비용이다. 서비스가 3개 미만이거나 팀이 소규모라면 Monolith가 더 나은 선택일 수 있다.