✔ What is the KAFKA????

아마 대부분의 데이터 엔지니어라면, Streaming Data Pipeline 구축을 고려하면서 Apache KAFKA 를 떠올릴 것 같습니다.

KAFKA를 쉽게 이해하려면 Pub/sub Model Messaging Queue가 Kafka를 나타내는 가장 적합한 말인 것 같은데…
제 주관적인 입장에서 이 부분이 초반에 이해하기 어려운 내용이었습니다.
아래 Pub/sub model을 구성하는 기본 구성요소를 설명하고 간단한 예로 Massaging Service를 설명해보겠습니다.

Publish/Subscribe - Pub/Sub

바로 위에서 설명한 것처럼 KAFKA는 Publish-Subscribe Model을 구현한 분산 Massaging Queue System 입니다.
Publish-Subscribe Model 모델은 데이터를 만들어내는 Producer(생산자), 소비하는 Consumer(소비자)
그리고 둘 사이를 중재하는 Broker(Brocker)로 구성된 시스템입니다.

여기서 Massaging Queue System에 대해서 간단한 예를 들어서 설명드리도록 하겠습니다.
Massaging Queue System ?? : Log, Event Msg 등 API로 호출될 때 보내는 데이터를 중앙 집중화하여 처리하는 시스템

Above Architecture Info : Web Market에서 자동적으로 메일을 발송하는 시스템

간단하게 이해하기 위해서 위와 같은 아키텍쳐를 만들었습니다.
위의 아키텍처를 보다 간단하게 설명하면 각각의 이벤트 별로 서비스 Application이 분리되었을 경우
Pub/Sub 방식의 Massaging 시스템 파이프라인에서의 메시지 처리 프로세스는 아래와 같이 이루어 집니다.

• ① User Service Application에서 회원가입, Order Service Application에서 주문완료 Event가 발생.
• ② Massage Client로 메일 전송에 필요한 데이터 (User 정보, 구매 목록, 품목… 등등)를 API 호출
• ③ Message Client에서 Broker로 메시지를 Produce (메시지 생산)
• ④ Mail Service Application에서 메시지가 존재하는지 Subscription하고 있다, 메시지가 존재하면 메시지를 Consume (메시지 소비)
• ⑤ Mail Service Application에서는 받은 API 정보를 통해 User에게 메일을 발송

Cluster of Kafka?

Kafka는 처리량에 의한 확장 (scale horizontally, scale out)을 위해 보통 클러스터로 구성됩니다.
Kafka를 통해 처리되는 메시지가 늘어나면 Broker의 부하는 당연하게 증가하게 되고, 클러스터의 규모를 확장할 필요가 있습니다.
이 부분에서 여러 Broker들의 클러스터링 및 관리를 위해 Apache ZooKeeper를 사용합니다.

Kafka Cluster 위에서 Producer가 전송한 메시지는 Replication 되어 특정 Brocker의 장애 상황에서도 고가용성(High Availability)을 보장합니다.
즉 Producer가 메시지를 Cluster로 전송하면 Broker는 또 다른 Broker에게 메시지를 중복해서 저장하게됩니다.
때문에 만약 한 Broker에 장애가 생기더라도 중복 저장된 메세지를 Consumer에게 전달 할 수 있으므로 Fault-tolerant 구현이 가능합니다.

Why Kafka??

Producer/Consumer의 분리 (독립)

Kafka의 Producer와 Consumer는 완전 별개로 동작합니다.
Producer는 Broker의 Topic에 메세지를 게시하기만 하면 되고, consumer는 Broker의 특정 Topic에서 메세지를 가져오기만 하면 됩니다.
위의 구조 떄문에 kafka는 확장성이 높습니다, Producer/consumer를 필요에 의해서 늘리고, 늘이기 아주 유용한 구조이며,
다중 Producer, 다중 Consumer 구현이 가능합니다.
특정 토픽에 여러 Producer가 메세지를 전송할 수도 있고, 마찬가지로 Kafka 토픽의 메세지를 여러 Consumer가 읽어 갈 수도 있으며,
반대로 하나의 Producer가 여러 토픽에 메세지를 전송하고, 하나의 Consumer가 여러 토픽에서 메세지를 읽는 것도 가능합니다.

Consumer의 Pull 방식

메세징 시스템은 Brocker가 Consumer에게 데이터를 전달해주는 “Push 방식”과, Brocker에게서 메시지를 가져오는 “Pull 방식” 두가지가 존재합니다.
Kafka는 "Pull 방식"을 사용합니다. Pull 방식의 경우 Consumer의 처리량을 Brocker에서 신경 쓸 이유가 사라집니다.
Consumer 자체에서 처리 가능한 양의 메세지만 Brocker에서 가져가면 되기 때문에 보다 효율적으로 메세지를 처리할 수 있습니다.
또한 Producer가 보내는 속도보다 Consumer가 처리하는 속도가 느리다면, Consumer를 추가하여 처리량을 늘릴 수도 있고.
메세지를 한번에 모았다 처리하는 Batch 처리도 간단히 구현 가능합니다.

