[ Kafka ] - 카프카의 개념에 대한 설명

이벤트 스트리밍 플랫폼

---

Kafaka는 세가지 주요 기능을 결합해서 end-to-end 이벤트 스트리밍을 구현할 수 있게 됩니다.

 

• 이벤트 스트리밍을 지속적으로 발행하고 구독.
• 이벤트 스트리밍을 원하는 만큼 내구성 있고 안정적으로 저장. KafkaCluster(broker)
• 이벤트 스트림을 발생 시 또는 소급하여 처리.

이 기능은 모두 분산되고 확장성이 뛰어나고 탄력적이고 내결함성이 있으며 안전항 방식으로 제공됩니다. Kafka는 베어메탈 하드웨어, 가상 머신, 컨테이너, 온프레미스 및 클라우드에 배포할 수 있습ㄴ다. 

 

메시지 큐(Message Queue: MQ)

---

메시지 지향 미들웨어(Message Oriented Middleward: MOM)은 비동기 메시지를 사용하는 각각의 응용프로그램 사이의 데이터 송수신을 의미하고, 이를 구현한 시스템을 메시지 큐(Message Queue: MQ)라고 합니다. 

 

많이 사용하는 오픈소스 MQ로는 RabbitMQ, ActiveMQ, RedisQueue등이 있습니다.

 

Kafka는 이벤트 스트리밍 플랫픔으로서, 여러가지 작업을 할 수 있고 MQ처럼 메시지 브로커 역할을 할 수 있도록 구현하여 사용할 수도 있으며 기존 범용 메시지브로커들과 비교했을 때 아래와 같은 특징이 있습니다.

 

• 대용량의 실시간 로그 처리에 특화되어 있어 TPS가 우수하다.
• 분산 처리에 효과적으로 설계되어 병렬처리와 확장(Scaleout), 고가용성(HA)에 용이하다.
• 발행/구독(Publish-Subscribe) 모델 (Push-Pull 구조)
  • 메시지를 받기를 원하는 컨슈머가 해당 토픽(topic)을 구독함으로써 메시지를 읽어오는 구조
  • 기존에 퍼블리셔나 브로커 중심적인 브로커 메시지와 다릴 똑똑한 컨슈머 중심
  • 브로커의 역할이 줄어들기 때문에 좋은 성능을 기대할 수 있게 됨
• 파일 시스템에 메시지를 저장함으로써 영속성(durability)가 보장됨.
  • 장애시 데이터 유실 복구 가능
  • 메시지가 많이 쌓여도 성능이 크게 저하되지 않음
  • 대규모 처리를 위한 batch 작업 용이

 

주요 개념 및 용어

---

• KafkaCluster: 카프카 브로커들의 모임. Kafka는 확장성과 고가용성을 위해서 broker들이 클러스터로 구성됩니다.
• Broker: 각각의 카프카 서버
• ZooKeeper: 카프카 클로스터 정보 및 분산처리 관리 등 메타데이터 저장. 카프카를 띄우기 위해 반드시 실행되어야 합니다.
• Producer: 메시지(이벤트)를 발행하여 생산하는 주체
• Consumer: 메시지(이벤트)를 구독하여 소비하는 주체

 

토픽, 파티션, 오프셋

---

카프카에 저장되는 메시지는 topic으로 분류, topic은 여러개의 partition으로 나누어집니다.

 

• Topic: 메시지를 구분하는 단위
  • 파일시스템의 폴더, 메일함과 유사함 ex)주문용 토픽, 결제용 토픽 등
• Partition: 메시지를 저장하는 물리적인 파일
  • 한 개의 토픽은 한 개 이상의 파티션으로 구성됨.
  • 파티션은 메시지 추가만 가능한 파일(append-only)
• offset: 파티션내 각 메시지의 저장된 상대적 위치
• 프로듀서가 넣은 메시지는 파티션의 맨 뒤에 추가 (Queue)
• 컨슈머는 오프셋 기주으로 마지막 커밋 시점부터 메시지를 순서대로 읽어서 처리함
• 파티션의 메시지 파일은 처리 후에도 계쏙 저장되어 있으며 설정에 따라 일정시간 뒤에 삭제됨.

여러개의 파티션을 사용하는 이유는 아래와 같습니다.

