웹개발/Web

Kafka vs RabbitMq

slown 2025. 3. 24. 21:15

목차

1.메시지 큐

2.Kafka의 작동원리

3.RabbitMq의 작동원리

4.Kafka vs RabbitMq

 

1.메시지 큐

일단은 Kafka와 RabbitMq를 알기 위해서는 메시지큐의 개념을 알아야 합니다. 우선은 아래의 사진을 보면 메시지 큐에 대한 개념을 알 수 있습니다.

 

메시지 큐의 구조

 

위 사진의 용어를 보면 다음과 같습니다.

 

Producer : 정보를 제공하는 자

Queue: FIFO의 개념으로 Producer에서 보낸 메시지를 처리를 하는 방식으로 처리합니다.

Consumer: 정보를 받는 자.

 

그래서 메시지큐의 작동순서를 다시 정리를 하자면 다음과 같습니다.

 

1.메시지를 보낸다.

2. 보낸 메시지는 Producer가 받아서 Queue에 보낸다.

3.해당 메시지는 consumer가 사용하기 전까지 Queue에서 저장한다.

4.Consumer에 의해서 메시지 호출

5.호출된 메시지는 Queue에서 삭제

 

이렇게 된다.  그럼 위의 메시지 큐는 언제 필요한가는 몇가지로 볼 수 있다.

 

1. 비동기 처리

 

알림, 이메일 전송, 썸네일 생성 등은 사용자에게 즉시 응답할 필요가 없음

메시지 큐에 요청만 던지고 빠르게 응답 → 나중에 따로 처리

 

비동기화하면 서버 처리 시간 감소 + 응답 지연 방지 + 사용자 이탈 감소

 

2. 생산자와 소비자간의 차이 해소

 

생산자(요청 들어오는 속도) > 소비자(처리 속도) → 병목 발생

메시지 큐가 중간에 완충역할을 함.

 

3.시스템간의 결합도를 낮춘다.

 

서비스 간 직접 호출 대신 큐를 사이에 두면, 서로의 존재나 상태를 몰라도 동작 가능.

 

4. 트래픽 대응 및 확장성 향상

 

갑자기 트래픽이 몰릴 경우, 직접 처리 구조에서는 서버 과부하 또는 장애 발생 큐 구조에서는 일단 메시지를 쌓아두고, Consumer 수만 늘려서 처리량 확장 가능

 

2.Kafka의 작동원리

카프카의 작동원리.

 

카프카의 작동원리는 기본적으로 위의 사진과 같이 작동을 합니다. 그리고 위 사진에서 움직이는 것을 설명을 하기 전에 카프카에서 사용이 되는 용어에 대해 설명을 하면 다음과 같습니다.

 

  • 프로듀서(Producer): 데이터를 생성하여 카프카에 전송하는 역할을 합니다. 예를 들어, 사용자의 행동 로그를 수집하는 애플리케이션이 이에 해당합니다.​
  • 카프카 브로커(Kafka Broker): 프로듀서로부터 받은 데이터를 저장하고, 컨슈머에게 전달하는 중개자 역할을 수행합니다. 여러 대의 브로커가 모여 카프카 클러스터를 형성하고, 각 브로커는 특정 토픽의 파티션을 관리합니다.
  • 토픽(Topic): 데이터를 분류하는 단위를 토픽이라고 합니다. 각 토픽은 하나 이상의 파티션(Partition)으로 구성되며, 파티션은 데이터를 분산 저장하고 병렬 처리를 가능합니다.​
  • 컨슈머(Consumer): 카프카에서 데이터를 읽어와 처리하는 역할을 합니다. 컨슈머들은 컨슈머 그룹(Consumer Group)을 형성하여 병렬로 데이터를 처리할 수 있어.

그리고 카프카의 작동순서는 다음과 같습니다.

 

  • 프로듀서가 메시지 전송: 프로듀서는 특정 토픽의 파티션에 데이터를 전송합니다. 이때 키를 지정하면 해당 키에 따라 특정 파티션에 데이터가 할당됩니다.​
  • 브로커가 메시지 저장: 브로커는 받은 메시지를 해당 토픽의 파티션에 저장합니다. 각 파티션은 로그 구조로 되어 있어, 메시지는 순차적으로 저장되고 각 메시지는 고유한 오프셋(offset)을 가집니다.​
  • 컨슈머가 메시지 소비: 컨슈머는 자신이 구독한 토픽의 파티션에서 메시지를 읽어와 처리합니다. 컨슈머 그룹 내의 각 컨슈머는 파티션을 나누어 병렬로 데이터를 처리합니다.​
  • 오프셋 관리: 컨슈머는 자신이 어디까지 메시지를 읽었는지 오프셋을 커밋하여 추적합니다. 이를 통해 재시작 시에도 이전에 읽은 위치부터 이어서 데이터를 처리할 수 있습니다.​
  • 리플리케이션과 장애 복구: 각 파티션은 복제본(replica)을 가지고 있습니다. 하나의 브로커에 장애가 발생해도 다른 브로커가 리더로 승격되어 데이터의 가용성을 유지합니다.

 

3.RabbitMq의 작동원리

