본문으로 바로가기

Kafka 학습하기_브로커와 클러스터

category MQ 2024. 6. 1. 17:52
반응형


[인프런 - 아파치 카프카 애플리케이션 프로그래밍]

주키퍼 앙상블

- 주키퍼는 분산 애플리케이션을 위한 중앙 집중식 서비스로, 카프카의 메타데이터 관리 및 브로커의 상태를 유지시킴.

- 카프카 3.0부터는 주키퍼가 없어도 클러스터 동작 가능.
카프카 클러스터
- 여러 브로커로 구성된 클러스터로, 주키퍼와 연동하여 메시지를 관리, 
- 주키퍼는 브로커들의 상태를 감시하고, 장애가 발생하면 클러스터의 균형을 유지하도록 도와줌.

 

브로커의 역할  

- 하나의 서버나 인스턴스 위에서 동작함
- 1개로도 기본 기능 실행 가능
- 3개 이상의 브로커 서버를 1개의 클러스터로 묶어 운영
- 데이터를 안전하게 분산 저장하고, 복제해 장애로부터 가용성 확보 가능

 

- 컨트롤러
클러스터의 다수 브로커 중 한 대가 컨트롤러의 역할을 한다.
컨트롤러는 다른 브로커들의 상태 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배한다.
카프카는 지속적으로 데이터를 처리해야 하므로 브로커의 상태가 비정상이라면 빠르게 클러스터에서 빼내는 것이 중요하다.
만약 컨트롤러 역할을 하는 브로커에 장애가 생기면 다른 브로커가 컨트롤러 역할을 한다.

- 데이터 삭제

카프카는 다른 메시징 플랫폼과 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않는다.
또한 컨슈머나 프로듀서가 데이터 삭제를 요청할 수도 없다. 오직 브로커만이 데이터를 삭제할 수 있다.
데이터 삭제는 파일 단위로 이루어지는데 이 단위를 로그 세그먼트라고 부른다.
이 세그먼트에는 다수의 데이터가 들어 있기 때문에 일반적인 데이터베이스처럼 특정 데이터를 선별해서 삭제할 수 없다.

- 컨슈머 오프셋 저장

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

- 그룹 코디네이터

코디네이터는 컨슈머 그룹의 상태를 체크하고 피티션을 컨슈머와 매칭되도록 분배하는 역할을 한다.
컨슈머가 컨슈머 그룹에서 빠지면 매칭되지 않은 파티션을 정상 동작하는 컨슈머로 할당하여 끊임없이 데이터가 처리되도록 도와준다.
이렇게 파티션을 컨슈머로 재할당하는 과정을 리밸런스라고 부른다.

- 데이터의 저장

카프카를 실행할 때 config/server.properties의 log.dir 옵션에 정의한 디렉토리에 데이터를 저장한다.

토픽의 파티션에 존재하는 데이터를 확인할 수 있다. log에는 메시지와 메타데이터를 저장한다.

index는 메시지의 오프셋을 인덱싱한 정보가 담은 파일이다. timeindex 파일에는 메시지에 포함된 timestamp값을 기준으로 인덱싱한 정보가 담겨 있다.

 

- 로그 세그먼트

log.segment.bytes 바이트 단위의 최대 세그먼트 크기 지정.

log.roll.ms 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기, 기본값은 7일

 

- 액티브 세그먼트

가장 마지막 세그먼트 파일을 액티브 세그먼트라고 부른다. 액티브 세그먼트는 브로커의 삭제 대상에서 포함되지 않는다.

 

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

retention.ms 세그먼트를 보유할 최대 기간. 기본값은 7일

retention.bytes 파티션당 로그 적재 바이트값. 기본값은 -1(지정하지 않음)

log.retention.check.interval.ms 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격. 기본 값은 5분

 

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

카프카에서 데이터는 세그먼트 단위로 삭제가 발생하기 때문에 로그 단위로 개별 삭제는 불가능하다.

또한 로그의 메시지 키, 값, 오프셋, 헤더 등 이미 적재된 데이터에 대해서 수정 또한 불가능하기 때문에 데이터를 적재할 때 또는 데이터를 사용할때 데이터를 검증하는것이 좋다.

 

- 토픽 압축 정책 (cleanup.policy=compact)

메시지 키 별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책.

삭제 정책과 다르게 일부 레코드만 삭제될 수 있다. 압축은 액티브 세그먼트를 제외한 데이터가 대상이다.

 

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

테일 영역: 압축 정책에 의해 압축이 완료된 레코드들, 클린 로그라고 부른다. 중복 메시지 키가 없다.

헤드 영역: 압축 정책이 되기 전 레코드들, 더티 로그라고 부른다. 중복된 메시지 키가 있다.

 

- min.cleanable.dirty.ratio

데이터의 압축 시작 지점은 min.cleanable.dirty.ratio 옵션값을 따른다. 테일 영역의 레코드 개수와 헤드 영역의 레코드 개수의 비율을 뜻함.

0.9와 같이 크게 설정하면 한번 압축을 할 때 많은 데이터가 줄어들므로 압축 효과가 좋지만 용량 효율이 좋지 않다.

반면 0.1과 같이 작게 설정하면 압축이 자주 일어나서 가장 최신 데이터만 유지할 수 있지만 압축이 자주 발생하기 때문에 브로커에 부담을 줄 수 있다.

 

- 복제

데이터 복제는 카프카를 장애 허용 시스템으로 동작하도록 하는 원동력이다. 복제의 이유는 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위함이다.

카프카의 데이터 복제는 파티션 단위로 이루어진다. 토픽을 생성할 때 파티션의 복제 개수도 같이 설정되는데 직접 옵션을 선택하지 않으면 최솟값 1(복제 없음)이고 최댓값은 브로커 개수만큼 설정하여 사용할 수 있다.

 

- 복제 ISR(In-Sync-Replicas)

ISR은 리더 파티션과 팔로워 파티션이 모든 싱크가 된 상태를 뜻한다.

- unclean.leader.election.enable=true 유실을 감수함. 복제가 아노딘 팔로워 파티션을 리더로 승급.

- unclean.leader.election.enable=false 유실을 감수하지 않음. 해당 브로커가 복구될 때까지 중단.

반응형

'MQ' 카테고리의 다른 글

Kafka 학습하기_프로듀서  (0) 2024.06.04
Kafka 학습하기_토픽, 파티션, 레코드  (0) 2024.06.02
Kafka 학습하기_장단점  (0) 2024.06.01
Rabbitmq 이해하기  (0) 2023.05.11
RabbitMQ Prefetch Count 란? (closing AMQP connection)  (0) 2023.02.10