Apache Kafka란?

카프카 등장배경

Source Application과 Target Application이 증가함에 따라 그 복잡도 또한 비례하여 확장성 및 장애에 취약했다.

그래서 Source Application과 Target Application 간 결합도를 약하게 하면서 단순화 하기 위해 등장.

Kafka는 라이브러리로 되어 있어 Application에서 쉽게 구현 가능,

Produser는 데이터를 Kafka에 넣는 역할,
Consumer는 Kafka에 있는 데이터를 가져오는 역할.

1. 구조

Producer	->	Apache Kafka (데이터 전송)	->	Consumer
Source Apllication		(Topic == queue)#1		Target Application
		(Topic == queue)#2
		(Topic == queue)#3

2. 특징

• 고가용성으로, 서버 이슈에 데이터 손실 없이 복구 가능
• 높은 처리량
• 빅데이터 처리에 유용

Topic

• 토픽여러개 생성가능

• 토픽에 데이터 넣음.

• 토픽명 명명가능

  토픽 내부

• 하나의 토픽은 여러개 파티션으로 구분 가능

• 데이터는 가장 오래된 순서 (0번)부터 가져감. (FIFO원칙)

• 컨슈머가 데이터를 가져가도 데이터는 삭제 안함

• 새로운 컨슈머가 다시 0번부터

partition

• 파티션 늘리는건 가능하지만 줄이진 못함.

offset

• Topic 내 partition내 위치한 데이터에 상태를 구분하기 위한 숫자.
• ex) 프로듀서가 마지막으로 넣은 offset, 컨슈머가 마지막으로 읽은 offset
• 위 2개의 offset의 격차를 Kafka Consumer lag이라고 부름.
• partition 내 데이터에 offset이 존재하기에 partition이 여러개면 Consumer lag도 여러개 발생

Burrow

• Consumer lag을 모니터링 할 수 있는 오픈소스, 독립적인 Application
• HTTP API 제공
• 여러 Kafka Cluster가 있어도 1개의 Burrow에 통합 연동 가능

Partitioner

• 메시지 키, 값 또는 Topic명에 따라 어느 파티션에 어느 데이터를 넣을 것인지 커스텀 가능
• ex) VIP 고객을 위한 프리미엄 데이터 처리량 or 속도 제공, 우선순위 설정 등..

broker

• Kafka에 설치되어 있는 서버단위를 의미.
• 보통 3개 이상 권장

replication

• 고 가용성을 위해 사용

메시지 브로커와 이벤트 브로커 차이점

	메시지 브로커	이벤트 브로커
방식	데이터 전송 -> 처리 -> 삭제	데이터 전송 -> 처리 -> 보관
종류	레디스큐, 레빗엠큐	카프카, 키네시스(aws)

• 이 차이로 인해 이벤트 브로커는 장애 시 장애 시점에 복구가 가능하며
• 설정에 따라 메시지 브로커처럼 사용할 수도 있다.