[Kafka] 카프카란 ? 주요개념 정리 및 Pub/Sub 모델 비교

카프카(kafka) 란?

Kafka는 대규모 실시간 데이터 스트리밍을 처리하는 데 사용되는 분산 이벤트 스트리밍 플랫폼이다.

 

먼저 "분산 이벤트 스트리밍"이라는 용어에 대해 알아보자

분산 이벤트이라는 말은 여러 대의 서버(노드)에 분산되어 저장된 이벤트(데이터) 를 말한다.

이벤트 스트리밍은 대량의 이벤트(데이터)를 실시간으로 처리하는 방식을 의미한다.

 

즉, 이 두 내용을 연결 시키면 분산 되어 있는 이벤트(데이터)들을 실시간으로 처리하는 플랫폼이라는 뜻이 된다.

링크드인의 카프카 적용 전 - 카프카 적용 후 아키텍처

위 그림의 왼쪽은 링크드인에서 개발한 카프카가 등장하기전의 아키텍처 모습니다.

각 데이터 저장소들이 도착지점까지 모든 시스템을 거치는 End - To - End 연결로 매우 복잡한 것을 볼 수 있다.

하지만 카프카가 적용된 오른쪽 그림을 보면 모든 이벤트와 데이터를 카프카가 처리하는 것을 볼 수 있다.

 

그렇다면 이 분산 이벤트를 실시간으로 어떻게 관리하는 걸까 ?

바로 kafka가 Pub / Sub 모델의 메세지 큐 형태로 동작하기 때문이다.

---

메세지 큐 (Message Queue, MQ)

카프카를 이해하기 위해서는 카프카의 핵심 개념인 메세지 큐에 대한 이해가 필요하다.

 

메세지 큐는 "메시지 지향 미들웨어 (MOM : 서로 다른 시스템, 애플리케이션, 서비스 간에 메시지를 교환하는 방식)"를 구현한 시스템이다.

 

메시지 큐를 사용하면 메세지를 보낸 사람(발행자)와 메세지를 받는 사람(수신자)가 서로를 직접 알 지 못해도 전송, 수신이 가능하다. (비동기 : 느슨한 결합)

바로 발행자와 수신자 사이에 메시지 큐가 이를 중개하고 있기 때문이다.

 

메세지큐의 장점

• 수신자의 서비스에서 장애가 발생하더라도 발행자로 인해 발행된 메세지는 이미 메시지 큐에 남아 있기 때문에 수신자에게 메세지 전달을 보장할 수 있다.
• 발행자와 수신자가 서로 의존하지 않고 독립적이기 때문에 확장하는데 문제가 없다.
• 메세지 큐라는 중개소가 있기 때문에 발행자와 수신자가 서로의 요청과 응답을 기다리지 않고 큐에 담아 비동기로 통신할 수 있다.

 

Point to Point 와 Pub / Sub

메시지 큐는 크게 Point to Point(P2P) 와 Publish/Subscribe (Pub / Sub)모델로 구분된다.

• Point to Point(P2P) : 한 명의 발행자의 메세지는 한 명의 컨슈머에 의해 소비되는 방식으로 즉, 1 : 1 메시지 전송 방식이다.
• Publish/Subscribe (Pub / Sub) : 발행자가 특정 Topic(토픽)에 메시지를 보내면, 해당 Topic을 구독한 여러 수신자가 해당 메시지를 받는 방식이다.

	Point to Point(P2P)	Publish/Subscribe (Pub / Sub)	둘다 지원
서비스	- Amazon SQS	- Amazon SNS - Kafka - Redis	- ActiveMQ - RabbitMQ

우리가 이번 포스팅에서 알아볼 Kafka는 Pub / Sub 를 지원한다.

Pub / Sub 모델을 기본으로 하지만 각 메시지가 한 번만 처리되도록 보장하는 P2P 스타일의 소비도 가능하다고 한다. (GPT 말함.)

---

카프카 용어 정리

출처 : https://www.linkedin.com/pulse/how-deploy-kafka-zookeeper-cluster-linux-based-operating-tiwari

◼ 카프카 클러스터 (kafka cluster)

브로커들의 모임으로 확장성과 고가용성을 위해 Broker들이 클러스터로 구성되어 있다.

 

◼ 브로커 (Broker)