1) 병렬처리: 파티션을 사용하면 여러 컨슈머가 동시에 데이터를 읽을 수 있습니다.
2) 확장성: 파티션을 여러 브로커에 분산시켜 저장할 수 있습니다. 이를 통해 HA와 Throughput을 높일 수 있습니다.
3) 내구성: 파티션의 데이터는 여러 Replica에 복제됩니다. 이를 통해 하나의 브로커가 fail하더라도 다른 브로커의 레플리카에서 데이를 복구할 수 있게 됩니다.

--> 이는 일종의 파일시스템과의 Trade-off라고 볼 수 있겠죠.

 

프로듀서

---

• Producer: 메시지(이벤트)를 발행하여 생산하는 주체라고 했습니다.
• 프로듀서는 메시지 전송 시 토픽을 지정합니다.
• 파티션은 Round-Robin(RR)방식 혹은 파티션 번호를 지정하여 넣을 수 있습니다.
• 같은 키를 갖는 메시지는 같은 파티션에 저장되며 순서가 유지됩니다. 

 

컨슈머

---

• Consumer: 메시지(이벤트)를 구독하며 소비하는 주체라고 했습니다.
• Consumer Group
  • 메시지를 소비하는 컨슈머들의 논리적인 그룹입니다.
  • Topic의 파티션은 컨슈머 그룹과 1:N 매칭 관계로 동일 그룹내 한 개의 컨슈머만 연결가능합니다.
  • 이로써 파티션의 메시지는 순서대로 처리되도록 보장
  • 특정 컨슈머에 문제가 생겼을 경우 Fail over를 통한 리벨런싱 가능
  • 보통 파티션과 컨슈머는 1:1이 best practice라고 한다

 

Why Kafka

---

• 다중 프로듀서, 다중 컨슈머가 상호 간섭없이(=de-coupling)되어 메시지를 쓰고 읽어서 처리
• 디스크 기반의 이벤트 보존
  • 지속해서 보존 가능, 데이터 유실 위험이 적고 컨슈머가 항상 안떠있어도 됨
  • 장애 발생시 유실 복구 가능(=재처리)
  • 파티션은 파일의 OS 페이지 캐시를 통해 IO를 메모리에서 처리하여 성능이 유리
  • Zero Copy를 통해 디스크 버퍼에서 네트워크 버퍼로 직접 데이터 복사
• 브로커가 하는일이 비교적 단순 - 똑똑한 컨슈머
  • 브로커는 컨슈머와 파티션간 맵핑 관리만 하며 성능에 집중
  • 메시지 필터, 메시지 재전송과 같은 일은 프로듀서, 컨슈머에 위임
• batch 기능을 제공하여 동시 처리량 증가
  • 프로듀서: 일정 크기만큼 메시지를 모아서 전송
  • 컨슈머: 최소 크기만큼 메시지를 모아서 읽어옴
• 확장성 (scale-out): 수평 확장이 쉽게 가능 > 브로커, 파티션, 컨슈머 추가

 

고가용성(HA - High Availability)

• Kafka의 topic은 partition이라는 단위로 쪼개어져 클러스터의 각 서버들에 분산되어 저장되고, 고가용성을 위해 복제(replication) 설정을 할 경우 이 또한 partition 단위로 각 서버들에 분산되어 복제되고 장애가 발생하면 partition별로 fail over가 수행됩니다.
• Replication: 토픽 내 파티션의 복제본으로써, replciation-factor를 통해 개수를 지정할 수 있습니다.
  • 복제수(replication factor)만큼 파티션의 복제본이 각 브로커에 생깁니다.
  • --> 토픽 생성시 복제수를 2로 하면 파티션이 2개가 각각의 브로커에 생기게 되는겁니다.
• leader와 follower로 구성
  • 프로듀서&컨슈머는 리더를 통해서만 메시지 처리
  • 팔로워는 리더가 속한 브로커에서 메시지를 복제합니다.
• 리더가 속한 브로커가 장애나면 다른 팔로워가 리더가 되어 처리됩니다.

 

Reference

---

https://ifuwanna.tistory.com/487

[Kafka] 카프카란? 주요개념 및 용어 소개

https://kafka.apache.org/

Apache Kafka