4 분 소요

KAFKA 개요 및 개념

개요

Kafka는 대용량 실시간 데이터 스트림 처리를 위한 분산 메시징 시스템

구글의 Pub/Sub이나 아마존의 Kinesis와 같은 메시징 시스템과 비슷하지만 Kafka는 이들과 달리 저장소 역할까지 수행한다.

Kafka는 대량의 데이터를 높은 처리량과 낮은 지연 시간으로 처리할 수 있으며, 수평 스케일링이 가능하다. 또한 안정적인 데이터 전송과 함께 데이터 손실을 방지하기 위한 복제 기능을 제공한다.

주요기능

Kafka 는 pub-sub model 을 지원하는 분산 메세지 큐이다.

여러대의 서버로 scale-out 할 수 있는 클러스터를 구성한다

Topic 을 중심으로 producer 라고 하는 publisher 와 consumer(group) 이라고 하는 subscriber 로 데이터를 관리하고 처리한다.

하나의 Topic 은 복수개의 partition 으로 확장가능하다.

KAFKA가 해결하려는 문제

기존의 RabbitMQ와 같은 single message queue 가 가지는 scale과 속도 문제를 해결할 수 있다.

Cluster 구성으로 Fault tolerance, High availability 를 자체적으로 해결한다.

topic, partition, offset, producer(ack), consumer group(commit) 개념으로 대용량 분산 메세지 처리에서의 메세지 저장과 처리의 신뢰를 관리할 수 있는 메커니즘을 구현했다.

대용량 데이터를 다루면서도 빠른 데이터 처리가 가능하게 한다.

KAFKA의 구성요소

KAFAK의 구성요소는 다음과 같다.

  • Producer: 데이터를 생산하고 Kafka의 topic으로 전송함.
  • Consumer: Kafka topic에서 데이터를 구독하여 소비함.
  • Broker: Kafka 서버이며, topic에 대한 데이터를 저장하고 producer와 consumer 간의 데이터 흐름을 조정함.
  • Topic: Kafka 데이터의 주제를 나타내며, producer와 consumer 간의 데이터 전송을 위한 메커니즘을 제공함.
  • Partition: Kafka topic은 여러개의 partition으로 구성되며, 각 partition은 별도의 offset을 가지며 독립적으로 관리되고 이를 통해 Kafka는 대용량 데이터 처리 및 병렬 처리를 가능하게 한다.

서버: Kafka는 하나 이상의 서버로 구성된 클러스터다. 서버 중 일부는 브로커라고 하는 스토리지 계층을 형성한다. 그 외의 다른 서버는 Kafka Connect를 통해 데이터를 스트리밍하면서 Kafka를 다른 시스템(e.g. RDBMS, 다른 Kafka 클러스터 등)과 통합한다.

클라이언트: Kafka 클라이언트를 사용하면 네트워크 또는 시스템 문제가 발생한 경우에도 고가용성을 보장하면서 이벤트 스트림을 병렬적으로 처리할 수 있는 분산 애플리케이션 및 마이크로서비스를 만들 수 있다. Kafka 커뮤니티에서는 Java, Scala, Go,Python, C/C++ 등 다양한 언어 기반의 Kafka 클라이언트 라이브러리를 제공하고 있다.

KAFKA의 주요개념 및 용어

이벤트(event): 이벤트는 발생한 일에 대한 기록으로, ‘레코드’ 또는 ‘메시지’라고도 한다. Kafka에서는 이벤트 형태로 데이터를 읽거나 쓴다. 이벤트에는 키, 값, 타임스탬프 및 선택적 메타데이터 헤더가 포함된다.

프로듀서(producer)와 컨슈머(consumer): 프로듀서와 컨슈머는 모두 Kafka 클라이언트다. 프로듀서는 Kafka에 이벤트를 발행하며, 컨슈머는 프로듀서가 발행한 이벤트를 구독해서 읽고 처리한다. Kafka에서 프로듀서와 컨슈머는 서로 완전히 분리되어 있는데,(SoC) 이는 Kafka가 높은 확장성을 달성할 수 있는 핵심 요인이다.(프로듀서는 컨슈머가 메시지를 수신하는 것을 기다릴 필요 없다) Kafka가 이벤트를 처리하는 데 있어서 몇 가지를 보장하도록 설정할 수도 있다.(이벤트는 최소한 한 번 이상 처리된다.)

Untitled 1

