Kafka 기본개념 및 생태계

Before Kafka : 엔드 투 엔드 연결 방식의 아키텍쳐. -> 데이터 연동의 복잡성 증가. 각각의 하드웨어/운영체제 다르니 장애 대응 시 너무 많은 운영요소가 생김. 각각 파이프라인을 만들어야 했음. => 코드의 복잡성 증가.

 

After Kafka : 프로듀서/컨슈머 분리. 메시지 데이터 여러 컨슈머에게 허용/ 높은 처리량을 위한 메시지 최적화 

 

카프카 클러스터 : 메시지 (이벤트) 저장.

 

 

 

Kafka broker (각각의 서버.)

:  카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자, 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션. 

 

하나의 서버에는 한 개의 카프카 브로커 프로세스가 실행됨. 

카프카 브로커 서버 1대로도 기본 기능이 실행되지만, 데이터를 안전하게 보관하고 처리하기 위해 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영. 

카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장하고 복제하는 역할 수행.

 

 

 

데이터 저장, 전송

프로듀서로부터 데이터를 전달받으면 카프카 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 저장하고 컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를 전달함. 

 

 

 

 

Kafka Controller (다수 브로커 중 한 대)

: 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배함. 

카프카는 지속적으로 데이터를 처리해야 하므로 브로커의 상태가 비정상이라면 빠르게 클러스터에서 빼내는 것이 중요함.

if 컨트롤러 브로커에 장애 발생 시 다른 브로커가 컨트롤러 역할을 함.

 

 

데이터 삭제

: 다른 메시징 플랫폼과는 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않음. 컨슈머, 프로듀서가 데이터 삭제 요청 못함. 오직 브로커만이 데이터 삭제 가능. 

- 데이터 삭제는 파일 단위로 이루어짐 (=로그 세그먼트)

이 세그먼트에는 다수의 데이터가 들어가 있기 때문에 일반적인 DB 처럼 특정 데이터를 선별해서 삭제할 수 없음. 

 

실행된 카프카 애플리케이션 서버 중 1대 (서버 한 대에 하나의 카프카가 떠 있다.)

3대 이상의 브로커로 클러스터 구성. 주키퍼와 연동 .  여러 대 중 한 대는 컨트롤러 기능 수행. 

= 메세지 나눠서 저장, 이중화 처리, 장애 나면 처리..

 

이 카프카 클러스터를 관리하는 용도로 주피터가 필요. (주피터 속 카프카클러스터 와 관련된 정보가 관리되고 기록된다.)

 

프로듀서 : 메시지(이벤트)를 카프카에 넣음.

컨슈머 : 그 메시지를 읽어와서 필요한 처리 함. 

 

즉, 카프카 클러스터는 데이터 이동에 필요한 핵심 역할을 함. 

 

토픽 : 카프카에서 데이터를 구분하기 위해 사용하는 단위. 

한 개의 토픽은 한 개 이상의 파티션 (메세지를 저장하는 물리적인 파일) 소유.

파티션에는 프로듀서가 보낸 데이터들이 들어가 저장되는데 이 데이터를 = 레코드 라고부름.

 

 

 

 

 

그래서

프로듀서 ) 메시지를 카프카에 저장할 때 어떤 토픽에 저장해줘. 라고 요청

컨슈머) 어떤 토픽에서 메세지 읽어올래 .

이렇게 토픽을 기준으로 메세지 주고받음.