Kafka와 RabbitMQ를 알아보자

이번에 알아볼 Kafka와 RabbitMQ는 두 어플리케이션, 프로세스 등 간의 메세지를 교환할 때 사용하는 플랫폼입니다.
첫 번 째 게시글은 Kafka와 RabbitMQ에 대해 이론적으로 알아보고, 다음 게시글은 Spring boot + Python을 사용하여 Kafka로 통신하는 방법에 대해서 알아볼 것입니다.

메시지 큐 (MQ)

먼저, Kafka와 RabbitMQ에 대해서 알아보기 전 필수적인 개념인 메시지 큐에 대해서 알아보겠습니다.

정의

프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할 때 사용하는 통신 방법

독립적인 애플리케이션과 서비스에서 정보를 교환할 수 있도록 지원하며, 한 애플리케이션이 큐에 메세지를 보내고, 다른 애플리케이션이 큐에서 메시지를 받아 사용하는 통신 방법입니다.
즉, 발신자와 소비자 간에는 강력하게 커플링된 일대일 관계가 성립하게 됩니다.

구조

앞서, 이름에서 유추할 수 있다시피 Queue라는 자료구조를 사용하여 메세지를 전달하는 통신을 말합니다.
메세지를 발행하여 Queue에 추가를 담당하는 곳을 Producer라고 하며, 발행된 메시지를 받아서 소비하는 곳을 Consumer라고 지칭합니다.

특징

특징	설명
비동기	Queue에 메시지를 저장하기 때문에, 나중에 처리할 수 있다.
비동조	각 어플리케이션 또는 서비스들은 메시지 큐를 통해 느슨한 결합이 된다.
탄력성	일부가 실패해도 전체에 영향이 가지 않는다.
과잉	실패할 경우 다시 시도할 수 있다.
확장성	다수의 프로세스들이 큐에 메시지를 보낼 수 있다.

각 특징을 통해 서비스 간의 API 호출, 비용이 많은 작업을 다른 서비스로 분리, 많은 양의 프로세스 처리 등에 사용합니다.

Pub/Sub

Pub/Sub 구조는 Producer가 Topic에게 메시지를 보내고, Consumer는 Topic을 구독하여 메시지를 받는 방식입니다.
보내고자 하는 메시지를 Topic을 통해 카테고리화 하고, Producer와 Consumer는 Topic에 대한 정보만 알 뿐 서로에 대해서는 모르는 게 가장 큰 특징입니다.

Message Broker

애플리케이션, 시스템, 서비스 간에 메시지를 전달하고 중개하는 소프트웨어

Message Broker는 다양한 시스템 간에 메시지를 안전하고 신뢰성 있게 교환할 수 있도록 하며, 주로 비동기 통신을 지원합니다.

RabbitMQ

RabbitMQ는 Message Broker 중 대표적인 소프트웨어입니다.
AMQP 프로토콜을 구현한 Message Broker로써, 지정된 Consumer에게 원하는 방식을 적용하여 메시지를 신뢰성 있게 전달하는 데 초점이 맞춰진 소프트웨어입니다.

용어

이름	설명
Producer	메시지를 생성하고 발송하는 시스템입니다.
Consumer	메시지를 수신하는 시스템입니다.
Exchange	메시지를 받아 Routing Key와 Bindings 규칙을 사용하여 어떤 큐에 발송할지 정하는 메시지 라우팅을 담당합니다.
Bindings	Exchange와 Queue 사이의 연결을 정의하며, Exchange가 메시지를 어떤 큐로 보낼지 결정하는 규칙을 설정합니다.
RoutingKey	Exchange가 어떤 Queue에 메세지를 전달할지 결정하는 기준입니다.

Exchange Types

Direct Exchange

https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

Routing Key를 기반으로 메시지를 Queue에 전달하는 방법으로, Binding Key와 Routing Key가 일치해야만 해당 Queue로 메시지를 전달하는 방식입니다.
만약, 일치하는 키가 없다면 메시지는 삭제됩니다.

