카프카 기본 개념 설명

[manjeong-dev]

• 카프카 클러스터
• 토픽
• 스트림즈
  • 토픽에 있는 데이터를 stateful or stateless 하게 처리해서 다시 토픽에 넣고자 할 때 사용
• 컨슈머
• 커넥트(소스)
  • 소스에서 가져와서 토픽에 넣는
• 커넥트(싱크)
  • 토픽에서 가져와서 타겟애플리케이션에 넣는
• 데이터 파이프라인을 운영하는 가장 핵심적인 툴 중 하나
  • 클러스터로 운영
  • 파이프라인을 반복적으로 여러번 생성 가능

MirrorMaker2

• 클러스터 단위로 카프카를 운영할 때 토픽에 있는 데이터를 완벽하게 복제하기 위해 사용

  

주키퍼

• 3.0 부터는 주키퍼 없이 사용할 수 있지만 아직 완전 대체는 못함
• 카프카 클러스터를 실행하기 위해 필요
• 주키퍼의 서로 다른 znode에 클러스터를 지정
• root znode에 각 클러스트별 znode를 생성하고 클러스터 실행시 root가 아닌 하위 znode로 설정

클러스터

• 여러개의 브로커로 이루어짐 (일반적 3개)
  • 브로커를 묶는 단위(논리적인, 실제 존재 x, 브러커 여러개 있고 1~3번까지 클러스터로 묶어! 정도)
• 분산 저장/복제
  • 안정적 운영을 위해. 장애 발생시 다른 브로커 사용
• 각기 다른 클러스터를 운영할 수 있음

카프카 브로커

• 하나의 서버 or 인스턴스에서 동작
• 하나의 프로세스
• 컨트롤러
  • 브로커들의 상태 체크
  • 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 leader partition 재분배
  • 빠르게 빼내고, 지정하는 게 중요!! > 컨트롤러 역할을 하는 브로커 장애시 다른 브로커가 해당 역할을 수행
• 데이터 삭제
  • 토픽의 데이터 < 컨슈머, 프로듀서가 삭제할 수 없음. 브로커만 삭제 가능
  • 파일 단위인 log segment 단위로 브로커가 삭제
  • 일정 시간, 용량에 따라 delete(cleanup policy)
  • 특수한 상황 compact 옵션 (가장 최신의 키가 있는 레코드를 제외하고 나머지 삭제)
• 컨슈머 오프셋 저장
  • 컨슈머 그룹은 토픽이 특정 partition으로부터 데이터를 가져가서 처리, 이 partition의 어느 레코드까지 가져갔는지 확인하기 위해 offset 을 커밋
  • 커밋한 offsetdms __consumer_offsets 토픽에 저장 (이 값을 보고 컨슈머 그룹이 다음 레코드를 가져가 처리)
• 그룹 cordinator
  • rebalance
  • 컨슈머 그룹의 상태 체크, partition을 컨슈머와 매칭되도록 분배
  • 컨슈머가 한 그룹에서 빠지면 매칭되지 않은 partition을 정상 동작하는 컨슈머로 할당 > 끊임없는 데이터 처리
  • partition:consumer=1:1 or partition:consumer=1:n
• 데이터 저장
  • config/server.propertie의 log.dir 옵션에 정의한 디렉토리에 데이터 저장
  • 이름 : 토픽 이름+partition 번호
  • log : 메시지, 메타데이터(key, value, 헤더 등..)
  • index : 메시지의 offset을 indexing한 정보
  • timeinde : 메시지에 포함된 timestamp값을 기준으로 indexing한 정보
  • 세그먼트
    • log.segment.bytes(바이트 단위로 세그먼트 크기 지정), log.roll.ms(hours)(다음 파일로 넘어가는 시간 주기) 단위로 나눔
    • active 세그먼트
      • 가장 마지막 세그먼트 파일. 쓰기가 일어나고 있는 파일
      • 브로커의 삭제 대상에 포함되지 않음
    • retention 옵션에 따라 로그 세그먼트 단위로 삭제 (cleanup.policy=delete)
      • retention.ms(minutes,hours) : 기본값 7일
      • retention.bytes : 적재 바이트 수에 다다르면 삭제 (기본값 -1:지정하지 않음)
      • log.retention.check.interval.ms : 브로커가 주기적으로 체크 (기본값 5분)
      • 레코드 단위 삭제/수정은 불가능 (producer/consumer는 record 데이터 검증이 중요~~!)
    • cleanup.policy=compact
      • 동일 키값을 가진 것 중 최신만 남겨둠. 일부 레코드만 삭제 가능
      • min.cleanable.dirty.ratio : 데이터 compact 시작 시점을 정하는 옵션값
      • 0.5 = head와 tail의 개수가 같을 때
      • 0.9 등 너무 높으면 한번 압축 시 너무 많이 해야하고 그동안 용량도 많이 차지, 0.1은 너무 압축 자주 일어나 브로커가 힘들어, 최신 데이터는 유지할 수 있겠지
      • tail/head 영역, clean/dirty 로그 (tail=clean, head=dirty)
      • tail : active 제외한 모든 세그먼트들에서 compact 완료된 레코드들, clean 로그, 중복 메시지키가 없음
      • head : compact 되기 전 레코드들, dirty 로그, 중복된 메시지 키 존재할 수 있음
