아파치 카프카 입문 강의를 듣고 정리한 내용입니다

카프카란

• 분산형 데이터 처리 및 전송

  • 데이터 손실 없이 복구 가능

  • 낮은 지연과 대용량 데이터 처리

  • 비동기 처리

  • 데이터 처리 통일화

카프카 토픽

• 메세지가 생산되고 소비되는 주제

• 카프카(브로커)에 여러 토픽이 있고 토픽에 여러 파티션이 있다

  • 토픽은 이름을 가질 수 있다.(데이터 특징을 기반으로 명명)

• producer로부터 파티션에 데이터가 쌓인다

  • offset(index)은 0부터 시작된다

• consumer로 먼저 적재된 오래된 데이터부터 빠져나간다

• 데이터를 가져가도 데이터는 파티션에 유지된다

  • 다른 consumer(target)에 넣을 수도 있다

• 파티션이 두 개 이상인 경우

  • 데이터를 보낼 때 키를 지정해서 파티션을 지정한다

• 파티션 삭제

  • 시간을 설정한다

kafka broker

• 카프카가 설치되어있는 서버단위

• 보통 3개 == 한 클러스터 내에 여러 대의 브로커(서버)

  • 파티션 1, 리플리케이션 1

  • 파티션 1, 리플리케이션 2 (=원본 하나, 복제본 하나)

  • 파티션 1, 리플리케이션 3 (=원본 하나, 복제본 둘)

• 리더 파티션(원본), 팔로워 파티션(복제) == in sync replica

• 고가용성 - 팔로워 싱크 맞춤으로써 파티션 복구가 가능하다

• ack 옵션 - 0, 1, all

  • 0일 경우, 리더 partition에 데이터 전송 후 응답 x

  • 1일 경우, 리더 partition에 데이터 전송 후 응답 o

  • 2일 경우, 모든 partition에 복제까지 확인 후 응답 o

kafka 파티셔너

• 데이터를 토픽의 어떤 파티션에 넣을지 결정한다

  • 메세지 키 또는 값에 따라 위치가 결정된다

• 또는 UniformStickyPartitioner로 설정한다

  • 메세지 키가 있는 경우, hash값에 따라 결정 (순서 o)

    • 키를 사용할 경우, 키 수 == 파티션 수여야 효과 있음

  • 메세지 키가 없는 경우, 각 파티션에 배치단위 라운드로빈 방식으로 넣어진다(분배)

• 파티셔너 인터페이스를 통해 커스텀 파티셔너 사용 가능

  • 우선순위 큐

컨슈머 그룹

• Partition에 접근하는 Consumer 관리

• Consumer들이 파티션의 어떤 offset을 소비해야하는지 관리한다

• 하나의 파티션에 하나의 컨슈머 인스턴스만 접근할 수 있도록 관리

• 반대로 컨슈머는 여러 개의 파티션 소비 가능

• 즉, 파티션의 개수 >= 컨슈머의 개수

• 컨슈머그룹에서 컨슈머가 소비하는 offset 정보는 토픽별로 분리되어있다.

• 파티션은 한 번 늘리면 줄일 수 없다는 점 주의

• 컨슈머는 브로커로부터 메세지를 pull하는 방식 <> push

컨슈머 랙(Consumer Lag)

• 카프카 프로듀서가 토픽의 파티션에 데이터를 저장하며 offset이 생성됨

• 컨슈머 랙은 프로듀서가 넣은 데이터의 오프셋과 컨슈머가 가져간 오프셋과의 차이를 의미

• 파티션 수에 따라 랙은 여러개가 존재할 수 있음

  • 랙 필수 발생 

  • records leg max

컨슈머 랙 모니터링 - 카프카 버로우(Burrow)

• DB에 넣고 그라파나로 모니터링도 가능

• 하지만 컨슈머에 디펜던시가 걸려있기 떄문에 컨슈머에서 랙을 수집하는 것은 비용이 듬

• 버로우 특징

  • 버로우는 링크드인에서 golang 언어로 개발된 오픈소스

  • 카프카 클러스터가 여러 개여도 버로우 어플리케이션 하나로 모니터링 가능

  • 컨슈머의 status 확인 가능 - 오프셋 불균형에 따라 warning, error ...

  • Http api 제공

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

• 메세징 플랫폼 - 메세지 브로커, 이벤트 브로커

  1. 메세지 브로커; 레빗엠큐, 레디스큐

     • 이벤트 브로커로 활용 불가 

     • 미들웨어에 사용(메세지, 인증, DB 등 플랫폼)

     • 메세지 처리 후 삭제
       

  2. 이벤트 브로커; 카프카

     • 인덱스를 통해 개별 엑세스

     • 필요한 시간 동안 유지

     • 큐에 저장

       • 단일 진실 공급원(이벤트 저장 한 곳에)

       • 장애 지점에서 장애 처리

       • 많은 양의 실시간 데이터 스트림 처리

주키퍼 - 클러스터의 서버들이 공유하는 데이터를 관리(클러스터 관리)

• 카프카의 메타데이터 정보를 저장, 카프카의 상태관리 등 목적으로 이용

• 주키퍼 제거됨 -> 카프카 내부에 메티데이터 저장하는 방식으로 변경

• 메타데이터용 프로토콜인 카프카 라프트 또는 크라프트로 대체됨

카프카 스트림즈

• 카프카에 저장된 데이터 처리 및 분석하는 라이브러리 

• 카프카와 완벽호환

• 스케줄링이 필요없다

• 스트림즈DSL - 이벤트 기반 데이터 처리 관련 메서드 제공

• 프로세서API를 통해 로직 작성 가능

• 상태 기반 분산 저장

  • 상태 변환 정보를 변경 로그 토픽에 저장

  • 장애 처리 가능

카프카 커넥트 - 반복적인 데이터 파이프라인  개발

• 싱크 커넥터 - DB에 데이터 저장(컨슈머 역할)

• 소스 커넥터 - DB로부터 데이터를 가져와서 토픽에 넣는 프로듀서 역할

• 커넥트; 커넥터를 실행

  • 단일 실행모드 커넥트

  • 분산모드 커넥트

    • 여러 개의 프로세서(커넥트)를 하나의 클러스터로 묶음

    • 장애 시 복구 가능

카프카 사용법

• 카프카 관련 설정; producer, topic

• 프로듀서

  • RestController API

  • 파라미터를 통해 객체 전달 EventDto

  • KafkaTemplate.send("topic", eventDto)

    • 토픽에 요청 쌓음
      

• 컨슈머; consumerFactory

  • @EnableKafka

  • @KafkaListener("topic", groupId, containerFactory)

    • 토픽 꺼내와서 처리

  • listen(ConsumerRecord) 메서드

  • poll records

    • record.value()