[Tech] 메시지 큐 - Kafka, RabbitMQ

gyehwan·2023년 7월 16일

이번 포스팅에서는 메시지 큐의 개념과 이점에 대해 소개하고,
Kafka와 RabbitMQ의 개념과 동작 방식, 차이점에 대해 설명하겠다.

⭐️ 메시지 큐

메시지 큐(Message Queue)는 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중 하나로, 메시지 지향 미들웨어(Message Oriented Middleware:MOM)를 구현한 시스템을 의미한다.

메시지 지향 미들웨어란 비동기 메시지를 사용하는 응용 프로그램들 사이에서 데이터를 송수신하는 것을 의미한다. 여기서 메시지란 요청, 응답, 오류 메시지 혹은 단순한 정보 등의 작은 데이터가 될 수 있다.

메시지 큐는 말 그대로 메시지를 임시로 저장하는 큐라고 생각하면 된다. 메시지를 전송 및 수신하기 위해 중간에 메시지 큐를 두는 것이다.

메시지 전송 시 생산자가 메시지를 메시지 큐에 추가한다. 해당 메시지는 소비자가 메시지를 검색하고 이를 사용해 어떤 작업을 수행할 때 까지 메시지 큐에 저장된다. 각 메시지는 하나의 소비자에 의해 한 번만 처리될 수 있어서 메시지 큐 방식을 일대일 통신이라고 한다.

메시지 흐름 순서
1. 메시지 전송
2. 생산자(producer)는 해당 메시지를 queue에 추가
3. 해당 메시지는 소비자(consumer)가 메시지를 검색하고 이를 사용하기 위한 작업 전까지 임시 저장
4. 소비자(consumer)에 의해 호출
5. 해당 메시지는 queue에서 삭제

메시지 큐를 사용하는 경우

일반적인 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 그에 대한 처리를 한 후 클라이언트에게 응답을 한다. 간단한 서버 구조에서는 굳이 메시지 큐를 사용할 필요가 없다. 사용자가 응답을 기다려야 하는 HTTP 요청을 바로 처리하지 않고 중간에 메시지 큐를 두는 경우는 썩 바람직하지 않아 보인다. 그럼 왜 메시지 큐를 사용하며, 어떤 경우에 도입하는 걸까?

메시지 큐는 소비자(consumer)가 실제로 메시지를 어느 시점에 가져가서 처리하는지 보장하지 않는다. 언젠가는 큐에 넣어든 메시지가 소비되어 처리될 것이라고 믿는 것이다. 이러한 비동기적 특성 때문에 메시지 큐는 실패하면 치명적인 핵심 작업보다는 어플리케이션의 부가적인 기능에 사용하는 것이 적합하다.

예를 들어, 이메일 전송(비밀번호 재설정, 회원가입 등을 위한)에 메시지 큐를 사용할 수 있다.

⭐️ 메시지 큐의 이점

비동기 (Asynchronous)

메시지 큐는 생산된 메시지의 저장, 전송에 대해 동기화 처리를 진행하지 않고 큐에 넣어 두기 때문에 나중에 처리할 수 있다. 기존 동기(Synchronous) 방식은 많은 메시지(데이터)가 전송될 경우 병목이 생길 수 있고, 뒤에 들어오는 요청에 대한 응답이 지연될 것이다.

낮은 결합도 (Decoupling)

생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아진다. 결합도가 높은 경우, 즉 하나의 서비스에 여러 서비스가 달려있는 경우 점점 복잡해지고 테스트하기도 어려워지는데 메시지 큐를 사이에 집어넣으면 서비스는 메시지 큐만 알면 되어 서비스들 간에 의존도가 낮아진다.

확장성 (Scalable)

생산자 서비스 혹은 소비자 서비스를 원하는 대로 확장할 수 있기 때문에 확장성이 좋다.

탄력성 (Resilience)

소비자 서비스가 다운되더라도 어플리케이션이 중단되는 것은 아니다. 메시지는 메시지 큐에 남아있다. 소비자 서비스가 다시 시작될 때마다 추가 설정이나 작업을 수행하지 않고도 메시지 처리를 시작할 수 있다.

