[Kafka] Kafka Topic Replication

Replication

---

Kafka 는 Fault Tolerant 를 위해 Replication 을 지원한다. Replication 이 무엇인지 간단하게 말하자면, 메시지를 복제해 관리하고 이를 통해 특정 브로커에 장애가 발생해도 다른 브로커가 해당 브로커의 역할을 대신할 수 있도록 하는 것이다.

 

Replication Factor

---

Replication Factor 는 토픽의 파티션의 복제본을 몇 개를 생성할 지에 대한 설정이다. 카프카에서는 Replication Factor 를 임의로 지정해 토픽을 생성할 수 있는데, Factor 를 2 로 설정하면 복제본을 한 개 생성하고 3 으로 설정하면 두 개의 복제본을 생성한다는 의미이다. 이해를 위해 다음의 그림을 통해 설명을 덧붙이겠다.

위의 그림은 topic01 과 topic02 모두 replication factor 를 1로 설정한 경우이다. (여기서 Partition 은 고려하지 않겠다.) 이에 대해 topic01 는 replication.factor 를 2로, topic02 는 3으로 설정한 경우를 다음 그림에서 볼 수 있다.

이와 같이 Replication Factor 를 조정해 replication 의 수를 몇 개로 설정할 지 관리자가 조정할 수 있다. replication 수가 많을수록 브로커 장애 시 토픽에 저장된 데이터의 안전성이 보장되기 때문에 중요 데이터의 경우는 replication factor 를 크게 설정하는 것이 좋다. 물론 replication 이 많아지면 그만큼 데이터의 복제로 인한 성능 하락이 있을 수 있기 때문에 무조건 크게 설정하는 것이 권장되지는 않는다.

 

Leader & Follower

---

Rabbit MQ 의 경우 복제본이 2개 존재하는 경우 하나를 Master, 다른 하나를 Mirrored 라 표현하는데 이러한 용어는 어플리케이션마다 상이하다. Kafka 에서는 Leader / Follower 라는 용어를 사용하는데, 위 그림에서 Replication 을 표현했던 것에 Leader, Follower 를 연결해 보자.

topic01 은 두 개의 복제본을 가지고 있어 하나는 Leader / 다른 하나는 Follower 로 구성되고, topic02 는 하나의 Leader / 두 개의 Follower 로 구성된다. 카프카는 Leader 에게 특별한 기능을 부여했는데, 그 기능이란 다음과 같다.

Topic 으로 통하는 모든 데이터의 Read/Write 는 오직 Leader 를 통해서 이루어진다.

위와 같이 기능을 하기 위해, 리더는 항상 정상적으로 동작해야 한다. 하지만 어떻게 그렇게 할 수 있을까? 리더도 똑같은 브로커 중 하나일 뿐인데 장애가 발생하지 않으리란 보장이 있을까?

 

답을 간단하게 얘기하자면, 리더와 팔로워는 변경될 수 있다. 카프카는 리더가 장애가 발생하면 기존의 팔로워 중 하나가 리더가 될 수 있는 Failover 방식을 채용하고 있다. 자세한 것은 아래의 ISR 에서 이어서 설명하겠다.

 

ISR (In-Sync Replication)

---

ISR 이라는 용어는 다소 생소하지만 간단하게 얘기하면 Replication Group 이라 표현할 수 있다. 위에서 토픽 별로 Replication Factor 를 설정해 Replication 을 생성했는데, 각각의 토픽으로 묶인 Replication 들을 ISR 이라 칭한다.

위 그림에서 보는 것과 같이 하나의 ISR 에는 하나의 Leader 와 n 개의 Follower 가 존재한다. ISR 의 규칙은 다음과 같다.

ISR 내의 모든 Follower 들은 Leader 가 될 수 있다.

 

Broker Down Situation

 

위의 규칙으로 인해 리더가 장애가 발생할 경우 ISR 내의 팔로워 중 하나가 리더가 되는 것이다. 이 부분에 대해서는 추가적으로 설명이 필요하다. 우선은 장애가 발생했을 때 어떤 일들이 벌어지는 지 그림과 같이 이해해보자.

 

만약 위와 같이 broker1 이 down 되었다고 하자. topic01 의 리더와 topic02 의 팔로워가 다운되었기 때문에 다음과 같은 변화가 생긴다.

topic01 의 경우, ISR 내에 하나의 팔로워가 존재하고, 위에서 설명한 누구든 ISR 내의 follower 는 leader 가 될 수 있다는 조건을 충족하기에 기존의 팔로워가 새로운 리더가 된다. 이때, 일시적으로 리더가 존재하지 않기 때문에 Read/Write 의 Timeout 이 발생할 수 있지만, Retry 가 일어나면 새로운 리더에 Read/Write 할 수 있으므로 장애 상황은 아니다.

topic02 는 팔로워 하나가 다운되었고, 다운된 팔로워가 ISR 에서 제외된다. topic01 과 다르게 리더는 변하지 않았기 때문에 아무런 특이사항 없이 read/write 가 계속 이루어진다.

추가적으로 브로커 2까지 다운되었다고 가정해보자. topic01 의 경우 ISR 내의 더 이상의 팔로워가 없기 때문에 리더를 넘겨줄 수 없고, 리더가 없기 때문에 read/write 를 지속할 수 없다. 즉, topic01 의 경우는 read/write 가 불가능한 장애 상황이 된 것이다. topic02 의 경우는 ISR 내에 남은 팔로워가 있기 때문에 해당 팔로워가 리더를 이어받아 read/write 를 지속한다.

 

