LinkedIn에서 최초로 만들고 opensource화 한 확장성이 뛰어난 분산 메시지 큐(FIFO : First In First Out)

→ 분산 아키텍쳐 구성, Fault-tolerance한 architecture(with zookeeper), 데이터 유실 방지를 위한 구성이 잘되어 있음

→ AMQP, JMS API를 사용하지 않은 TCP기반 프로토콜 사용

→ Pub / Sub 메시징 모델을 채용

→ 읽기 / 쓰기 성능을 중시

→ Producer가 Batch형태로 broker로 메시지 전송이 가능하여 속도 개선

→ 파일 시스템에 메시지를 저장하므로, 데이터의 영속성 보장

→ Consume된 메시지를 곧바로 삭제하지 않고 offset을 통한 consumer-group별 개별 consume가능

---

카프카는 메세지큐이며, 메세지큐의 목적은 단순하다. 메세지를 한곳에 던지고 그걸 필요한 주체가 가져다 처리한다. 이건 RabbitMQ, 카프카, 멤캐시 등 다수의 제품들의 기본기능이다. 일단 메세지큐를 가장 많이쓰는 서비스는 로그 관리이다. 어느 회사들 로그관리의 필요성을 가지게 되고 그에 맞는 로그 시스템을 구축한다.

🚩 RabbitMQ

• 구성이 쉽다.

• 유연한 라우팅이 가능하면 관리 UI 가 편리하다.

• 제품 성숙도가 높다.

• 개방형 프로토콜을 위한 AMQP 를 구현 위해 개발

• 필요에 따라 동기/비동기식이 가능함

• 소비자중심의 설계

• 20k/sec 처리를 보장

🚩 Apache Kafka

• 구독방식의 비동기식 구성

• 고성능 고가용성

• 분산처리에 효과적으로 설계 됨.

• 생산자 중심의 설계

• 범용 메세징 시스템에서 제공되는 다양한 기능은 제공되지 않음.

• 100k/sec 처리를 보장

---

👨‍💻 Kafka Architecture

Broker : Kafka를 구성하는 각 서버 1대 = 1 broker

Topic : Data가 저장되는 곳

Producer : Broker에 data를 write하는 역할

Consumer : Broker에서 data를 read하는 역할

Consumer-Group : 메세지 소비자 묶음 단위(n consumers)

Zookeeper : Kafka를 운용하기 위한 Coordination service(zookeeper 소개)

Partition : topic이 복사(replicated)되어 나뉘어지는 단위

---

💡👨‍💻💡👨‍💻💡👨‍💻💡👨‍💻💡

Producer : 데이터 넣음
Consumer : 데이터 가져감
Topic : 데이터가 저장되는 공간 = 테이블
( 토픽 명 확실할 시 , 유지보수시 편리)

🔖 파티션은 늘리는것은 가능하지만, 다시 줄일 수 없으므로 주의해야하며 파티션을 늘리면 컨슈머 갯수를 늘려서 데이터 처리를 분산시킬 수 있다.

• 하나의 토픽은 여러개의 파티션으로 구성될 수 있으며 0번부터 파티션 시작

• 하나의 파티션은 큐와 같이 내부에 데이터가 파티션 끝에서 부터 차곡 쌓이게 됨

• 차곡 쌓인 데이터는 컨슈머가 가장 오래된 순서대로 데이터를 가져감

• 더이상 데이터가 들어오지 않으면 컨슈머는 또 다른 데이터가 들어올때 까지 기다림

• 컨슈머가 데이터 ( reord )들을 가져가도 데이터는 삭제되지 않음

= 파티션에 그대로 남게되는것

---

🚨 그렇다면 , 이 파티션에 남은 데이터는 누가 들고가는것일까?

새로운 컨슈머가 붙었을때 다시 0번부터 가져가서 사용가능하다.

다만 컨슈머 그룹이 달라야하고, outo.offset.reset = earlist 세팅되어야한다.

동일데이터에 대해서 두번 처리가능

파티션이 두개일 경우
( 데이터를 보낼때 키를 지정가능하다. )

1) 키가 null이고, 기본파티셔너 사용할 경우
➡️ 라운드로빈으로 할당
2) 키가 있고, 기본파티셔너 사용할 경우
➡️ 키의 해시 값을 구하고, 특정 파티션에 할당

📌 파티션의 데이터(record)는 언제 삭제 되는가?

레코드가 저장되는 최재시간과 크기를 지정할 수 있음
log.retention.ms : 최대 record 보존시간
log.retention.byte: 최대 record 보존크기

---

✨ 카푸카 운영에서 중요한 역할 3가지

💡 Broker, Replication, ISR

Broker : 카프카가 설치되어 있는 서버단위 (보통 3개이상 권장 )
Replication: 복제/ 가용성보장 (ex. Replication 3개 = 원본 1개, 복제본 2개 ) = 브로커 개수에 따라서 Replication 개수가 제한된다.

원본 : Leader partiton (프로듀서가 데이터를 전달할때 받는 곳)
복제본 : Follower partiton

Leader partiton + Follower partiton ➡️ In Sync Replica (ISR)

📌 Producer

• topic에 해당하는 메시지를 생성
• 특정 topic으로 데이터를 publish
• 처리 실패/재시도

프로듀서의 ack 동작 ➡️ 상세옵션 ➡️ 고가용성 유지

💡 ack 종류 : 0, 1, all

0: 데이터 전송 확인 응답값 X , 파티션 복제응답값 X
1: 데이터 전송 확인 응답값 O , 파티션 복제응답값 X
all: 데이터 전송 확인 응답값 O , 파티션 복제응답값 O
=> (대신속도가 현저히 느리지만 가장굿)

Replication 개수가 많으면 ?
브로커의 리소스 사용량도 늘어나게 됨을 주의하자

출처 : https://blog.voidmainvoid.net/179
https://ellune.tistory.com/29