[MSA] kafka - broker

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

인프런 Dowon Lee님의 Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의를 듣고 정리한 내용입니다.😊
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의 들으러 가기👩‍🏫
✅ 추가로 kafka 에 대해 잘 정리된 블로그가 있어 참고 하였습니다. » 언제나김김

카프카 브로커(Kafka Broker)

카프카는 분산 메시징 시스템으로, 프로듀서(Producer)가 보낸 메시지를 브로커(Broker)에 저장하고 컨슈머(Consumer)가 이를 가져가는 구조로 동작한다.

카프카에 대해 조금 더 깊게 알고 싶어서 검색한 내용과 강의 내용을 섞어서 정리해보았다.

1️⃣ 카프카 브로커란?

1. 카프카 브로커란?
   • 카프카 브로커는 카프카 클라이언트(프로듀서와 컨슈머)와 데이터를 주고받으며, 데이터를 분산 저장하고 복제하여 장애 발생 시에도 안정적인 서비스를 제공하는 서버 애플리케이션이다.
   • 일반적으로 하나의 서버에는 하나의 브로커 프로세스가 실행되며,
   • 데이터의 안전한 관리와 고가용성을 위해 3대 이상의 브로커 서버를 하나의 클러스터로 구성하여 운영한다.
2. 브로커 동작 과정
   • 브로커는 프로듀서로부터 데이터를 받아 토픽(Topic)과 파티션(Partition)에 따라 저장하고,
   • 컨슈머가 요청하면 해당 데이터를 전달한다.
   • 이때 데이터는 파일 시스템에 저장되며, 페이지 캐시(Page Cache)를 활용하여 디스크 입출력 속도를 향상시킨다. 따라서 브로커를 실행할 때 힙 메모리 사이즈를 크게 설정할 필요가 없다.
     • 페이지 캐시: 운영체제에서 파일 입출력 성능 향상을 위해 사용하는 메모리 영역
3. 주키퍼(Zookeeper)와의 관계
   • 카프카 2.x 버전까지는 주키퍼(Zookeeper)를 통해 클러스터의 메타데이터(ex : 파티션 위치, 토픽 설정 정보 등)를 관리했다.
   • 주키퍼는 분산 시스템의 메타 정보를 관리하고, 브로커의 상태를 감시하며, 컨트롤러 선출 등을 담당한다.
   • 그러나 주키퍼와 브로커 간 메타데이터 불일치 문제 및 복잡성을 줄이기 위해, 카프카 2.8 버전 이후로는 주키퍼 없이 운영할 수 있는 KRaft(Kafka Raft) 모드가 도입
     • 이로써 카프카 내부적으로 메타데이터를 관리하게 되어 시스템의 일관성과 안정성이 향상되었다.

2️⃣ 브로커 내부 동작 요소

컨트롤러(Controller)

• 역할: 클러스터 내 브로커들의 상태를 모니터링하고, 브로커가 클러스터에서 제거되면 해당 브로커에 있던 리더 파티션을 재분배한다
• 특징: 컨트롤러 역할은 클러스터 내 단 하나의 브로커에 부여되며, 장애 발생 시 주키퍼 또는 KRaft를 통해 새로운 컨트롤러가 선출된다.

코디네이터(Coordinator)

• 역할: 컨슈머 그룹의 상태를 관리하고, 파티션을 컨슈머와 매칭하여 분배한다.
• 리밸런스(Rebalance): 컨슈머 그룹 내에서 컨슈머가 추가되거나 제거되면 파티션을 재분배하여 데이터 처리가 원활하게 이루어지도록 한다.

3️⃣토픽과 파티션

토픽(Topic)

• 데이터의 분류 단위로, 프로듀서가 데이터를 보낼 때 반드시 지정해야 한다.
• 하나의 토픽은 하나 이상의 파티션을 가진다.

파티션(Partition)

• 토픽 내에서 실제 데이터가 저장되는 단위이다.
• 병렬 처리의 핵심 요소로, 컨슈머 그룹이 토픽을 구독하면 파티션 단위로 컨슈머와 매핑된다.
• N:1 매핑 관계: 하나의 컨슈머는 여러 파티션을 처리할 수 있지만, 하나의 파티션은 여러 컨슈머에 매핑될 수 없다.
• 컨슈머 그룹 격리: 서로 다른 컨슈머 그룹은 동일한 토픽을 구독하더라도 독립적으로 동작하여 서로에게 영향을 주지 않는다.