위의 예제를 통해, 브로커에 장애가 발생한 경우 리더가 어떻게 변경되고, ISR 이 변경되는지 설명했다. 추가적으로 이와 같은 동작을 위해 카프카가 내부적으로 어떤 동작들을 하는 지 알아보자.

 

먼저 우리가 토픽을 만들고 옵션으로 Replication Factor 를 설정하면, 설정에 맞게 위의 예제와 같이 ISR 이 구성된다. ISR 이 구성되면 리더와 팔로워는 각자 역할이 주어지고 그 역할을 수행하기 시작하는데, 그 역할은 다음과 같다.

Leader : 팔로워를 감시하고 팔로워들 중 자신보다 일정 기간 뒤쳐진 팔로워가 발생하면 해당 팔로워가 리더가 될 자격이 없다고 판단하고, 뒤쳐진 팔로워를 ISR 에서 제외한다.
Follower : 리더와 동일한 내용을 유지하기 위해 일정 주기마다 리더로부터 데이터를 가져온다.

위에서 설명한 역할을 그림을 통해 살펴보자. 우선 리더의 입장에서, 리더는 ISR 내의 팔로워들을 감시하고, 뒤쳐진 팔로워를 ISR 에서 제외한다. 추가적으로, 브로커가 다운되는 경우에 팔로워는 리더로부터 데이터를 가져오지 못하고, 이러한 상황이 일정 시간동안 지속되면 리더는 해당 팔로워가 뒤쳐졌기 때문에 팔로워에게 리더를 넘길 수 없다 판단해 해당 팔로워를 ISR 에서 제외시키는 것이다.

반대로, 팔로워 입장에서 보면 ISR 내의 팔로워는 언제든 리더가 될 수 있어야 하기 때문에 리더와 동일한 데이터를 유지하는 것이 매우 중요하다. 따라서 팔로워는 리더를 계속 바라보며 컨슈머들이 카프카에서 데이터를 가져가는 것과 동일한 방법으로 주기적으로 데이터를 풀링한다. 매우 짧은 주기마다 새로운 데이터를 체크하며 리더와 동기화를 하게 된다.

 

결국 동일한 ISR 내에서 리더와 팔로워는 데이터 정합성을 위해 각자의 방식으로 서로를 계속 체크하며 Fault-Tolerance 한 메시지 시스템을 제공하는 것이다.

 

All Down Situation

모든 브로커가 다운되는 상황은 거의 발생하지 않지만, 발생할 수 있는 가능성이 아주 조금이라도 존재하기 때문에 이에 대해 인지하고 대응할 방안을 고려하는 것이 필요하다. 

 

그림을 통해 순서대로 상황을 설명하자면 다음과 같다.

프로듀서가 위와 같이 파란색 메시지를 카프카에 보냈고, Leader 와 두 Follower 모두 메시지를 전달받았다. 하지만 메시지가 전달되자마자 브로커3 이 다운되었다.

다음으로 프로듀서가 초록색 메시지를 보냈고, 위와 마찬가지로 동작하는 리더 / 팔로워에게 모두 메시지가 전달되었다. 하지만 브로커2가 메시지를 받고 바로 다운되었다.

세 번째로 프로듀서가 분홍색 메시지를 보냈고, 리더에게만 전달되었다. 하지만 리더가 동작중이던 브로커1이 바로 다운되면서, 결국 모든 브로커가 다운되었다.

이러한 경우에 대응할 수 있는 방법이 두 가지가 있다.

1. 마지막까지 리더였던 브로커1이 다시 Up 되고 리더가 될 때까지 기다린다.
2. 리더 / 팔로워 상관없이 가장 빨리 Up 이 되는 브로커의 파티션이 리더가 된다.

카프카는 기본 설정으로 2번 방법을 사용한다. 동작 방식을 설명하기 위해, 가장 적은 메시지를 보유한 브로커3 이 가장 먼저 Up 되는 상황을 살펴보자.

파란색 메시지만 저장한 브로커3 이 Up 되고, 새로운 리더가 되었다. 새로운 리더가 된 후 프로듀서가 보라색 메시지를 보냈고, 리더에게 잘 전달되었다.

이후 브로커1 / 브로커2 가 모두 Up 되었고, 자동으로 팔로워로 이들이 연결되면서 리더로부터 데이터를 복제한다. 이 과정에서 결과적으로 초록색, 분홍색 메시지는 손실되었다.

 

위의 예제에서, 카프카의 설정을 변경함으로써 1번 방법으로 대응할 수도 있다. 1번 방법은 모든 브로커가 다운되는 상황에서도 데이터 손실 가능성이 적기 때문에 좋은 대응방안이 될 수 있다. 하지만 여기에는 조건이 붙는데, 마지막 리더인 브로커1 이 반드시 Up 되어야 하고, 또 가장 먼저 Up 되어야 한다. 그렇게 될 경우 거의 손실 없이 모든 데이터의 복구가 가능하다. 이와 같은 장점이 있는 반면, 최악의 경우 브로커1이 기계적 결함으로 Up 이 되지 않거나 Up 되는 데 오랜 시간이 걸릴 경우 장애 상황인 채로 막연히 기다리게 되는 문제가 있다.

 

위와 같은 문제로 인해, 일반적으로 빠른 장애 대응이 가능한 2번 방법을 적용하고 데이터의 손실을 감안하는 방법이 효율적일 수 있다. 물론 위와 같이 클러스터 전체가 다운되는 경우는 거의 발생하지 않지만, 앞서 언급했듯 가능성이 있다는 것만으로 대응할 준비는 필요하다.

 

#Reference.

Kafka 운영자가 말하는 Topic Replication | Popit