[Kafka 원리] replication-factor, ISR , 리더 에포크, 가용성 알아보기

목차

• replication factor
  • leader-follower
  • ISR(In Sync Replica)
  • Push방식이 아닌 Pull방식
  • hive water mark
  • leader epoch

Replication factor

kafka에서는 cluster를 구성하고 고가용성을 유지 하기 위해서 replication(복제)을 해야합니다. 복제를 얼마나 할 것인지에 대해 topic을 생성할 때 설정을 할 수 있습니다. 아래 그림과 같이 topic 1 을 복제를 2번 한다고 하고, topic2를 복제를 3번한다고 하면 아래와 같이 복제를 하게 됩니다. 복제는 broker가 장애 시에 다른 broker에서 메세지를 produce 및 consume합니다.

Leader - Follower

여기서 Producer가 진짜로 메세지를 보내는 대상인 Leader가 존재 하며 복제본을 가지고 있는 Follower가 존재 하게 됩니다. 예로 아래 그림 처럼 Leader와 Follower가 존재 할 수 있습니다. 여기서 알아야 할 것은 leader만 read/write가 가능 하다는 점입니다.

ISR(In Sync Replica)

Sync Replica는 복제가 동기화 되는 것을 이야기 합니다. Kafka는 Replica를 진행 할 때 동기화가 메세지 복사가 잘된 Follower들을 구성하여 목록을 가지고 있습니다. Leader가 장애 발생 시 ISR 목록에서 Leader를 선출합니다.

Push방식이 아닌 Pull방식

다른 메세지 큐와 달리 kafka는 leader가 메세지를 복제하라고 follower들에게 message push 해주는 방식이 아닌 message가 준비 됬으니 가져가서 복제해 놔라고 하는 message pull 방식을 사용합니다. Leader는 복제를 진짜 잘 가지고 가고 있는지의 기준을 잡고 ISR 목록을 구성합니다.

Pull 방식에서의 Follower선출

Leader가 message를 read/write하고 이 내용을 Follower가 가져가서 message를 복사한다고 했는데 Leader 는 어떤 Follower가 준비 되었는 지 확인이 불가능 합니다. 그럼 잘 복제 됬는지 안됐는지 모르는 상태로 남아있는데 어떻게 Follower라 잘 복재하고 있는지 인지하고 목록을 구성할 까요? 다음 내용을 참고해봅시다.

Message Commit(=high watermark)

방식을 알기 전에 먼저 메세지 commit에 대해 알아야 합니다.

Producer가 Message 3개 보냈을 때

message를 3개 보냈을 때 리더가 주로 read/write를 하기 때문에 3개의 메세지를 먼저 다 가지고 있습니다. 그리고 Follower가 Pull을 하여 메세지를 복제 했습니다. follower1은 2개 follower2 는 1개를 복제 했다고 하면 M1 메세지가 준비 되었다고 하면서 watermark가 찍힙니다.

메세지가 다시 5개가 들어왔다면 leader는 메세지를 8개 가지고 있습니다. Follower1이 메세지를 복사했지만, Follower 2 는 복사하지 못했습니다. 이렇게 잘 따라오는지 못하는지 확인을 하여 잘 못따라 온다면 ISR 그룹에서 제외 시키게 됩니다. 또한 replica가 2로 되어있는 topic이기 때문에 복제가 2번 되지 않아서 commit도 진행 되지 않습니다.

다시 Follower2 가 메세지를 복제하면 ISR 목록에 편입되며, Commit도 진행 되게 됩니다.

ISR 편입 주요 옵션

Commit에 대해 알아 봤는데 이렇게 Commit이 되었다고 알려주면 Leader는 ISR에 편입해 주게 됩니다. 그럼 메세지가 영원히 안들어오는 경우는 어떻게 할까요? 그래서 주요 옵션을 알아야 합니다. ISR 편입 조건 주요 옵션은 아래 두가지 옵션입니다. Leader는 Leader 자기 자신이 장애 시 Follower에게 Leader를 넘길 수 있는 상태를 체크하고 목록을 구성합니다. Leader는 아래 설정에 해당하지 않는다면, Follower를 탈락시키고 새로운 Follower를 찾아 메세지를 복제 시킵니다. 

• replica.lag.max.messages - follower들이 최대 몇 개까지 복제가 늦어져도 되는지 설정
• replica.lag.time.max.ms - follower들이 max message를 벗어났을 때 max message 보다 안쪽으로 들어올 때 까지 기다리는 최대 시간 설정

Leader epoch

epoch는 시대라는 뜻입니다. Leader가 죽었을 때 시로운 리더가 돼면서 epoch가 바뀌게 되는데 그 과정에 대해 알아야 할 것 같습니다. 예를 들어서 아래와 같은 상황이 있다고 가정해 보겠습니다. 기존의 Leader가 장애가 발생하였다고 하고, 들어와있던 message가 commit되지 않은 상태라고 해보면 아래와 같은 그림이 될 수 있습니다. 이따 새로운 Leader가 선출 되었다면 기본에는 epoch0 이였지만 epoch = 1로 바뀝니다.

 

이 때 새로운 commit되진 않았지만 m6가 복제되어 있습니다. 하지만 leader에서 온 메세지가 아니기 때문에 m6메세지는 삭제 됩니다. 그리고 새로운 leader를 맞을 시대 epoch가 1로 올라 갑니다.

이 때 새로운 leader에 메세지가 2개가 들어왔다고 하면 그림과 같이 write가 됩니다. 그리고 새로운 epoch 를 가진 follower는 이 leader가 가진 메세지를 복제 합니다.

Kafka는 위와 같은 내용(leader-follower, ISR, commit, leader epoch)으로 가용성을 유지 하게 됩니다.

 

Producer가 acks를 설정하여 보낼 때 주요사항

위와 같은 경우는 M6가 메세지가 삭제 됩니다. 그럼 메세지 유실이 발생했다는 뜻인데 이를 예방 할려면 어떻게 해야 할까요? ack=all로 설정 하였을 때 복제가 최소 복제 기준을 적용할 수 있습니다.  min.sync.replica속성을 이용하여 최소로 복제 되는 조건을 정해 최소 복제 조건에 해당하면 ack return해줍니다.

• replicas.factor=3, min.insync.replicas=2, acks=all
• min.sync.replica속성은 ack=all일 때 만 적용된다

 

 

 

 

 

참고문헌

https://www.cloudkarafka.com/blog/what-does-in-sync-in-apache-kafka-really-mean.html

https://www.slideshare.net/ConfluentInc/hardening-kafka-replication

https://medium.com/sfu-cspmp/in-depth-understanding-of-apache-kafka-in-10-minutes-255da627b9e