Kafka의 구조

특징 : 

대용량 실시간 처리에 특화

기존의 메시지를 메모리에 저장하는 메시징 시스템과 달리 파일에 저장을 통해 재시작해도 메시지 유실 우려가 적음 

 

• 컨슈머(Consumer)가 브로커(Broker)에게 메시지를 직접 가져가는 Pull 방식으로 동작
  • 따라서 컨슈머의 처리 능력만큼 메시지를 가져옴 -> 최적의 성능 

 

카프카의 구성 요소 

 

# Topic  / Partition

topic : 카프카에 저장되는 메시지의 대분류 단위 (메시지를 구분하는 단위 - 파일시스템의 폴더)

Partition : Topic 은 여러 patition 으로  나눠진다. ( 한 개의 토픽은 한 개 이상의 파티션으로 구성 - 메시지를 저장하는 물리적 파일)

- (partition 내에는 상대적 위치의 offset을 통해 메시지의 위치 정보를 파악)

- 동시에 들어오는 많은 데이터를 여러 파티션에 나누어 저장 → 병렬 처리 

 

# Producer / Consumer

말대로 Producer는 생산 , Consumer는 소비하는 역할

서로간에는 상호 존재 여부를 알지 못함, 자신에게 주어진 역할만 수행

Producet - RR 방식으로 저장 혹은 key 값을 기준으로 파티션에 저장

# Consumer Group 

- 하나의 공동된 목표를 위해 소비하는 Consumer 들 

 

Producer가 메시지를 여러 파티션에 저장하기 때문에 소비하는 쪽에서는 여러 소비자가 메시지를 읽어가는 것이 효율적인 상황

특정 컨슈머에 문제가 있을 경우 다른 그룹 내 컨슈머로 리밸런싱 가능

 

- 컨슈머 그룹에 속한 컨슈머들은 한 파티션을 공유할 수 없음 

 

(cf. Consumer group 규칙 - Topic 파티션은 Consumer 그룹과 1:n 매핑 [ 자신이 읽는 파티션에는 같은 그룹 내 다른 컨슈머는 읽을 수 없음 ] )

 

일반적으로 파티션 개수는 컨슈며 개수와 동일하게 구성하는 것이 좋다 [ 다르다면 컨슈머가 일을 하지 못하거나 ] 

 

# Broker, Zookeeper, Replication

broker - kafka 서버 , 동일한 노드 내에 여러 broker 띄우기 가능 [ 개수 조정 가능]

zookeeper - 분산 메시지큐를 관리하는 역할 수행 

replication - replication 수를 통해 topic 생성 가능 / 데이터 복제 및 broker 문제 상황에 대한 대처 [ 개수 설정 ]

• replication 개수 = 원본 개수  + 복제 개수
  • 따라서 replication 3 = 원본(리더) 1 + 복제 2 
• replication 개수 < partition 개수를 지켜진다. 
• replication의 이유 
  • 고가용성 -> 장애 상황시를 대처 
• replication 내에 leader / follwer 로 나누어져 master 역할[read/write] 수행 
  • ack 을 통해 복제에 대한 설정 가능 (0 , 1) 
• 3개 이상의 브로커 사용할 때 => replication 은 3

 

 

# 성능

• 파티션 파일은 OS 페이지 캐시 사용 
  • 파티션에 대한 파일 IO를 메모리에서 처리
• Zero Copy
  • 디스크 버퍼에서 네트워크 버퍼로 직접 복사 
• 컨슈머 추적을 위해 브로커의 일은 비교적 단순
  • 메시지 필터 / 메시지 재전송과 같은 일은 브로커가 하지 않는다. 
  • 브로커는 컨슈머와 파티션 간의 매핑만 관리 
• 처리량 증대 및 확장이 쉽다
  • 1개의 장비 용량 부족 -> 브로커 추가 혹은 파티션 추가
  • 컨슈머가 느리면 -> 컨슈머 추가 + 파티션 추가