카프카 주키퍼

카프카 클러스터를 운영하기 위해 반드시 필요한 애플리케이션.

카프카 3점대부터는 주키퍼가 없더라도 클러스터를 운영할 수 있으나,
완벽하게 주키퍼를 대체하지 못하여 대부분은 주키퍼가 있는 환경에서 클러스터를 운영하고 있다.

카프카 클러스터

한 개의 클러스터는 여러 개의 브로커로 이루어져 있다.

최소한 상용 환경에서는 세 개의 브로커로 운영되는 게 일반적이다.

데이터량이 많고 확장해야 할 경우 50 ~ 100개의 브로커로 운영하기도 한다.

상황에 따라서 클러스터의 용도에 따라서 클러스터를 2개나 3개 정도로 나눈다.
카프카 클러스터의 경우, 여러 대를 동시에 운영하는 경우도 많다.

카프카 브로커

카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자, 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션(프로세스)이다.
각 브로커는 하나의 피지컬 머신(서버 혹은 인스턴스)에서 동작된다.

브로커 서버 한 대로도 기본 기능이 다 제공되긴 하지만,
데이터를 안전하게 보관하고 처리하기 위해서는 3대 이상의 서버(브로커)를 한 개의 클러스터로 묶어서 운영하는 것이 일반적이다.

데이터가 한 개의 브로커에만 저장하게 되면
브로커가 장애가 발생하였을 때 데이터는 더 이상 사용하지 못하게 된다.

---

주키퍼 앙상블

주키퍼 앙상블을 이용하여 상황에 따라서 여러 종류의 클러스터를 다양하게 동시에 운영할 수 있다.

사실 여기서 root znode와 클러스터별 znode... 이러한 설명이 나와있었는데
이 부분은 좀 더 인프런 강의를 살펴본 후 다시 찾아봐야 할 요소로 보인다.

브로커의 역할

컨트롤러

클러스터의 다수 브로커 중 한 대가 컨트롤러의 역할을 한다.
컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배한다.

브로커에 장애가 생겼을 때, 그 장애가 발생한 브로커를 제외하고
그 브로커에 있던 리더 파티션의 경우 다른 팔로우 파티션이 리더로 승급하여야 하는데
이를 분배하는 역할을 하는 것이 컨트롤러 역할이다.

복습!
카프카는 기본적으로 토픽이라는 DB의 Table과 같은 개념이 있으며,
이 토픽에는 1개 이상의 파티션을 가진다. 이 파티션에 데이터가 저장된다.

카프카는 지속적으로 데이터를 처리해야 하므로 브로커의 상태가 비정상이라면 빠르게 클러스터에서 빼내는 것이 중요하다. 만약 컨트롤러 역할을 하는 브로커에 장애가 생기면 다른 브로커가 컨트롤러 역할을 한다.

브로커와 파티션이 차이?
브로커는 카프카 클러스터에서 메시지를 저장하고 클라이언트와 통신하는 서버이며,
파티션은 토픽을 나눈 메시지 저장 단위로, 각 브로커에 할당되어 데이터의 분산 저장과 처리를 가능하게 합니다.

여기서 리더 파티션과 팔로우 파티션 등. 이러한 내용이 이해가 되지 않아 chatGPT를 이용하여 이에 대해 알아보았다.

리더 파티션과 팔로워 파티션

• 리더 파티션
  실제로 읽기와 쓰기 작업을 처리하는 파티션.
  클라이언트(프로듀서와 컨슈머)는 주로 리더 파티션과 통신한다.

• 팔로워 파티션
  리더 파티션의 데이터를 복제하는 역할. 동일한 데이터를 유지하며 필요시 리더로 승급될 수 있다.

브로커 장애와 리더 파티션 승급

다음 상황을 가정해보자.

브로커 1에 파티션 A가 저장되어 있고, 파티션 A가 리더 역할을 하고 있다.
브로커 1에 문제가 생겨 다운되면, 이 파티션 A에 접근할 수 없게 된다.
이는 데이터를 읽거나 쓰는 모든 작업이 중단된다.

이 때, 팔로워 파티션을 리더로 승급하는 이유를 설명할 수 있다.

• 데이터 가용성 보장 : 만약 브로커 1이 다운되어도, 파티션 A의 복제본이 브로커 2 또는 다른 브로커에 존재한다.

• 리더 역할을 넘겨받기 : 장애가 발생했을 때, 복제본(팔로워 파티션)이 리더로 승급되면, 브로커 2에 있는 새로운 리더 파티션이 모든 데이터 읽기/쓰기 작업을 이어받는다.

따라서, 장애 발생 시 데이터의 지속적인 접근성과 시스템의 안전성을 유지하기 위해 필수적인 과정이다.

데이터 삭제

카프카는 다른 메시징 플랫폼과 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않는다. 또한, 컨슈머나 프로듀서가 데이터 삭제를 요청할 수도 없다.

오직 브로커만이 데이터를 삭제할 수 있으며, 로그 세그먼트 단위로 데이터를 삭제한다.

우리가 원하는 것만 찝어서 삭제하는 것은 불가능하고, 로직을 통해서 삭제를 수행한다고 볼 수 있다.

컨슈머의 오프셋을 저장

커밋(commit)
컨슈머가 토픽에 있는 데이터를 가져갈 때 해당 컨슈머가 어느 오프셋까지 처리했는지를 알린다.

이 커밋을 통해 컨슈머의 오프셋을 특정 토픽에 저장한다. (__consumer_offsets)

__consumer_offsets
이는 카프카를 생성하고 컨슈머를 생성하여 컨슈머 그룹 운영 시 커밋 이후에 자동으로 생성된다. 그래서 internal topic이라 부른다.
개발자나 운영자는 이 토픽을 볼 일이나 쓸 일도 없고 그러한 역할도 없다.

컨슈머가 장애나 버전 업그레이드 등으로 재시작이 된다고 하였을 때,
마지막 커밋 이후에 다음으로 처리해야 할 데이터를 바라볼 때 오프셋이 커밋된 데이터를 바탕으로 다음 오프셋부터 데이터를 가져가도록 하는 것이 컨슈머 오프셋의 역할이다.

그룹 코디네이터

컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭 되도록 분배하는 역할.
각각의 파티션은 컨슈머와 1:1로 매핑되고 만약 특정 파티션에 문제가 발생하게 되면
문제가 발생한 컨슈머는 삭제하고 컨슈머 한 대가 여러 파티션을 가져와서 데이터를 지속적으로 처리할 수 있게 된다. (rebalance)

즉, 문제가 발생하더라도 지속적으로 데이터가 처리되도록 도와준다.