01. Kafka의 시작

00) 시작하기 전에

아파치 KAFKA 를 이해하기 위해서는 이벤트의 대한 이해가 필요합니다. 이에 따라 이벤트의 대한 개념을 설명하고, 뒤에 설명을 드리겠습니다.

(01) 이벤트란(Event) ?

이벤트란, 시스템 상 혹은 비즈니스 상 발생되는 모든 데이터를 이야기 합니다.
-> 일반적으로, 우리가 생각하는 클릭도 이벤트에 해당하고, 키보드의 키를 누르는 행위도 이벤트에 해당 합니다.

(02) 이벤트 스트림 이란 ?

이벤트 스트림은 이벤트의 흐름 즉, 데이터가 이동하는 것을 이야기 합니다.

예를 들자면, 키보드를 200타를 치는 사람은 1분에 이벤트를 200타를 발생 시킬 수 있습니다. 이런 데이터는 1분에 200건의 이벤트 스트림이 발생한다고 볼 수 있습니다.

(03) 메세지 큐 시스템(MQ)

메세지 큐는 서버와 클라이언트 간의 통신을 돕기 위해 만들어 졌습니다. 기본적으로 클라이언트는 서버가 정상적으로 데이터를 수신 했다고 하기 이전까지는 데이터를 지니고 있어야 합니다. 그러다 보니 서버의 부하가 있는 경우 클라이언트는 요청이 실패하여, 데이터를 보관하고 있어야 하는 단점이 있었습니다.

이를 극복하기 위해, 클라이언트와 서버 사이에 주고 받는 데이터를 보관할 수 있는 메세지 큐를 만들었습니다. 서버와 클라이언트는 요청을 직접 받지 않고, 메세지 큐에 대상에게 보낼 데이터를 넣거나, 자신에게 온 데이터를 보면서 처리할 수 있도록 하였습니다.

이를 통해, 지연이 있는 상황에서도, 클라이언트 서버 모두 상대가 응답하지 않아 대기 상태로 있지 않게 할수 있습니다.
또한, 메세지 큐의 경우 여러 서버에서 동시에 사용가능하니, 처리하는 서버에 직접적인 확장 없이 많은 데이터를 처리 할 수 있게 되었습니다.

01) Apahce Kafka 탄생 배경

카프카를 개발한 링크드인은 아래와 같은 상황을 가지고 있었습니다.

[상황 ]
1. 하루 5 조개 이상의 이벤트 스트림* 처리가 필요
2. 하루 3,000억 개 이상의 사용자 관련 이벤트 스트림* 처리 필요

[ 문제 ]
기존 MQ 서비스(메세지 큐)*의 경우 대용량 데이터 처리시, 지연시간의 상승으로 실시간 데이터 처리가 어려워 졌습니다.

[해결]

자체적으로 이벤트를 처리할 수 있는 솔루션을 만들고자 하였고, 그 결과 카프카가 탄생 하였습니다.

02) Kafka 란 ?

Apache Kafka 는 대용량 Event Streaming(이벤트 스트리밍)을 처리하기 위한 플랫폼 입니다.
(쉽게 이야기 해서는 움직이는 데이터를 처리하기 위한 플랫폼 이라고 보시면 됩니다. )

[출처] https://developer.confluent.io/patterns/event-stream/event-stream/

03) Kafka 의 특징

1. 이벤트 스트림을 안전하게 주고 받을 수 있도록 구성 하였습니다.
2. 이벤트 스트림을 디스크에 저장 합니다.
   -> 메세지 큐의 경우, 메모리 상에서 저장하기에 용량과 비용적으로 고비용이 소모 되었습니다.
   그렇기에, 대용량 데이터를 처리 하기에는 적합하지 않았습니다.
   이를 극복 하기 위해, HDD 를 이용한 메세지 큐를 만들어 내었습니다.
   (참고로, HDD의 속도는 메모리 보다 느리긴 하지만, 데이터를 순차 저장 함으로써, 하드 디스크 속도를 극대화 시켰습니다. )
3. 이벤트 스트림 분석 및 처리
   ( 현재 전송되고 있는 데이터 들을 분석하고, 처리가 가능해 졌습니다. )

04) 기존 메세지 큐보다 얼마나 좋아 졌는가 ?

출처 : confluent.io

기존에, 주로 많이 사용되던 RabbitMQ 의 경우 대용량 데이터 처리는 지원되지 않아, 30 MB 까지 제한된채 사용 되었습니다.
크지 않은 데이터에서는 RabbitMQ가 메모리를 사용하기에 속도가 좋았지만, 대용량 데이터를 지원하지 못하였고, 대용량 데이터를 지원하는 플랫폼 에서는 Kafka가 빠르게 처리할 수 있음 확인할 수 있었습니다.

02. Apache Kafka에서 사용되는 용어 개념

01) Topic, Producer, Consumer

(01) Topic

Kafka 안에서 메세지가 저장되는 장소의 논리적인 표현
– 쉽게 이야기하면, 그냥 메세지를 저장할때 분류로 정하는 개념과 동일 합니다. 예를 들자면, 쇼핑몰에서 나눈다면 결제 모듈, 장바구니 모듈, 상품 모듈 등으로 구분 지어 놓는 기준 입니다.

(02) Producer

메세지를 생산하는 생산자 입니다. ( 클라이언트가 요청을 보낸다고 보셔도 됩니다. )
(데이터의 변화가 발생하면 이 이벤트를 Kafka 측에 보내는 역할을 합니다. )

