kafka 기본 개념

브로커

- 카프카 클라이언트와 데이터를 주고받기 위한 주체 

- 데이터를 분산 저장하여 fault tolerance 유지해주는 애플리케이션

- 실 운영 환경에서는 3대 이상의 브로커를 1개의 클러스터로 묶어 운영해야 함 

---

데이터 저장, 전송 

- 프로듀서가 브로커로 데이터를 전송 

- 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 저장

- 컨슈머가 데이터를 요청하면 브로커는 파티션에 저장된 데이터를 전송 

 

일반적인 메시지 큐잉 서비스는 큐에 저장된 데이터 전송하면 해당 메시지는 삭제되지만, kafka는 파일 시스템을 이용하기 때문에 설정한 유지 기간 (retention.ms 등) 동안 파일 시스템에 메시지가 저장됨. 

하지만 페이지 캐시를 사용해 디스크 입출력 속도를 높혀 파일 시스템을 통한 I/O에 대한 속도 문제를 해결함. 

또한 이런 특징으로 브로커 실행 시, 힙 메모리를 크게 설정할 필요가 없음 (리소스 절약)

---

데이터 복제, 싱크

- 데이터 복제는 파티션 단위로 이루어짐. (클러스터링된 서로 다른 브로커 간의 동일 토픽, 동일 파티션끼리 복제가 이루어짐) 

- 복제 최소 개수는 1 (복제 없음), 최대 개수는 브로커 개수 

- 파티션은 리더와 팔로워로 구성 

- 프로듀서, 컨슈머와 직접 통신하는 파티션을 리더, 복제 데이터를 갖는 파티션을 팔로워 

- 리더 파티션을 갖는 브로커가 다운되면, 팔로워 파티션을 갖는 다른 브로커가 리더 파티션을 갖게 됨

---

컨트롤러

- 클러스터의 브로커 중 하나가 컨트롤러 역할 

- 다른 브로커들의 상태를 체크하고, 브로커가 클러스터에서 빠질 경우, 해당 브로커에 존재하는 리더 파티션을 재분배함

- 컨트롤러 역할을 하는 브로커에 장애 발생 시, 다른 브로커가 컨트롤러 역할을 수행함

---

데이터 삭제

- 컨슈머가 데이터를 가져가더라도 토픽 내의 데이터는 삭제되지 않음

- 컨슈머, 프로듀서가 데이터 삭제를 요청할 수 없음

- 브로커만 데이터 삭제할 수 있으며, 데이터 삭제는 파일 단위(로그 세그먼트)로 이루어짐 

- 브로커에 설정된 log.segment.bytes, log.segments.ms 옵션 값 도달 시, 세그먼트 파일이 닫힘 (기본값 : 1GB) 

- 닫힌 세그먼트 파일은 log.retention.bytes, log.retention.ms 옵션 값 도달 시 삭제됨

- 닫힌 세그먼트 파일을 체크하는 간격은 log.retention.check.interval.ms 간격으로 수행 

---

컨슈머 오프셋 저장 

- 컨슈머 그룹이 데이터를 가져가서 처리하고, 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋 값을 브로커에 커밋함

- 커밋한 오프셋은 __consumer_offsets 토픽에 저장됨 

- 저장된 오프셋을 토대로 컨슈머 그룹은 다음 레코드를 가져감

---

코디네이터 

- 클러스터 내의 브로커 중 하나는 코디네이터 역할을 수행

- 컨슈머 그룹의 상태를 체크하고, 파티션을 컨슈머와 매칭되도록 분배하는 역할 

- 파티션을 컨슈머로 재할당하는 과정 : 리밸런스 (rebalance) 

---

주키퍼 (zookeeper) (kafka 3.5 버전 이후로 kraft 정식 지원. 해당 부분은 추후 공부 예정) 

- kafka의 메타데이터 관리에 사용 

- 클러스터로 묶인 브로커들은 동일 경로의 주키퍼를 바라보게 해야 정상 동작함 

- 2개 이상의 kafka 클러스터 구축 시, 주키퍼의 서로 다른 znode에 클러스터들을 설정하면 됨 (root znode 대신, 한 단계 아래의 znode를 브로커 옵션으로 지정해야 함) 

