250x250
Notice
«   2025/04   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
Today
Total
관리 메뉴

serendipity

Kafka 카프카 본문

Study/Big Data

Kafka 카프카

z 2022. 1. 25. 16:41
728x90

Kafka

MOM (message oriented Middleware 메시지성 데이터 처리)에 최적화되어 있는 소프트웨어 중 하나로
대규모로 발생하는 메시지성 데이터를 비동기 방식으로 중계하는 역할을 하며 실시간 처리에 사용된다.

 

 

 

 

 

Topic : broker에서 데이터의 발행/ 소비 처리를 위한 저장소 기능 수행.

이때, 이를 파일시스템에 비유하면 토픽은 폴더와 유사하며 토픽 안의 이벤트는 폴더안의 파일과 유사.

토픽에 저장된 이벤트는 필요한만큼 다시 읽을 수 있다.

 

Broker : topic 컨트롤러로 kafka에서 server를 담당하며 한 클러스터 내에서 kafka server를 여러 대 띄울 수 있다.

Provider : broker의 특정 topic에 데이터를 전송하는 역할

Consumer : 데이터를 수신(소비)하는 역할

*Partition : 토픽은 여러 브로커에 분산되어 저장되며 이렇게 분산된 topic을 partition이라고 한다.

 

이벤트가 partition에 저장될 지는 이벤트의 key에 의해 정해지고, 같은 키를 가지는 이벤트는 항상 같은 파티션에 저장

전송하는 메시지에 키 값을 지정하게 된다면 원하는 파티션으로 전송하고,
키 값을 지정하지 않는다면 파티션은 Round-Robin 방식으로 파티션에 메시지를 균등하게 배분

 

 

 


 

Partition과 Consumer의 개수

 

Partition은 하나의 Consumer만 접근이 가능하다. 반대로 Consumer는 여러 개의 Partition을 소비할 수 있다.

(원래는 partition, consumer 는 각각 1개로 가정)

 

- Partition 1개 / Consumer 인스턴스 4개

Consumer를 4개로 늘렸지만, Consumer Group에서 Partition은 하나의 Consumer 밖에 접근을 못하는 구조다.

 

- Partition 4개 / Consumer 인스턴스 4개

Consumer는 하나의 Partition에 접근할 수 있으므로, Partition과 Consumer는 1:1 구성

이상적인 상황!

 

- Partition 4개 / Consumer 인스턴스 3개

잘 운영이 되다가, 갑자기 Consumer 하나가 죽어도 문제가 없다.

Consumer Group에서 offset이 공유되고 있으므로 Consumer가 하나 죽더라도
다른 Consumer가 해당 Partition에 접근하면 되니까!

 

- Partition 3개 / Consumer 인스턴스 3개

메시지가 잘 처리되고, 상황을 보니 Partition을 3개로 줄여도 될 것 같았지만  Partition은 한번 늘리면 줄일수가 없다.

 

* Partition의 개수 >= Consumer 인스턴스의 갯수를 유지하는 것이 좋다 (Consumer>Partition은 불가능)

주의할 점은 한 번 Partition을 늘리면 다시 줄일 수 없기 때문에, 

처리량을 잘 고려하여 Partition과 Consumer의 개수를 선택해야 할 것!!

 

 

* Consumer 확장 시 Partition도 같이 늘려줘야 한다.

Consumer group 내의 consumer는 무조건 다른 partition에만 연결 가능 -> 컨슈머의 메시지 처리 순서를 보장

 

하나의 컨슈머 그룹이 하나의 토픽을 담당 / 접근 가능

하나의 partition에는 하나의 consumer 인스턴스만 접근할 수 있도록 관리

*Consumer 다운될 때를 대비해 Consumer Group Consumer 인스턴스들은 offset 공유하고 있으며,

이를 통해 고가용성이 확보된다.

 


 

kafka 특징

1) 페이지 캐시 기능 사용 : 높은 처리 속도와 성능 향상

메모리(RAM) 영역에 애플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리 캐시로 전환 ->  디스크 접근 최소화  ->   I/O 성능 향상

 

2) 단순한 브로커의 역할 : 컨슈머와 파티션 간 매핑 관리   *메시지 필터, 재전송은 프로듀서 컨슈머가 직접 수행

 

3) 수평확장 용이한 구조 : 처리량 증대

- 1개 장비의 용량 한계 : 브로커 or 파티션 추가

- 컨슈머가 느리다 : 컨슈머 및 파티션 추가

 

4) 파티션 리플리케이션 + 리더/팔로워 구조 : 고가용성 및 장애 대응 

* 리플리카 : 파티션의 복제본 

- 프로듀서와 컨슈머는 리더를 통해서만 메시지를 처리한다.

- 팔로워는 리더로부터 복제된다.

<->  리더가 속한 브로커에 장애 발생 시 다른 팔로워가 리더가 된다.

 

5) 파일시스템 저장 

전통적인 메시징 시스템은 프로듀서가 전송한 메시지를 브로커의 메모리 상에 존재하는 큐(Queue)에 유지한다.

이후 컨슈머가 메시지를 읽어가면 큐에서 메시지를 제거한다.  프로듀서가 생성한 메시지는 브로커를 통해 컨슈머에 의해 빠른 시간내에 소비될 것이라고 가정하고 만들어졌기 때문이다.

카프카는 프로듀서가 생성한 메시지를 브로커가 위치한 서버의 파일 시스템에 저장한다. 따라서 컨슈머는 프로듀서가 생성한 메시지를 바로 소비하지 않아도 되며 카프카가 메시지를 보존하고 있는 기간내에서는 언제든지 읽어갈 수 있다.

 


 

메시지 (이벤트) 전달 컨셉

최대 한번 (메시지가 손실 될 수 있지만, 재전달은 하지 않는다)

최소 한번 (메시지가 손실되지 않지만 재전달이 생긴다)

정확히 한번 (메시지는 정확히 한번 전달된다)

 

728x90

'Study > Big Data' 카테고리의 다른 글

MapReduce 맵리듀스  (0) 2022.01.26
Zookeeper 주키퍼  (0) 2022.01.26
Flume 플럼  (0) 2022.01.25
하둡 Ecosystem  (0) 2022.01.10
Hadoop 하둡  (0) 2021.08.24
Comments