본문

Kafka 이해하기

반응형

1. Kafka의 핵심요소

a) Broker: 카프카 애플리케이션 서버 단위

b) Topic: 데이터 분리 단위. 다수 파티션 보유

c) Partition: 레코드를 담고 있음. 컨슈머 요청시 레코드 전달

d) Offset: 각 레코드당 파티션에 할당된 고유 번호

e) Consumer: 레코드를 polling하는 애플리케이션

   - Consumer group: 다수 컨슈머 묶음

   - Consumer offset: 특정 컨슈머가 가져간 레코드의 번호

f) Producer: 레코드를 브로커로 전송하는 애플리케이션

g) Replication: 파티션 복제 기능

   - ISR: 리더+팔로워 파티션의 sync가 된 묶음

h) Rack-awareness: Server rack 이슈에 대응

 

 

1.1 Kafka broker

a) 실행된 카프카 애플리케이션 서버 중 1대

b) 3대 이상의 브로커를 클러스터 구성

c) 주키퍼와 연동(~2.5.0. 버전)
   - 주키퍼의 역할: 메타데이터(브로커id, 컨트롤러id 등) 저장
d) n개 브로커 중 1대는 컨트롤러(Controller) 기능 수행
   - 컨트롤러: 각 브로커에게 담당 파티션 할당 수행. 브로커 정상 동작 모니터링 관리. 누가 컨트롤러 인지는 주키퍼에 저장

 

1.2 Topic & Partition

a) 메세지 분류 단위
b) n개의 파티션 할당 가능
c) 각 파티션마다 고유한 오프셋(offset)을 가짐
d) 메시지 처리순서는 파티션 별로 유지 관리됨

 

1.3 Producer & Consumer

a) 프로듀서는 레코드를 생성하여 브로커로 전송
b) 전송된 레코드는 파티션에 신규 오프셋과 함께 기록됨
c) 컨슈머는 브로커로부터 레코드를 요청하여 가져감(polling)

 

1.4 Kafka log & segment

a) 실제로 메시지가 저장되는 파일시스템 단위
b) 메시지가 저장될때는 세그먼트파일이 열려있음
c) 세그먼트는 시간 또는 크기 기준으로 닫힘
d) 세그먼트가 닫힌 이후, 일정시간(또는 용량)에 따라 삭제(delete) 또는 압축(compact)

 


2. 파티션과 컨슈머

2.1 파티션 3개인 토픽과 컨슈머 1대

a) 파티션이 3개인 토픽
b) 1개의 프로듀서가 토픽에 레코드를 보내는 중
c) 1개의 컨슈머가 3개의 partition으로부터 polling 중

 

2.2 파티션 3개인 토픽과 컨슈머 3대

a) 파티션이 3개인 토픽
b) 1개의 프로듀서가 토픽에 레코드를 보내는 중
c) 3개의 컨슈머로 이루어진 1개의 컨슈머 그룹이 토픽으로부터 polling 중

 

2.3 파티션이 3개인 토픽과 컨슈머 4대

a) 가능한 경우: 파티션 개수 >= 컨슈머 개수

b) 불가능: 파티션 개수 < 컨슈머 개수

   - 남은 컨슈머는 파티션을 할당받지 못하고 대기 중

 

2.4 컨슈머 3대 중 1대 장애 발생

a) 컨슈머 중 한개가 장애가 난 경우에 대한 대비 가능

b) 리밸런스 발생: 파티션 컨슈머 할당 재조정

c) 나머지 컨슈머가 파티션으로부터 polling 수행

 

2.5 2개 이상의 컨슈머 그룹

a) 용도/목적에 맞게 컨슈머 그룹을 분리할 수 있음

 

2.6 애플리케이션 로그 적재용 컨슈머 그룹 2개

a) applicatoin log 적재 Example

- 엘라스틱서치: 로그 실시간 확인용. 시간순 정렬

- 하둡: 대용량 데이터 적재. 이전 데이터 확인용

 

2.7 컨슈머 그룹 장애에 격리되는 다른 컨슈머 그룹

a) 컨슈머 그룹간 간섭(coupling) 줄임

b) 하둡에 이슈가 발생하여 컨슈머의 적재지연이 발생하더라도 엘라스틱서치에 적재하는 컨슈머의 동작에는 문제가 없음


3. Replication

3.1 Broker partition replication 설정 in kafka topics

bin/kafka-topic.sh --bootstrap-server localhost:9092 --create --topic topic_name --partition 3 --replication-factor 3

 

3.2 Broker partition replication

Question: Kafka broker 이슈에 대응하기 위해 사용할 수 있는 방법은?

Answer: Partition을 다른 Broker에 복제하여 이슈를 대응한다. 1번 Broker에 이슈가 생기면 다른 Broker에 복제된 데이터를 사용한다.

 

3.3 고가용성을 위한 복제

고가용성을 위한 파티션 복제기능으로 데이터 유실 방지

3.4 리더 파티션, 팔로워 파티션

a) 리더 파티션: Kafka 클라이언트와 데이터를 주고 받는 역할

b) 팔로워 파티션: 리더 파티션으로부터 레코드를 지속 복제. (복제하는데 시간이 걸림)

리더 파티션의 동작이 불가능할 경우, 나머지 팔로워 중 1개가 리더로 선출됨

3.5 ISR, 리더와 파로워의 싱크(Sync)

파티션 3개, 리플리케이션이 3개로 이루어진 토픽이 브로커에 할당된 모습

a) 특정 파티션의 리더, 팔로워가 레코드가 모두 복제되어 sync가 맞는 상태 → ISR(In-Sync Replica)

b) ISR이 아닌 상태에서 장애가 나면 → unclean.leader.election.enable

 

unclean.leader.election.enable
리더 파티션에 장애가 발생할 경우, 팔로워 파티션에 데이터 복제가 정상적으로 되지않음: 즉 ISR이 아닌상태

a) 복제가 완료될때까지 대기: 즉 장애가 발생한 파티션이 복구될때까지 기다린다. (ISR을 맞추기위해)
unclean.leader.election.enable: false (default option)

b) 대기하지않음(복제안하고 처리): 복제에 실패한 데이터를 유실시키고, 다음 메세지를 처리한다.
unclean.leader.election.enable: true

 운영중 kafka cluster가 장애가 났는데, consumer과 produser가 정상적으로 작동하지않는다면
unclean.leader.election.enable 옵션 확인 필요

 


3.6 Broker partition replication

a) Broker#1 장애 발생시

- Partition#1의 리더가 브로커#2 또는 #2로 새로 할당 됨

- Kafka 클라이언트는 새로운 파티션 리더와 연동

 

 


💡 Apache kafka 기본개념 및 생태계

https://www.youtube.com/watch?v=catN_YhV6To

반응형

공유

댓글