[MSA] 서비스 간 통신 방법

남순식·2026년 4월 13일

서비스 간 통신 방법

마이크로서비스 아키텍처(MSA)에서는 시스템이 기능별로 분리된 독립적인 서비스(주문, 유저, 배송 등)들로 구성된다. 각 서비스는 자체 데이터베이스를 가지며 서로 격리되어 있어 서비스 간 유기적인 동작을 위한 통신 설계가 필수

1. 통신 방식의 분류

1.1 동기 통신 (Synchronous Communication)

요청을 보낸 서비스가 응답이 올 때까지 대기하는 방식이다.

기술: HTTP/REST, gRPC
특징: 설계와 구현이 직관적이지만, 호출된 서비스에 장애가 발생할 경우 호출한 서비스까지 영향을 받는 장애 전파(Cascading Failure)가 발생할 수 있다.

1.2 비동기 통신 (Asynchronous Communication)

요청을 보낸 후 응답을 기다리지 않고 다음 로직을 수행하는 방식이다.

기술: Message Broker (Kafka, RabbitMQ)를 활용한 메시지 큐
특징: 서비스 간 결합도가 낮아져 시스템 확장성에 유리하다. 다만, 데이터의 최종 일관성(Eventual Consistency)을 보장하기 위한 추가 설계가 필요하다.

2. 주요 구성 요소 및 통신 적용

A. 서비스 디스커버리 (Eureka)

동적으로 변하는 서비스 인스턴스의 위치(IP, Port)를 관리하는 핵심 컴포넌트이다.

유레카 서버: 모든 서비스의 위치 정보를 저장하는 레지스트리 역할을 수행한다.
유레카 클라이언트: 주문, 유저, 배송 등 각 서비스가 이에 해당하며, 가동 시 서버에 자신의 정보를 등록한다.
적용: 서비스 간 통신 시 고정된 IP 대신 서비스 이름을 사용하여 호출할 수 있게 한다.

B. REST 기반 동기 통신 (FeignClient)

Spring Cloud 환경에서 서비스 간 HTTP 호출을 추상화한 라이브러리이다.

사용 예시: * 주문 서비스 → 유저 서비스: 주문 생성 전 유저의 유효성 및 권한 확인.
- 배송 서비스 → 허브 서비스: 배송 경로 계산을 위해 허브 위치 및 경로 정보 조회.
주의: 해당 서비스의 고정 url로 요청을 보내는 것이 아닌 gateway를 통해 요청을 보내도록 해야함

C. API Gateway를 통한 라우팅

클라이언트의 모든 요청은 Gateway를 통해 적절한 서비스로 전달된다.

역할: 인증/인가 처리, 서비스별 라우팅, 로드 밸런싱.
흐름: 클라이언트 요청 → Gateway → Eureka에서 서비스 위치 조회 → 해당 서비스(주문, 상품 등) 전달.

D. 메시지 브로커를 활용한 비동기 통신

특정 서비스의 상태 변화를 다른 서비스에 전파할 때 사용한다.

사용 예시:
- 주문 서비스 → 상품 서비스: 주문 완료 후 재고 차감을 위한 이벤트 발행.
- 주문 서비스 → 배송 서비스: 주문 생성 후 배송 담당자 배정 및 배송 시작 요청.
장점: 특정 서비스에 부하가 몰리거나 장애가 발생해도 메시지 큐에 요청을 쌓아둘 수 있어 시스템 전체의 안정성이 향상된다.

3. 서비스 간 통신 구조 요약 (Feign vs Event)

서비스의 목적과 데이터 일관성 요구 수준에 따라 통신 방식을 분리하여 적용한다.

3.1 FeignClient 적용 영역 (동기 통신)

즉각적인 응답이 필요하거나, 조회 결과가 이후 로직 진행에 필수적인 경우에 사용한다.

주문 서비스 → 유저 서비스: 주문 생성 시 해당 유저가 유효한지, 주문 권한이 있는지 실시간 확인이 필요할 때 사용한다.
배송 서비스 → 허브 서비스: 배송 경로를 생성하기 위해 특정 허브의 위치 정보나 허브 간 최단 경로 데이터를 실시간으로 참조해야 할 때 사용한다.

3.2 Event 적용 영역 (비동기 통신)

서비스 간의 결합도를 낮추고, 특정 작업의 완료가 다른 서비스의 후행 작업을 트리거할 때 사용한다.

주문 서비스 → 상품 서비스: 주문이 성공적으로 생성된 후, 상품의 재고를 차감하는 프로세스에 적용한다. 주문 서비스는 이벤트를 발행하고 자신의 로직을 마친다.
주문 서비스 → 배송 서비스: 주문이 성공적으로 생성된 후, 배송정보를 생성하고 배송담당자 배정 프로세스를 시작한다. 주문 서비스는 이벤트를 발행하고 자신의 로직을 마친다.

3.3 요약 비교표

구분	FeignClient (Synchronous)	Event-Driven (Asynchronous)
주요 목적	실시간 데이터 조회 및 검증	상태 변경 전파 및 후속 로직 실행
결합도	높음	낮음
데이터 특성	즉각적인 데이터 정합성 필요	최종적인 데이터 일관성 필요

4. 결론

MSA 환경에서는 서비스 간의 강한 결합을 피하는 것이 중요하다. 단순한 데이터 조회에는 FeignClient를 통한 동기 방식을 적용하고, 서비스 간의 비즈니스 로직 연결이나 데이터 변경이 수반되는 작업에는 메시지 브로커를 통한 비동기 방식을 혼합하여 시스템의 가용성과 확장성을 동시에 확보해야 한다.