[Apache Kafka] 2. 카프카 기본 개념 설명(1)

본 포스팅은 인프런 데브원영님의 [아파치 카프카 애플리케이션 프로그래밍]의 강의를 수강 후 정리하는 글입니다.

[아파치 카프카 애플리케이션 프로그래밍] 개념부터 컨슈머, 프로듀서, 커넥트, 스트림즈까지!

 

 

1. 오픈 소스 아파치 카프카 생태계

카프카 생태계

출처: https://developer.confluent.io/what-is-apache-kafka/

• Producer: 데이터를 보내는 곳
• Consumer: 데이터를 처리하는 곳
• Connect(Source, Sink): 데이터 파이프라인을 운영하는 가장 핵심적인 툴
• Streams: 프로세싱을 통해서 데이터를 처리하고 다시 토픽으로 넣는 역할
• MM2: 클러스터 단위로 토픽에 있는 데이터를 완벽하게 복제하는데 쓰임

---

2. 카프카 브로커와 클러스터

브로커 · 클러스터 · 주키퍼

 

출처: https://codeblog.dotsandbrackets.com/hello-world-with-apache-kafka/

 

주키퍼: 카프카 클러스터를 운영하기 위해 필요한 분산 코디네이션 서비스(카프카 v2 이하에서 필수)
브로커: 최소 1대로도 기본 기능이 실행되지만, 데이터를 안전하게 보관하고 처리하기 위해 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영

---

3. 카프카 클러스터와 주키퍼

여러 개의 카프카 클러스터가 연결된 주키퍼

주키퍼의 서로 다른 znode에 클러스터를 지정하면 됨
root znode에 각 클러스터별 znode를 생성하고, 클러스터 실행 시 root가 아닌 하위 znode로 설정

 

 

---

4. 카프카 브로커의 역할들

4-1. 브로커의 역할

4-1-1. 브로커의 역할 - 컨트롤러

클러스터의 다수 브로커 중 한 대가 컨트롤러의 역할을 함
다른 브로커들의 상태를 체크
브로커가 클러스터에서 빠지는 경우, 해당 브로커에 존재하는 리더 파티션을 재분배
브로커의 상태가 비정상이라면 빠르게 클러스터에서 제거
컨트롤러 역할을 하는 브로커가 비정상이면 다른 브로커가 컨트롤러 역할을 위임

 

 

4-1-2. 브로커의 역할 - 데이터 삭제

카프카는 다른 메시징 플랫폼과 다르게 컨슈머가 데이터를 수집할 때, 토픽의 데이터를 삭제하지 않음
오직 브로커만이 데이터를 삭제할 수 있음
데이터 삭제는 파일 단위로 이루어지는데, 이때 단위는 로그 세그먼트라고 함
세그먼트에는 다수의 데이터가 들어가 있기 때문에, 특정 데이터를 선별해서 삭제할 수 없음
시간과 용량에 따라서 데이터를 삭제 또는 compact 옵션을 통해 최신의 메시지 키를 제외한 레코드들을 삭제

 

4-1-3. 브로커의 역할 - 컨슈머 오프셋 저장

커밋: 어느 오프셋까지 소비했는지 알리는 것
컨슈머 그룹은 토픽이 특정 파티션으로부터 어느 레코드까지 가져갔는지 확인하기 위해 오프셋을 커밋
커밋한 오프셋은 __consumer_offsets 토픽에 저장
여기에 저장된 오프셋을 토대로 컨슈머 그룹은 다음 레코드를 가져가서 처리

 

4-1-4. 브로커의 역할 - 그룹 코디네이터

컨슈머 그룹의 상태를 체크하고, 파티션을 컨슈머와 매칭되도록 분배하는 역할
리밸런스: 컨슈머가 컨슈머 그룹에서 빠지면, 매칭되지 않은 파티션을 정상 동작하는 컨슈머로 할당

4-1-5. 브로커의 역할 - 데이터의 저장

카프카를 실행할 때 config/server.properties의 log.dir 옵션에 정의한 디렉터리에 데이터를 저장
토픽 이름과 파티션 번호의 조합으로 하위 디렉토리를 생성하여 데이터를 저장

 

• log: 메시지와 메타데이터 저장
• index: 메시지의 오프셋을 인덱싱한 정보 저장
• timeindex: 메시지(레코드 하나)에 포함된 timestamp값 기준으로 인덱싱 한 정보

4-2. 로그와 세그먼트

$ ls /tmp/kafka-logs/hello.kafka-0
├── hello.kafka-0
│   ├── 00000000000000000000.log
│   ├── 00000000000000000010.log
│   ├── 00000000000000000020.log

 

파일의 첫번째 오프셋 번호가 파일 이름이 된다.
액티브 세그먼트는 브로커의 삭제 대상에서 포함되지 않음
액티브 세그먼트가 아닌 세그먼트는 retention 옵션에 따라 삭제 대상으로 지정

 

• log.segment.bytes: 최대 세그먼트 크기 지정[바이트 단위], 디폴트: 1GB
• log.roll.ms(hours): 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기, 디폴트: 7일

---

5. 세그먼트와 삭제 주기

5-1. 세그먼트와 삭제 주기(cleanup.policy=delete)

액티브 세그먼트가 아닌 세그먼트 삭제

 

• retension.ms(minutes, hours): 세그먼트를 보유할 최대 기간, 디폴트: 7일 (늘릴 경우, 디스크 용량 확인 필요)
• retension.bytes: 파티션당 로그 적재 바이트 값, 디폴트: -1(지정하지 않음)
• log.retension.check.interval.ms: 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격, 디폴트: 5분

5-2. 세그먼트의 삭제(cleanup.policy=delete) 

카프카에서 데이터는 세그먼트 단위로 삭제가 발생하기 때문에 레코드 단위로 개별 삭제는 불가능
이미 적재된 레코드의 메시지 키, 메시지 값, 오프셋, 헤더에 대해서 수정 불가능

 

5-3. cleanup.policy=compact

출처: https://learn.conduktor.io/kafka/kafka-topic-configuration-log-compaction/

액티브 세그먼트를 제외한 데이터가 대상
메시지 키 별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제

 

5-4. 테일/헤드 영역, 클린/ 더티 로그

출처: https://docs.confluent.io/kafka/design/log_compaction.html

• 테일 영역(클린 로그): 압축 정책에 의해 압축이 완료된 레코드들
• 헤드 영역(더티 로그): 압축 정책이 되기 전 레코드들

5-5. min.cleanable.dirty.ratio

액티브 세그먼트를 제외한 세그먼트에 남아 있는 더티 레코드 수와 클린 레코드 개수의 비율

• min.cleanable.dirty.ratio=0.5 : 더티 레코드 수와 클린 레코드 개수가 동일
• min.cleanable.dirty.ratio=0.9 : 한 번 압축을 할 때 많은 데이터가 줄어들므로 압축 효과가 좋지만 용량 효율은 좋지 않음
• min.cleanable.dirty.ratio=0.1 : 압축이 자주 일어나서 가장 최신 데이터만 유지할 수 있지만, 브로커에 부담