1. 카프카의 탄생
- 데이터를 생성하는 소스 애플리케이션과 최종적으로 데이터가 적재되는 타깃 애플리케이션의 연결을 위해 탄생
- 소스 어플리케이션과 타깃 어플리케이션의 개수가 많아짐에 따라 파이프라인이 복잡해짐
- 각각의 어플리케이션을 따로따로 연결하는 것이 아닌 카프카를 통해 한 곳에 데이터를 모아서 데이터를 처리할 수 있도록 중앙집중화함
2. 카프카의 내부 구조
프로듀서가 토픽의 특정 파티션으로 레코드를 차례대로 적재
컨슈머가 토픽의 여러 파티션을 구독하여 먼저 들어온 순으로 레코드를 가져감
토픽
- DB의 테이블과 같은 개념
- 데이터의 구분에 따라 토픽을 운영
파티션
- 토픽 안에 1개 이상의 파티션을 가짐
- 데이터가 토픽 안의 하나의 파티션에 저장됨
- 파티션의 내부 구조는 선입선출(FIFO)의 큐(queue) 구조와 동일
- 먼저 들어온 데이터부터 쌓이고, 먼저 들어온 데이터부터 순차적으로 컨슈밍함
프로듀서
- 토픽의 파티션으로 데이터 송신
- 특정 메시지를 보내면 토픽의 여러 파티션 중 하나의 파티션에 저장 (토픽의 모든 파티션에 저장되는 것이 아님)
- 들어온 데이터 순서대로 데이터를 적재
컨슈머
- 토픽의 파티션에 있는 데이터를 소비
- 적재된 순서대로 차례대로 데이터를 가져감
- 컨슈머가 파티션의 데이터를 가져가더라도 데이터는 삭제되지 않음
- 특정 컨슈머가 데이터의 어디까지 읽었는지를 커밋을 통해 기록
브로커
- 한 개의 클러스터는 여러 개의 브로커로 구성
- 각각의 브로커는 카프카 프로세서
- 프로듀서에서 데이터를 전송하면 각각의 카프카 브로커에 데이터 저장
- 프로듀서에서 데이터를 보내면 그 메시지는 모든 브로커에 복제되어 저장됨
3. 카프카의 장점
높은 처리량
- 카프카 브로커로 송신, 브로커에서 데이터 수신 시 모두 묶음 단위로 처리할 수 있도록 배치(batch)로 묶어서 일괄적으로 전송할 수 있는 옵션이 있음
-> 데이터 송신 시 네트워크 통신 횟수를 줄임 - 하나의 파티션에 하나의 컨슈머가 할당되는데, 데이터를 여러 파티션에 분배하도록 파티션을 추가하고 파티션 개수만큼 컨슈머 개수를 늘려 병렬 처리 가능
-> 초당 데이터 처리량 증가
확장성
- 파이프라인 운영 시 데이터의 양을 예측하기 어려움
- 각각의 브로커가 처리할 수 있는 데이터 처리량에 한계가 있음
- 데이터가 적을 때는 카프카 브로커 개수를 줄여 최소한으로 운영 (scale-in)
- 데이터가 많아지면 카프카 브로커 개수를 늘림 (scale-out)
영속성
- 데이터를 파일 시스템에 저장
- 페이지 캐시 메모리 영역을 사용해 한번 읽은 파일 내용은 OS차원의 메모리에 저장해두고 재사용
- 브로커에 장애가 발생해도 재시작하면 파일 시스템의 데이터를 복구시켜 처리할 수 있음
고가용성
- 프로듀서에서 받은 메시지를 여러 브로커에 복제하여 저장
- 카프카 클러스터로 묶인 여러 브로커 중에서 한 대의 브로커에 장애가 발생하더라도 나머지 브로커를 통해 데이터를 가져갈 수 있음
