kafka-starter

유튜브: 데브원영
https://www.youtube.com/playlist?list=PL3Re5Ri5rZmkY46j6WcJXQYRlDRZSUQ1j

kafka

• fault tolerant
• low latency
• high throughtput

kafka topic

• 카프카 토픽에는 파티션이 존재
  • 하나의 토픽에 여러개의 파티션이 존재할 수 있음
  • 여러개의 파티션이 존재한다면 다음의 규칙으로 파티션에 할당
    • 라운드 로빈으로 할당: 키가 NULL이고, 기본 파티션을 사용할 경우
    • 해시값에 따라 할당: 키가 존재하고, 기본 파티션을 사용
  • 파티션을 늘릴 수 있지만 줄일 수는 없기 때문에 파티셔닝은 주의해서 사용
• 데이터를 가장 오래된 순서대로 가져감
• 컨슈머가 데이터(레코드)들을 가져가도 데이터는 삭제되지 않음
• 파티셔닝의 레코드는 다음의 경우에 삭제될 수 있음
  • log.retention.ms: 최대 레코드 보존 시간
  • log.retention.byte: 최대 레코드 보존 크기 (byte)

브로커, 레플리케이션, ISR

브로커

• 카프카가 설치되어 있는 서버 단위
• 보통 3개의 서버 단위로 구성

레플리케이션

• 파티션의 복제
  • 레플리케이션이 1이면 파티션은 1개만 존재한다
  • 레플리케이션이 2이면 파티션은 1개, 레플리케이션된 파티션이 1개 존재한다
  • 레플리케이션이 3이면 파티션은 1개, 레플리케이션된 파티션이 2개 존재한다
  • 이는, 브로커 개수에 따라 레플리케이션 개수가 제한됨을 의미한다.
    • (브로커 개수가 3이면 레플리케이션 개수는 4가 될 수 없다)
• 원본 파티션을 '리더 파티션'이라고 부르고, 복제 파티션을 '팔로워 파티션'이라고 부름
• 리더 파티션과 팔로워 파티션을 합쳐서 ISR(In Sync Replica)라고 부름
• 레플리케이션을 사용하는 이유는 리더 파티션의 고가용성을 위함
• 리더 파티션이 장애가 발생하면 복제 파티션이 승계되어 역할을 대체하게 됨
  • producer가 레코드를 전달하는 대상은 '리더 파티션'이고,
  • producer에 ack 옵션이 존재
    • 0: 속도는 빠르지만 데이터 유실 가능성 존재
    • 1: 데이터를 정상적으로 보내고 받았는지에 대해 알 수 있다. 단, 팔로우 파티션들과 동기화 되었는지는 모름
    • all: 리더 파티션과 팔로워 파티션에 저장 및 동기화가 되었는지에 대해 알 수 있다. 유실률은 적으나 속도는 느림

파티셔너

• 프로듀서가 레코드를 보내면 파티셔너를 통해 브로커로 전달된다.
• 파티셔너는 어떤 파티션에 넣을지 결정하는 역할을 함
  • 레코드에 포함된 메시지 키 또는 메시지 값에 따라 파티션의 위치가 결정됨
• 파티셔너를 별도로 설정하지 않으면 UniformStickyPartitioner로 설정됨
  • 메시지 키가 있으면 파티셔너에 의해 해시값에 따라 파티셔너가 결정됨
  • 메시지 키가 두개 이상인 있는 경우 동일한 키값에 따라 동일한 파티션에 동일한 키 값을 넣음
  • 메시지 키가 없는 경우 라운드 로빈으로 파티션에 들어감
    • 전통적인 라운드 로빈 방식이 아닌 버퍼에 담아두었다가 배치 형태로 브로커에 전달함

컨슈머 랙

• 파티션에 레코드가 담기면 레코드의 순서를 '오프셋'이라고 부름
• 파티션이 데이터를 쌓는 오프셋(프로듀서 오프셋)과 데이터를 가져가는 오프셋(컨슈머 오프셋)의 차이
• 이러한 컨슈머 랙은 성능과도 관련이 있음
• 컨슈머 랙은 여러 개 존재할 수 있음

카프카 버로우

• 카프카 컨슈머 랙을 모니터링 하는 모니터링 서비스

기능

• 멀티 카프카 클러스터 지원
• 슬라이딩 윈도우를 통한 컨슈머의 상태를 확인 가능
• HTTP API를 제공

카프카 vs 레빗엠큐 vs 레디스큐

메시징 플랫폼

• 메시지 브로커: 이벤트 브로커 역할을 할 수 '없음'
  • 메시지 기반 미들웨어 아키텍처로 활용되어 왔음
  • 특징: 메시지를 처리하고나면 즉시 또는 짧은 시간 내에 삭제하는 특징을 가짐
  • ex) redis queue, rabbit MQ
• 이벤트 브로커: 메시지 브로커 역할을 할 수 '있음'
  • 특징: 레코드(이벤트 또는 메시지)의 장부를 하나만 보관하고 인덱스를 통해 개별 액세스를 관리함. 이벤트를 보존할 수 있음
  • 단일 진실 공급원, 실시간 스트림 데이터를 효과적으로 처리 등
  • ex) kafka, AWS kinesis

---

프로듀서의 역할

• 토픽에 해당하는 메시지를 생성
• 특정 토킥으로 데이터를 퍼블리시
• 처리 실패/재시도

!주의

• 만약 키가 있는 상태로 기존에 쌓인 레코드들이 존재할 때 새로운 파티션이 생성되게 되면 키 <-> 파티션의 일관성은 보장되지 않음
• 데이터 유실 혹은 브로커의 이슈에 대처하기 위한 별도 옵션과 대응 코드들 필요

컨슈머의 역할

• 컨슈머는 파티션에 저장된 데이터를 가져옴 (폴링)
  • 데이터는 토픽 내부의 파티션에 저장됨
• 파티션 오프셋 위치 기록 (커밋)
  • 오프셋은 토빅별로 그리고 파티션별로 별개로 지정됨
  • 오프셋은 컨슈머가 어느 지점까지 읽었는지를 나타내기 위한 용도
• 컨슈머 그룹을 통해 병렬 처리
• 하나의 토픽으로 들어온 데이터는 다양한 역할을 하는 여러 컨슈머들이 각자 원하는 데이터로 처리될 수 있음

컨슈머를 몇 개까지 만들 수 있을까

• 컨슈머가 1개면 2개의 파티션에서 데이터를 가져감

• 컨슈머가 2개이고 2개의 파티션이라면 각 컨슈머가 각각의 파티션을 가져감

• 컨슈머가 3개이고 2개의 파티션이 있다면 2개의 컨슈머는 각각 파티션 하나씩 가져가고, 나머지 하나의 컨슈머는 동작되지 않는다.

  • 즉, 컨슈머 개수는 파티션 개수보다 적거나 같아야 한다.