KAFKA

KAFKA 출시

2011년 링크드인 웹 사이트에서 생성되는 로그를 처리하여 웹사이트 활동을 추적하는 것을 목적으로 개발되었다.

 

 

KAFKA

Publish-Subscribe 모델의 메시지 큐이다

 

대용량 실시간 로그처리에 특화되어 설계된 메시징 시스템으로 분산환경에 특화되어 있다. (분산 이벤트 스트리밍 플랫폼)

 

메시지 큐 란?

• 프로세스 또는 프로그램 간 데이터를 교환할때 사용하는 통신 방법중 하나.
• 메시지 지향 미들웨어를 구현한 시스템을 말한다.
• 메시지 지향 미들웨어(MOM : Message Oriented Middleware)는 비동기 메시지를 사용하는 다른 응용프로그램 사이의 데이터 송수신을 의미한다.

 

메시지 큐의 장점

 - 비동기(Asynchronous): Queue에 넣기 때문에 나중에 처리할 수 있습니다.

 - 비동조(Decoupling): 애츨리케이션과 분리할 수 있습니다.

 - 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않습니다.

 - 과잉(Redundancy): 실패할 경우 재실행 가능합니다.

 - 보증(Guarantees): 작업이 처리된걸 확인할 수 있습니다.

 - 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있습니다.

 

메시지 큐 사용처

 - 다른 곳의 API로 부터 데이터 송수신이 가능합니다.

 - 다양한 애플리케이션에서 비동기 통신을 할 수 있습니다.

 - 이메일 발송 및 문서 업로드가 가능합니다.

 - 많은 양의 프로세스들을 처리할 수 있습니다.

(출처: https://12bme.tistory.com/176)

 

 

카프카의 특징

기본 메시징 시스템에서는 브로커가 컨슈머에게 메시지를 push 해주는 방식인데

KAFKA는 컨슈머가 브로커에게 메시지를 직접 가져저오는 pull 방식으로 동작.

이로인한 장점은 컨슈머가 자신의 처리능력 만큼의 메시지만 가져와서 최적의 성능을 낼 수 있다

(다양한 소비자의 형태와 속도를 고려하지 않아도 된다)

 

 

KAFKA 의 구성요소

 

 

event

어떠한 일에 대해 일어난 기록이다.

프로듀서와 컨슈머가 데이터를 주고받을때 Event 형태를 사용하게 된다.

key, value, timestamp 구성

 

topic

이벤트가 조직화 되고 저장되는 장소이다 (데이터를 구분하기 위해 사용하는 단위) 

ex) 주문용 토픽, 결제용 토픽 등등

파일 시스템의 폴더이며 이벤트는 이 폴더 내의 파일로 존재한다. 

프로듀서는 이 topic에 이벤트를 게시하고 여러개의 프로듀서를 가질 수 있다. 

컨슈머는 마찬가지로 Topic에서 메시지를 가져와서 소비한다.

이 topic은 여러 borker에 분산 저장되며 이렇게 분산된 topic을 partition이라고 한다

topic과 partition

토픽은 하나 이상의 파티션을 소유하고 있다.

파티션은 카프카의 병렬처리의 핵심으로, 그룹으로 묶인 컨슈머들이 레코드를 병렬로 처리할 수 있도록 매칭된다

파티션은 큐와 같은 FIFO 구조로 먼저 들어간 레코드는 컨슈머가 먼저 가저간다.

(pop처럼 레코드를 삭제하지않고 카프카에 남아있다)

 

데이터 복제

카프카를 장애 허용 시스템으로 동작하게 하는 원동력이다.

일부 장애가 발생하여도 데이터를 유실하지 않고 안전하게 사용이 가능하다

데이터 복제는 파티션 단위로 이루어진다

리더 파티션 : 프로듀서와 컨슈머랑 직접 통신하는 파티션이다

팔로우 파티션 : 나머지 복제 데이터를 가지고있는 파티션

 

 

broker

카프카의 데이터를 주고받기 위해 사용되는 주체이다.

브로커는 각각의 kafka의 서버라고 불리움 (topic을 저장함)

하나의 브로커로 기본적인 실행은 가능하나, 3대이상 브로커 서버를 하나의 클러스터로 묶어서

안전하게 데이터를 보관한다.

 

프로듀서가 생성한 메시지를 받아서 관리하고

컨슈머로부터 메시지를 읽으려는 요청에 응답을 하는 중요 역할을 한다. (데이터 저장과 전송)

 

 

Controller

클러스터의 다수의 브로커중 한대가 컨트롤러 역할을 한다

컨트롤러는 다른 브로커의 상태를 체크하고, 브로커가 클러스터에게 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배

파티션 관리를 책임 (리더 선정, 토픽 생성, 복제본 관리)

 

컨슈머 오프셋 저장

 

레코드

 

 

cluster

kafka 브로커들의 모임이다. 확장성과 고가용성을 위해 broker들이 클러스터로 구성되어 있다.

 

producer

생산을 하는 주체로, kafka에서 이벤트를 post하는 클라이언트 어플리케이션을 의미

(메시지 이벤트를 발행하여 생산하는 주체)

 

consumer

topic을 구독하고 이로부터 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션

(메시지 이벤트를 구독하여 소비하는 주체)

 

offset

 

zookeeper

이러한 분산 메시지 큐의 정보(환경 설정, 상태체크 등)를 통합 관리(master가 죽으면 master선정 부여) 해주는 역할이다.

컨트롤러 선정, 브로커와 컨슈머 관리

(consumer와 통신을 하고 kafka의 상태를 관리해주는 툴)

따라서 kafka를 띄우기 위해 반드시 zookeeper가 실행되어야 한다.

• 설정 관리(Configuration management) : 클러스터의 설정 정보를 최신으로 유지하기 위한 조율 시스템으로 사용됩니다.
• 클러스터 관리(Cluster management) : 클러스터의 서버가 추가되거나 제외될 때 그 정보를 클러스터 안 서버들이 공유하는 데 사용됩니다.
• 리더 채택(Leader selection) : 다중 어플리케이션 중에서 어떤 노드를 리더로 선출할 지를 정하는 로직을 만드는 데 사용됩니다. 주로 복제된 여러 노드 중 연산이 이루어지는 하나의 노드를 택하는 데 사용됩니다.
• 락, 동기화 서비스(Locking and synchronization service) : 클러스터에 쓰기 연산이 빈번할 경우 경쟁상태에 들어갈 가능성이 커집니다. 이는 데이터 불일치를 발생시킵니다. 이 때, 클러스터 전체를 대상을 동기화해( 락을 검 ) 경쟁상태에 들어갈 경우를 사전에 방지합니다.

출처 : https://engkimbs.tistory.com/660

 

zookeeper ensemble? : 주키퍼의 클러스터를 주키퍼 앙상블이라 부른다

 

 

 

zookeeper 에서 controller broker 선정

-> controller broker는 브로커의 상태 채크하고 파티션 관리

-> 브로커가 빠질 시 리더 파티션 지정

-> 만약 새로운 리더 파티션이 지정되면 정보를 모든 브로커에게 알린다

 

---

Kafka - Kafka란? (Kafka의 구조와, 주요개념)

[Kafka] 카프카란? 주요개념 및 용어 소개

Kafka - Event Streaming Platform

[Kafka] 3장 카프카 기본 개념 설명 (1)

[주키퍼, Zookeeper] 아파치 주키퍼(Apache Zookeeper) 소개 및 아키텍처

 

[Kafka] 컨트롤러 분석