각각의 Kafka 서버를 말한다. 프로듀서로 부터 메세지를 전달받아 토픽에 저장하고 컨슈머에 저장한다. (한나의 브로커는 여러개의 토픽을 가질 수 있다.)

 

◼ 주키퍼 (zookeeper)

Kafka 클러스터 상태와 정보 등을 관리하는 역할을 한다. (Kafka를 실행 시키기 위해선 Zookeeper도 같이 실행해야함)

 

◼ 프로듀서 (Producer)

메시지를 발행하는 주체이다. 메시지 발행 시 특정 토픽을 정하여 발행한다.

 

◼ 컨슈머 (Consumer)

메시지를 소비, 수신하는 주체이다. 특정 토픽을 구독하여 메시지를 전달 받는다.

 

◼ 컨슈머 그룹 (Consumer Group)

컨슈머 그룹은 하나 이상의 컨슈머가 모여 구성된 그룹이다.

같은 컨슈머 그룹 내에서는 각 파티션에 대한 메시지 처리가 한 컨슈머에게만 할당된다. (즉, 각 파티션의 메시지는 한 번만 처리).

쉽게 얘기하면 "책"이라는 토픽에 파티션이 1, 2가 있고 그룹 G에 컨슈머 a, b가 있다면 a는 1, b는 2 파티션에서 메시지를 받는 것이다.

즉, 한 그룹안에 있는 여러 컨슈머들이 서로 다른 파티션에서 동일한 토픽을 동시에 소비하는 것.

 

◼ 토픽 (Topic)

메시지를 구분하는 단위로 프로듀서로 부터 전송된 데이터는 토픽이름으로 구별된다.

 

◼ 파티션 (partition)

하나의 토픽은 하나 이상의 파티션으로 나눠진다.

즉, 동일한 토픽이 여러 파티션에 나눠서 저장되는 것이다.

 

◼ 오프셋 (offset)

파티션 내에서 메시지의 위치(식별자)를 나타낸다. 책의 페이지 번호를 알면 해당 페이지로 바로 이동할 수 있듯이, 오프셋 값을 알면 해당 메시지로 바로 접근할 수 있다.

 

---

Pub / Sub 모델 별 차이

 

	Kafka	RabbitMQ	Redis Pub/Sub
데이터 유지	디스크에 데이터를 지속적으로 저장하며 TTL(Time-To-Live) 설정으로 오래된 데이터를 삭제할 수 있다. 또한 Consumer가 어디까지 메시지를 읽었는지 추적 가능.	메시지는 메모리와 디스크에 저장될 수 있으며 기본적으로 메시지는 Consumer가 처리하면 삭제된다.	기본적으로 메모리 기반의 스토리지로 데이터 유실 위험이 있다. 영속성을 위해선 AOP, RDB 추가 설정이 필요.
확장성	Topic의 Partition을 통해 확장성을 제공하며, 분산 처리가 가능	Queue를 통해 확장성을 제공하지만 Kafka 만큼의 높은 병렬처리 능력은 부족	Pub/Sub 모델에서는 병렬 처리나 분산 처리 방식이 제한적
우선순위	변경 불가능하지만 한 파티션 내에서는 시간 순서를 보장.	priority queue를 지원해 우선순위에 따라 처리 가능.	-
장점	- 이벤트가 전달되어도 삭제되지 않고 디스크에 저장된다. - 고성능, 고가용성, 분산처리에 효과적. - producer 중심적으로 많은 양의 데이터를 병렬 처리 가능하다.	- Direct, Fanout, Topic, Headers의 라우팅 옵션을 제공하여 유연한 라우팅이 가능하다. - Manage UI가 기본 제공 - Broker 중심적인 형태로 publisher와 consumer간의 보장되는 메시지 전달 - 플러그인도 제공되어 확장성 뛰어나다.	인메모리로 빈번하고 속도가 중요한 작업에
단점	범용 메세지 시스템에서 제공되는 다양한 기능이 제공되지 않는다.	- kafka보다 느리다. - 대용량 데이터 처리에 상대적으로 부적합하다.	이벤트 도착을 보장하지 못한다.
사용 사례	대용량 실시간 스트림 데이터 처리 및 분석에 적합	데이터 처리보단, 관리적 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 사용	캐싱, 세션 관리 등 인메모리 스토어가 필요하거나 경량의 실시간 Pub/Sub 시스템에 사용