Why ?
- 성능 관점이라기 보다는 다양한 분산 시스템에서 데이터 제어에 적합해 보여서 공부 시작.
- http 보다는 메시지 기반 통합
- 순차처리, 펍섭, 큐잉 등 다양한 기능이 있는것으로 보임
- Kafka as a Storage System 의 관점에서
왜 카프카를 알아야 하는가?
- 링크드인이 rabbitmq, redis 등을 이용하여 분산환경 데이터 흐름을 제어하는데 유지보수에 어려움을 느껴 카프카를 만들었다고 함. 데이터를 중앙관리하기 위함
-
카프카 왜 잘되나?
-
- 성능 좋음(분산/병렬처리, 실시간성)
-
- 확장성 뛰어남( 브로커 수평확장 가능, fault tolerant )
-
- undeleted log ( 컨슈머가 데이터 처리하더라도 큐에서 제거되지 않음 )
- 꼭 데이터 많은 데이터를 처리하기 위한것은 아니다. 데이터 양이 적어도 카프카를 사용해도 좋다.
- 카프가 생태계 계속 성장 중이다
사례와 대표적 기능
메시지 큐, 로그 수집, ETL(Extract / Trnasform / Load ) 등의 대체제
- 데이터 허브 : 여러 시스템 사이에서 데이터를 상호 교환
- 로그 수집 : 여러 서버에서 생성된 로그를 수집하고 축적할 곳에 연결
- 웹 활동 분석 : 실시간 대시보드와 이상 탐지/부정 검출 등 활동을 파악
- 사물인터넷: 센서등 다양한 디바이스 데이터 수신 후 송신
- 이벤트 소싱: CQRS 방식으로 대량의 이벤트를 유연하게 처리
기술 정리 내용
Topic
- 파일시스템의 폴더와 유사 이름을 가질 수 있다.
- 목적별로 토픽을 나누면 됨.
Partition
Producer
- 토픽에 메시지 생성, 처리 실패/재시도 가능
- kafa clients 라이브러리를 통해 사용가능. 다만 브로커와 클라이언트 하위호환 조심할것.
- 카프카 브로커의 주소목록은 2개이상의 아이피와 포트를 설정하여 고가용성을 확보하는게 좋음
- 프로드셔에서 레코드에 키 해슁되어 파티셔닝에 사용된다.
Broker, Replication, ISR
Consumer
- 카프카는 컨슈머가 데이터를 가져가더라도 데이터가 브로커(토픽)에서 빠지지 않음.
- 데이터를 가져오는 것을 폴링(polling)이라고 한다.
- 데이터를 가져오고, Partiion 의 offset 위치를 기록(commit ) 하며, Consumer Group 을 통해 병렬 처리 가능
- 프로듀서와 마찬가지로 kafa clients 라이브러리를 통해 사용가능. 다만 브로커와 클라이언트 하위호환 조심할것.
- polling loop 는 보통 while(true) 에 cousumer.poll(waiting).
- 처리는 단위는Record
- 파티션 내의 데이터는 컨슈머 그룹별로/토픽별로/파티션별로 offset number 를 갖게됨. 결국 컨슈머가 어디까지 데이터를 읽었느냐의 문제. 컨슈머가 이슈가 발생하더라도, 처리하던 offset 이후부터 다시 실행. 즉 컨슈머 처리 롤백이 가능함. 즉 메시지 가져갔다가 처리가 잘 안되면 offset commit 구조로 재시도 가능.
-
컨슈머 그룹이 같을 때

- 파티션보다 컨슈머가 많을 때, 컨슈머는 동작하지 않는다. 파티션에 동시에 여러 컨슈머가 붙을수 없다. ( 컨슈머 1개 파티션2개 ⇒ 가능, 컨슈머 3개 파티션 3개 ⇒ 1개 컨슈머 논다 )
-
컨슈머 그룹이 다를 떄

Consumer Lag
- 파티션안에서 프로듀서가 마지막으로 넣은 offset 과 컨슈머가 마지막으로 읽은 offset 의 차이를 기반으로 함
- 토픽의 여러 파티션이 존재할 경우, 파티션마다 랙이 여러개임. records-lag-max 가 파티션 여러개중 가장 높은 것. 컨슈머의 성능 모니터링에 lag 을 잘 살펴야 함. burrow 같은 lag checking 모니터링 라이브러리 있음.
via Queuing / Pubsub
- 큐잉과 펍섭 이 둘의 특징을 겸비한 형태로 만들어졌음.
카프카 데이터 영속화의 목적 ( 디스크에 메시지 저장함 )
- 고장에 의한 최근 메시지 손실 회피 목적으로 영속화하는 것은 아니다. 브로커 메모리에 메시지가 들어가면 송신완료로 간주하는 특성을 보면 잘 알 수 있다. ( 메모리에서 디스크 장애났을 때를 보호하기 위해 저장하는 뜻이 아님 )
전달보증
- At most one, At least one, Exactly One 다양하게 신뢰성과 성능의 tradeoff 옵션을 제공.
- 처음에는 트랜잭셔널 모델이 카프카에 없었으나, Exactly One 을 지원하면서 결국 트랜잭션 개념이 도입됨.
CQRS 와 카프카
- 이벤트 소싱이란 상태변화 하나하나를 이벤트로 취급하여 순서대로 기록. 마치 디비 트랜잭션 로그 같은 것. 카프카 메시지는 순차적으로 기록되기 때문에 이벤트소싱에 적합하다.
- CQRS(커맨트 쿼리 책임 분리)란 데이터 갱신과 문의 처리를 분리하는 개념이다. 제공하는 서비스에 따라 기록과 읽기의 액세스 패턴이 크게 다를 수 있다. 또한 기록되는 데이터는 동일하더라도 그 데이터를 여러 목적으로 사용하고 싶은 경우도 있다.
Stream
- 스트림 처리는 실시간으로 셍성되는 데이터를 순차적으로 처리하는 방식.
- 실시간 생성 데이터를 스트림 데이터라고 부르기도 한다. 가령 클릭로그, 센서데이터 측정된 데이터 등 스트림 데이터의 경우 대게 작은 단위로 지속적으로 보낸다 스트림
데이터 허브 with Kafka Connect
Kafka connect란
- 다른 시스템과의 데이터 연계에 사용한다. 카프카에 데이터를 넣거나, 데이터를 추출하는 과정을 간단히 하기 위해 만들어졌다.
- 데이터를 넣는 프로듀서 쪽 커넥터를 소스(source)라 부르고, 데이터를 출력하는 컨슈머 쪽의 커넥터를 싱크(sink)라고 한다. 이런 커넥터로 입출력을 손쉽게 할 수 있다.
참고자료