- ex. 파이프라인용 카프카 클러스터 : zookeeper.connect=localhost:2181/pipeline

- ex. 실시간 추천용 카프카 클러스터 : zookeeper.connect=localhost:2181/recommend 

---

토픽, 파티션 

- kafka에서 데이터를 구분하기 위해 사용하는 단위 

- 1개 이상의 파티션을 소유 

- 파티션에 저장되는 데이터를 레코드(record)라 부름 

- 레코드는 오프셋, 메시지 키, 메시지 값 등으로 구성 

- 파티션은 kafka 병렬 처리의 핵심. 컨슈머 그룹이 레코드를 병렬로 처리하도록 매칭됨 

- 컨슈머의 처리량이 한정된 상황이라면, 컨슈머 개수 / 파티션 개수를 늘려 스케일 아웃을 통해 병렬 처리하면 처리량이 증가됨 

- 파티션은 큐 구조로, 먼저 들어간 레코드는 컨슈머가 먼저 가져감

- 레코드는 컨슈머가 가져가더라도 삭제되지 않기 때문에, 다른 목적을 가진 컨슈머 그룹들이 레코드를 여러 번 가져갈 수 있음 

---

토픽 이름 조건 

- 빈 문자열은 안 됨 

- 마침표로만 구성 안 됨

- 249자 미만 

- 영어 대소문자, 숫자, 마침표, 언더바, 하이픈 조합 

- 카프카 내부 로직 관리를 위한 토픽과 동일 이름으로는 생성 불가 (__consumer_offsets, __transaction_state)

- 마침표와 언더바 동시에 들어가면 안 됨 

- 기존 토픽에 대해 마침표, 언더바를 서로 바꾸기만 새로운 토픽은 생성 불가 (to.pic 존재 시, to_pic 생성 불가) 

---

토픽 템플릿

- 데이터베이스 테이블 역할하므로 이름이 중요

- 소문자와 구분자 (., _, -) 조합으로 보통 사용

- <환경>.<팀-명>.<애플리케이션-명>.<메시지-타입> (ex. prd.marketing-team.sms-paltform.json)

- <프로젝트-명>.<서비스-명>.<환경>.<이벤트-명> (ex. commerce.payment.prd.notification)

- 위와 같이 개발 및 서비스 환경에 맞게 토픽 이름 정하는 것이 중요 

- 토픽 이름은 생성 후, 변경이 안 되므로, 신중하게 결정해야 함 

---

레코드 

- 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성 

- 프로듀서가 생성한 레코드가 브로커로 전송되면, 오프셋과 타임스탬프가 지정되어 저장됨 

- 파티션에 기록된 레코드는 수정 불가능하고, 브로커에 의한 강제 삭제 / retention 옵션에 의한 삭제만이 가능 

- 기본적으로 프로듀서가 레코드를 생성한 시점의 유닉스 타임이 타임스탬프로 지정

- 임의로 타임스탬프 지정 또는 파티션 적재 시점을 타임스탬프로 지정할 수도 있음 

- 프로듀서가 레코드 전송 시, 메시지 키의 해시값을 기준으로 파티션 지정 

- 즉, 동일 메시지 키에 대해서는 동일 파티션에 들어감 (단, 파티션 개수가 늘어난 경우, 이전에 저장된 동일 키와 동일한 파티션에 저장된다는 보장은 없음. 이러한 경우, 특정 키는 특정 파티션에 적재되도록 옵션을 지정해야 함) 

- 키가 없는 경우, null로 키를 가지며 설정된 파티셔너에 따라 파티션에 분배됨 (배치처리되어 라운드 로빈 등의 방식으로 파티션에 분배됨) 

- 메시지 키와 값은 직렬화되어 전송되므로, 컨슈머는 동일한 방식으로 역직렬화해야 함 

- java 기본형, 참조형, 바이너리 데이터 등을 전송할 수 있음 

- 헤더는 레코드 추가 정보를 담는 메타데이터 저장 용도

---

kafka 클라이언트 

- 클러스터에 명령을 내리거나, 데이터 송수신을 위한 라이브러리 

- 프로듀서, 컨슈머, 어드민 클라이언트를 제공 

- 라이브러리 형태이기 때문에 별도 프레임워크 위에서 구현 및 동작해야 함