[Kafka]기본 개념-1

Kafka 로고

1. Kafka System

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번에 존재하는 데이터 확인 화면이다.

test topic에 파티션 0번 디렉터리

3.6. 로그와 세그먼트

• 오프셋 단위로 로그에 저장됨

$ ls /logs/kafka/broker/test-0
00000000000000000000.log
00000000000000000010.log
00000000000000000020.log

로그파일에 저장된 Offset 저장 예시 화면

• 위 log 파일 주기는 2가지 방법으로 설정
  1. log.segment.bytes : 바이트 단위의 최대 세그먼트 크기 지정. 기본 값은 1GB
  2. log.roll.ms(hours) : 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기. 기본 값은 7일

3.7. 액티브 세그먼트

• 가장 마지막 세그먼트 파일(쓰기가 일어나고 있는 파일)을 액티브 세그먼트라고 한다.
• 액티브 세그먼트는 브로커의 삭제 대상에서 포함되지 않는다.

Active segment

3.8. 세그먼트와 삭제 주기

• 액티브가 아닌 로그 세그먼트에 대해서 삭제한다.
• Kafka에서 데이터는 세그먼트 단위로 삭제가 발생하기 때문에 로그 단위(레코드)로 개별 삭제는 불가능하다. 또한 로그(레코드)의 이미 적재된 데이터에 대해서 수정 또한 불가능하기 때문에 데이터를 적재할 때 또는 데이터를 사용할 때 데이터를 검증하는 것이 좋다.
• 삭제 주기 정책 cleanup.policy=delete
  1. retention.ms(minutes, hours) : 세그먼트를 보유할 최대 기간. 기본 값은 7일
  2. retention.bytes : 파티션당 로그 적재 바이트 값. 기본 값은 -1(지정하지 않음)
  3. log.restention.check.interval.ms : 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격. 기본 값은 5분
• 삭제 주기 정책 cleanup.policy=compact
  1. 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책
  2. 테일 영역(Clean 로그) : 압축 정책에 의해 압축이 완료된 레코드. 중복 메시지 키가 없다.
  3. 헤드 영역(Dirty 로그) : 압축 정책이 되기 전 레코드. 중복 메시지 키가 있다

헤드 영역(Dirty 로그)

테일 영역(Clean 로그)

• min.cleanable.dirty.ratio
  1. 데이터의 압축 시작 시점은 위 옵션 값을 따른다. 해당 옵션 값은 액티브 세그먼트를 제외한 세그먼트에 남아 있는 테일 영역의 레코드 개수와 헤드 영역의 레코드 개수의 비율을 의미한다.
  2. 비율을 0.5로 설정한 경우 테일 영역과 헤드 영역 레코드 개수가 동일할 때 압축이 발생한다.

비율 0.5인 경우

3.9. 복제(Replication)

• Cluster로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위해 복제를 한다
• Topic을 생성할 때 파티션의 복제 개수도 같이 설정되는데 직접 설정하지 않으면 브로커에 설정된 옵션 값으로 설정된다
• 복제 개수의 최솟값은 1이고 최댓값은 브로커 개수만큼 설정하여 사용할 수 있다
• 복제된 파티션은 리더와 팔로워로 구성된다. Producer 또는 Consumer와 직접 통신하는 파티션을 리더, 나머지 복제 데이터를 가지고 있는 파티션을 팔로워라고 부른다.

리더 파티션과 팔로워 파티션

3.10. ISR(In-Sync-Replicas)

• 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다. 오프셋 크기가 같은 것을 싱크가 된다고 말한다. 리더 파티션에 모든 데이터가 팔로워 파티션에 모두 복제가 되었다는 것을 의미한다.
• ISR 관련 옵션
  1. unclean.leader.election.enable=true
     유실을 감수하더라도 복제가 안된 팔로워 파티션을 리더로 승급
  2. unclean.leader.election.enable=false
     유실을 감수하지 않음. 해당 브로커가 복구될 때까지 중단

ISR 상태