위 그림과 같이 프로듀서(Producer)에서 보내는 메시지(Message) 혹은 이벤트(Event)들은 카프카 브로커(Kafka Broker)에 토픽(Topic)
이라는 단위로 저장되며 컨슈머(Consumer)는 저장된 토픽을 읽어온다. 여기서 카프카가 다른 메시징 큐(Messaging Queue)와 다른 점은 컨슈머가 저장된 토픽을 읽어온다고 하더라도 바로 삭제되지 않는다는 점이다. 다른 포스팅에서 설명하겠지만, 컨슈머는 컨슈머 그룹으로 구성될 수 있으며 각기 다른 컨슈머 그룹이 토픽을 각각 읽어갈 수 있기 때문이다. 또한 이를 통해 컨슈머가 가져간 데이터가 삭제된다 하더라도 다시 카프카의 토픽을 읽어오면 되므로 안정성을 높여준다. (참고로 별도의 옵션을 주지 않는 한 토픽은 일주일 동안 보관 후 삭제된다.)
카프카는 다른 데이터 플랫폼이 그렇듯 클러스터(Cluster) 구성이 가능하다. 클러스터 구성을 하게 되면 각각의 카프카 브로커에 대한 관리를 해야하는데 카프카 클러스터는 주키퍼(Zookeeper)를 통해 메타데이터(metadata)를 관리하며 브로커들의 상태를 점검한다.
위 그림에서는 프로듀서가 카프카 브로커에 보내는 메시지가 토픽으로 저장되는 과정이다. 하나의 토픽은 병렬 처리를 위해 여러 개의 파티션(Partition)으로 나누어 처리하며 위 그림에서는 1개의 토픽이 총 4개의 파티션으로 분리된 케이스이다. 토픽은 하나 이상의 파티션을 가질 수 있지만 따로 파티션의 개수를 지정하지 않는다면 토픽은 1개의 파티션을 가지며 병렬 처리의 이점을 기대할 수 없다. 파티션은 카프카 브로커 서버에 세그먼트(Segment) 단위로 저장된다. 토픽과 파티션이 논리적인 단위라면, 세그먼트는 실제로 물리적으로 서버에 저장하는 단위이다. 토픽의 메시지를 세그먼트라는 물리적 파일로 저장하기 때문에 세그먼트가 카프카 서버에 존재하는 한 컨슈머는 얼마든지 메시지를 다시 읽어갈 수 있으며 복수의 컨슈머가 같은 토픽을 읽을 수 있는 이유이기도 하다.(단, 같은 컨슈머 그룹 내의 컨슈머는 동일 메시지를 읽지 않으며 해당 내용은 컨슈머를 다루는 포스팅에서 설명할 예정이다.)
위 그림은 카프카 브로커가 클러스터로 구성되었을 때, 토픽과 파티션이 배치되는 예제와 세그먼트로 저장되는 예제 그림이다. 이해를 위해 심플한 케이스로 구성했다. 카프카 브로커는 101 ~ 104까지 총 4대로 구성이 되어있고 토픽은 “A”라는 이름의 토픽 1개이며 “토픽 A”의 파티션은 4개이다. 카프카 내부적으로 토픽을 구성하는 파티션들은 여러 카프카 브로커에 최대한 겹치지 않도록 분산배치되게 최적화가 되어 있다. 따라서 각각의 파티션들은 각각의 브로커들에가 1개씩 할당이 되어 있고, 각 파티션에 따라 세그먼트 단위로 물리적인 파일이 저장된다.
이번 포스팅에서는 Apache Kafka의 주요 요소인 Kafka Broker, Producer, Consumer, Topic, Partition, Segment에 대해 간략하게 살펴봤다. 큰 컨셉으로 각각의 요소들의 관계에 초점을 맞췄으며 다음 포스팅에서는 각 요소들을 한걸음 더 들어가 좀 더 깊게 살펴보겠다.
Docker-Compose로 Confluent Kafka 와 C3(Confluent Control Center) 설치 (0) | 2022.10.10 |
---|---|
Apache Kafka란 (0) | 2022.01.09 |
댓글 영역