카프카(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 말함.)
카프카 용어 정리
◼ 카프카 클러스터 (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 시스템에 사용 |
'◼ 오픈소스' 카테고리의 다른 글
| [ELK] ElasticSearch란? ELK란? 내부 구조, 장단점, RDB와 차이 (7) | 2023.10.05 |
|---|---|
| [TinyMce] 텍스트 에디터 적용하기 (+ 에디터 이미지 업로드) (0) | 2023.08.03 |
| Nginx란 무엇이고 왜 사용하는가? (Apache와 차이점) (0) | 2023.06.24 |
| [Docker] 도커 컴포즈(Docker Compose)란? 왜 사용하는가? (1) | 2023.06.23 |
| [Docker] 도커 명령어 총모음집 (image, container, compose) (2) | 2023.06.23 |