[Apache Kafka] Kafka 개념

참고 블로그 ​

https://devocean.sk.com/community/detail.do?ID=165483&boardType=DEVOCEAN_STUDY&page=1

https://medium.com/@0joon/10%EB%B6%84%EC%95%88%EC%97%90-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-kafka-bed877e7a3bc

 

 

Kafka 개요

Kafka는 이벤트 처리 시스템 중 하나인 분산 메세지 큐 (비동기) 방식 이벤트 스트리밍 플랫폼이다.

 

인기 많은 식당에는 사람들이 많이 줄 서있다. 여기서 사람들 한 명 한 명을 데이터로 취급해보자.

대기열(큐)이 없을 경우, 어떤 사람이 먼저 왔는지 구분이 되지 않는다. (질서 X)

식당 내 수용 인원은 한정되어있으므로 대기열(큐)을 두어 순서대로 사람들을 받는다.

식당 내 인원이 빠지면 대기열에 있는 사람들을 식당 안으로 받으므로 비동기 방식이다. (동시 처리 X)

 

이벤트 스트리밍 처리 시스템?

• 센서, IoT 장치와 같은 실시간으로 발생하는 이벤트(데이터)를 저장/처리하는 시스템

분산 메세지 큐?

• 대기열(큐) 서버를 별도로 두어서 Application은 대기열(큐) 서버의 client 가 됨
• 대기열(큐) 서버와 Application은 pub-sub 모델로 데이터를 읽고 쓰는 방식

pub-sub 모델?

• publisher (공급자) : 들어온(발생한) 이벤트를 Topic을 기준으로 구분하여 발신 (for 저장)
• subscribe (구독자) : 구독한 이벤트를 Topic을 기준으로 구분하여 수신 (for 보기)

consumer - producer?

Topic을 기준으로

• producer라고 하는 publisher와
• consumer(group) 라고 하는 subscriber 로

데이터를 관리하고 처리함

 

 

상황적 예시

예를 들어,

쇼핑몰 웹사이트에서 장바구니에 구두도 담고 바지도 담는다.

우리는 웹사이트 하나로 모든 걸 주문해서 편리하지만

사실 한 쇼핑몰이 아닌, 구두 매장 따로 바지 매장 따로인 경우가 많다.

1. Event 발생: 한 웹사이트에서 구두, 바지 주문 이벤트 발생
2. 데이터 수집: Producer(publisher)가 Topic에 맞게 구두 데이터는 “구두”별로, 바지 데이터는 “바지”별로 분류해서 Broker에 저장
3. 데이터 저장/처리: Kafka (broker)
   1. Zookeeper : Broker들 매니저 (관리자)
   2. Broker1, Broker2, … (담당자)

• 데이터들이 많으면 태그로 구분을 하는데, 여기서 태그는 Topic과 같다.

 

  4. Consumer(subscriber, 구두 매장 주인): Topic “구두” 주문 데이터만 보고 싶다고 요청

  5. Kafka가 Consumer(구두 매장 주인)에게 Topic “구두” 주문 데이터 담당자(Broker)를 알려줌

  6. Consumer( 구두 매장 주인 )는 담당자(Broker)로부터 Topic “구두” 주문 데이터를 봄

 

구조

• Zookeeper Cluster
• Kafka Cluster

여러 대의 서버(브로커들)에 데이터를 분산 저장하고 처리할 수 있는 시스템이므로

고가용성 및 확장성, 데이터 손실없이 안정적인 운영 보장!

• RAID 0처럼 striping 방식으로 저장

 

 

MSA 구조에 많이 쓰이는 이유?

 

느슨한 결합(loosely-couple) 때문이다!

 

 

도입 이전의 방식

1. 확장 어려움

직접 서버와 연결된 구조는 새로운 서버가 도입될 때마다 기존 시스템과 일일이 연결해야하므로

복잡도가 증가하여 확장하기 어려움

 

 

   2. 데이터 유실

 

하나의 서버가 문제가 생겨서 응답을 못할 때 kafka가 있었다면 그 데이터를 담아두었다가

재부팅시 다시 처리를 하도록 했겠지만 kafka가 없으면 그대로 데이터 유실

 

 

 

도입 이후의 방식

• 의존성이 낮아져 확장이 쉬워짐
• 데이터를 보내고 받는 대상들은 Broker 역할인 Kafka가 알아서 함

 

 

 

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

이벤트 브로커는 이벤트 소싱 방식으로, 시스템에서 발생하는 모든 이벤트를 저장해 사라지지 않음

메시지 브로커는 메시지가 사용되면 사라짐

→ Kafka는 이벤트 브로커 방식이다. 특정 시점 조회나 실시간 분석에 좋음

 

 

 

Kafka 만능인가?

• 컴퓨팅 자원을 많이 소모함
• Kafka 4 버전부터 Kraft 방식으로 주키퍼 없이 운영
• 소규모 시스템에서는 RabbitMQ가 더 좋음