RabbitMQ, Kafka

Today I Learn ✍🏼

이벤트 브로커, 메시지 브로커 두개 로 나뉜다

메시지 브로커

미들웨어 아키텍쳐에서 사용됨

미들웨어?

서비스하는 애플리케이션들을 연결하는 소프트웨어

ex) 메시징 플랫폼, 인증 플랫폼, 데이터베이스

메시지 브로커

데이터를 소비하면 데이터 삭제

ex) redis, rabbitmq

이벤트 브로커

데이터를 삭제하지 않음

인덱스로 개별 관리한다

이벤트를 보존함

ex) kafka, Aws 키네시스

이벤트

이벤트를 데이터처럼 저장한다

장애가 일어난 지점에서 재처리 가능함

많은 데이터를 효과적으로 병렬적으러 처리가능

이벤트 브로커 -> 이벤트 기반 micri service 아키텍쳐

RabbitMQ

고성능 메시지 브로커

메시지 전달, 라우팅에 초점

advanced message queue protocol

특징

1. 메시지 전달 보장

메시지 확인, 재전송 기능으로 메시지 손실 방지

2. 라우팅 기능

exchange와 queue를 통해 메시지 라우팅

direct, topic, fanout 다양한 라우팅 방식 지원

3. 사례

queue

- 비동기 작업 처리

즉각 메시지 전달이 중요한 시스템에 적합

- 사용자가 로그인하면 알림 이벤트 즉시 전송

메시지 라우팅

- 특정 조건에 따라 이벤트를 큐로 라우팅

4. 구조

프로듀서 -> exchange -> queue -> consumer

소비자가 메시지를 처리하면 큐에서 삭제됨

5. 내구성

메시지와 큐를 디스크에 저장

6. 성능

낮은 처리량을 요구하는 시스템에서 빠른 메시지 전달 가능

대규모 이벤트 스트리밍에는 적합하지 않음

kafka

분산 스트리밍 플랫폼

로그 저장, 이벤트 스트리밍에 초점

대규모 데이터 파이프라인 구축에 최적화

이벤트 저장소: 이벤트 데이터를 토픽에 기록

특징

1. 고성능 처리

분산 아키텍쳐로 초당 수백만개의 메시지 처리 가능

이벤트 스트리밍, 실시간 데이터 처리에 사용

2. 내구성, 확장성

데이터를 토픽에 저장, 로그 파일로 유지

데이터를 디스크에 저장하여 메시지 손실 최소화

클러스팅으로 확장성 보장

3. 구조

프로듀서 -> 토픽 -> 파티션 -> 컨슈머

컨슈머는 데이터를 offset 기반으로 읽음

메시지는 삭제 되지 않고, 여러 컨슈머 그룹에서 독립적으로 처리 가능

4. 스트리밍 데이터 처리

대규모 로그 데이터 저장, 분석

장기간 데이터 저장

이벤트 재처리 가능

5. 사례

로그 수집

- 사용자 행동 데이터를 수집, 실시간으로 추천 엔진 업데이트

데이터 파이프 라인

- 데이터베이스 변경 데이터를 데이터 웨어하우스로 스트리밍

- insert, update, delete를 실시간으로 감지하여 데이터웨어하우스로 전송하는 프로세스

데이터베이스는 transaction에 적합, 데이터 웨어하우스는 분석에 적합

장기 저장, 스트리밍 데이터 적합

- Iot 센서 데이터를 일정 기간 저장 후 재처리

tcp 사용

1. 신뢰성

tcp는 데이터가 손실 되지 않고, 순서대로 전달되도록 보장

kafka는 높은 데이터 신뢰성을 요구함

kafka에서 tcp 작동 방식

1. 클라이언트 연결

kafka 클라이언트(프로듀서, 컨슈머)가 kafka 브로커에 접속

브로커주소, 기본 포트 9092를 사용

tcp 소켓을 열어 연결

2. 요청/응답

클라이언트는 kafka 요청(메시지 전송, 데이터 읽기)를 tcp를 통해 브로커에게 보냄

브로커는 요청을 처리 한 뒤 tcp로 응답을 클라이언트에게 전송

3. 데이터 전송

kafka는 바이너리 protocol을 사용해 데이터를 직렬화 하여, tcp를 통해 전송

데이터 전송은 패킷 단위로 이루어짐

4. 클러스터 내 복제

리더 브로커가 메시지를 처리한 후 팔로워 브로커로 복제

tcp 연결을 통해 데이터 일관성 유지

프로듀서

메시지를 kafka 브로커에 전송

tcp를 사용해 브로커와 연결을 맺음, 데이터 전송

전공 성공 여부를 확인하기 위해 ack를 수산

컨슈머

kafka 브로커로부터 메시지를 가져옴

tcp 연결을 통해 data offset 정보를 교환, 데이터 순서 보장

브로커 간 통신

카프카는 분산 시스템으로, 여러 브로커가 클러스터를 이루어 동작

브로커 간 tcp를 통해 데이터를 동기화, 리더-팔로우 구조에서 리더 파티션 데이터를 팔로워에게 복제

연결 관리

tcp 연결은 지속적으로 유지되며, heartbeat를 통해 연결 상태 확인

연결이 끊어지면 tcp재연결 시도

토픽

이벤트를 저장하는 kafka의 논리적 저장소

이벤트는 토픽에 로그 형태로 저장

각 이벤트는 고유 offset을 가짐

브로커(Broker):

클러스터의 구성 요소로, 특정 토픽의 파티션을 저장하고 요청 처리

