서비스를 쪼갰더니, 이번엔 "네트워크"가 적이 됐다

모놀리스는 하나의 배포 단위에 모든 기능이 들어 있어요. MSA는 비즈니스 능력별로 독립 배포·독립 확장되는 작은 서비스들로 나눕니다. 각각 얻는 것과 잃는 것이 뚜렷해요.

서비스를 UI 서비스·비즈니스 서비스·DB 서비스처럼 기술 계층으로 나누는 건 흔한 함정이에요. 하나의 기능 변경이 세 서비스를 모두 건드려 결국 강결합이 됩니다. 좋은 경계는 비즈니스 능력(도메인)을 따라야 해요 — 이게 DDD의 바운디드 컨텍스트입니다.

MSA에서 가장 무서운 건 연쇄 장애(cascading failure)예요. 하위 서비스 하나가 느려지면, 그걸 기다리는 상위 서비스의 스레드가 전부 묶이고, 그 상위를 기다리는 서비스도 묶이면서 시스템 전체가 도미노로 무너져요. 이걸 막는 패턴들이에요.

// Resilience4j — 서킷 브레이커 + 재시도 + 폴백 조합
@Retry(name = "payment")            // 지수 백오프 + 지터로 재시도
@CircuitBreaker(name = "payment", fallbackMethod = "fallback")
public PaymentResult pay(Order order) {
    return paymentClient.charge(order); // 원격 호출(타임아웃 설정 필수)
}

// 회로가 Open이거나 재시도 소진 시 호출 — degraded 응답
public PaymentResult fallback(Order order, Throwable t) {
    return PaymentResult.pending("결제 지연 — 잠시 후 재시도됩니다");
}

서비스마다 DB가 따로 있으니, "주문 생성 + 결제 + 재고 차감"을 하나의 트랜잭션으로 묶고 싶어져요. 하지만 여러 DB에 걸친 ACID 트랜잭션은 MSA에서 사실상 불가능하거나 위험합니다.

사가(Saga)는 하나의 큰 분산 트랜잭션을 각 서비스의 로컬 트랜잭션들의 연속으로 쪼개요. 각 단계는 자기 DB에 대해선 정상 커밋합니다. 중간에 실패하면 롤백 대신 이미 성공한 단계들을 되돌리는 보상 트랜잭션(compensating transaction)을 역순으로 실행해요.

모놀리스에선 스택 트레이스 하나로 흐름이 보였지만, 하나의 요청이 5개 서비스를 거치면 로그가 5곳에 흩어져요. "이 느린 요청이 어디서 막혔나?"를 답하려면 요청 단위로 로그를 꿰는 장치가 필요합니다.