Kafka Replication (메시지 복제) 이해하기

- 목차

 

Replication 이란 ?

Topic 은 Kafka Message 들을 저장하고 관리하는 주체입니다.

이러한 Topic 은 여러 Partition 들로 나뉘어집니다.

기본값으로 제공되는 Partition 은 3개입니다.

그래서 Topic 으로 삽입되는 Kafka Message 들을 각각 Partition 으로 나뉘어져 저장이 됩니다.

Partition 의 갯수만큼 N 분의 1로 저장되는 느낌이죠.

 

그리고 각 Partition 은 Replication 처리가 되어 여러 Broker 들로 복제되어 분산됩니다.

Partition 의 Replication 은 카프카가 데이터의 Persistency, Consistency 그리고 Fail-Over 를 구축하는 방식입니다.

 

Topic - Partition - Replication 의 관계를 설명하기 위해서 아래 이미지를 한번 봐주세요.

 

< 출처 : https://blog.ippon.tech/event-driven-architecture-getting-started-with-kafka-part-2/ >

 

위 이미지에 해당하는 Kafka Cluster 는 아래와 같은 구조를 가집니다.

- 4개의 Broker ( broker 0 , broker 1, broker 2, broker 3 )

- 1개의 Topic ( Orders )

- 4개의 Partition ( "Orders" Topic 은 4개의 Partition 을 가집니다. )

- 3개의 Replication-Factor

 

broker 0 는 Partition 3 의 Leader Broker 입니다.

broker 1 은 Partition 1 의 Leader Broker 입니다.

broker 2 은 Partition 0 의 Leader Broker 입니다.

broker 3 은 Partition 2 의 Leader Broker 입니다.

각각의 Leader Broker 는 Client 의 Read/Write 를 책임지는 메인 서버가 됩니다.

 

반면 broker 0 은 Partition 0, Partition 1 의 Replication Broker 입니다.

broker 1 은 Partition 0, Partition 2 의 Replication Broker 입니다.

broker 2 은 Partition 2, Partition 3 의 Replication Broker 입니다.

broker 3 은 Partition 1, Partition 3 의 Replication Broker 입니다.

그래서 Leader Broker 가 메시지 생성을 처리한 결과를 받아 복제를 수행하게 되죠.

 

즉, 하나의 Broker 는 Leader 이자 Replication Broker 가 될 수 있습니다.

그리고 Replication 은 가능한 물리적으로 분산된 여러 Broker 에 분배되어 배치됩니다.

 

Leader and Follower.

Kafka Broker 들은 특정 Partition 의 Leader 또는 Follower 가 될 수 있습니다.

대부분 하나의 Broker 는 Leader 와 Follower 의 역할을 동시에 수행하는 경우가 많습니다.

Leader Broker 는 특정 Partition 에 Kafka Message 를 Read/Write 하는 Client 와 직접적인 소통을 합니다.

그리고 Follower Broker 는 전적으로 Leader Broker 가 제공하는 Kafka Message 를 Replication 하는데에 집중합니다.

 

아래 이미지는 Follower Broker 의 Replication 과정을 설명합니다.

Leader Broker 로부터 생성된 Record 를 전달받아 Replication 을 수행하게 됩니다.

 

< 출처 : https://medium.com/nerd-for-tech/apache-kafka-quick-start-1edeef53773e >

 

 

Acknowledgement.

Kafka 는 Record 의 Replication 을 보장하기 위해서 Acknowledgement 라는 개념을 사용합니다.

Producer 는 Record 를 생성하기 위해서 Partition 의 Leader Broker 에게 요청을 전달합니다.

key, value, header, timestamp 등의 데이터를 담아 하나의 Record 를 만들고, Producer 는 생성 요청을 전달하죠.

생성 요청을 전달받은 Partition Leader Broker 는 자신의 Log Segment 에 해당하는 Record 를 저장합니다.

그리고 Replication 이 시작됩니다.

Leader Broker 는 Follower Broker 들에게 생성해야하는 Record 를 전달합니다.

Follower Broker 를 전달받은 Record 를 복제하여 저장하죠.

여기까지가 Record 의 생성을 위한 과정입니다.

아래의 흐름대로 데이터 생성 요청이 전달됩니다.

Producer --> Leader Broker --> Follower Broker

 

Acknowlegement 는 생성의 역방향으로 전달됩니다.

Acknowlegement 는 Record 가 정상적으로 생성이 된 경우에 Successful Write 상태를 이전 Broker 또는 Client 에게 응답합니다.

Follower Broker 는 Leader Broker 에게 Record 가 생성되었다는 결과를 전달합니다. (Ack)

Leader Broker 는 Product 에게 Record 가 생성되었다는 결과를 전달합니다. (Ack)

Follower Broker --> Leader Broker --> Producer

 

 

Producer Acks.

Producer 의 acks 는 Kafka Message 의 Replication 이 보장되는 수준을 의미합니다.

acks 는 0, 1, all 세가지 값을 가질 수 있습니다.

 

acks 이 0 인 경우에는 Fire-and-Forget 방식으로써 Replication 을 고려하지 않습니다.

Producer 는 Record 의 생성 요청을 Leader Broker 에게 보내고, 그 이후의 응답은 전혀 고려하지 않습니다.

acks 를 0 으로 설정함으로써 얻을 수 있는 이득은 데이터 처리의 퍼포먼스입니다.

하지만 이는 데이터의 일관성 (Consistency) 을 보장할 수 없습니다.

 

그리고 acks 가 1 인 경우는 Leader Broker 의 데이터 쓰기를 보장합니다.

level 이 1 인 acks 를 "acks == leader" 라고 표현하기도 합니다.

acks 가 1 인 상황에서는 Leader Broker 가 성공적으로 Record 를 저장하였다면, 바로 Producer 로 응답을 하게 됩니다.

즉, Follower Broker 의 Replication 을 고려하지 않습니다.

 

마지막으로 acks 이 all 또는 -1 인 케이스입니다.

이는 Topic 의 min.insync.replicas 값만큼 Replication 을 보장하게 됩니다.

replication-factor 이 3 이고, min.insync.replicas 가 2 라면

Producer 는 적어도 2개의 Replication 이 성공한 이후에 Leader Broker 로부터 응답을 받을 수 있습니다.

 

그래서 Kafka Acks 는 메시지의 생성 속도와 메시지의 안정성을 반비례하는 구조를 취합니다.