(03) Consumer

메세지를 가져와 활용하는 소비자를 이야기 합니다.
(자신이 참고해야하는 메세지를 보고 메세지를 소비합니다. )

(04) Consumer Group

동일한 데이터를 처리할 수 있는 Consumer 서버가 2대 이상인 경우, 이를 그룹화 하는 것을 이야기 합니다. 이를 통해, 자신에게 할당된 메세지를 분산 병렬 처리 할수 있게 됩니다.

02) Commit Log, Offset , Log-END-OFFSET 등 Offset

(01) Commit Log

우리가 흔히 생각하는 Git 과 같은 형상관리의 Commit Log 와 동일한 개념입니다. 다만, 코드가 아닌 이벤트를 저장하고 기록하는 로그 입니다. 그리고, 커밋 로그는 기본적으로, 변경이 불가능한 데이터 구조를 지니고 있습니다.

(02) Offset

offset 은 말그대로 거리 차이를 의미 합니다. 일반적으로 Offset 이란 단어로만 사용 되는 경우 로그의 시작점 부터 끝점 까지의 차이 거리를 이야기 합니다.

(03) Log-end-offset

말 그대로, 로그의 마지막 위치 입니다. 로그는 기본적으로 생산자에 의해 쓰여지기 때문에, 생산자가 마지막으로 등록한 이벤트의 위치라고 이해하시면 됩니다.

(04) Current-offset

Consumer 가 읽는 로그의 위치를 이야기 합니다.

(05) Consumer-Lag

[ 마지막 커밋 위치 – 현재 소비하고 있는 위치의 차이를 이야기 합니다.

03) Topic, Partition, Segment

(01) Topic

Kafka 안에서 메세지가 저장되는 장소의 논리적인 표현
– 쉽게 이야기하면, 그냥 메세지를 저장할때 분류로 정하는 개념과 동일 합니다. 예를 들자면, 쇼핑몰에서 나눈다면 결제 모듈, 장바구니 모듈, 상품 모듈 등으로 구분 지어 놓는 기준 입니다.

(02) Partition

앞서 배운 Commit Log 와 동일한 개념 입니다. 1개의 토픽은 여러개의 파티션을 구성할 수 있습니다.
(일반적으로, 토픽은 여러개의 파티션을 무조건 구성하게 됩니다. 이유는, Multi Partition 을 구성하면, 데이터의 병렬 처리가 가능해지기 때문입니다. )

• 카프카의 데이터를 저장하는 서버(Broker)는 여러대가 될 수 있습니다. 이때, 파티션을 여러개로 분할 하면, 여러개의 서버에 파티션이 분산 저장되는 효과도 있습니다. (동일한 데이터를 가지는 개념은 아니며, 같은 Topic 의 데이터 이지만 여러 곳에 저장된다고 보시면 됩니다. )

(03) Segment

메세지(데이터)가 저장되는 실제 물리적인 파일을 이야기 합니다.

• Segement 의 분할 기준 ( Rolling Strategy [롤링 정책] )
  • log.segment.bytes [기본 1 GB] : 메세지 파일의 크기가 1 GB 가 되면 다음 파일로 넘어간다
  • log.roll.hours [기본 168 시간] : 메세지의 시간이 168시간이 되면 다음 파일로 넘어 간다. ( 일반적으로 많이 사용 )

04) Broker , Zookeeper/Kraft

(01) Broker

브로커는 Kafka를 구성하는 서버를 이야기 합니다. (실제로는 Partition 에 대한 Read / Write 를 관리하는 SW 를 이야기 합니다. )

(02) Kafka Cluster

여러대의 브로커를 묶어 놓은 것을 이야기 합니다. 기본적으로, Cluster 를 설정하기 위해서는, 3대 이상의 서버를 묶어야 하며 4대 이상을 권장하는 편 입니다.

(03) Bootstrap Server

부트스트랩의 용어는 굉장히 모호한 개념이지만, Kafka 에서는 Kafka 클러스터 중 서버 1대에 만 연결해도 전체 서버가 연결되도록 해준다는 개념으로 사용 되고 있습니다.
(그렇기에, 클라이언트 입장에서는 1대의 서버 접속 정보만 알고 있어서 클러스터에 접근할 수 있다는 장점이 있지만, 해당 서버가 장애가 발생할 것을 대비하여, 클러스터 전체의 정보를 가지고 있는 것이 좋습니다. )

(04) Zookeeper

Zookeeper 는 브로커들을 관리하는 소프트웨어 입니다.
Zookeeper는 원래 분산형 서버들의 설정 정보를 유지하고, 분산 동기화 서비스를 제공 하였습니다.

그렇기에 Kafka 는 초기 클러스터 유지 관리를 위해, Zookeeper 를 통해 구성하였습니다.
( 하지만, Zookeeper 를 사용하면서, 클러스터의 대한 최적화 부분이나, 메타 데이터 들이 카프카 클러스터 외부로 노출 되는 점등이 있어, KIP-500 [카프카 개선 요청] 을 통해서, Zookeeper 를 대체할 Kraft 가 개발 되었고, 2022년 때 배포 되었습니다. 다만, 현재는 Zookeeper의 기능 보다 부족한 부분이 있어, 2024년에 출시될 4.0 버전 부터 완전히 대체될 예정입니다. )

KRAFT 설명 주소