토픽(topic): 이벤트가 저장되는 공간이다. 토픽은 관련 이벤트를 그룹화하고 영구적으로 저장한다. 매우 단순하게 보면, 토픽은 파일 시스템의 폴더고, 이벤트는 해당 폴더의 파일이다. 위에서 하나의 토픽에 여러 프로듀서가 이벤트를 발행할 수 있고, 여러 컨슈머가 하나의 토픽을 구독해서 이벤트를 읽을 수 있다. 기존 메시징 시스템과 달리 이벤트는 소비 후 삭제되지 않기 때문에 토픽 의 이벤트는 필요한 만큼 여러 번 읽을 수 있다. Kafka는 토픽 별로 이벤트 유지 기간을 설정할 수 있고, 해당 기간이 지나면 이벤트는 자동으로 삭제된다. 토픽 이름 자체가 고유한 식별자로 기능한다.

파티션(partition): Kafka의 토픽은 여러 파티션으로 나눠진다. 토픽이 Kafka의 논리적 개념이라면, 파티션은 토픽에 속한 이벤트가 저장되는 가장 작은 물리적 저장 단위다. 파티션에 저장되는 이벤트를 레코드라고 부르며, 토픽을 생성할 때 파티션 수를 지정할 수 있다.

오프셋(offset): 파티션의 레코드에는 오프셋이라는 파티션 내에서 고유하고 순서 정보를 가진 식별자가 할당된다. 오프셋은 변경 불가능한 숫자로 Kafka에서 관리되며, 무한하게 증가한다. 오프셋 값의 순서는 파티션 내에서만 보장되고, 토픽의 전체 파티션 대상으로는 순서가 보장되지 않는다.

KAFKA의 Broker란?

Untitled 2

Kafka 클러스터는 하나 이상의 브로커 서버로 구성된다. 브로커는 여러 토픽을 갖고 있는 컨테이너로, 토픽은 여러 파티션을 가질 수 있다. 클러스터의 브로커는 정수 번호로만 식별된다. Kafka 브로커는 부트스트랩 브로커라고도 한다. 하나의 브로커와 연결되면 전체 클러스터와 연결되기 때문이다. 브로커가 전체 Kafka 데이터를 포함하지는 않지만, 클러스터의 각 브로커는 다른 모든 브로커와 해당 브로커가 가진 파티션 및 토픽에 대해 알고 있다.

Untitled

예를 들어 Broker 1, Broker 2, Broker 3 세 개의 브로커로 구성된 Kafka 클러스터를 가정해보자. 각 브로커는 Topic-x라는 토픽을 갖고 있다. Topic-x의 모든 파티션은 하나의 브로커에만 속하지 않고, 여러 브로커에 분산된다. 브로커 1과 브로커 2에는 Topic-y가 포함되어 있는데, Topic-y는 파티션 수가 2개이기 때문에 두 개의 브로커에만 분산된 것이다. 즉 브로커 번호와 파티션 번호 사이에는 어떠한 관계도 존재하지 않는다는 것을 알 수 있다.

KAFKA의 Client_API

Producer API: 하나 이상의 토픽에 이벤트를 발행하는 프로듀서 클라이언트를 만들고 싶을 때. Kafka에 데이터를 write 하는 가장 낮은 수준의 API

Consumer API: 하나 이상의 토픽을 구독하고, 가져온 이벤트 스트림을 처리하는 컨슈머 클라이언트를 만들고 싶을 때. Kafka로부터 데이터를 read 하는 가장 낮은 수준의API

Streams API: kafka에 대한 입력 출력을 stream 으로 처리하는 API. producer, consumer 를 내부적으로 이용하고, 더 추상화된 고수준의 API를 제공

Connector API: 기존 데이터 시스템 또는 애플리케이션과 Kafka 사이의 데이터 이동을 쉽게 할 수 있도록 제공하는 고수준의 API. Connector의 목적은

Consumer/Producer 클라이언트를 만들지 않고도 쉽게 Kafka와 외부 시스템 간에 데이터 스트리밍을 할 수 있도록 돕는 것.

KAFKA 클러스터 설치

Kafka 브로커 3개로 Kafka 클러스터를 구축해보자. 일반적으로 Kafka는 Zookeeper를 사용하여 Kafka 클러스터에 대한 모든 메타데이터 정보를 저장하고 관리하며, Zookeeper를 모든 Kafka 브로커 또는 서버를 관리하고 구성하는 중앙 집중식 컨트롤러로 사용한다. 그러나 최신 Kafka 버전에서는 모든 서버 구성 정보를 Zookeeper에 저장하는 대신 Kafka 서버 내부의 토픽 파티션으로 저장할 수 있다. Zookeeper 없이 Kafka를 시작하려면 KRaft와 같은 Kafka Raft 메타데이터 모드로 Kafka를 실행해야 한다.

다음 글에서는 EC2환경에서 브로커 3개를 이용하여 카프카 클러스터를 구성 및 실행하여, 리더노드 및 팔로워 노드가 제대로 작동하는지 확인해보며, 간단한 스크립트를 통해 Producer와 Consumer를 실습해보면서 작동원리를 확인해보자.

댓글남기기