1. Broker, Zookeeper 개념
Kafka Broker
- Topic과 Partition을 유지 및 관리
- Partition에 대한 Read Write를 관리하는 소프트웨어
- Topic 내의 Partition들을 분산, 유지 및 관리
- 각각의 Broker들은 ID로 식별됨
- Topic의 일부 Partition들을 포함 (Partition을 가질 뿐 전체를 갖고 있지 않음)
- Client는 특정 Broker에 연결하면 전체 클러스터에 연결됨
- 최소 3대 이상의 Broker를 하나의 클러스터로 구성해야함 (4대 권장)
- Topic을 구성하는 Partition들은 여러 Broker 상에 분산됨
- Topic 생성시 Kafka가 자동으로 Topic을 구성하는 전체 Partition들을 모든 Broker에게 할당하고 분배해 줌
- 모든 Kafka Broker는 Bootstrap 서버라고 부름
Zookeeper
-
Broker를 관리하는 소프트웨어
-
변경사항에 대해 Kafka에 알림 (Topic 생성/제거, Broker 추가/제거)
-
Zookeeper 없이는 Kafka가 작동할 수 없음 (하지만 점점 제거되는 추세)
-
Zookeeper는 홀수의 서버로 작동하게 설계되어 있음 (최소3 권장 5)
-
Leader(Writes)가 있고 나머지는 Followe(reads)
-
분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어
-
분산 작업을 위한 Tree 형태의 데이터 저장소 (브로커 간의 정보공유, 동기화 등을 수행)
-
Quorum 알고리즘 기반으로 동작함
- 쿼럼은 "정족수"이며 합의체가 의사를 진행시키거나 의결을 하는데 필요한 최소 인원을 뜻함
- 분산 코디네이션 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 일관성을 유지함
- ensemble이 3대라면 쿼럼은 2, 즉 zookeeper 1대가 장애 발생해도 정상 동작
2. Producer 개념
Producer의 Record 구조
- key, value는 Avro, JSON 등 다양한 형태가 가능
Serializer / Deserializer
- Kafka는 Record를 Byte Array로 저장
- Key와 Value 용 Serializer를 각각 설정함
High-Level Architecture
- 사용자가 Record를 만들어 send() 함수 수행 (사용자는 설정을 정하고 Record를 만들어 Send()만 수행시켜주면 된다 )
- Serializer에서 record를 직렬화 수행
- Partitioner에서 메시지의 Topic을 어떤 Partition으로 보낼지 결정
- 결과에 따라 분기
Partitioner의 역할
- Partition = Hash(Key) % Number Of Partitions
- 위 식을 이용하여 어떤 파티션으로 보낼지 결정함. (Key != null이어야 함)
- Kafka2.4 이전의 디폴트파티셔너는 Round Robin 정책으로 동작
- Kafka2.4 이후의 디폴트파티셔너는 Sticky 정책으로 동작
- 하나의 Batch가 닫힐 때까지 하나의 partition에게 record를 보내고 랜덤으로 파티션 선택
3. Consumer 개념
Consumer Offset
Consumer Group이 읽은 위치를 표시
- Consumer가 자동이나 수동으로 데이터를 읽은 위치를 commit하여 다시 읽음을 방지
- __consumer_offsets 라는 Internal Topic에서 Consumer Offset을 저장하여 관리
파티션과 컨슈머
- 여러개 파티션, 하나의 컨슈머가 있는 경우 해당 컨슈머는 모든 파티션에서 Record를 consume함.
- 동일한 group.id로 구성된 Consumer들은 하나의 Consumer Group을 형성
- 그룹 내에서 Consumer들은 파티션을 분배하여 Consume함.- 특정 파티션은 항상 Consumer group 내의 하나의 Consumer에 의해서만 사용됨
- Consumer는 주어진 Topic에서 0개 이상의 많은 파티션을 사용할 수 있음
Message Ordering (메시지 순서)
- Partition이 2개 이상인 경우 모든 메시지에 대한 전체 순서 보장 불가능
- Partition을 1개로 구성하면 모든 메시지 전체 순서 보장 가능 -> 처리량 저하
- Partition을 1개로 구성해서 모든 메시에서 전체 순서를 보장하는 경우가 많을까????
- 대부분은 동일 Key 내부에서 순서 보장이 필요함.
- 동일한 Key를 가진 메시지는 동일한 Partition에만 전달되어 Key레벨의 순서 보장 가능
Key Cardinality
- Key Cardinality는 Consumer Group의 Consumer가 수행하는 작업의 양의 영향
- Key 선택이 잘못되면 작업 부하가 고르지 않음
- Key는 Integer, String 등과 같은 단순한 유형일 필요가 없음
- Key 역시 Value와 마찬가지로 Avro, JSON등 여러 필드가 있는 복잡한 객체일 수 있음.
- 따라서 Partition 전체에 Record를 고르게 배포하는 Key를 만드는 것이 중요.
Consumer 장애 상황
- 컨슈머에서 장애가 발생하면 그룹 내의 다른 멀쩡한 컨슈머가 해당 로드를 가져가는 Rebalancing이 일어남
- Partition은 항상 Consumer Group 내의 하나의 Consumer에 의해서만 사용된다는 룰 위배하지 않음