위의 사진은 RabbitMq의 전반적인 아키텍처입니다. RabbitMq를 설명하기 전에 RabbitMq에 사용되는 용어를 알아야하는데 그것은 다음과 같습니다.

  • 프로듀서: 데이터(메시지)를 생성해서 Exchange로 전송하는 역할을 합니다. 예를 들어, 사용자가 알림이 필요한 행동(일정 등록, 결제 등)을 하면 그 정보를 메시지로 만들어 RabbitMQ로 보냅니다.
  • 익스체인지: 메시지를 받아서 어떤 큐(Queue)로 보낼지 라우팅 결정을 하는 중간 허브입니다. Exchange는 여러 가지 타입이 있고, 각 타입에 따라 메시지가 라우팅되는 방식이 다릅니다.
  • 바인딩: Exchange와 Queue를 연결하는 설정입니다. 어떤 라우팅 키를 가진 메시지를 어떤 큐로 보낼지를 정의합니다. Exchange와 Queue 사이의 규칙이라고 보면 됩니다.
  • 큐: 메시지를 저장하고 기다리는 공간입니다. FIFO(First-In First-Out) 구조로, 메시지는 먼저 온 순서대로 소비됩니다.
    여러 큐에 같은 메시지를 보낼 수도 있고, 각각 다른 용도의 큐를 만들 수 있습니다.
  • 컨슈머: 큐에 쌓인 메시지를 읽고 처리하는 역할을 합니다. (예: 이메일 발송기, 알림 처리기, 로그 저장기 등)
    메시지를 처리한 후에는 **ACK(확인)**을 보내야 RabbitMQ가 그 메시지를 삭제합니다.

다음은 RabbitMq의 작동순서는 다음과 같습니다.

 

  • 프로듀서가 메시지 전송: 일정 등록, 결제 등 이벤트 발생 시 메시지를 생성하여 RabbitMQ의 특정 Exchange에 전송합니다.
  • Exchange가 메시지를 받음: 메시지의 라우팅 키를 보고 어떤 큐로 보낼지 판단합니다. Exchange 타입(direct, topic, fanout 등)에 따라 라우팅 방식이 달라집니다.
  • Binding 조건에 따라 큐로 메시지 전달: Exchange는 등록된 바인딩 조건을 확인하여, 해당 키에 맞는 큐에 메시지를 전달합니다.
  • 큐에 메시지 저장: 조건에 맞는 큐에 메시지가 들어가고, 대기 상태가 됩니다.
  • 컨슈머가 큐에서 메시지를 읽음: 컨슈머는 메시지를 받아 처리한 뒤, 성공 여부를 ACK로 응답합니다. 실패 시 메시지를 재시도하거나 Dead Letter Queue로 이동시킬 수 있습니다.

 

4.Kafka vs RabbitMq

1. 기본 철학의 차이

  • Kafka는 분산 로그 저장 시스템에 가깝다. 메시지를 단순히 전달하는 것이 아니라, 디스크에 저장하고, 여러 Consumer가 독립적으로 읽을 수 있도록 설계되어 있다. 그래서 이벤트 스트리밍, 로그 수집, 데이터 파이프라인에 자주 사용된다.
  • RabbitMQ는 전통적인 메시지 브로커다. 메시지를 큐에 저장하고, 소비자가 처리하면 바로 삭제하는 구조이다.
    작업 큐, 알림 전송, 백엔드 작업 분배 등에 많이 쓰인다.

2. 메시지 라우팅 방식의 차이

  • Kafka는 Topic과 Partition 기반으로 메시지를 라우팅한다. Producer가 메시지를 특정 Topic에 전송하면, 키를 기반으로 Partition이 정해지고, 해당 Partition의 리더 브로커가 메시지를 저장한다.
  • RabbitMQ는 Exchange와 Binding을 통해 라우팅한다. 메시지는 Exchange로 먼저 전달되고, 정의된 조건(Binding Key 등)에 따라 적절한 Queue로 분배된다. 이 구조는 유연한 라우팅이 필요한 경우에 매우 유용하다.

 3. 메시지 저장과 소비 방식의 차이

  • Kafka는 메시지를 디스크에 저장하고, 지정된 보존 기간(Retention Period) 동안 삭제하지 않는다. 따라서 같은 메시지를 여러 번 읽거나, 나중에 다시 읽는 것도 가능하다. 각 Consumer는 자신의 Offset(현재까지 읽은 위치)을 관리하여 재시작 시 이어서 읽을 수 있다.
  • RabbitMQ는 메시지를 한 번 읽으면 기본적으로 큐에서 삭제된다. 처리 실패 시에는 다시 큐에 넣거나, Dead Letter Queue로 이동시켜야 한다. 순차 처리와 정확한 1회 처리(Exactly once)가 중요한 경우에 유리하다.

4. 처리량과 확장성

  • Kafka는 고성능과 확장성이 매우 뛰어나다. 수십만 건 이상의 메시지를 초당 처리할 수 있으며, 클러스터 구조로 쉽게 확장 가능하다.
  • RabbitMQ는 Kafka보다 상대적으로 처리량이 낮고, 단일 노드 혹은 클러스터 환경에서 적당한 규모의 처리에 적합하다. 대신 설정이 간단하고 운영이 쉬운 편이다.

5. 지연 큐, 재시도 등 실무 기능의 차이

  • Kafka는 기본적으로 지연 큐(Delay Queue)나 메시지 TTL 같은 기능이 없다. 직접 구현하거나 다른 시스템(Redis 등)과 연동해야 한다.
  • RabbitMQ는 Delay Queue, TTL(Time-To-Live), Dead Letter Queue(DLQ) 같은 기능을 내장하고 있어,예약 알림, 실패한 작업 처리 등에 매우 유리하다.