Example

메시지와 Routing Key를 pdf_create로 설정
pdf_events라는 exchange로 메시지를 전달
Routing Key는 Binding Key의 pdf_create와 일치하므로 Queue A에 메시지를 전달

Topic Exchange

Routing Key를 기반으로 메시지를 전달하는 방법으로, Direct와 다른 점은 완전히 똑같은 게 아닌 패턴만 일치하면 해당 큐로 메시지를 전달합니다.
즉, Direct는 1 : 1를 위한 전달 방식이고, Topic은 1개 이상 큐에 전달하는 방식을 뜻합니다.
또한, Routing Key는 반드시 .(dot)으로 구분된 단어로 이뤄져야 합니다.

* (asterisk)
Binding Key를 설정할 때 "*"는 특정 위치에 있는 단어와 일치할 수 있도록 만드는 방법입니다.
e.g. "agreements.*.*.b.*" => 첫 번째 단어가 "agreements"이며, 4번째 단어가 "b"이어야 합니다.

# (Number sign)
Binding Key를 지정할 때 "#"은 0개 이상의 단어가 일치함을 나타내는 방법입니다.
e.g. "agreements.eu.berlin.#" => "agreements.eu.berlin"으로만 이루어져 있으면 됩니다.

Example

Queue A는 Berlin에 있는 모든 계약(agreements)에 대한 메시지를 받습니다.
Queue B는 모든 계약(agreements) 에 대한 메시지를 받습니다.
즉, Queue B는 Queue A 또는 Queue C와 같이 반드시 메시지를 전달받습니다.
Queue C는 유럽(eu) 본점(store) 계약에 대한 메시지를 받습니다.

Fanout Exchange

Direct Exchange와 Topic Exchange랑은 다르게 Routing Key 또는 패턴과 일치하지 않아도 메시지를 복사하여 모든 큐에 전달하는 방식을 말합니다. 즉, 제공된 Routing Key는 무시됩니다.
Fanout Exchange는 같은 메시지를 각 Cosumer에서 다르게 처리해야할 때 유용한 방법입니다.

Example

sport news Exchange에 메시지를 전달하면 모든 큐에 메시지가 전달됩니다.

Headers Exchange

Topic Exchange와 매우 유사한 방식을 가진 Header Exchange는 Routing Key 대신 Header 값을 기반으로 메시지를 전달합니다. Header 값과 Binding 값이 일치하면 메시지를 보내는 형식입니다.

x-match

Header 값에는 "x-match"라는 인자를 넣을 수 있고, "all" 또는 "any"라는 값을 지정할 수 있습니다.

값	설명
all	Binding에 있는 모든 Key: Value가 메시지에 지정된 Key: Value와 일치해야 합니다. x-match를 지정하지 않으면 기본 값입니다.
any	Binding에 있는 Key: Value 중 메시지에 지정된 Key: Value와 하나라도 일치하면 됩니다.

Example

Message 1은 Queue A와 Queue B에 전달됩니다.
1. Message 1은 Queue A의 "format = pdf", "type = report"와 모두 일치하여 일치하여 메시지가 전달됩니다.
2. Message 1은 Queue B의 "format = pdf"와 하나 일치하여 메시지가 전달됩니다.
Message 2는 Queue B에 전달됩니다.
1. Message 2는 Queue B의 "format = pdf"와 하나 일치하여 메시지가 전달됩니다.
Message 3는 Queue B에 전달됩니다.
1. Message 3는 Queue B의 "type = log"와 하나 일치하여 메시지가 전달됩니다.

Kafka

RabbitMQ와 많이 사용되는 Message Broker입니다.
실시간으로 처리량이 많은 스트림을 다수에게 전달하고 처리할 때 유용하게 사용할 수 있는 소프트웨어입니다.

용어