• 복제
  • partition 단위 복제
  • replication factor=1 : 복제 없음, 최대값 : 브로커 개수만큼
  • 리더:producer, consumer랑 모두 붙고, 다른 팔로워들이 리더에서 값 가져감
    • 팔로워는 리더와 오프셋 비교로 데이터 복제
  • 저장 용량 증가 but 안정성/가용성 up
  • 토픽마다 replication factor를 다르게 설정할 수 있음
  • 데이터 처리 속도 중요 > 1로 설정(metric,지도와 같이 유실 가능, but 속도 빨라야함)
• ISR(In-Sync-Replicas)
  • 리더 partition과 팔로워 partition이 모두 sync(offset 개수가 같음)가 된 상태
  • unclean.leader.election.enable < 토픽 단위로 설정 가능
    • true(유실 감수. 새로운 리더를 팔로워 partion으로 승급)

    • false(해당 브로커가 복구될 때까지 중단)

      토픽 & 파티션

      

토픽

• 1개 이상의 파티션으로 이루어짐
• 데이터를 구분하기 위해 사용하는 단위

파티션

• 큐
• 데이터는 컨슈머가 가져가도 삭제되지 않음

토픽 생성시 파티션은 0번 브로커부터 시작하여 round-robin 방식으로 leader partition 생성

• hot spot(통신 집중)을 막고 linear scale out(선형 확장)하게 해줌
• kafka-reassign-partiions.sh 로 파티션 재분배 가능 (특정 브로커에 파티션이 몰리는 경우)

파티션 : 컨슈머 = 1:1 (병렬 처리)

• 단 연결된 컨슈머에서 장애 발생시, 다른 컨슈머가 해당 파티션의 연결을 가져와 처리할 수는 있음
• 컨슈머 개수 늘림 > 파티션 개수도 늘리면 처리량 증가 (컨슈머 lack 해소)

파티션 개수 줄이는 건 불가능

• 토픽을 삭제하고 재생성하는 방법 외에는 없음

• 파티션의 데이터를 세그먼트로 저장하고 있음 > 여러 브로커에 저장된 데이터를 취합하고 정렬해야 함

  레코드

  

• 브로커로 레코드가 전송되면 offset, timestamp 가 지정되어 저장됨 (프로듀서의 레코드에는 없음)

• 브로커에 한번 적재되면 수정 x, log retention 기간 또는 용량에 따라서만 삭제됨

• timestamp

  • 기본값 : 프로듀서가 레코드 생성한 시간(createTime)
  • LogAppendTime : 브로커 적재 시간
  • 토픽 단위 설정 (message.timestamp.type)

• offset

  • 파티션별로 고유한 offset을 가짐
  • 컨슈머에서 중복 처리를 방지하기 위한 목적으로 사용

• key

  • 처리하고자 하는 메시지 값을 분류하기 위한 용도 (partitioning)
  • key는 partitioner에 따라 토픽의 partition 번호가 정해짐
  • 필수값은 아님, 지정하지 않으면 null (round-robin으로 파티션 정해질수도, 균등하게 들어감)
  • null 이 아닐 때는 해쉬값에 의해 특정 partition에 매핑됨 (동일한 데이터는 동일한 파티션에 들어감)
    • 순서를 지정하고자 할 때도 사용

• 메시지 값

  • 프로듀서-컨슈머가 직렬화/역직렬화 포맷을 알아야 함

    토픽 이름은 생성 후 수정이 안됨!!! 클라이언트 메타데이터

    

• 리더 partition의 위치를 알기 위해

• 프로듀서와 컨슈머가 데이터를 주고받기 전 브로커로부터 전달 받음

• metadata.max.age.ms : 메타데이터 강제 리프래시 간격(기본 5분)

• metadata.max.idle.ms : 프로듀서가 유휴상태일 경우 메타데이터를 캐시에 유지하는 기간(기본 5분)

• LEADER_NOT_AVAILABLE exception : 잘못된 메타데이터로 인해 리더파티션이 올바르지 않을 경우

[manjeong-dev]

브로커의 컨트롤러는 그럼 복제 대상에서 빠지나? 아님 부가적인 일을 하는 걸까?

• 부가적인 역할을 함( 파티션 복제도 해두고 컨트롤러 역할도 함 )

