Search

카프카 기본 개념

Status
UPLOADING
Date
2024/03/29
Tags
Kafka

1. 개요

Kafka란 무엇일까?
Apache 소프트웨어 재단에서 개발 된 오픈소스 플랫폼으로 데이터 스트림을 실시간으로 처리하고 실시간으로 저장하기 위해 고안되었습니다. 카프카는 많은 양의 데이터를 효율적으로 처리하면서도 높은 처리량과 낮은 지연 시간을 제공하는데 사용됩니다. 이러한 특징은 카프카가 대규모 데이터 파이프라인, 실시간 분석, 로그 수집 및 모니터링 등 다양한 용도에 사용되는 이유입니다.
Kafka의 구조
Kafka는 크게 다음으로 구성되어 있습니다.
Producer
Cluster
Consumer

2. Cluster

Cluster는 처리해야 하는 데이터를 쌓아 놓고 있는 데이터 저장소
Producer가 처리해야 하는 이벤트를 넣어주면 Cluster가 보관하고 있게 되고 Consumer가 순차적으로 처리하는 것이 기본 흐름입니다.

2-1. Topic

Kafka를 이해하기 위해서는 Topic이라는 개념을 이해하고 있어야 합니다. Kafka는 이벤트를 Topic이라는 개념으로 구성합니다.
Topic은 주제별로 관련된 이벤트를 모으는 단위로 생각할 수 있습니다.
(파일 시스템의 폴더와 유사한 역할을 합니다.) 쉽게는 이벤트를 분류하는 단위라고 생각하시면 됩니다.
Kafka Cluster는 처리해야 하는 이벤트를 Topic 단위로 가지고 있게 됩니다. 토픽으로 이벤트가 구분되기 때문에 ProducerConsumer는 하나의 Kafka Cluster 안에서 각자의 관심사를 분류할 수 있습니다.
Topic은 한 개 이상의 Partition으로 구성됩니다. Partition은 이벤트를 저장하는 물리적인 파일입니다. Partitionappend-only 파일, 즉, 추가만 가능한 파일입니다.
새로운 이벤트가 토픽으로 들어오면 뒤에 append 형식으로 뒤에 추가되며 offset을 할당 받게 되어 offset이 메세지를 식별할 수 있는 유니크 한 값이 됩니다.
offset을 기준으로 이벤트는 순차적으로 Consumer 의해 처리됩니다. 예를 들어, Consumer에게 3번 이벤트를 읽어달라는 요청이 들어왔을 때는 3번 부터 뒤에 들어온 이벤트 들만 읽을 수 있습니다. 이벤트는 삭제되지 않으며, 설정에 따라 자동적으로 삭제될 수 있습니다.
Producer는 라운드 로빈 또는 키로 파티션을 선택합니다.
KafkaTopic 단위로 파티션을 지원하기 때문에 Consumer가 발행한 이벤트는 파티션이 여러 개일 경우 여러 개로 나누어서 저장하고 Consumer도 파티션 별로 따로 붙을 수 있기 때문에 병렬 처리가 용이합니다.

3. Producer

Kafka Producer는 데이터를 생성하고 Kafka Cluster로 전송하는 역할을 합니다. 즉, Producer는 데이터를 생성하고 Topic으로 데이터를 보내는 것입니다.
Producer는 데이터를 단일 Topic 또는 여러 Topic으로 보낼 수 있으며 Topic 내 Partition의 데이터를 분배합니다. 이를 통해 데이터의 병렬 처리와 분산 저장이 가능해집니다.
쉽게 설명하자면 Kafka에서 Producers는 단어 그대로 처리해야 할 일을 생산하는 생산자 역할을 합니다.
처리해야 하는 일들을 모아두는 Cluster 보내어 해야할 일을 차곡차곡 모아둡니다.
만약 Topic에 여러 Partition이 설정되어 있다면, Producer여러 개일 경우에 하나의 파티션을 기다릴 필요 없이 각각의 파티션에 정해진 규칙에 따라 저장하면 되기 때문에 데이터 처리 속도가 더 빨라집니다.
위 그림을 보시면 Partition이 세 개로 구성되어 있고 각각의 Partition은 각각의 offset으로 구성되게 됩니다. 프로듀서는 각자 할당된 Partition에 데이터를 순차적으로 집어 넣게 됩니다.

4. Consumer