이름	설명
Producer	메시지를 생성하고 발송하는 시스템입니다.
Consumer	메시지를 수신하는 시스템입니다.
Broker	하나의 Kafka 서버를 말합니다. 즉, 메시지를 물리적으로 저장하는 서버 또는 컴퓨터를 말합니다. 하나의 컴퓨터에 여러 개의 Broker를 띄울 수 있지만, 하드웨어 자원을 공유하기 때문에 컴퓨터가 장애를 일으키면 모든 Broker가 다운되어 권장하지 않습니다.
Cluster	여러 대 서버(Broker)의 집합을 의미합니다. 하나의 Broker가 장애를 일으켜도 다른 Broker가 이를 처리할 수 있게 합니다.
Zookeeper	분산 애플리케이션 관리를 위한 코디네이션 시스템을 말합니다. 쉽게 말해, Kafka Cluster는 Zookeeper를 통해 Broker의 상태를 추적하고, 관리하는 역할을 합니다.

Topic과 Partition

Topic

메시지를 구분하는 논리적인 단위
Producer가 메시지를 보낼 때는 Topic을 지정하여 전송해야 함
Consumer는 Topic을 구독하여 들어온 메시지에 대하여 처리함
Topic은 여러 개의 Partition을 가짐

Partition

메시지를 실제 저장소에 저장하는 가장 작은 물리적인 단위
Partition에 저장된 메시지는 offset을 통해 순서를 보장하지만, Partition끼리의 메시지 순서는 보장하지 않음
여러 개의 메시지를 병렬 처리할 수 있게 해줌

Replication

Kafka Cluster의 메시지의 고가용성과 내결함성을 보장하는 역할을 위한 핵심 기능이다.
각 Partition은 Replica(복제본)을 가지며, 이 복제본은 다른 Broker에 저장됩니다.

고가용성이란?
서버, 네트워크, 프로그램 등의 시스템이 장애를 일으켜 다운되지 않고, 정상적으로 오랫동안 유지되는 능력을 말합니다.

내결함성이란?
시스템의 일부 요소가 작동하지 않더라도 계속 동작할 수 있는 기능을 말합니다.
즉, 시스템에서 일어난 장애를 감지하고, 복구하는 능력을 말합니다.

Leader and Followers Replica

Leader Replica : 각 Partition은 하나의 리더가 있습니다. Leader는 Producer와 Consumer의 모든 읽기, 쓰기 작업을 처리합니다.
즉, 모든 메시지의 읽기와 쓰기 요청은 Leader를 통해 처리하고, 저장합니다.
Followers Replica : 리더의 복제본인 Follower는 Leader로부터 메시지를 복제하여 로컬 디스크에 저장합니다.
즉, Leader에 있는 메시지를 복사하여 같은 상태를 유지하는 역할을 합니다.

Leader 장애

Leader가 장애가 일어나 사용할 수 없는 상태가 되면 Zookeeper가 이를 감지합니다.
장애를 감지한 Zookeeper는 존재하는 Follower 중 하나를 새로운 Leader로 승격시킵니다.
원래 Leader의 상태를 계속해서 복제하던 Follower는 메시지의 손실 없이 새롭게 Leader의 역할을 수행합니다.

References

'Project 하면서 알아가는 것들' 카테고리의 다른 글

[Nextjs] Tiptap 사용법과 커스텀마이징 기능 구현 (1)	2024.02.28
IoC, DI, DPI 확실히 개념 잡기 (0)	2023.11.12
REST API 확실히 개념 잡기 (0)	2023.11.02
백엔드에서 이미지 업로드는 어떻게 하면 좋을까? (6)	2023.11.01
typescript ?(Optional Parameters)와 \| undefined(Union)의 차이 (0)	2023.02.09

메시지 큐 (MQ)

정의

구조

특징

Pub/Sub

Message Broker

RabbitMQ

용어

Exchange Types

Direct Exchange

Topic Exchange

Fanout Exchange

Headers Exchange

Kafka

용어

Topic과 Partition

Topic

Partition

Replication

Leader and Followers Replica

Leader 장애

References

'Project 하면서 알아가는 것들' 카테고리의 다른 글

검색 태그

티스토리툴바