Message Queue

Request, Response vs Messaging

대부분 웹 서버는 HTTP Req/Res 방식을 많이 사용하는데, 대표적으로 REST API가 존재한다.

Req/Res 방식은 HTTP 프토콜을 기반으로 구현되기 때문에 Stateless 특성을 가지고있다.

하지만 클라이언트-서버 사이에 강한 “의존성”이 존재하며, 서버가 실행중이어야 데이터 송수신이 가능하다.

또, 클라이언트는 서버에서 응답이 올 때까지 대기 하고있다. 즉, 동기식 통신 방법이다.

반대로 HTTP 방식보다 느슨하게 결합하여 비동기 시스템 통합 방식인 메시징이 있다.

• 메시징은 중간 시스템을 통해서 발신자(publisher)에서 수신자(subscriber) 로 데이터를 전송

그림처럼 중간에 메시징 시스템을 통해 전송을 하기 때문에 채널만 연결되어 있으면 서버는 데이터를 받는 수신자(클라이언트)가 누군지 알 필요가 없다.

이러한 메시징 시스템에는 대표적으로 Rabbit MQ, Active MQ, Kafka 등이 있다.

메시지 플랫폼은 메시지 브로커, 이벤트 브로커로 나눌 수 있다.

메시지 브로커

• 메시지를 받아서 처리하고 나면 즉시, 짧은 시간내에 삭제되는 구조이다. 즉, 메시지를 보내고 처리 후 삭제한다.

• redis, Rabbit MQ가 해당한다.

이벤트 브로커

• 이벤트, 메시지라고 부르는 레코드를 인덱스를 통해 개별 엑세스를 관리한다. (??)

• 업무상 필요한 시간동안 이벤트를 보존할 수 있다. 데이터를 처리하고 삭제하지 않는다.

• Kafka가 해당한다.

Message Queuing (메시지 큐잉) vs pub/sub

큐잉 시스템과 pub/sub 시스템은 분산 시스템에서 메시지를 전달하는 두 가지 주요 패턴이다.

“메시징” 시스템을 구현하는 방법은 대표적으로 두 가지가 존재한다.

1. 메시지 큐잉 (Point-to-Point Channel)

메시지 큐잉은 Point-to-Point Channel 방식으로, 한 수신자(Consumer)만 메시지를 수신할 수 있다.

서버에서 큐에 메시지를 전달하면 클라이언트는 큐에서 하나씩 꺼내서 수신한다.

즉, 1:1 통신으로 이루어진다.

• 소비자가 처리를 완료하고 명시적으로 삭제할 때까지 큐에 남아있는다. 이는 메시지가 손실되지 않도록 보장한다.

1. Publish/Subscribe

큐잉과 반대로 pub/sub은 수신자(클라이언트) 모두에게 메시지를 전송한다.

publisher(발행자)가 특정 Topic에 메시지를 전달하면, 해당 Topic을 구독한 subscriber(클라이언트) 모두에게 메시지가 전송된다.

• 브로드캐스팅에 적합한 방식이다.