Kafka란?

Apache Kafka는 실시간으로 스트리밍 데이터를 수집하고 처리하는 데 최적화된 분산 데이터 스토어이다. 스트리밍 데이터는 수천 개의 데이터 원본에서 연속적으로 생성되는 데이터로 보통 데이터 레코드를 동시에 전송하는데, 스트리밍 플랫폼은 이러한 지속적인 데이터 유입을 처리하고 데이터를 순차적이고 점진적으로 처리해야 한다.

카프카의 탄생 배경

기존 데이터 시스템의 문제점

각 애플리케이션과 DB가 end-to-end 로 연결되어 있고(각 파이프라인 파편화), 요구사항이 늘어남에 따라 데이터 시스템 복잡도가 높아지면서 다음과 같은 문제가 발생하게 되었다.

시스템 복잡도 증가 (Complexity)
- 통합된 전송 영역이 없어 데이터 흐름을 파악하기 어렵고, 시스템 관리가 어려움
- 특정 부분에서 장애 발생 시 조치 시간 증가 (연결 되어있는 애플리케이션들을 모두 확인해야 하기 때문)
- HW 교체 / SW 업그레이드 시 관리포인트가 늘고, 작업시간 증가 (연결된 애플리케이션에 side effect가 없는지 확인해야 함)
데이터 파이프라인 관리의 어려움
- 각 애플리케이션과 데이터 시스템 간의 별도의 파이프라인 존재하고, 파이프라인 마다 데이터 포맷과 처리 방식이 다름
- 새로운 파이프라인 확장이 어려워지며 확장성 및 유연성이 떨어짐
- 데이터 불일치 가능성이 있어 신뢰도 감소

이러한 문제를 해결하기 위해 새로운 시스템의 개발 필요성이 높아졌고, 다음과 같은 목표를 가지고 새로운 시스템을 개발했다.

모든 시스템으로 데이터를 전송할 수 있고, 실시간 처리도 가능하며, 급속도로 성장하는 서비스를 위해 확장이 용이한 시스템을 만들자!

Kafka의 주요 기능

레코드 스트림 게시 및 구독
레코드가 생성된 순서대로 레코드 스트림을 효과적으로 저장
레코드 스트림을 실시간 처리 Kafka는 데이터 스트림에 적응하는 실시간 스트리밍 데이터 파이프라인과 애플리케이션을 구축하는 데 주로 사용된다. 메시징, 스토리지, 스트림 처리를 결합해 과거 및 실시간 데이터 모두의 저장 및 분석을 허용한다.

카프카 구성 요소

Topic

각각의 메시지를 목적에 맞게 구분할 때 사용한다.
메시지를 전송하거나 소비할 때 Topic을 반드시 입력한다.
Consumer는 자신이 담당하는 Topic의 메시지를 처리한다.
한 개의 토픽은 한 개 이상의 파티션으로 구성된다.

Partition

분산 처리를 위해 사용된다.
Topic 생성 시 partition 개수를 지정할 수 있다. (파티션 개수 변경 가능. *추가만 가능)
파티션이 1개라면 모든 메시지에 대해 순서가 보장된다.
파티션 내부에서 각 메시지는 offset(고유 번호)로 구분된다.
파티션이 여러개라면 Kafka 클러스터가 라운드 로빈 방식으로 분배해서 분산처리되기 때문에 순서 보장 X
파티션이 많을 수록 처리량이 좋지만 장애 복구 시간이 늘어난다.

Offset

컨슈머에서 메세지를 어디까지 읽었는지 저장하는 값
컨슈머 그룹의 컨슈머들은 각각의 파티션에 자신이 가져간 메시지의 위치 정보(offset) 을 기록
컨슈머 장애 발생 후 다시 살아나도, 전에 마지막으로 읽었던 위치에서부터 다시 읽어들일 수 있다.

Producer

메시지를 만들어서 카프카 클러스터에 전송한다.
메시지 전송 시 Batch 처리가 가능하다.
key값을 지정하여 특정 파티션으로만 전송이 가능하다.
전송 acks값을 설정하여 효율성을 높일 수 있다.
- ACKS=0 -> 매우 빠르게 전송하며 파티션 리더가 받았는 지 알 수 없음
- ACKS=1 -> 파티션 리더가 받았는지 확인하며, 기본값
- ACKS=ALL -> 파티션 리더 뿐만 아니라 팔로워까지 메시지를 받았는지 확인

Consumer

카프카 클러스터에서 메시지를 읽어서 처리한다.
메세지를 Batch 처리할 수 있다.
한 개의 컨슈머는 여러 개의 토픽을 처리할 수 있다.
메시지를 소비하여도 메시지를 삭제하지는 않는다. (Kafka delete policy에 의해 삭제)
한 번 저장된 메시지를 여러번 소비도 가능하다.
컨슈머는 컨슈머 그룹에 속한다.
한 개 파티션은 같은 컨슈머그룹의 여러 개의 컨슈머에서 연결할 수 없다.

Broker

실행된 카프카 서버를 말한다.
프로듀서와 컨슈머는 별도의 애플리케이션으로 구성되는 반면, 브로커는 카프카 자체이다.
Broker(각 서버)는 Kafka Cluster 내부에 존재한다.
서버 내부에 메시지를 저장하고 관리하는 역할을 수행한다.

Zookeeper

분산 애플리케이션 관리를 위한 코디네이션 시스템
분산 메시지큐의 메타 정보를 중앙에서 관리하는 역할

주요 설계 특징

왜 하나의 topic을 여러개의 partition으로 분산시키는가?

병렬로 처리하기 위해 분산저장한다. 카프카의 토픽에 메세지가 쓰여지는 것도 어느정도 시간이 소비된다. 몇 천건의 메세지가 동시에 카프카에 write 되면 병목현상이 발생할 수 있다. 따라서 파티션을 여러개 두어서 분산 저장함으로써 write 동작을 병렬로 처리할 수 있다.

다만, 한번 늘린 파티션은 절대 줄일 수 없기 때문에, 운영 중 파티션을 늘려야 하는건 충분히 검토 후 실행되어야 한다. (최소한의 파티션으로 운영하고 사용량에 따라 늘리는 것을 권장) 파티션을 늘렸을 때 메세지는 Round-Robin 방식으로 쓰여진다. 따라서 하나의 파티션 내에서는 메세지 순서가 보장되지만, 파티션이 여러개일 경우에는 순서가 보장되지 않는다.

컨슈머 그룹은 왜 존재할까?

consumer의 묶음을 consumer group이라고 한다. 컨슈머 그룹은 하나의 topic에 대한 책임을 갖고 있다. 즉, 어떤 consumer가 down된다면 파티션 재조정(리밸런싱)을 통해 다른 컨슈머가 해당 파티션의 sub을 맡아서 한다. offset 정보를 그룹간에 공유하고 있기 때문에 down 되기 전 마지막으로 읽었던 메세지 위치부터 시작한다.

Judy's Devlog

Kafka를 자세히 공부해보자