Kafka는 무엇인가 그리고 왜 사용하는가?

[ayeon59]

왜 Kafka인가? — 데이터 전송의 복잡성 해결

기존 문제

• 데이터 소스(A) ↔ 타겟(B) 간 직접 통신 구조에서는 전송 라인이 많아질수록 복잡해지고 포맷도 제각각이라 유지보수가 어려움


해결책: Kafka

• 데이터를 중앙에서 모아주는 허브(중개자) 역할
• 소스(Producer)와 타겟(Consumer)을 직접 연결하지 않고, Kafka를 통해 느슨하게 연결 (decoupling)
• 즉, 모든 데이터가 Kafka를 거쳐간다

---

Kafka의 구조 개념

구성 요소	역할
Producer	데이터를 Kafka로 보내는 쪽
Broker	Kafka 서버 단위 (보통 3개 이상 권장)
Topic	데이터 저장소 (폴더/테이블 개념)
Partition	Topic 내부의 분할 단위 (데이터 분산/병렬 처리용)
Consumer	Kafka에서 데이터를 읽는 쪽
Consumer Group	여러 Consumer가 하나의 작업을 나눠 읽는 그룹
Zookeeper	Kafka 클러스터 메타데이터(토픽, 브로커 상태 등) 관리

소스 코드에서 보내는 데이터 형태는 정말 다양할 수 있다.

• json, tsv,auro 등

Topic 이란?

카프카에는 다양한 데이터가 들어갈 수 있고 그 데이터가 들어가는 공간을 Topic이라고 한다.

카프카로 오는 다양한 데이터가 저장되는 논리적 공간으로, 목적에 따라 나뉜다.

• 데이터베이스의 테이블이나 파일시스템의 폴더와 비슷한 개념으로 생각해도 된다.
• 무슨 데이터를 담는지를 기준으로 나눈다. ex) 로그, 트래픽 등
• 하나의 토픽은 여러개의 파티션으로 구분된다.

---

Partition 이란?

하나의 토픽을 나누는 분할 단위

ex) click_log라는 토픽은 여러개의 파티션으로 나눌 수 있다

• 사용자는 파티션 내부에 차곡차곡 쌓인 데이터를 오래된 순으로 가져간다.
• 이때 동일 데이터에 대해 여러번 처리도 가능
  • 대신, Consumer Group이 달라야 하며
  • auto.offset.reset = earliest (가장 처음 offset 부터 읽어라) 설정이 되어 있어야 한다.
• 파티션은 기본적으로 추가만 가능하며 삭제가 불가능하다.
  • 데이터 처리를 분산시키기 위해 파티션을 늘린다

Partition 분배 방식

• Key 기반 : 같은 Key는 같은 Partition으로 순서 유지가 가능하다
• Round-Robin : 키가 없을 때에는 균등하게 분산한다.
• Custom Partitioner : 직접 로직 정의 가능
  • 예) VIP 고객만 특정 파티션으로 처리

이렇게 파티션에 저장된 데이터들은 최대 보존 시간 및 최대 보존 크기를 설정하면 옵션에 따라 삭제된다.

---

Broker 란?

• 카프카가 설치된 서버 1대로, 보통 3개 이상을 설정하는 것을 권장

---

Leader / Follower Partition 이란?

• Leader Partition : 실제 데이터 쓰기/읽기를 담당하는 partition
• Follower Partition : 복제본(Replica)으로 백업 역할을 하는 partition
• 둘 다 합쳐서 ISR (In-Sync Replica) 라고 함

왜 repllication를 사용하는가?

partition의 고가용성을 위해 사용한다.

• 만약에 replication이 1 이면 해당 브로커가 망가졌을때 파티션을 복구할 수 없음

ACK 옵션

• 0 : 어떠한 응답도 받지 않기 때문에 데이터를 전달하는 속도는 빠른데 유실 가능성 있음
• 1 : 리더 파티션에 보낸 후 응답을 받지만 복제본에 대한 응답은 받지 않기 때문에 데이터 유실 가능성 있음
• all : 리더 파티션에 보낸 후, 복제본에 전달 후 모두 응답을 받기 때문에 데이터 유실 가능성은 없으나 느림

그럼 replication이 많을수록 좋은거 아닌가?

• 아니다. 브로커의 리소스 사용량이 늘어나서 카프카에 들어오는 데이터량과 저장시간을 고려해서 개수를 적당하게 지정해야 한다.
• 보통 3개 이상의 브로커 기준으로 replication은 최소 3개를 써야 함

