[Kafka] 개요

 

보기전에 한번 보고 메시징 시스템에 대한 이해를 하고 가길 추천한다.

메시징 시스템

 

Kafka는 Open-source Distributed Event Streaming Platform이다.

Event Streaming이란? DB, Sensor, Moblie, app... 등과 같은 곳에서 발생하는 데이터를 event stream 형태로 저장해서 나중에 검색할 수 있도록 하는 것을 말한다.

 

다시 말해, Kafka는 데이터를 실시간으로 처리하고, 필요에 따라서 데이터가 또 다른 target 시스템으로 event stream을 라우팅 해주는 것이다.

 

주요 특징은 다음과 같다.

 

Event Streaming Platform

• Event Streaming을 실시간으로 처리하고 계속 쌓이는 데이터를 지속적으로 보관하다가 그 데이터를 쓰려고 하는 다른 target 시스템들이 가져갈 수 있도록 제공.

 

Publish/Subscribe(Pub/Sub) 구조

• 다른 시스템에서 데이터를 가져와서 Kafka에 publish(발행, 저장)하거나 Kafka로 부터 데이터를 subscribe(구독, 읽기) 할 수 있는 기능을 제공

 

Decoupling

• Pub/Sub 구조를 구현하기 위해 Producer와 Consumer가 존재한다.
• Producer : Kafka에 event를 publish하는 client application
• Consumer : Kafka로부터 event를 subscribe하는 client application

 

Kafka의 전체 Architecture(출처 : https://velog.io/@jwpark06/Kafka-시스템-구조-알아보기)

 

 

Kafka Componets - Broker

Broker는 메시징 서비스를 담당해주는 Kafka 서버 또는 Kafka 시스템을 말한다.

하나의 Broker는 하나의 Kafka Broker Process를 의미한다.

"Kafka를 구성한다.", "Kafka를 통해 메시지를 전달한다."에서 Kafka는 Broker를 의미한다.

 

프로세스를 구동하는 방법에 따라 다양한 방법으로 클러스터를 구성할 수 있는데 주로 multi broker를 사용한다.

Broker가 여러 개일 경우, 각각의 Broker들은 ID로 식별한다.

 

주요 역할은 토픽(Topic) 내의 파티션(Partition)들의 분산, 유지 및 관리 이다.

Broker 내부에 여러 Topic들이 생성될 수 있고, 이러한 토픽들에 의해 파티션들이 생성되게 된다.

 

Broker는 파티션의 데이터를 분산하여 저장해주기 때문에 시스템에 예기치 못한 장애가 발생하더라도 분산된 데이터를 통해 안전하게 데이터를 사용할 수 있도록 해준다.

 

브로커의 중요한 특징 중 하나는 토픽의 일부 파티션들을 포함하고 있지만, 데이터의 일부분인 파티션을 가질 뿐 전체 데이터를 갖고 있지는 않다.

 

 

Kafka Componets - Kafka Cluster

여러 개의 Broker로 이루어진 집합체를 의미한다.

일반적으로 최소 3개 이상의 Broker를 하나의 클러스터로 구성한다.

 

 

Kafka Componets - Topic

Broker에서 event(data)를 관리하는 "기준" 또는 어떤 event를 저장할 지를 정하는 "주제"이다.

파일 시스템의 "폴더"와 같고, event는 폴더 속 "파일"과 같다.

 

전통적인 메시징 시스템과는 다르게 message(event)들을 subscribe 해서 받아보더라도 그 메시지는 삭제되지 않는다. 

대신 Topic마다 지정된 기준에 따라 event를 유지할 지 정할 수 있고, 설정된 기간 또는 용량에 따라 event를 유지 시킨다.

 

 

Kafka Componets - Partition

Topic에는 Partition이 존재하며 모든 Partition들은 Producer로부터 전달된 데이터를 보관하는 역할을 한다.

 

반드시 존재하는 "리더 파티션(Leader Partition)"과 존재할 수도 있는 "팔로워 파티션(Follower Partition)"으로 구분된다.

 

리더 파티션(Leader Partition)

• Producer or Consumer와 직접 통신하는 파티션
• 직접 통신함으로써 read, write 연산을 담당

 

팔로워 파티션(Follower Partition)

• Producer에 의해 리더 파티션으로 전달된 데이터를 복제하여 저장
• 리더 파티션의 데이터를 복사하여 보관하는 역할을 하고 있다가 리더 파티션이 속해 있는 브로커에 장애 발생 시 팔로워 파티션이 리더 파티션의 지위를 가지게 된다.

 

리더 파티션과 팔로워 파티션의 개수는 Replication Factor의 수에 따라 달라진다.

Replication Factor는 Topic의 파티션의 복제본을 몇개 생성할 것인가에 대한 값이다.

 

예시1. Replication Factor=1(복제 x)

• Broker A의 리더 파티션의 데이터를 복제해서 가지고 있을 Broker B,C의 팔로워 파티션이 없음
• Broker A에만 리더 파티션이 존재, Broker A의 파티션이 3개라면, 3개 모두 리더 파티션

 

예시2. Replication Factor=3(복제 2개)

• Broker A의 리더 파티션의 데이터를 복제해서 가지고 있을 Broker B,C의 팔로워 파티션이 존재
• Broker A의 파티션이 3개라면, A,B,C는 각각 하나의 리더 파티션과 두개의 팔로워 파티션을 가짐

 

 

 

Kafka Componets - Zookeeper

분산 시스템에서 시스템 간의 정보 유지, 상태 체크, 서버들 간의 동기화 등을 처리해주는 분산 코디네이션 서비스(Distributed Coordination Service) 이다.

 

직접 어플리케이션 작업을 조율하지 않고, 조율하는 것을 쉽게 개발할 수 있도록 도와줌.

API를 이용하여 동기화를 하거나 마스터 선출 등의 작업을 쉽게 구현할 수 있도록 도와줌.

 

Zookeeper의 데이터는 분산 작업을 제어하기 위해 트리 형태의 데이터 저장 장소에 스냅샷을 저장한다.

 

Zookeeper Ensemble

• zookeeper 서버의 클러스터를 뜻한다.
• 하나의 zookeeper 서버에 문제가 생겼을 경우, zookeeper 서버들에 쌓이는 데이터를 기준으로 일관성을 맞추기 떄문에 클러스터는 보통 홀수로 구축, 최소 3개로 구축해야 하며 일반적으로 5개를 권장
• 하나의 리더 서버와 나머지 팔로워 서버로 구성
• 리더 서버 - write 담당
• 팔로워 서버 - read