[Kafka] - Broker 리더 에포크

개요

안녕하세요. 이번 시간에는 브로커에 리플리케이션 복구 전략으로 리더에 포크라는 개념에 대해 알아보겠습니다.

 

혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 아래 링크를 통해 학습하고 오시는 걸 추천드리겠습니다.

[Kafka] - Broker 리플리케이션(Replication) 동작 원리

[Kafka] - Broker 리플리케이션(Replication) 동작 원리

 

리더 에포크(Leader Epoch)

리더 에포크는 카프카의 파티션들이 복구 동작을 할 때 메시지 일관성을 유지하기 위한 용도로 이용됩니다.

리더 에포크는 컨트롤러에 의해 관리되는 32비트의 숫자로 표현 되며, 리플리케이션 프로토콜에 의해 전파됩니다.

 

팔로워 장애 복구 상태

 

위 그림은 팔로워가 장애 발생 후 막 복구 된 상태입니다. 팔로워는 리더에게 리더 에포크 요청을 보내 메시지 복구 작업을 진행합니다.

 

1. 팔로워는 복구 동작을 위해 리더에게 리더 에포크를 요청합니다.
2. 요청을 받은 리더는 리더 에포크의 응답으로 1번 오프셋과 메시지 정보인 message 2정보를 팔로워에게 응답합니다.
3. 팔로워는 자신의 하이워터마크 보다 높은 1번 오프셋의 message 2 정보를 삭제하지 않고, message 2 까지 자신의 하이워터마크 정보를 상향 조정 합니다.

팔로워 복구 완료

 

위와 같이 리더 에포크를 활용해서 파티션 간에 메시지 복구 전략이 이뤄집니다.

 

만약 다른 상황으로 리더가 오프셋 1번인 message 2 까지 메시지를 저장한 다음 팔로워가 복제를 하지 못하는 상황에서 리더에게 장애가 발생 했다면 어떻게 될까요?

 

다음 상황을 가지고 리더 에포크가 어떻게 동작하는지 설명하겠습니다.

뉴 리더로 승격과 동시에 새로운 메시지 저장

 

위 그림에서 기존에 팔로워는 뉴 리더로 승격이 됐습니다. 그러면서 프로듀서로부터 새로운 메시지 message 3 이라는 정보를 전달 받아 하이워터 마크 정보를 상향 조정했습니다.

 

여기서 구 리더는 message 2 (오프셋 1)을 가지고 있고 뉴 리더는 message 3(오프셋 1)을 가지고 있습니다. 만약 이런 상황에서 리더 에포크는 어떤식으로 동작 할까요?

 

아래 그림은 장애에 구 리더는 장애에 복구된 상태입니다. 중요한 부분은 뉴 리더가 자신이 팔로워일 때 하이워터 마크와 리더일 때 하이워터 마크를 알고 있다는 것 입니다.

 

구 리더가 장애 복구

 

위 그림을 통해 복구 프로세스를 설명하겠습니다.

1. 구 리더였던 브로커가 장애에서 복구 됩니다. 복구 되는 과정에서 팔로워로 강등됩니다.
2. 팔로워는 리더에게 리더 에포크 요청을 보냅니다.
3. 뉴 리더는 0 . 번오프셋까지 유효하다고 응답합니다.
4. 팔로워는 메시지 일관성을 위해 로컬 파일에서 1번 오프셋인 message 2 를 삭제 합니다.
   (팔로워는 쓰기 권한이 없으므로, 리더에게 mssage 2 를 추가할 수 없습니다.)
5. 팔로워는 리더로부터 1번 오프셋인 message 3을 리플리케이션 하기 위해 준비합니다.

 

하지만 위와 같은 상황에서 컨슈머가 이미 구 리더에 message 2 번을 가져 간 상황이라면 메시지 유실이 발생할 수 있습니다.

 

이런 상황을 대비 하기 위해 이전에도 설명했듯이 메시지 유실이 문제가 큰 서비스는 다양한 옵션을 통해 메시지 손실을 보장합니다.

 

Kafka의 메시지 손실 방지 전략: Kafka는 메시지 유실을 최소화하기 위해 몇 가지 중요한 설정 및 메커니즘을 제공합니다:

1. acks 설정:
   • acks=all로 설정하면, 프로듀서가 메시지를 전송할 때 리더와 모든 팔로워에게 확인 응답(ACK)을 받아야만 성공으로 처리됩니다. 이 설정은 메시지 손실을 줄이는 데 효과적입니다.
2. min.insync.replicas 설정:
   • 최소 몇 개의 리플리카가 메시지를 복제했을 때만 해당 메시지를 커밋할지를 설정합니다. 이를 통해 메시지의 내구성을 강화할 수 있습니다.
3. ISR(In-Sync Replicas) 관리:
   • ISR은 리더와 팔로워들이 동일한 메시지를 가지고 있는 상태를 의미합니다. 리더 장애가 발생해도 ISR에 속한 팔로워가 리더로 승격되므로 메시지 일관성을 유지할 수 있습니다.
4. 컨슈머의 오프셋 관리:
   • 컨슈머는 커밋을 통해 어느 메시지까지 처리했는지 기록합니다. 메시지 유실을 방지하려면 오프셋 커밋 정책을 잘 관리해야 합니다. 예를 들어, enable.auto.commit=false로 설정하고, 컨슈머가 처리를 완료한 후 수동으로 커밋하는 방식도 사용됩니다.

 

이번 시간에는 리더 에포크에 대해 알아봤습니다. 혹시 모르는 개념은 댓글을 남겨주시면 감사하겠습니다.