[Kafka] 개념

 

아파치 카프카

무엇
데이터를 전송하는 source와 데이터를 받는 target이 점점 많아지면 데이터 전송 관계들이 복잡해진다.
이 복잡함을 해결하기 위해 등장한 오픈소스

장점
낮은 지연과 높은 처리량으로 효과적으로 빅데이터 처리가 가능하다. 

 

 

 

카프카 클라이언트

 

카프카 프로듀서

- 토픽에 해당하는 메시지를 생성

- 특정 토픽으로 데이터를 publish

- 처리 실패/재시도 

 

카프카

- 데이터를 담는 큐와 같은 역할을 한다고 보면 된다.
- 데이터 흐름에 있어서 fault tolerant

- 가용성으로 서버이슈 발생해도 데이터를 복구할 수 있음

카프카 컨슈머

- 토픽 내 파티션의 데이터를 가져옴. (polling)

- 파티션의 오프셋 위치를 기록 (commit)

- 컨슈머 그룹을 통해 병렬처리 가능 (파티션의 개수에 따라 컨슈머를 여러개 만들면 병렬처리가 가능해진다.)

 

 

 

토픽

데이터를 담는 공간을 토픽이라고 한다.

토픽은 여러개 생성할 수 있다.  DB의 테이블/ 파일시스템의 폴더 같은 역할을 한다. 

Producer는 토픽에 데이터를 저장하고, Consumer는 토픽에서 데이터를 가져간다. 

토픽 이름은 데이터의 특징을 반영하게 짓는 것이 유지보수에 유리하다. (click_log 이런식)

 

파티션

토픽 내에 여러개 파티션으로 구성할 수 있다.
하나의 파티션은 큐와 같이 데이터가 차곡차곡 쌓이고, Consumer는 가장 오래된 데이터부터 가져간다.  
(Consumer가 record를 가져가도 데이터는 삭제되지 않음. 새로운 Consumer 들어오면 처음부터 가져간다)

만약 파티션이 2개라면, 데이터를 저장할 때 어느 파티션에 저장할지 키를 지정할 수 있다.
파티션을 늘리면 Consumer를 늘려서 분산처리를 할 수 있다.  (파티션은 늘리는 것이 가능하지만, 줄일 수는 없다.)
파티션 데이터의 삭제는 보존기간과 보존크기를 미리 정하면 일정 기간/ 용량동안 저장되었다가 삭제될 수 있다.

 

 

브로커

카프카가 저장되어 있는 서버를 의미. 보통 3개 이상의 브로커로 구성함.

만약 브로커가 3대라면, 그 중 한대에 토픽정보가 저장된다.

복제 (Replication)
replication이 3이라면, 파티션은 원본 1대와 복제본 2대로 구성된다.  (leader partition 1, follower partition 2)
만약 브로커가 사용불가하게 되면, 리더 파티션은 못쓰게 되도 팔로워 파티션으로 복구 가능해진다.

ack는 0, 1, all  셋 중 하나를 사용할 수 있다. 
0 - 리더파티션에 데이터 전송 후, 잘 전송됐는지 확인하지는 않는다. 데이터 전달 속도 빠르지만 유실 가능성 있음.
1 - 리더파티션에 데이터 전송 후, 잘 전송됐는지 확인한다. 팔로워 파티션에 복제됐는지 확인하지 않음.
all - 리더파티션에 데이터 전송 후, 잘 전송됐는지 확인한다. 복제 잘 됐는지 응답까지 확인 (너무 느림..)

ISR (In-Sync-Replication)
원본 + 복제본 합쳐서 ISR 이라고 지칭한다.

 

 

파티셔너

파티션을 더 효과적으로 쓰기 위해 파티셔너 존재함.

데이터를 토픽의 어떤 파티션에 넣을지 결정하는 역할을 한다.

메시지의 키에 따라 특정 해시값이 결정되고, 이를 기반으로 저장될 파티션이 결정된다. 

 

 

컨슈머 랙 (consumer lag)

 

카프카 운영함에 있어 모니터링 해야하는 지표 중 하나.

프로듀서가 마지막으로 저장한 오프셋과 컨슈머가 마지막으로 읽은 오프셋의 차이

 

카프카 프로듀서 : 토픽의 파티션에 데이터를 저장하는데 오프셋 0부터 시작한다.

카프카 컨슈머 : 데이터를 오프셋0번부터 가져간다. 

 

 

컨슈머그룹이 1개이고, 만약 파티션이 2개라면 lag은 2개가 측정된다.

그중 큰 값이 records lag max 값이다.

 

 

 

카프카 버로우 (Burrow)

컨슈머 랙 모니터링 애플리케이션

 

1. 버로우 1대 이용하여, 멀티 카프카 클러스터 지원

2. 윈도우 wanrning, error

3. HTTP api를 제공한다.

 

 

 

카프카 /  레빗엠큐RabbitMQ / 레디스 큐의 차이

메시지 브로커: RedisQ, RabbitMQ

대규모 메시지 기반 미들웨어, 전송이 되고 나면 삭제된다.

 

이벤트 브로커: 카프카, AWS의 키네시스

이벤트를 보존한다. 서비스에서 나오는 이벤트를 DB에 저장하듯이 큐에 저장한다.

1. 한번 일어난 이벤트도 저장하여 "단일진실공급원"으로서 사용이 가능하다.

2. 장애가 발생했을때 그 이전부터 재처리 할 수 있음.

3. 많은 양의 스트림 데이터를 실시간으로 처리할 수 있다.