728x90
1. Kafka System
- Zookeeper는 Consumer와 통신, Kafka의 메타 데이터 정보를 저장, Kafka의 상태 관리 등 목적으로 사용
- Kafka 3점대 버전부터는 Zookeeper가 없더라도 Kafka 운영이 되지만 Zookeeper를 대체하는 것이 완벽하지 않기 때문에 Zookeeper를 사용
- Kafka Broker는 하나의 서버에 한 개가 실행되며, Kafka 클라이언트와 데이터를 주고받는 주체
- Kafka Broker는 1대로도 실행은 되지만, 가용성을 위해 3대 이상의 Broker를 1개의 Cluster로 묶어서 운영
2. Zookeeper 역할
2.1. 브로커 메타 데이터 저장
- Kafka 브로커들은 자신의 메타 데이터(브로커 ID, 브로커의 주소 등)를 Zookeeper를 사용하여 저장
- 이 정보는 Kafka Cluster의 브로커 간에 공유되어 서로를 인식하고 통신할 수 있게 한다.
2.2. 리더 선출과 파티션 할당
- Kafka Cluster 내의 Topic의 파티션 리더를 선출하는데 사용
- 새로운 Consumer Group이나 Consumer 인스턴스가 특정 파티션을 어떻게 할당받을지 결정하는데
필요한 정보를 제공
2.3. Offset 저장(최신 버전에서는 삭제된 기능)
- Kafka 0.8.x Version 이전에는 Zookeeper가 Offset을 저장
- Kafka 0.9. Version 이후 부터는 Kafka Broker 내부 토픽(__consumer_offsets)에 Offset이 저장됨
2.4. Cluster 관리(최신 버전에서는 삭제된 기능)
- Kafka Cluster 내의 모든 브로커가 정상적으로 동작하고 있는지 모니터링 하며 필요 시 Cluster 재구성을 수행
3. 브로커 역할
3.1. 컨트롤러
- Cluster의 다수 브로커 중 한 대가 컨트롤러의 역할을 한다. 컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 Cluster에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재 분배 한다.
- 컨트롤러 역할을 하는 브로커가 장애가 발생하면 다른 브로커가 컨트롤러 역할을 한다.
3.2. 데이터 삭제
- Kafka는 Consumer가 데이터를 가져가더라도 Topic의 데이터는 삭제되지 않는다.
- Consumer나 Producer가 데이터 삭제를 요청할 수 없다.
- 브로커만이 데이터 삭제를 할 수 있으며, 데이터 삭제는 파일 단위로 이루어지는데 이 단위를 '로그 세그먼트'라고
부른다. - 로그 세그먼트에는 다수의 데이터가 들어 있기 때문에 일반적인 데이터베이스처럼 특정 데이터를 선별해서 삭제할 수 없다.
3.3. Consumer 오프셋 저장
- Consumer 그룹은 Topic이 특정 파티션으로부터 데이터를 가져가서 처리하고 이 파티션의 어느 레코드까지 데이터를 가져갔는지 확인하기 위해 오프셋을 Commit 한다
- Commit 한 오프셋은 __consumer_offsets 토픽에 저장한다.
3.4. 그룹 코디네이터
- 코디네이터는 Consumer 그룹의 상태를 체크하고 파티션을 Consumer와 매칭되도록 분배하는 역할을 한다.
- Consumer가 Consumer 그룹에서 빠지면 매칭되지 않은 파티션을 정상 동작하는 Consumer로 할당하여 끊임없이 데이터가 처리되도록 도와준다.
3.5. 데이터 저장
- Kafka를 실행할 때 config/server.properties의 log.dir 옵션에 정의한 디렉터리에 데이터를 저장한다.
- Topic 이름과 파티션 번호의 조합으로 하위 디렉터리를 생성하여 데이터를 저장한다.
- log에는 메시지와 메타데이터를 저장한다. Index는 메시지의 Offset을 인덱싱 한 정보를 담은 파일이다.
- timeindex 파일에는 메시지에 포함된 timestamp 값을 기준으로 인덱싱한 정보가 담겨 있다.
- 아래는 test topic에 파티션 0번에 존재하는 데이터 확인 화면이다.
3.6. 로그와 세그먼트
- 오프셋 단위로 로그에 저장됨
$ ls /logs/kafka/broker/test-0
00000000000000000000.log
00000000000000000010.log
00000000000000000020.log
- 위 log 파일 주기는 2가지 방법으로 설정
- log.segment.bytes : 바이트 단위의 최대 세그먼트 크기 지정. 기본 값은 1GB
- log.roll.ms(hours) : 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기. 기본 값은 7일
3.7. 액티브 세그먼트
- 가장 마지막 세그먼트 파일(쓰기가 일어나고 있는 파일)을 액티브 세그먼트라고 한다.
- 액티브 세그먼트는 브로커의 삭제 대상에서 포함되지 않는다.
3.8. 세그먼트와 삭제 주기
- 액티브가 아닌 로그 세그먼트에 대해서 삭제한다.
- Kafka에서 데이터는 세그먼트 단위로 삭제가 발생하기 때문에 로그 단위(레코드)로 개별 삭제는 불가능하다. 또한 로그(레코드)의 이미 적재된 데이터에 대해서 수정 또한 불가능하기 때문에 데이터를 적재할 때 또는 데이터를 사용할 때 데이터를 검증하는 것이 좋다.
- 삭제 주기 정책 cleanup.policy=delete
- retention.ms(minutes, hours) : 세그먼트를 보유할 최대 기간. 기본 값은 7일
- retention.bytes : 파티션당 로그 적재 바이트 값. 기본 값은 -1(지정하지 않음)
- log.restention.check.interval.ms : 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격. 기본 값은 5분
- 삭제 주기 정책 cleanup.policy=compact
- 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책
- 테일 영역(Clean 로그) : 압축 정책에 의해 압축이 완료된 레코드. 중복 메시지 키가 없다.
- 헤드 영역(Dirty 로그) : 압축 정책이 되기 전 레코드. 중복 메시지 키가 있다
- min.cleanable.dirty.ratio
- 데이터의 압축 시작 시점은 위 옵션 값을 따른다. 해당 옵션 값은 액티브 세그먼트를 제외한 세그먼트에 남아 있는 테일 영역의 레코드 개수와 헤드 영역의 레코드 개수의 비율을 의미한다.
- 비율을 0.5로 설정한 경우 테일 영역과 헤드 영역 레코드 개수가 동일할 때 압축이 발생한다.
3.9. 복제(Replication)
- Cluster로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위해 복제를 한다
- Topic을 생성할 때 파티션의 복제 개수도 같이 설정되는데 직접 설정하지 않으면 브로커에 설정된 옵션 값으로 설정된다
- 복제 개수의 최솟값은 1이고 최댓값은 브로커 개수만큼 설정하여 사용할 수 있다
- 복제된 파티션은 리더와 팔로워로 구성된다. Producer 또는 Consumer와 직접 통신하는 파티션을 리더, 나머지 복제 데이터를 가지고 있는 파티션을 팔로워라고 부른다.
3.10. ISR(In-Sync-Replicas)
- 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다. 오프셋 크기가 같은 것을 싱크가 된다고 말한다. 리더 파티션에 모든 데이터가 팔로워 파티션에 모두 복제가 되었다는 것을 의미한다.
- ISR 관련 옵션
- unclean.leader.election.enable=true
유실을 감수하더라도 복제가 안된 팔로워 파티션을 리더로 승급 - unclean.leader.election.enable=false
유실을 감수하지 않음. 해당 브로커가 복구될 때까지 중단
- unclean.leader.election.enable=true
728x90
'Message Queue > Kafka' 카테고리의 다른 글
[Kafka]기본개념-2 (0) | 2024.07.26 |
---|---|
[Kafka]설 치 (0) | 2024.07.08 |
[Kafka] Kafka (0) | 2024.03.11 |