파티션 개수 설정 시 고려사항

1. 데이터 처리량
   • 프로듀서의 데이터 전송량과 컨슈머의 처리 능력을 고려하여 파티션 수를 결정해야 한다.
   • 예를 들어, 프로듀서가 초당 1,000 레코드를 전송하고, 컨슈머가 초당 100 레코드를 처리할 수 있다면 최소 10개의 파티션이 필요하다.
   • 계산식: 프로듀서 전송량 ≤ 컨슈머 처리량 × 파티션 개수
2. 메시지 키 사용 여부
   • 메시지 키를 사용하면 동일한 키를 가진 메시지가 항상 같은 파티션에 저장되어 순서가 보장된다.
   • 파티션 개수가 변경되면 메시지 키의 해싱 결과가 달라져 데이터 순서가 깨질 수 있으므로, 초기 파티션 개수를 충분히 크게 설정하는 것이 좋다.
   • 파티션 수 변경 시 커스텀 파티셔너를 구현하여 기존 매핑을 유지할 수 있다.
3. 브로커 영향도
   • 파티션 수가 증가하면 브로커에서 관리해야 할 파일 수가 늘어나므로 운영체제의 파일 디스크립터 제한을 초과하지 않도록 주의해야 한다.
   • 브로커당 파티션 수를 모니터링하고 필요 시 브로커 개수를 늘려 파티션을 분산시켜야 한다.

4️⃣ 레코드와 오프셋

레코드(Record)

• 파티션에 저장되는 실제 데이터 단위
• 구성 요소: 타임스탬프, 메시지 키, 메시지 값, 오프셋.
• 브로커에 저장될 때 오프셋과 타임스탬프가 지정된다.

오프셋(Offset)

• 레코드의 고유 식별자이며, 파티션 내에서 순차적으로 증가하는 정수 값
• 컨슈머 그룹이 데이터를 어디까지 읽었는지 추적하는 데 사용된다.
• 컨슈머는 데이터를 처리한 후 커밋(commit)을 통해 오프셋을 저장한다.
• 오프셋 정보는 내부 토픽인 __consumer_offsets에 저장된다.

5️⃣ 데이터 복제와 동기화

복제 설정

• 복제 개수(Replication Factor): 토픽 생성 시 설정하며, 브로커 개수보다 클 수 없다.
• 복제 개수가 3이면 하나의 리더 파티션과 두 개의 팔로워 파티션으로 구성된다.

리더와 팔로워

• 리더 파티션: 프로듀서와 컨슈머가 직접 통신하는 파티션.
• 팔로워 파티션: 리더 파티션의 데이터를 복제하여 저장한다.
• 팔로워 파티션은 리더의 오프셋을 추적하여 동기화한다.

장애 발생 시 처리

• 리더 파티션을 가진 브로커에 장애가 발생하면, 팔로워 파티션 중 하나가 새로운 리더로 승격된다.
• 이를 통해 데이터 유실 없이 서비스의 지속성이 유지된다.

6️⃣ 브로커의 내부 동작 상세

메시지 저장과 파일 관리

• 메시지는 로그 자료구조 형태로 디스크에 저장되며, 이는 빠른 쓰기를 가능하게 한다.
• 세그먼트 파일: 파티션별로 메시지를 저장하는 파일 단위
• Zero-Copy 기술: 데이터 복사 없이 커널 영역에서 네트워크로 직접 데이터를 전송하여 성능을 향상시킨다.
  • 주의: SSL 암호화를 사용하면 제로 카피를 활용할 수 없다.

브로커의 성능 최적화

• 메시지 압축: 프로듀서에서 메시지를 압축하여 전송하면 네트워크 사용량을 줄일 수 있다.
• 메시지 배치: 프로듀서에서 여러 메시지를 한 번에 전송하여 성능을 향상시킨다.
• 페이지 캐시 활용: 브로커는 OS의 페이지 캐시를 활용하여 디스크 I/O를 최소화한다.

---

카프카 브로커는 분산 시스템에서 데이터의 안정적인 저장과 전송을 담당하는 핵심 요소다. 브로커의 구조와 동작 원리를 이해하면 카프카를 더욱 효율적으로 활용할 수 있다. 특히 운영 환경에서의 설정 최적화, 모니터링, 보안 설정 등을 통해 안정적인 서비스를 제공할 수 있다.

MSA 카테고리 내 다른 글 보러가기