카프카의 기본 구조

카프카의 기본 구조

---

프로듀서 (Producer)

• 이벤트(메시지)를 카프카 클러스터에 넣는 역할 - 생성자 API

이벤트
기록(record) 또는 메시지(message)라고 한다.
키, 값, 타임스탬프 및 선택적 메타데이터 헤더가 있다.

주키퍼 클러스터 (Zookeeper Cluster)

• 카프카 클러스터를 관리하는 역할 - 커넥터 API
• 새로운 토픽 생성/삭제, 브로커 추가/제거 등을 관리
• 카프카 브로커에서 브로커와 토픽의 메타데이터를 저장하기 위해 사용하는 장치

카프카 클러스터 (Kafka Cluster)

• 이벤트(메시지)를 저장하는 저장소 - Streams API
• 카프카 클러스터는 브로커 서버로 구성되어 있다.

브로커 (Broker)

• 이벤트를 저장하고 있는 스토리지 계층으로 이벤트를 저장, 이중화 처리, 대체 등등을 하는 중앙 시스템이다.
• 브로커는 여러 파티션으로 나뉜 토픽(Topic)을 관리하며, 프로듀서로부터 메시지를 수신하여 해당 토픽의 파티션에 저장한다.
• 최소 3대 이상을 권장하고 있다.

토픽 (Topic)

• 데이터 로그를 관리하는 기준 개념으로 이벤트를 정렬된 방식으로 저장한다.
• 토픽은 메시지를 구분하는 단위로 파일시스템의 폴더와 유사하게 생각하면 된다.
• 한 개의 토픽은 한 개 이상의 파티션으로 구성된다.
• 프로듀서와 컨슈머는 토픽을 기준으로 이벤트를 주고받는다.

파티션 (Partition) = commit log

• 이벤트를 저장하는 물리적인 파일
• 큐와 같이 작동한다.
• 파티션은 추가만 가능한(append-only) 파일
• 각 이벤트 저장 위치를 offset이라고 한다. (offset = index 개념?)
• 프로듀서가 넣은 이벤트를 파티션의 맨 뒤에 추가
• 컨슈머는 오프셋 기준으로 인벤트를 순서대로 읽는다. (옵션으로 특정 파티션의 순서부터 순차적으로는 가능하다.)
• 사용된 이벤트는 바로 삭제되지 않는다. (설정에 따라 일정 시간이 지난 뒤 삭제)

컨슈머 (Consumer)

• 이벤트를 카프카 클러스터에서 읽는 역할 - 소비자 API
• 컨슈머는 브로커로부터 메시지를 읽어와서 처리하거나 외부 시스템으로 전달할 수 있다.

기본적인 흐름은 프로듀서에서 이벤트를 카프카 클러스터의 브로커로 전송을 하면 해당 토픽의 파티션에 저장을 하고, 컨슈머는 구독하고 있는 토픽의 파티션에서 저장된 이벤트를 처리를 한다.
기본적인 흐름은 대략적으로 알았고 하나하나의 기능이나 작동들을 여러 가지로 확인을 해봐야겠다.