메시지큐

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

---

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를 통해 전달하는 건 필요없는 오버헤드가 될 수도 있다.