---

Partitioner 이란?

프로듀서가 카프카에게 데이터를 보낼 때 어떤 Partition에 보낼 지 결정을 한다

동작 방식 : 기본 파티셔너 UniformStickyPartitioner

• 레코드에 메시지 키가 있을때

  • 메시지 키 → 해시함수 → 파티션 결정
  • 메시지 키가 같으면 동일한 파티션에 들어가므로 순서대로 데이터 처리 가능

• 레코드에 메시지 키가 없을때

  • 라운드 로빈 방식 (단, 전통적인 라운드 로빈 방식은 아니고)
  • 배치로 최대한 모은 후 한 번에 골고루 분산

  예시:
  Batch 1 [로그1, 로그2, 로그3] → Partition 0
  Batch 2 [로그4, 로그5, 로그6] → Partition 1
  Batch 3 [로그7, 로그8, 로그9] → Partition 2
  

커스텀 파티셔너

• Partitioner interface 구현 가능
  • 메세지키, 메세지 값, 토픽 이름에 따라서 어느 파티션에 보낼 것 인지 정할 수 있음
  • 예를들어 error 전용 로직을 만든다면 10개 파티션중에 8개는 error에게 몰아준다는 등등

---

Consumer & Lag이란?

카프카 렉은 카프카를 모니터링 하는 중요한 지표이다.

Lag = Producer Offset - Consumer Offset
예시:

Producer Offset: 1000

Consumer Offset: 950

──────────────────────

Lag = 50 (50개 밀림!)

• 이를 통해 프로듀서와 컨슈머의 상태에 대해 유추가 가능하다
  • 주로 컨슈머 상태를 볼 때 사용
• Lag은 파티션 별로 존재한다.

Records-Lag-Max

파티션이 여러 개면 각각 Lag 존재
Partition 0: Lag = 10

Partition 1: Lag = 50  ← 최대값

Partition 2: Lag = 5
Records-Lag-Max = 50

---

Burrow란?

렉을 모니터링할 수 있는 라이브러리

Kafka-client 라이브러리를 통해 lag 정보를 가져올 수 있고 elastic/influxdb에 넣고 grafano로 볼 수 있으

• 다만 이렇게 consumer 단위에서 모니터링하는건 굉장히 위험함
• 즉 컨슈머가 개발될 때마다 해당 컨슈머에 lag정보를 특정 저장소에 저장할 수 있게 로직 개발해야 하고,

→ 이를 Go 언어로 작성한 독립적인 어플리케이션이 Burrow이다.

• 멀티 카프카 클러스터를 지원함 → burrow하나로 전부 다 볼 수 있음
• 모든 Kafke 클러스트 모니터링 해서 HTTP API를 제공
  • Response 받은 데이터를 시계열 DB에 저장해서 사용할 수 있음
  • 즉, burrow를 쓰면 많은 log를 이후 개발에 효과적으로 사용할 수 있는 것

---

메시지 브로커 vs 이벤트 브로커란?

기본적으로, 메시지 브로커는 이벤트 브로커를 대신하지 못하지만

이벤트 브로커는 메시지 브로커를 대신한다.

[메시지 브로커 (RabbitMQ, Redis Queue)]

• 메시지를 받으면 처리 후 즉시 삭제 하므로 휘발성이다.

[이벤트 브로커 (Kafka, Kinesis)]

• 이벤트를 받으면 처리가 끝나도 저장해놓고 삭제 안 하기 때문에 영구성이다
• 왜? : 서비스에서 나오는 이벤트를 마치 데이터베이스에 저장하듯이 이벤트 브로커의 큐에 저장
  • 딱 한번 일어난 이벤트 데이터를 브로커에 저장함으로써 단일 진실 공급원으로 사용 가능
  • 장애가 발생했을때 장애가 일어난 지점부터 처리할 수 있음
  • 많은 양의 실시간 스트림 데이터를 효과적으로 처리할 수 있음

---

Zookeeper (주키퍼)란?

Kafka 클러스터의 메타데이터를 관리한다.

• 카프카 클러스터의 식별 정보부터 현재 살아있는 브로커 정보, 나아가 권한 정보 등이 저장됩
• 프카 브로커들 중 일종의 지휘자 역할을 하는 컨트롤러(Controller) 브로커를 뽑는 역할을 담당