Microservices와 분산 시스템 경계

Overview

Microservices Architecture는 서비스를 작게 만드는 규칙이 아니다. 같은 이유로 함께 변경되는 비즈니스 Capability를 경계로 나누어 독립 변경과 배포를 얻는 선택이다. 그 대가로 Process 내부 호출이 네트워크 호출이 되고, 하나였던 Transaction과 운영 화면이 분산된다.

서비스 경계

코드 줄 수나 Table 수보다 Bounded Context와 Team의 변경 단위를 본다. 변경 하나마다 여러 서비스를 동시에 배포해야 한다면 물리적으로만 나뉜 Distributed Monolith일 수 있다.

Database per Service

각 서비스가 자기 데이터의 소유권을 갖고 다른 서비스가 Table을 직접 조회하지 않게 한다. 반드시 DB Server 한 대씩을 뜻하지는 않는다. 다른 경계의 데이터는 API, Event, 복제된 Read Model로 받는다.

분산 업무 흐름

sequenceDiagram; participant O as Order; participant P as Payment; participant S as Stock; O->>P: 결제 요청; P-->>O: 결제 완료 이벤트; O->>S: 재고 차감; alt 재고 실패; O->>P: 결제 취소(보상); end

Saga의 보상은 DB Rollback이 아니다. 이미 일어난 결제를 지우는 대신 결제 취소라는 새로운 업무를 실행한다. Orchestration은 Coordinator가 순서와 보상을 지시해 추적하기 쉽지만 중앙 의존성이 생긴다. Choreography는 Event로 느슨하게 연결하지만 흐름이 퍼지면 이해와 장애 추적이 어려워진다.

Eventual Consistency와 멱등성

모든 복제 데이터가 즉시 같지 않을 수 있으므로 비즈니스가 허용할 지연과 사용자 경험을 정의한다. Timeout 뒤에는 요청이 실패했는지, 성공하고 응답만 사라졌는지 알기 어렵다. Retry와 중복 전달을 전제로 같은 메시지를 다시 처리해도 결과가 망가지지 않도록 멱등 Key와 처리 기록을 둔다.

DB 변경과 Event 발행의 Dual Write는 Transactional Outbox로 단일 Local Transaction에 모으고, Consumer 쪽은 멱등성·중복·순서에서 Inbox와 Sequence로 보호한다.

실무에서 발생하는 문제

• Timeout, Retry, Circuit Breaker의 잘못된 조합으로 장애가 증폭된다.
• Event Schema 변경이 이전 Consumer와 호환되지 않는다.
• 동기 호출 사슬이 길어져 부분 장애가 전체 요청으로 전파된다.
• Service별 Log만 있고 Trace ID가 없어 한 요청을 재구성하지 못한다.

Trade-off

독립 배포, 확장, Team 자율성이 실제 필요할 때 가치가 있다. 작은 Team이나 강한 Transaction 일관성이 중요한 시스템은 Modular Monolith가 더 단순하고 안전할 수 있다.

Interview Questions

1. Database per Service가 물리 DB 분리와 같은 말이 아닌 이유는?
2. Saga의 보상과 DB Rollback은 어떻게 다른가?
3. Orchestration과 Choreography는 어떤 실패 모드를 갖는가?
4. Retry가 멱등성을 요구하는 이유는?
5. Modular Monolith가 더 적합한 신호는 무엇인가?

Related Topics

Transactional Outbox, 멱등성·중복·순서, Kafka를 함께 확인한다.