😊 Topic, Partition, Segment File1

Kafka에 전달되는 Massage Stream의 추상화된 개념을 토픽(Topic)이라고 합니다.
Producer는 메세지를 특정 토픽에 보내고, Consumer는 특정 토픽의 메세지를 구독할 수 있습니다.

Producer가 메시지를 토픽에 전송하면 Kafka Cluster에서는 토픽을 좀 더 세분화된 단위인 Partition(Partition)으로 나누어 관리합니다.
기본적으로 Producer는 전달한 메시지가 Broker Topic의 어떤 Partition에 저장되는지 관여하지 않습니다.
(다만 Key/Partitioner를 이용하여 특정 Partition으로 메시지를 전송할 수 있습니다)
각 Partition의 경우 Cluster를 구성하는 각 Brocker들이 골고루 나눠 갖게됩니다.
(Kafka 클러스터의 Brocker 중 하나가 컨트롤러(Controller)가 되어 이 분배 과정을 담당합니다.)

특정 Partition으로 전달된 메시지에는 오프셋(Offset)이라고하는 특정 숫자가 할당됩니다.
오프셋(Offset)은 여러 Partition에서 현재 해당 Partition의 메시지의 순서를 파악할 수 있는 고유한 ID 같은 개념이라고 생각하면 됩니다.
오프셋(Offset)을 이용해서 Consumer가 메시지를 가져가고, 몇 번째 오프셋까지 읽었고, 몇 번째 오프셋부터 읽겠다는 요청등을 할 수 있습니다.
오프셋은 Partition 내에서 유일한(Unique) 값을 갖습니다.

Broker는 Producer에게 받은 메세지, 즉 Partition에 저장되어 있는 메세지를 파일 시스템에 저장합니다.
이 때 만들어지는 파일이 세그먼트 파일(Segment File)입니다.
기본 Broker Config에 설정된 옵션으로는 1GB까지 세그먼트 파일이 커지거나 일정 시간이 지나면 새로운 파일을 다시 만듭니다.
또한 보존 기간이 지난 메시지가 지워질 경우, 세그먼트 파일 단위로 지워지게 됩니다.

Replication ²

Kafka는 고가용성(High Availability)을 제공하기 위해 Partition 데이터의 Replication을 설정할 수 있습니다.
몇 개의 복사본을 저장할 것인지는 Replication Factor로 설정할 수 있으며 각 토픽 별로 다르게 설정 할 수 있습니다.
만약 Replication Factor를 N개로 설정하면 N개의 Replication이 유지되고, 각 Brocker가 겹치지 않게 나눠갖습니다.
여기서 복사본은 리플리카(Replica)이고, N개중 1개의 Replica가 리더(Leader)로 선정되어 전체 클라이언트의 요청을 담당합니다.
나머지 N-1 개의 Replica는 팔로워(Follower)가 되어 리더의 변경사항을 따라가기만 합니다.
Producer와 Consumer의 쓰기, 읽기 요청은 Leader Replica에만 전송되며 추후에 자세하게 설명하겠지만,
클라이언트 설정에 따라 Follower들에게 전송되기까지 기다릴 수도 있고, Leader에게만 전송하게 유지할 수도 있습니다

여기서 Follower들은 ISR(In-Sync Replica)이라는 그룹을 구성하며 Leader를 담당하는 Brocker에 장애가 생겼을 때,
ISR에 속한 Replica가 새로운 Leader로 선정되어 다시 클라이언트 요청을 담당하게 됩니다.
만약 ISR에 있는 Follower가 Leader의 변경 사항을 따라가지 못하면 ISR에서 제외 됩니다.
Leader의 변경을 따라가지 못 한 Follower가 Leader가 되면 그 사이에 반영되지 못한 변경 사항에 대한 데이터가 유실되기 때문입니다.

Partition의 Leader와 Follower는 각자 다른 Brocker에 할당해야 데이터의 고가용성을 보장할 수 있습니다.
Kafka 버전 0.10.0 이상 부터는 Rack (물리적 서버 위치)를 식별할 수 있는 정보도 설정이 가능합니다.
즉, 데이터 센터에서 같은 랙에 있는 서버의 경우 전원이나 네트워크 스위치를 공유할 가능성이 있어 같이 장애가 발생할 수 있는데,
동일한 데이터를 가지고 있는 Leader와 팔로워 둘 중 하나는 물리적 장애에서 살아남아야 고가용성이 보장되기 때문에
물리적으로 다른 랙으로 할당할 수 있게 랙 정보를 입력할 수 있는 기능이 제공됩니다.

Reference