MSA 통신방식에 대해서 질문 있습니다.

8 câu hỏi đã được viết

0

안녕하세요, 인프런 AI 인턴입니다.

정인호님, 좋은 질문입니다.

MSA로 전환한다고 해서 처음부터 모든 통신을 EDA 방식으로 변경할 필요는 없습니다.

핵심은 “이 통신이 반드시 즉시 성공해야 하는가?”를 기준으로 동기식과 비동기식을 나누는 것입니다.

1. 동기식 통신이 적합한 경우
   

사용자의 요청에 대한 결과를 즉시 반환해야 하는 경우에는 REST API나 gRPC 같은 동기식 통신이 적합합니다.

예를 들어 다음과 같은 경우입니다.

• 상품 상세 정보 조회
  
• 로그인 및 인증
  
• 재고 확인
  
• 결제 승인 결과 확인
  
• 사용자가 즉시 결과를 확인해야 하는 명령
  

다만 동기식 호출은 말씀하신 것처럼 호출 대상 서비스의 장애가 호출자에게 전파될 수 있습니다.

따라서 다음과 같은 보호 장치를 함께 적용해야 합니다.

• 짧고 명확한 타임아웃
  
• 무한 재시도를 막는 재시도 정책
  
• 서킷 브레이커
  
• Bulkhead를 이용한 리소스 격리
  
• 상황에 따른 대체 응답 또는 장애 처리
  
• 호출 체인의 최소화
  

특히 타임아웃과 재시도 없이 동기 호출을 연결하면 장애가 발생했을 때 여러 서비스의 스레드와 커넥션 풀이 함께 고갈될 수 있습니다.

2. 비동기식 통신이 적합한 경우
   

호출 결과를 즉시 사용자에게 반환할 필요가 없거나, 여러 서비스에 변경 사실을 전파해야 하는 경우에는 이벤트 기반 통신이 적합합니다.

예를 들어 주문이 생성된 이후 다음 작업을 수행한다고 가정해 보겠습니다.

• 결제 처리
  
• 재고 차감
  
• 알림 발송
  
• 포인트 적립
  
• 배송 준비
  

주문 서비스가 각각의 서비스를 동기식으로 순서대로 호출하면 전체 처리 시간이 길어지고, 하나의 서비스 장애가 주문 처리 전체에 영향을 줄 수 있습니다.

이때 주문 생성 이벤트를 발행하고 각 서비스가 이를 독립적으로 처리하도록 구성할 수 있습니다.

주문 서비스
    └─ OrderCreated 이벤트 발행
          ├─ 결제 서비스
          ├─ 재고 서비스
          ├─ 알림 서비스
          └─ 포인트 서비스

이 구조에서는 일부 소비자 서비스가 일시적으로 장애가 나더라도 이벤트를 보관했다가 복구 후 재처리할 수 있습니다.

다만 EDA가 모든 장애를 해결해 주는 것은 아닙니다.

EDA를 도입하면 다음과 같은 새로운 문제가 생깁니다.

• 최종적 일관성
  
• 중복 이벤트 처리
  
• 이벤트 순서 보장
  
• 이벤트 유실 방지
  
• 재처리와 보상 트랜잭션
  
• 디버깅 및 모니터링의 어려움
  
• 이벤트 스키마 변경 문제
  

따라서 소비자는 동일한 이벤트를 여러 번 받아도 결과가 한 번만 반영되도록 멱등성을 보장해야 합니다.

3. 실무에서는 혼합 방식을 많이 사용합니다
   

실제로는 동기식 또는 비동기식 중 하나만 선택하기보다는 다음처럼 조합하는 경우가 많습니다.

주문 요청
  → 주문 서비스가 주문 생성
  → 사용자에게 "주문 접수" 응답
  → OrderCreated 이벤트 발행
  → 결제, 재고, 알림 서비스가 비동기로 처리

사용자에게는 주문 접수 결과만 빠르게 반환하고, 이후 처리는 이벤트 기반으로 진행하는 방식입니다.

반대로 결제 승인처럼 다음 단계 진행 여부가 즉시 결정되어야 하는 작업은 동기식으로 처리할 수 있습니다.

4. MSA 전환 시 권장하는 접근 순서
   

처음부터 모든 서비스를 이벤트 기반으로 만들기보다는 다음 순서로 접근하는 것을 권장합니다.

• 서비스 간 의존성과 호출 관계를 먼저 파악합니다.
  
• 사용자 응답에 반드시 필요한 호출과 나중에 처리해도 되는 작업을 구분합니다.
  
• 즉시 결과가 필요한 부분은 동기식으로 구현합니다.
  
• 알림, 통계, 포인트 적립처럼 지연 처리가 가능한 부분은 비동기로 분리합니다.
  
• 동기 호출에는 타임아웃, 재시도, 서킷 브레이커를 적용합니다.
  
• 이벤트 기반 처리에는 멱등성, 재처리, 모니터링을 설계합니다.
  
• 장애 상황에서 데이터 정합성을 어떻게 복구할지 정의합니다.
  

정리하면, 서비스 하나가 다운될 때의 장애 전파가 걱정된다고 해서 바로 EDA로 전환하는 것은 아닙니다.

“즉시 응답이 필요한가?”는 동기식으로 판단하고, “나중에 처리해도 되는가?” 또는 “여러 서비스에 변경 사실을 전달해야 하는가?”는 비동기 이벤트 방식으로 판단하는 것이 좋습니다.

결국 실무적인 MSA 통신 구조는 동기식 API와 비동기 이벤트를 업무 특성에 맞게 혼합하고, 각각의 장애 및 일관성 문제를 별도로 대비하는 형태에 가깝습니다.

참고로 Kafka는 변경 사항을 시간 순서의 이벤트 로그로 저장하고 이를 기반으로 애플리케이션을 구성하는 이벤트 소싱과 같은 이벤트 기반 설계를 지원할 수 있습니다.

참고 자료: https://kafka.apache.org/documentation/#uses_eventsourcing