[Kafka] 카프카 개요

 

 

 

Ref

---

• 실전 아파치 카프카 (사사키 도루 외 4인) 책 (아래 포스팅에 있는 내용(1장)만 추가 정리)
• https://www.hanbit.co.kr/media/channel/view.html?cms_code=CMS9400468504
• https://kuckjwi0928.tistory.com/14

 

Apache Kafka란?

---

• 실시간으로 데이터 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼
• 대용량/대규모 메시지 데이터를 빠르게 처리하는 분산 메시징 시스템(플랫폼)
• 아래 4가지 실현 가능
  • 확장성 (Scale Out) : 데이터 양에 따라 시스템 확장 가능
  • 영속성 (Persistence) : 언제라도 데이터를 읽을 수 있음
  • 유연성 (Flexibility) : 연계할 수 있는 제품이 많음 (API)
  • 신뢰성 (Reliability) : 메시지 전달 보증 -> 데이터 분실 x

 

Kafka 탄생 배경 (2011, LinkedIn)

---

LinkedIn 요구 사항

웹사이트에서 생성되는 대량의 로그를 처리해 웹사이트 활동 추적을 목적으로 개발됨

1. 높은 처리량으로 실시간 처리 : 수백 밀리초에서 수 초 안에 데이터 처리
2. 임의의 타이밍에서 데이터 읽음 : 실시간 처리 + 배치 처리 둘 다 취급
3. 다양한 제품과 시스템에 쉽게 연동
4. 메시지 잃지 않음 : 중복이 생기더라도 메시지를 잃지 않는 것이 중요

 

LinkedIn이 검토한 제품들

1. Message Queue
   • 종류 : WebSphere MQ(IBM MQ), Apache ActiveMQ, RabbitMQ
   • 강력한 전달 보증 (Over Spec) -> 처리량이 제대로 나오지 않음
   • Scale Out이 어려움
   • 배치 처리를 위한 대량 데이터 장시간 축적이 불가능
2. Log Aggregator System (로그 수집 시스템)
   • 종류 : Scribe, Flume (당시 존재하던 것)
   • https://blog.seulgi.kim/2014/04/log-aggregator-scribe-flume-fluentd.html
   • 데이터 축적 및 배치 처리만 고려된 시스템 -> 실시간 처리 불가능
   • 알기 쉬운 API x
   • 로그 기반 서버 -push-> 수신자 구조 : 수신자가 pull 하는 방식이 필요 (임의의 타이밍에서 읽기 위해)
3. ETL 도구
   • 종류 : DataStage, Interstage, Cosminexus, Informatica PowerCenter, Talend
   • 데이터를 파일 단위로 다룸 -> 링크드인은 한 건의 레코드 단위로 실시간 처리를 원함
   • 임의의 타이밍에 데이터를 읽을 수 있는 중계 역할 x

 

LinkedIn 요구 사항 실현

1. Messaging Model과 Scale Out형 아키텍처 : 요구사항 1, 2, 3 실현

• 메시징 모델 구성 요소
  • Producer : Message 생산자
  • Broker : Message 수집/전달자
  • Consumer : Message 소비자

• Queuing Model 특징
  • Broker 안에 Queue가 있음
  • Producer -> Queue -> Consumer
  • 하나의 Queue에 대해 여러 Consumer 존재 가능 -> Consumer에 의한 처리가 병렬로 가능
  • 한 Consumer가 메시지를 받으면 다른 Consumer는 메시지 받을 수 없음 (Consumer에 도달한 메시지는 사라짐)

• Pub/Sub Messaging Model 특징
  • [공부/기타] - [Pub/Sub] Publish/Subscribe 구조(모델)
  • Producer == Publisher / Consumer == Subscriber
  • Publisher의 메시지 -> Broker 내의 Topic에 등록
  • Publisher는 Broker에 메시지를 보내기만 할 뿐, 누가 메시지를 이용하는지는 신경 쓰지 않음
  • Subscriber는 여러 Topic 중 하나를 선택하여 메시지를 받음
    -> 여러 Subscriber가 동일한 Topic 구독 가능 (동일한 메시지 받음)

• Kafka Messaging Model
  • Queuing Model의 <여러 Consumer가 분산 처리로 메시지 소비> 하는 모델
  • Pub/Sub Model의 <여러 Subscriber에 동일한 메시지를 전달하고, Topic 기반으로 전달 내용을 변경> 하는 모델
  • -> Consumer Group 이라는 개념을 도입해 Consumer를 확장 구성할 수 있도록 설계

2. Disk로의 데이터 영속화 : 요구사항 2, 4 실현

• 장기 보존, 용량(배치 처리 위해) 등을 위해 Disk에서 영속화가 이루어짐
• 그래도 높은 처리량 제공하는 것이 Kafka 특징
• 장기 보존을 목적으로 영속화할 수 있기 때문에 Kafka를 Storage System으로도 간주 가능

3. 이해하기 쉬운 API 제공 : 요구사항 3 실현

• Producer, Consumer에 쉽게 접속할 수 있도록 Connect API 제공
• API 기반으로 Kafka에 접속하기 위한 프레임워크인 Kafka Connect 제공
• Kafka Connect와 접속하기 위한 플러그인으로 Connector가 개발되어 있음 -> 외부 시스템과 접속 가능

• Kafka Streams : Kafka에 존재하는 데이터를 스트림 처리하는 Streams API를 라이브러리화한 Client Library
• Kafka Streams library를 이용해 kafka 입출력에 사용하는 stream 처리 application을 비교적 쉽게 구현 가능

4. 전달 보증 : 요구사항 4 실현

• 메시지를 잃지 않고 전달 : 세 가지 수준의 전달 보증 단계가 제공됨 (kafka 전달 보증 검색하면 많이 나옴)
  • At Most Once : 1회는 전달을 시도 해본다
    • 재전송 x, 중복 삭제 x
    • 메시지는 중복되지 않지만 상실될 수 있다
  • At Least Once : 최소 1회는 전달한다
    • 재전송 o, 중복 삭제 x
    • 메시지가 중복될 순 있지만, 상실되지 않는다
    • Ack + Offset Commit 개념
  • Exactly Once : 1회만 전달한다
    • 재전송 o, 중복 삭제 o
    • 메시지가 중복되거나 삭제되지 않지만, 성능이 저하된다
    • 트랜잭션 개념

 

 

끝