kafka는 어떻게 고가용성을 유지할까?

개요

kafka는 고가용성, 내결함성이 보장된다고 합니다.

고가용성 및 내결함성이란 시스템의 일부 구성 요소가 작동하지 않더라도 계속 작동할 수 있는 기능을 말합니다.

그러면 Kafka는 어떻게 고가용성을 유지할 수 있을까요?

핵심키워드인 kafka replication factor, leader & follower, ISR를 통해 알아보고자 합니다.

 

Kafka replication factor

kafka에서는 replication 수를 임의로 지정하여 topic을 만들 수 있습니다.

replication-factor 옵션을 통해서 설정할 수 있습니다.

 

replication-factor가 1일 때

topic1 그리고 topic2의 replication factor가 1인 경우입니다.

broker1에만 저장되어 있습니다.

 

topic1의 replication factor가 2일 때

이제 broker1, broker2에서 topic1이 저장됩니다.

 

topic2의 replication factor가 3일 때

이제 broker1,2,3에서 topic2가 저장됩니다.

replication factor 수를 조정하여 replication 수를 몇 개로 할지 조정할 수 있습니다.

replication 수가 많을수록 broker 장애 발생 시 topic에 저장된 데이터 안정성이 보장됩니다.

 

 

replication factor의 수는 많을수록 좋을까?

replication이 많아진다는 것을 데이터를 저장할 때 복제로 인해 그만큼 성능이 하락될 수 있습니다.

중요한 데이터의 경우 replication factor의 수가 3으로 사용하는 것이 권장됩니다.

물론 replication은 broker에 저장되기 때문에 broker의 개수가 1개라면 replication factor는 1개 이상인 2개, 3개가 될 수 없습니다.

 

그러면 왜 replication factor가 3으로 사용되는 것이 권장될까요?

이 말은 어떻게 보면 broker의 수도 3대 이상이 권장됨을 의미합니다.

서치 하다 보면 zookeper의 quorum이라는 개념으로 분산 합의 프로토콜과 Consensus Algorithm 등의 키워드가 보입니다.

(하지만 kafka에는 zookerper가 이제 필수가 아닙니다.)

만약 replication factor가 2였을 때 하나의 broker가 동작하지 않으면 이제 리더는 홀로 남게 됩니다.

하지만 3으로 설정하면 하나의 broker가 동작하지 않더라도 이미 2개의 broker가 생존하여 있여 복제본을 계속 만들어낼 수 있습니다.

이런 leader & follower, ISR에 대한 이야기들은 밑에서 자세하게 나옵니다.

 

Leader & Follower

master & slave 그리고 primary & secondary 등으로도 설명되는 표현입니다.

topic2에 대해 replication factor를 3으로 두었다면 위의 그림과 같이 leader와 follower 모습이 구성될 것입니다.

topic으로 통하는 모든 데이터의 read/write는 오직 leader와 이루어집니다.

이때 leader가 속한 broker2가 down 되면 어떻게 될까요?

follower 중 하나가 이제 leader가 됩니다.

 

ISR(In Sync Replica)

ISR이란 쉽게 말해 replication group입니다.

topic1 끼리 ISR이 구성되고, topic2 끼리 ISR이 구성됩니다.

여기에 leader, follower의 개념이 녹아들어 가며 ISR에는 하나의 leader와 n개의 follower가 존재합니다.

 

ISR내의 모든 follower들은 누구라도 leader가 될 수 있습니다.

이를 위해 follower는 leader와 데이터가 잘 동기화되어 있어야 합니다.

 

이를 보장하기 위해서 leader는 ISR내에 존재하는 follower들을 감시하고 자신보다 뒤처지는 follower는 leader가 될 자격이 없다고 판단하여, ISR에서 강제로 제외시킵니다.

 

follower 입장에서는 leader와 동일한 데이터를 유지하기 위해 주기적으로 데이터를 pull 합니다.

 

Kafka Cluster에서 모든 broker가 down 되는 경우

낮은 확률로 모든 brokder가 down 될 수 있습니다.

이런 경우가 발생했을 때 대응할 수 있는 방법은 두 가지가 있습니다.

 

1. 마지막까지 leader였던 broker가 up 되고 다시 leader가 될 때까지 기다린다

이유는 가장 최신의 데이터를 최대한 많이 가지고 있을 가능성이 높다.

 

2. ISR과 상관없이 가장 빨리 up 되는 topic이 leader가 된다.

이유는 데이터가 조금 손실되더라도 장애 대응이 빠르다.

 

kafka에서는 2번 방법이 기본적으로 선택되어 있습니다.

1번 방법도 선택할 수 있지만 leader였던 broker가 반드시 up 되어야 하며, 가장 먼저 up 되어야 합니다.

최악의 경우 해당 broker의 장애 시간이 길어지는 경우를 생각하면 2번이 효율적일 수 있습니다.

 

정말 중요한 데이터의 경우는 kafka-mirror-maker를 사용하여 다른 kafka로 mirror 할 수 있습니다.

 

 

Kafka UI Topic 생성

안정성을 위해 Replication Factor는 3개, Min In Sync Replicas는 2로 설정하였습니다.

 

min.insync.replicas 옵션은 ack 응답을 보내기 위해 리더가 확인해야 할 최소 replication 수를 의미합니다.

따라서 acks=all으로 설정하더라도 해당 설정이 1이라면 리더만 메시지를 수신하면 되므로 나머지 브로커들에게 복제되지 않고 리더가 다운된다면 메시지 손실이 일어날 가능성이 있습니다.

 

그러면 왜 3으로 설정하진 않을까요? (3개의 브로커에 복제하면 더 안전할 것 같아요)

만약 하나의 브로커가 다운되면 가용 가능한 브로커는 2개입니다.

이 상황에서 프로듀서가 메시지를 전송하면 리플리케이션 조건을 충족할 수 없어 에러가 발생할 수 있습니다.

 

 

 

참고자료

https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-topic-replication/

https://stackoverflow.com/questions/70988693/kafka-why-3-node

https://songhayoung.github.io/2020/07/13/kafka/acks-replicas/#Introduction