반면에 ConsumerTopic에서 데이터를 읽어오는 역할을 합니다.
ConsumerTopic 내의 하나 이상의 Partition에서 데이터를 소비하고 처리합니다. Consumer는 특정 토픽이나 파티션에서 데이터를 읽어오기 위해 카프카 클러스터와 연결됩니다.
Consumer는 읽어온 데이터를 어플리케이션 로직에 따라 처리하거나 다른 시스템으로 전달할 수 있습니다. 또한, Consumer는 읽어온 데이터의 offset을 기록하여 자체적으로 읽은 데이터의 위치를 추적합니다. 이를 통해 Consumer는 중단된 지점 부터 데이터를 다시 읽거나 특정 범위의 데이터 만을 읽을 수 있습니다.
ConsumerConsumer 그룹에 속합니다. Consumer가 Kafka Broker에 연결할 때 '나는 어떤 그룹에 속할거야' 라고 지정하게 되어있습니다. 그리고 한 개의 PartitionConsumer 그룹의 한 개 Consumer에만 연결 가능합니다. 즉, 한 Consumer 그룹에 속한 Consumer들 끼리Partition을 공유할 수 없습니다. 다르게 말하면 그룹 내에서 한 개의 Consumer만 한 개의 Partition을 처리할 수 있기 때문에 Partition의 이벤트가 순서대로 처리되는 것을 보장할 수 있게 됩니다.
이 외에도 Kafka 운영과 유지보수를 위해 알아야 할 요소들이 있습니다.
첫 번째로 Broker 입니다. Broker는 데이터의 저장과 전달을 관리하며 Producer로 부터 전송된 데이터를 토픽에 저장하고 Consumer에게 필요한 데이터를 제공합니다.
이전에 언급된 Kafka Cluster가 아닌 실질적으로는 Broker가 중간에서 데이터를 관리하고 있습니다. Kafka Cluster는 여러 개의 Broker로 구성되며 각 Broker는 데이터의 파티션을 관리하고 데이터의 복제와 장애 조치 기능을 수행합니다.
Broker는 데이터의 처리량과 안정성 확보를 위해서 확장 가능한 방식으로 설계되어 있습니다.
두 번째로 ZooKeeper 입니다. KafkaZooKeeperKafka Cluster 구성 정보와 상태를 관리하는 분산 형성 관리 도구입니다. ZooKeeperKafka Cluster의 구성 토픽의 메타데이터 브로커의 상태, 컨슈머 그룹 등을 추적하고 유지합니다. ZooKeeper는 브로커들간의 리더 선출, 동기화, 이벤트 처리 등 분산 시스템 작업을 수행합니다.
ZooKeeperBroker의 추가 및 제거, 토픽의 생성 및 삭제와 같은 카프카 클러스터의 구성 변경을 관리합니다. 안정성과 일관성을 보장하는 역할을 수행합니다.
간단히 정리하자면 Kafka ClusterBrokerZooKeeper로 구성되어 있으며, 브로커는 데이터의 저장과 전달하는 저장소의 역할을 하고 ZooKeeperCluster의 구성 정보와 상태를 관리하는 관리자 역할을 합니다.

5. Replica

Kafka는 장애가 났을 때 이를 대처하기 위해서 Replica 라는 것을 사용합니다. Replica는 파티션의 복제본이고, 복제 수 만큼 PartitionReplicaBroker에 생기게 됩니다.
예를 들어, 토픽을 생성할 때 복제 수를 2로 지정하면 동일한 데이터를 갖고 있는 Partition이 서로 다른 브로커에 2개가 생기게 됩니다.
여러 Partition 중에서 하나가 리더가 되고 나머지가 팔로워가 됩니다. 리더를 통해서만 ProducerConsumer는 이벤트를 처리하며, 나머지 팔로워는 리더로 부터 데이터를 읽어와서 저장(복제) 하는 역할을 수행하게 됩니다.
리더가 장애가 생기면 다른 팔로워들 중에서 하나가 리더가 되고 ProducerConsumer는새로운 리더를 통해서 다시 이벤트를 처리합니다.

6. 그래서 카프카를 왜 사용하나요?

비슷한 시스템인 rabbitMQ와 같은 메세지 시스템과 비교해보았을 때는 rabbitMQ는 메모리 상에서 동작하여 시스템이 꺼지면 모든 메세지가 유실되는 것과 반대Kafka디스크에 이벤트를 저장하기 때문에 복구가 가능합니다.
Topic 내에 Partition을 설정함으로써 대규모 트래픽을 병렬적으로 분산 처리 할 수 있습니다. 또한, 필요에 따라 Broker, Partition, Consumer 등을 추가할 수 있습니다. 즉, scale-up이 쉽습니다.
Kafka는 묶어서 보내고 묶어서 받을 수 있습니다. 즉, Producer는 일정 크기만큼 메세지를 모아서 전송할 수 있으며, Consumer는 최소 크기만큼 메세지를 모아서 조회할 수 있습니다. 이는 낱개로 처리하는 것 보다 처리량이 증가됩니다.