Kafka 너는 대체 뭐냐!

 

 

---

메시지 지향 미들웨어 (Message-oriented Middleware, MOM)

 

메시지 지향 미들웨어 (MOM) : 메시지 API를 통해 분산되어있는 애플리케이션 간의 데이터를 교환할 수 있도록 하는 시스템

 

비동기적으로 메시지를 전달하고, 수신할 수 있다.

즉, 보낸 쪽이 받는 쪽의 응답을 기다릴 필요가 없다.

따라서, 즉각적인 응답이 필요하지 않거나, 많은 수의 요청을 동시에 처리해야 하는 환경에서 사용하기에 적합하다.

 

---

메시지 큐 (Message Queue, MQ)

 

 

메시지 큐 (MQ) : 메시지 지향 미들웨어를 구현한 시스템

• Producer (발행자) : 메시지 큐로 메시지를 전송한다.
• Consumer (수신자) : 메시지 큐로부터 메시지를 받아온다.

발행자와 수신자 사이에서 메시지 큐가 중개 역할을 수행한다.

따라서, 발행자와 수신자가 서로를 몰라도 되며, 비동기적으로 느슨하게 결합된다.

 

 

메시지 큐를 사용하면 다음과 같은 이점을 얻을 수 있다.

• 수신자의 서비스에 장애가 발생하더라도, 발행자의 메시지는 이미 메시지 큐에 남아 있기 때문에, 메시지는 언젠가 수신자에게 전달됨을 보장할 수 있다.
• 발행자와 수신자가 서로 의존하지 않고 독립적이기 때문에, 확장성이 좋다.
• 발행자와 수신자가 서로의 요청 및 응답을 기다리지 않고 비동기적으로 통신할 수 있다.

 

메시지 큐는 다음과 같은 종류가 있다.

• Point-to-Point (P2P)
  • 하나의 발행자와 하나의 수신자가 1:1 메시지 송수신을 수행한다.
  • Amazon SQS 등이 여기에 속한다.
• Publish/Subscribe (Pub/Sub)
  • 발행자가 특정 토픽으로 메시지를 보내면, 해당 토픽을 구독한 여러 수신자가 메시지를 수신한다.
  • Amazon SNS, Kafka, Redis 등이 여기에 속한다.

참고로 ActiveMQ, RabbitMQ는 둘 다 지원한다.

 

---

Kafka

 

카프카 : Pub/Sub 모델을 기반으로 한 메시지 큐의 한 종류이다.

• Producer (발행자) : 토픽으로 메시지를 전송한다.
• Consumer (수신자) : 토픽으로부터 메시지를 받아온다.
• Broker (브로커) : 각각의 카프카 서버로, 여러 토픽을 소유한다.

 

 

• Kafka Cluster (카프카 클러스터) : 확장성과 고가용성을 위해 여러 브로커들이 클러스터로 구성된 것
• Zookeeper (주키퍼) : 카프카 클러스터의 상태와 정보를 관리한다. (카프카 실행 전 주키퍼가 실행되어야 함)

 

 

• Topic (토픽) : 발행자가 전송한 메시지를 구분하는 단위
  
  • 예시 : 인증번호
• Partition (파티션) : 토픽을 구성하는 단위
  
  • 예시 : 사용자 A에게 보내진 인증번호, 사용자 B에게 보내진 인증번호 등

각각의 파티션 내의 메시지들은 offset를 유지함으로써 순서를 보장한다.

예를 들어, 사용자 A에게 보내진 인증번호 간의 순서는 보장되는 것이다.

 

그러나, 서로 다른 파티션 내의 메시지 간의 순서는 보장되지 않는다.

예를 들어 ,사용자 A에게 보내진 인증번호와 사용자 B에게 보내진 인증번호 간의 순서는 알 수 없다.

 

수신자는 메시지 내의 offset 정보를 통해, 파티션의 어떤 메시지까지 처리했는지 확인할 수 있다.

이를 통해, 수신자가 실수로 같은 데이터를 처리하거나, 미처 다하지 못한 작업을 이어서 수행할 수 있다.

 

Consumer group : 하나 이상의 수신자가 모여 구성된 그룹

• 각 파티션은 그룹 내의 하나의 수신자에게만 할당된다.
• 수신자 그룹은 각각의 메시지를 병렬 처리하면서도 중복 없이 수신할 수 있게 해준다.

 

 

각각의 파티션마다 리더와 팔로워가 존재할 수 있다.

• Leader (리더)
  
  • 발행자로부터 메시지를 직접 받아 저장한다.
  • 수신자에게 메시지를 전달한다.
  • 팔로워들과 동기화를 유지한다.
• Follower (팔로워)
  • 리더의 데이터를 복제하여 저장한다.
  • 리더와 지속적으로 동기화를 수행한다.
  • 리더에 에러가 발생할 경우, 새로운 리더가 된다.
  • 수신자에게 메시지를 전달하지만, 발행자로부터 메시지를 받아서 저장할 순 없다.

리더와 팔로워를 둠으로써, 파티션의 고가용성을 보장한다.

이를 위해서는 브로커가 여러 개 필요하다.

 

 

ISR : 리더와 팔로워가 동기화를 수행하는 메커니즘

1. 리더가 팔로워들의 동기화 상태를 지속적으로 확인한다.
2. 각 팔로워는 리더로부터 메시지를 복제할 때마다 fetch 요청을 보낸다.
3. 기본 설정 시간 내에 fetch 요청이 없으면, 해당 팔로워는 ISR에서 제외된다.
4. 제외된 팔로워가 동기화 속도를 따라잡으면 다시 ISR에 포함된다.

 

---

Kafka vs RabbitMQ

	Kafka	RabbitMQ
사용 사례	대용량 실시간 스트리밍	서비스 구축을 위한 비동기 작업 처리
메시지 처리 방식	수신자가 직접 요청하는 Pull 기반 동작 방식	브로커가 전달하는 Push 기반 동작 방식
메시지 저장	디스크에 영구적으로 저장하므로, 메시지를 반복적으로 읽을 수 있음	메시지가 소비되면 삭제되는 일회성 방식
메시지 재처리	offset 값을 통해, 재처리 가능	별도의 설정 없이는 불가능
처리량	초당 수십만~수백만 메시지 처리 가능, 고성능	Kafka에 비해 느림

 

즉, 카프카는 대용량 트래픽의 환경에서 성능과 확장성이 중요할 때에 적합하다.

반면, RabbitMQ는 간단한 비동기 처리 로직이 필요할 때에 적합하다.

 

 

---

 

 

참고:

https://hstory0208.tistory.com/entry/Kafka-%EC%B9%B4%ED%94%84%EC%B9%B4%EB%9E%80-%EC%A3%BC%EC%9A%94%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC-%EB%B0%8F-PubSub-%EB%AA%A8%EB%8D%B8-%EB%B9%84%EA%B5%90