[아키텍처] 카프카(Kafka)의 기본 개념부터 최신 KRaft까지

메세지 큐 관련하여 찾아보다가 Kafka에 대해 궁금해졌다 💭

 

Kafka

Kafka란?

많은 양의 데이터를 빠르고 안전하게 처리하는 데 특화된 분산 이벤트 스트리밍 플랫폼

 

Kafka 하는 일

📡 시스템 간의 결합도 완화 (Decoupling)

▶︎ 서비스 규모가 커지면 여러 API 서버 간의 동기(Synchronous) 호출이 증가하여 시스템 결합도가 높아짐

▶︎ 데이터를 생산하는 주체(Producer)와 소비하는 주체(Consumer)를 완벽하게 분리하여 비동기(Asynchronous) 통신 환경을 제공

예시)  프로젝트 연동규격서 등록 API가 호출되었을 때 검색 서버 인덱싱과 담당자 알림 발송이 추가로 필요하다고 가정  API 서버가 타 서버의 API를 직접 호출하는 대신, 카프카의 특정 토픽(Topic)에 '프로젝트 등록 이벤트'를 발행(Publish)하기만 하면 됨.  이후 검색 서버와 알림 서버는 각자의 타이밍에 맞춰 메시지를 구독(Subscribe)하여 처리  새로운 요구사항(예: 통계 데이터 수집)이 추가되어도 기존 API 서버의 코드는 전혀 수정할 필요가 없어 시스템 확장에 매우 유리

 

📡 대규모 트래픽의 버퍼링 및 부하 분산 (Load Leveling)

▶︎ 특정 이벤트로 인해 트래픽이 급증(Spike)할 때, 시스템 전체의 과부하를 막아주는 강력한 버퍼(Buffer) 역할을 함

▶︎ 데이터를 생산하는 속도가 데이터를 처리하는 속도보다 빠를 경우, 카프카가 대량의 메시지를 자체 큐에 안전하게 적재

    이후 백엔드 컨슈머 서버들은 자신들의 처리 능력(Throughput)에 맞춰 카프카로부터 데이터를 당겨와(Pull 방식) 처리

    이를 통해 데이터베이스나 다운스트림(Downstream) 서비스에 가해지는 순간적인 부하를 통제하고 연쇄적인 시스템 다운을 방지

 

📡 디스크 기반의 데이터 영구 저장 및 유실 방지 (Durability & Fault Tolerance)

▶︎ 일반적인 인메모리(In-Memory) 기반 메시지 큐와 달리, 카프카는 수신한 메시지를 로컬 디스크에 순차적인 파일 형태로 기록

▶︎ 메시지를 디스크에 저장함으로써 높은 내구성(Durability)을 보장하며, 설정된 보관 주기(Retention Period) 동안 데이터를 유지

    만약 메시지를 처리하던 컨슈머 서버에 장애가 발생해 다운되더라도, 데이터는 카프카에 그대로 보존

    서버가 정상화된 후, 중단되었던 오프셋(Offset) 지점부터 다시 메시지를 읽어와 재처리할 수 있어 데이터 유실을 완벽하게 방지

 

📡 실시간 데이터 스트리밍 파이프라인 구축 (Data Pipeline)

▶︎ 애플리케이션 로그, 사용자 활동 이벤트, 데이터베이스 변경 이벤트(CDC, Change Data Capture) 등 수많은 데이터 소스를 중앙 집중화하는 파이프라인 역할을 수행

▶︎ 모인 거대한 데이터 스트림은 하둡(Hadoop), 스파크(Spark) 혹은 엘라스틱서치(Elasticsearch)와 같은 빅데이터 분석 시스템이나 검색 엔진으로 실시간으로 전달

▶︎ 이기종 시스템 간의 데이터 통합을 위한 안정적이고 확장 가능한 인프라로 작동

---

Zookeeper

Zookeeper란?

Kafka 클러스터의 메타데이터를 관리하고 분산 환경의 상태를 조율하는 분산 코디네이터 역할을 수행

 

Zookeeper 하는 일

⚙️ 클러스터 메타데이터 (Metadata) 중앙 관리

▶︎ 카프카 클러스터 내부에는 수많은 토픽(Topic)과 파티션(Partition)이 존재

▶︎ 어떤 토픽이 몇 개의 파티션으로 구성되어 있는지, 각 파티션의 리더(Leader)와 복제본(Replica)은 현재 어느 브로커(Broker, 카프카 서버)에 분산되어 저장되어 있는지 등의 핵심 메타데이터를 중앙에서 안전하게 저장하고 관리

 

⚙️ 컨트롤러(Controller) 브로커 선출 (Leader Election)

▶︎ 카프카 클러스터 내의 여러 브로커 중 한 대는 반드시 '컨트롤러' 역할을 맡아야 함.

    컨트롤러는 클러스터의 상태 변화를 감지하고 파티션 리더를 재분배하는 등 클러스터를 통제하는 역할

▶︎ 자체적인 앙상블(Ensemble) 구조를 통해 카프카 브로커 중 하나를 컨트롤러로 선출하고, 만약 해당 컨트롤러 브로커에 장애가 발생하면 즉시 다른 브로커를 새로운 컨트롤러로 승격시키는 합의 과정을 수행

---

 

🤔 KRaft

과거에는 카프카 클러스터를 운영하려면 반드시 주키퍼가 함께 필요했습니다.

두 개의 무거운 분산 시스템(Kafka, Zookeeper)을 동시에 관리해야 하는 운영상의 복잡함과, 파티션이 많아질수록 메타데이터 처리 성능이 떨어지는 한계가 존재했습니다.

이를 해결하기 위해 카프카는 외부 시스템인 주키퍼 없이 독자적으로 메타데이터를 관리하는 KRaft(Kafka Raft Metadata) 아키텍처를 도입했습니다.

 

KRaft의 특징

아키텍처의 단순화

▶︎ 외부 시스템(주키퍼) 의존성을 제거하여 인프라 구성이 훨씬 단순해지고 가벼워짐

 

성능 향상

▶︎ 카프카 내부의 합의 알고리즘(Raft)을 사용하여, 수백만 개의 파티션 환경에서도 메타데이터를 훨씬 빠르고 안정적으로 처리