[개발자를 위한 레디스] 메시지 브로커로 사용

• 근래 서비스 아키텍처의 경우 여러 모듈이 서로 느슨하고 적절하게 연결된 구조를 선호함
• 여럿 장점이 있겠지만, 모듈 간의 효율적인 메시징 솔루션 → 메시지 브로커가 필수적임

메시지 브로커의 필요성

• 비동기 통신이 권장되는 상황
  • 서비스 간 커넥션의 실패 상황을 대비해 비동기 통신을 사용해야하는 경우!
• 메시지 저장 및 처리
  • 당장 메시지를 처리하지 못하더라도 메시지를 어딘가 쌓아두고, 나중에 처리할 수 있는 채널을 제공하는 것이 메시지 브로커의 핵심 역할

메시지 브로커의 2 가지 형태

• 크게 메시징 큐 와 이벤트 스트림 이라는 2 가지의 형태로 나뉜다.

메시징 큐

• 구조
  • 데이터를 생성하는 쪽을 생산자 (Producer)
  • 데이터를 수신하는 쪽을 소비자 (Consumer)
• 동작 방식
  • 생산자는 소비자의 큐로 데이터를 직접 푸시한다.
• 데이터 영속성
  • 소비자가 데이터를 읽어갈 때 큐에서 데이터를 삭제함.

이벤트 스트림

• 구조
  • 데이터를 생성하는 쪽 발행자(Publisher)
  • 데이터를 조회하는 쪽 구독자(Subscriber)
• 동작 방식
  • 발행자는 스트림의 특정 저장소에 하나의 메시지를 보냄
  • 구독자들은 스트림에서 같은 메시지를 풀링하여 가져간다.
• 데이터 영속성
  • 구독자가 읽어간 데이터를 바로 삭제되지않고, 저장소 설정에 따라 특정 기간 동안 저장될 수 있음.

메시징 큐와 이벤트 스트림의 차이점

1. 방향성
   • 메시징 큐
     • 생산자 → 소비자 큐로 데이터 직접 푸시
     • 여러 서비스에 같은 메시지를 보내려면 각각 다른 큐에 데이터를 각각 해줘야함
   • 이벤트 스트림
     • 생산자는 스트림의 특정 저장소에 하나의 메시지를 보냄.
     • 여러 소비자가 같은 메시지를 풀링하여 가져갈 수 있음.
2. 데이터의 영속성
   • 메시징 큐
     • 소비자가 데이터를 읽어갈 때 큐에서 데이터를 삭제함
   • 이벤트 스트림
     • 구독자가 읽어간 데이터는 바로 삭제되지 않고, 특정 기간 동안 저장될 수 있음.

새로운 소비자 추가 시의 동작

• 메시징 큐
  • 새로운 소비자는 추가된 이후의 이벤트만 확인가능
• 이벤트 스트림
  • 새로 추가된 서비스도 스트림에 남아 있는 이전 데이터의 히스토리를 조회 가능

뭐 언제 쓰는데

• MQ
  • 1 : 1 상황에서 한 서비스가 다른 서비스에게 동작 지시시
• 이벤트 스트림
  • 다 대 다 상황에서 유리함.