개발이 취미인 사람

[Kafka] - Kafka 브로커 동작 원리 (1) 본문

백앤드(Back-End)/Kafka

[Kafka] - Kafka 브로커 동작 원리 (1)

RyanSin 2024. 8. 2. 18:18
반응형

개요

안녕하세요. 이번 시간에는 Kafka 동작원리에 대해 알아보겠습니다.

 

혹시 Kafka 기본 개념에 대해서 잘 알지 못 하시는 분들은 아래 링크를 통해 학습을 하고 오시는 걸 추천드리겠습니다.

[Kafka] - 기본 개념

 

[Kafka] - 기본 개념

개요안녕하세요. 이번 시간에는 Apache Kafka의 대해 알아보겠습니다.  Apache Kafka(이하: 카프카)는 아파치 재단에서 만든 오픈소스 메시지 브로커 프로젝트입니다.  위 그림은 메시지 브로커 기본

any-ting.tistory.com

 

리더와 팔로워

기본 개념 시간에 Kafka 클러스터 환경에서는 여러 Broker를 구성했을 때 리더와 팔러우가 존재한다고 말씀을 드렸습니다.

리더와 팔로우 구조


Producer와 Consumer는 리더 브로커와 연결해서 메시지를 전송하고 소비합니다.  전달 받은 데이터는 리더 브로커에 저장되며, 팔로워 브로커는 메시지를 가져가서 복제 합니다.

 

만약 리더 브로커가 장애가 발생한다면 팔로워 브로커는 새로운 리더로 승격되며 장애가 발생한 브로커는 새롭게 실행되는 순간 팔로워 브로커로 강등됩니다.

 

리더 브로커가 메시지를 처리하는 동안 팔로워 브로커는 내부적으로 언제든 리더로 승격할 준비를 하며, 리더 브로커가 새로운 메시지를 전달 받았는지 확인하고 해당 메시지를 가져갑니다.

 

ISR(In Sync Replica) - 메시지 복제와 커밋

기본적으로 리더와 팔로우는 ISR(In Sync Replica)이라는 논리적 그룹으로 묶어 있습니다.

실제 ISR 그룹에 묶여 있는 팔로워들만 리더의 자격을 가질수 있기 때문에 포함되어 있지 않는 팔로워는 자격을 가질 수 없습니다.

 

ISR 내의 팔로워들은 리더와의 데이터 일치를 유지하기 위해 지속적으로 리더의 데이터를 따라가게 되고, 리더는 ISR 내 모든 팔로워가 메시지를 받을 때까지 기다립니다.

 

왜 기다릴까요?.

 

팔로워가 네트워크 오류, 브로커 장애 등 여러 이유로 리더로부터 리플리케이션을 하지 못하는 상황이 발생합니다.

이런 상황이라면 팔로워와 리더는 불일치하기 때문에 해당 팔로워가 리더가 되면 데이터 불일치 문제가 발생할 수 있습니다.

 

이 문제를 해결하기 위해 리더 브로커는 팔로워 브로커가 제대로 동작했는지 감시합니다. 즉, 리더는 읽고 쓰는 동작은 물론 팔로워가 리플리케이션 동작을 잘 수행하고 있는지도 판단합니다.

 

만약 팔로워가 특정 주기의 시간만큼 복제 요청을 하지 않는다면, 리더는 해당 팔로워가 리플리케이션 동작에 문제가 발생했다고 판단해 ISR 그룹에서 추방시킵니다.

 

ISR 안에 모든 팔로워의 복제가 완료되면, 리더는 내부적으로 커밋되었다는 표시를 하게 됩니다.

여기서 중요한 개념은 마지막 오프셋 위치를 하이워터마크(High water mark) 라고 부릅니다. 즉, 커밋되었다는 것은 리플리케이션 팩터 수의 모든 리플리케이션이 전부 메시지를 저장했음을 의미합니다.

 

팔로워 브로커들이 복제 완료 후 리더에게 복제된 마지막 오프셋을 전달하며, 리더 브로커는 모든 팔로워가 복제한 가장 낮은 오프셋을 하이워터마크로 설정합니다.

 

 

만약 그렇다면 리더 브로커에게 새로운 메시지가 전달되었는데 팔로워 브로커에게 메시지를 복제하지 못하고 장애가 발생하면 어떻게 될까요?

 

사실 위아 같은 상황이라면 메시지 유실이 맞습니다. 이런 부분은 다양한 전략을 통해 메시지 무손실을 보장하는 로직을 만들거나 아니면 Producer과 Broker 옵션을 설정해서 처리해야 합니다.

 

  1. acks 값을 all(-1)로 설정 - Producer
    - 리더 브로커와 모든 ISR이 메시지를 기록한 후 확인 응답을 보냅니다. 이는 내구성이 가장 높습니다.
      나머지 1 또는 0은 데이터 손실 가능성이 있습니다.

  2. min.insync.replicas 설정 - Broker
    - min.insync.replicas 설정은 브로커가 메시지를 커밋하기 위해 필요한 최소한의 동기화된 리플리카 수를 지정하는 옵션입니다.
       만약 min.insync.replicas=2 설정 했다면, 브로커가 최소한 2개의 ISR(In-Sync Replica)에 메시지가 복제될 때만 메시지를
       커밋할 수 있도록 합니다.
       min.insync.replicas 값보다 ISR의 수가 적으면 브로커는 메시지를 커밋하지 않고, 프로듀서에게 오류를 반환합니다.

 

이번 시간에는 브로커간에 데이터 전달 방식에 대해 알아봤습니다. 실제 개념을 알고 사용하는게 중요하기 때문에 꼭 실습하시는 걸 추천드리겠습니다.