동기식 통신 방식은 사용자로부터 요청을 받아서 요청을 다 처리할때까지 서버가 다른 행동을 취하지 못하지만, 메세지큐를 사용해 외부에 요청을 맡긴다면 서버가 보다 많은 사람들의 요청을 빠르게 처리할 수 있다.

MQ 사용 구조

클라이언트는 서버에 직접 요청하는 것이 아닌 MQ에 전달한다.
그럼 서버는 MQ로 부터 요청 데이터를 수신해서 처리한다.
만약 서버가 요청을 받을 수 없을 수 없는 상황이라면 해당 요청은 서버가 받을 때까지 MQ에 머무르게 된다.
이런 상황에서 MQ에 다운타임이 발생하면 무용지물이 되어버리기 때문에 많은 MQ가 고가용성을 위해 클러스터링 등을 지원한다.

Pub/Sub 모델

Pub/Sub 모델은 Publish/Subscribe의 줄임말로 메세지 기반의 미들웨어 시스템을 말한다.
일반적으로 메시지를 전송할 때는 Publisher(sender)가 Subscriber(receiver)에게 직접 메시지를 전송하는데, Pub/Sub 모델에서 Publisher는 어떤 Subscriber가 있는지 모르는 상태에서 메시지를 전송하고 Subscriber는 Publisher에 대한 정보 없이 자신의 Interest에 맞는 메시지만을 전송받는다.
대표적인 Pub/Sub 서비스로는 Kafka와 Redis가 있다. 하지만 구체적인 발행/구독 방식은 조금씩 다르다.

Kafka

Kafka에서의 Producer/Consumer는, 각각 Publisher/Consumer와 기능이 동일하다.
Producer는 Topic에 이벤트를 보내고, 이 이벤트는 Topic의 각 partition에 분산되어 '저장'된다.
Topic을 구독하고 있는 Consumer group 내의 Consumer는 각각 1개 이상의 partition으로부터 이벤트를 가져온다.

Kafka의 주요 특징

높은 확장성

kafka의 Producer와 Consumer는 완전 별개로 동작한다.
Producer는 Broker의 Topic에 메시지를 게시하기만 하면 되고, Consumer는 그걸 가져와서 처리하기만 하면 된다.
Producer와 Consumer가 직접적으로 연관을 가지고 있지 않기 때문에, 확장 또는 축소시에 번거롭게 연결·해제할 필요가 없다.

Pull모델

Kafka의 Consumer는 Pull모델을 기반으로 메시지 처리를 진행한다.
즉, Broker가 Consumer에게 메시지를 전달하는 것이 아닌, Consumer가 필요할때, Broker로 부터 메시지를 가져와 처리하는 형태이다.
이러한 형태는 다양한 소비자의 처리 형태와 속도를 고려하지 않아도 된다는 장점이 있다.
Push 모델에서는 Broker가 데이터 전송 속도를 제어하기 때문에 다양한 메시지 스트림의 소비자를 다루기 어렵지만, Pull 모델은 Consumer가 처리 가능할때 알아서 가져와 처리하는 것이기 때문에 다양한 소비자를 다루기 쉽다.

Redis

Redis에는 그룹이라는 개념이 존재하지 않고, 각 subscriber가 channel을 구독하고 있는 구조이다.
이때 중요한 점은, Channel이 이벤트를 저장하지 않는다는 것이다.
만일 Channel에 이벤트가 도착했을 때, 해당 채널의 Subscriber가 존재하지 않는다면, 이벤트는 사라진다.

MQ를 사용하는 경우

MQ를 사용하면 좋은 경우
- 처리할 데이터가 많을 때 부하분산을 위해 MQ를 사용할 수 있다.
  - 여러 대의 서버가 하나의 큐를 바라보도록 구성하면 각 서버는 자신의 처리량에 맞게 태스크를 가져와 처리할 수 있다.
  - 이러한 구조는 horizontal scaling에 유리하다.
MQ가 어울리지 않는 경우
- 요청 결과를 즉시 응답해야할 때는 MQ가 적절하지 않다.
  - MQ는 요청과 별개로 처리할 수 있는 비동기 처리에 어울린다.
  - 서버에서 간단하게 처리할 수 있는 일을 MQ를 통해 전달하는 건 필요없는 오버헤드가 될 수도 있다.