삭제(delete, compact)는 세그먼트 내에서만 발생? 다른 세그먼트는 compact 영향 안받음?

• retention 단위에 들어온 애들로 compact (< 확인 필요)

[manjeong-dev]

로그와 세그먼트 차이 프로듀서-브로커-파티션 연관관계

[manjeong-dev]

하나의 주키퍼로 클러스터를 묶는 단위는?

• 주키퍼를 하나의 db로 보고, 각각의 클러스터가 하나의 db(주키퍼)를 본다 정도로 이해
• 주키퍼 znode 관리

[manjeong-dev]

브로커 당 토픽 n개, 토픽은 n개의 파티션

• 토픽은 같은 데이터 집합군을 묶은 것

[manjeong-dev]

Q1. 특정 브로커 다운시, 해당 브로커가 가지고 있던 리더 파티션들을 다시 선출하는 주체는? 주키퍼 팔로워 파티션을 가진 브로커들 파티셔너 카프카전문가 태선님 컨트롤러

Q2. 컨슈머 처리량이 많이 필요하지않다면 파티션 개수를 줄이면된다 (O/X)

Q3. 카프카 프로듀서 또는 컨슈머 대신 카프카 커넥트를 썼을때 장점 2개는?

Q4. 카프카가 빠른 쓰기/읽기가 가능하지만 이미 쓰여진 메세지는 변경이 불가한 이유는 레코드를 [ ] 자료구조 형태로 저장하기 때문이다. 트리(Tree) 자료구조 로그(Log) 자료구조 스택(Stack) 자료구조 링크(Link) 자료구조

Q5. 일반적인 데이터 삭제 단위는? 데이터 레코드 단위 토픽에 포함된 데이터 전체 파일단위로 이루어진 로그 세그먼트 물리 디스크의 특정 directory 단위

Q6. 운영시 특정 브로커에 리더 파티션이 쏠리는 현상이 발생할 경우 대응할 수 있는 방안은? 수동으로 옮겨준다. 파티셔너가 설정한 주기마다 자동으로 옮겨주므로 따로 할건 없다. kafka-reassign-partitions.sh 스크립트로 파티션을 재분배해준다. 해당 브로커에 장애를 일으켜서 다시 리더 파티션을 선출한다.

Q7. 토픽 내 특정 키에 대한 처리 순서 보장이 필요하다면 프로듀서에서 메시지 전송시 offset을 지정해주면 된다. (O/X)

Q8. 브로커에 저장되는 데이터 파일 종류에 맞지 않은 것은? .index .timeindex .segment .log

Q9. cleanup.policy=delete 와 cleanup.policy=compact 옵션에 차이점은?

Q10. 토픽이 생성되었을 때 리더 파티션이 선출되는 방식은 [] 방식이다.

Q11. 카프카 클라이언트가 메타데이터 요청을 하는 주요한 이유는 무엇인가? 리더 파티션의 위치 토픽 이름 세그먼트 정보 파티션 개수

Q1. 5 Q2. X 파티션은 다시 줄일 수 없다 Q3. 카프카 커넥트는 대표적으로 다음과 같은 5가지 특징을 가지고 있다. 데이터 중심 파이프라인 : 카프카 커넥트를 이용해 카프카로 데이터를 보내거나, 카프카로 데이터를 가져옴 유연성 : 커넥트는 테스트를 위한 단독 모드(standalone mode)와 대규모 운영 환경을 위한 분산 모드(distributed mode)를 제공 재사용성과 확장성 : 커넥트는 기존 커넥터를 활용할 수도 있고 운영 환경에서의 요구사항에 맞춰 확장이 가능 편리한 운영과 관리 : 카프카 커넥트가 제공하는 REST API로 빠르고 간단하게 커넥트 운영 가능 장애 및 복구 : 카프카 커넥트를 분산 모드로 실행하면 워커 노드의 장애 상황에도 메타데이터를 백업함으로써 대응 가능하며 고가용성 보장 https://minkwon4.tistory.com/319 Q4. 2 로그는 마지막 offset 가지고 있음, 중간에 있는 데이터의 offset은 없음 세그먼트 단위로 삭제 가능 Q5. 3 Q6. 3 Q7. X 메시지 키를 똑같이 지정해주면 같은 파티션으로 들어가서 순서 보장해줌 Q8. 3 Q9. delete 는 세그먼트 전체를 삭제, compact 는 컴팩트 로직을 가지고 세그먼트 내에 메시지키를 단위로 삭제해 메시지키별로 가장 최근에 남아있는 메시지키만 남김. Q10. round-robin assignor로 지정가능 sticky.. 등 https://blog.voidmainvoid.net/361 Q11. 1 4번, availablePartition 갯수 등도 메타데이터 요청을 할 수 있음

[manjeong-dev]

[manjeong-dev]