kafka 클러스터 내에서 이벤트 데이터를 관리하는 서버

데이터 분산, 데이터 처리, 데이터 저장

파티션(Partition):

토픽을 물리적으로 나누는 단위. 데이터는 각 파티션에 로그 형태로 저장

복제(Replication):

데이터의 안정성을 위해 각 파티션의 복사본이 여러 브로커에 저장

오프셋(offset)

토픽의 파티션 내에서 메시지의 고유한 위치를 나타내는 정수 값

메시지가 Kafka에 기록될 때 부여

소비자가 메시지를 읽을 때 메시지의 순서를 추적하는 데 사용

Offset의 특징:

메시지는 append-only log로 저장되며, offset은 증가하면서 할당됩니다.
각 메시지는 삭제되지 않는 한 고유한 offset을 유지합니다.
Offset은 소비자가 메시지를 읽는 위치를 추적하는 데 사용됩니다.

메시지 생산 예시:

Offset: 0 → Message: "Login"
Offset: 1 → Message: "Click"
Offset: 2 → Message: "Purchase"

메시지 소비 예시:

Topic: user-activity
Partition 0: [Message 0, Message 1, Message 2]
Partition 1: [Message 0, Message 1]

소비자 그룹: consumer-group-1
소비자가 읽은 offset:
- Partition 0: offset 2까지 읽음.
- Partition 1: offset 1까지 읽음.

3. 소비자 재시작 후:

소비자가 재시작하면 Kafka는 __consumer_offsets를 참조하여 각 파티션의 마지막 읽은 위치(offset)부터 메시지를 제공합니다.

rabbitMQ, Kafka 차이

rabbitmq

1. 장기 데이터 저장 불가

메시지를 소비하면, 삭제됨, 이벤트를 로그로 유지하거나 재처리 불가능

2. 재처리 어려움

kafka는 컨슈머 offset으로 과거 데이터를 읽을 수 있음

3. 데이터 분석

kafka는 데이터가 로그로 저장해서, 데이터 분석이 가능하다. rabbitmq는 실시간 전달만 함

이벤트 스트리밍

이벤트

시스템 내에서 발생한 상태 변화, 동작

사용자가 상품을 클릭, 결제완료

스트리밍

이벤트를 실시간으로 캡처하고 전달하여 중단 없는 데이터 흐름 유지

토픽과 클러스터의 관계

클러스터는 Kafka의 전체 메시징 환경을 운영하며, 여러 토픽을 포함합니다.
클러스터 내부의 브로커들은 토픽의 파티션을 나눠서 저장하고 처리합니다.
예를 들어:
- 클러스터: 3개의 브로커 (Broker-1, Broker-2, Broker-3)로 구성.
- user-activity 토픽: 사용자의 로그인, 클릭, 구매 데이터를 저장.
- user-activity 토픽: 6개의 파티션으로 구성.
  - 파티션 1~2는 Broker-1 저장
  - 파티션 3~4는 Broker-2 저장
  - 파티션 5~6은 Broker-3 저장

1. 토픽(Topic)

정의:
- **토픽(topic)**은 Kafka에서 데이터를 카테고리로 구분하는 논리적 단위입니다.
- 메시지는 특정 토픽에 **생산(produce)**되고, 해당 토픽에서 **소비(consume)**됩니다.
- 간단히 말해, **메시지를 저장하고 관리하기 위한 이름(label)**입니다.
특징:
- **파티션(partition)**으로 구성되어 데이터를 분산 저장합니다.
  - 각 파티션은 특정 물리적 브로커(서버)에 저장됩니다.
- 데이터는 append-only log 형식으로 저장됩니다.
- 동일한 토픽의 데이터를 여러 **생산자(producer)**와 **소비자(consumer)**가 동시에 사용 가능합니다.
사용 목적:
- 데이터를 주제별로 분리하여 관리.
- 생산자와 소비자 간의 효율적인 데이터 교환.
예시:
- user-activity 토픽: 사용자의 로그인, 클릭, 구매 데이터를 저장.
- order-processing 토픽: 주문 생성 및 상태 업데이트 정보를 저장.

2. 클러스터(Cluster)

정의:
- **클러스터(cluster)**는 Kafka를 실행하는 하나 이상의 브로커(broker)(Kafka 서버)의 집합입니다.
- 클러스터는 Kafka의 전체 인프라를 나타내며, 데이터 저장 및 처리를 분산 시스템으로 관리합니다.
특징:
- 브로커(broker):
  - 클러스터는 여러 브로커로 구성됩니다.
  - 각 브로커는 데이터를 저장하고, 소비자와 생산자 요청을 처리합니다.
- Zookeeper(또는 KRaft):
  - 클러스터의 메타데이터(토픽, 파티션, 리더 정보 등)를 관리합니다.
- 확장성:
  - 브로커를 추가하여 클러스터의 용량과 처리 성능을 확장할 수 있습니다.
- 내결함성:
  - 브로커가 장애를 일으켜도 다른 브로커가 데이터를 제공하여 안정성을 유지합니다.
사용 목적:
- 데이터의 분산 처리 및 저장.
- 여러 브로커를 통해 고가용성과 확장성을 제공.
예시:
- Kafka Cluster:
  - 3개의 브로커(Broker-1, Broker-2, Broker-3)로 구성된 Kafka 클러스터가 있다면,
  - 토픽의 파티션이 각 브로커에 나누어 저장되고, 데이터는 브로커 간에 복제됩니다.