보장성 (Guarantees)

메시지 큐는 큐에 보관되는 모든 메시지가 소비자 서비스에게 전달된다는 보장을 제공한다.

⭐️ Kafka

Kafka는 메시지 큐 방식 기반 분산 이벤트 스트리밍 플랫폼이다.

Kafka의 기본 구조는 위 그림과 같다. 크게 Producer, Consumer, Kafka Cluster
로 구성된다.

Kafka 용어 정리

토픽(Topic): 메시지를 구분하는 단위 (파일시스템의 폴더와 유사)
파티션(Partition): 메시지를 저장하는 물리적인 파일
한개의 토픽은 한 개 이상의 파티션으로 구성된다.

하나의 Topic을 여러개의 Partition으로 분산하는 이유

병렬로 처리하기 위해 분산 저장한다.

Kafka 동작 방식

생산자는 전달하고자 하는 메시지를 topic을 통해 카테고리화 한다.
소비자는 원하는 topic을 구독함으로써 메시지를 읽어온다.
생산자와 소비자는 topic 정보만 알 뿐, 서로에 대해 알지 못한다.

Kafka 특징

메시지를 파일 시스템에 저장함으로써 영속성 보장
소비자가 broker로부터 직접 메시지를 가지고 가는 pull 방식으로 동작
생산자 중심적이 형태로 많은 양의 데이터를 파티셔닝하는데 초점을 맞춘 시스템
소비자가 전달 상태를 기억한다.
방대한 양의 데이터를 처리할 때 사용

⭐️ RabbitMQ

RabbitMQ는 AMQP 프로토콜을 구현한 메시지 브로커이다.
AMQP란 Client와 Middleware broker간의 메시지를 주고받기 위한 프로토콜이다.

RabbitMQ의 동작 원리를 간단히 그림으로 보면 아래와 같다.

Kafka와 다른 점이 하나 있다.
바로 메시지가 queue로 들어가기 전, exchange라는 하나의 단계를 더 거친다는 점이다.
exchange는 생산자가 전달한 메시지를 queue에 전달하는 역할을 수행한다.

RabbitMQ의 특징

Broker 중심적인 형태로 생산자와 소비자간의 보장되는 메시지 전달에 초점
클러스터 구성이 쉽고 Manage UI가 제공되며 플러그인도 제공되어 확장성이 뛰어남
데이터 처리보단, 관리적 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 사용

⭐️ Kafka vs RabbitMQ

Kafka와 RabbitMQ의 차이점에 대해 정리해보겠다.

1️⃣ 방식의 차이

kafka의 pub/sub방식은 생산자 중심적인 설계로 구성되어있다. 생산자가 원하는 각 메시지를 게시할 수 있도록 하는 메시지 배포 패턴으로 진행된다.
RabbitMQ의 메시지 브로커 방식은 브로커 중심적인 설계로 구성되어있다. 지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메시지 전달에 초점을 맞춘다.

2️⃣ 전달된 메시지에 대한 휘발성

Kafka는 생산자로부터 메시지가 들어오면 해당 메시지를 topic으로 분류하고 이를 event streamer에 저장한다. 그 후, 소비자가 해당 메시지를 가져가더라도 event streamer는 해당 topic을 유지하기 때문에 특정 상황이 발생하더라도 재생이 가능하다.
RabbitMQ는 queue에 저장되어 있던 메시지를 소비자가 가져가게 되면 queue에서 해당 메시지를 삭제한다.

3️⃣ 용도의 차이

Kafka는 클러스터를 통해 병렬처리가 가능한 만큼 방대한 양의 데이터를 처리할 때 장점이 부각된다.
RabbitMQ는 데이터 처리보단 관리적인 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 장점이 부각된다.

마무리

이번 포스팅에서는 메시지 큐(Message Queue)의 개념과 동작 원리, 이점에 대해 알아보고 대표적인 솔루션인 Kafka와 RabbitMQ에 대해 알아보았다. 이 포스팅을 작성하니 메시지 큐에 대해 조금은 감이 잡힌 것 같다. 추후에 직접 코드로 구현해보면서 이해도를 더욱 높여야겠다.