유튜브 데브원영님 카프카 강의

유튜브 내 블로그 링크 참고

배경

참고 : https://velog.io/@sung-ik-je/DW
ETL, DW, DM 등의 설명이 있는 글을 참고하며 생각했을 때 여러 Tool의 역할이 존재하기 이전에 Data Source에서 Target(=목적으로 하는 작업)까지 직접적으로 연결되어 결합도가 굉장히 높았고 시스템이 커질수록 유지보수 및 운영에 많은 차질 존재

kafka는 해당 과정에서 Source와 Target의 결합도를 낮춰주며 유지보수 및 운영이 힘든 단점을 커버하기 위한 기술이라 생각하면 된다

Source는 kafka에 데이터만 보내준다면 Target은 kafka에서 데이터를 꺼내 사용할 수 있다

오픈 소스이며 빌드 도구에 의존성을 추가해 사용

• maven, gradle 등
• 이 때 clinets와 broker의 버전 호환성 유의

hadoop, ELK 등의 저장소에 데이터를 저장해주는 역할

작동

Source를 Kafka Producer, Target을 Kafka Consumer라 지칭하며 Kafka는 Topic이라는 Queue 형태로 작동한다.

Topic

데이터가 들어갈 수 있는 공간

여러 개 생성할 수 있으며 DB의 테이블, 파일 시스템의 폴더 개념과 유사

Producer가 Topic에 Data를 넣고 Consumer가 가져가며 Topic 고유 이름 작명 가능

partition

하나의 Topic은 여러 개의 partition으로 구성될 수 있으며 partition = queue 역할

consumer는 데이터를 가장 오래된 순서대로 가져간다

• 데이터 안들어오면 추가 데이터 들어올 때 까지 기다린다
  
  
• consumer가 데이터 가져가도 데이터는 partition에 그대로 위치한다
  
  
• 다른 consumer는 다시 0(가장 오래된 데이터)부터 가져감
  • consumer group마다 head 위치 다름
  • 이는 동일 데이터 두번 사용 가능하며 같은 데이터를 다양한 목적으로 사용 가능하다
    
    
• partition이 여러 개인 경우 기본적으로는 round-robin(모두 동일한 시간 주어지며 초과 시 대기 모드)
  • 골고루 들어가는 개념
    
    
• partition 늘리는거 자유지만 줄일 수는 없다
  + 이 경우 consumer를 늘려서 데이터 처리를 분산 시킬 수 있다
  
  
  분산 데이터 작업이라는게 여러 개의 topic-partition(Queue)를 여러 개의 consumer(작업)으로 분리해 하나의 데이터를 다양한 작업을 진행한다는 것을 의미하는 것 같다는 생각이 든다
  
  
  
  
  
  

Producer

데이터를 kafka에 보내는 역할(생산자)

• kafak에 적재
• 여기서 전달 받는 주체가 Leader Partition

역할

Topic에 해당하는 메시지를 생성

특정 Topic으로 데이터를 전송

전송 성공 여부 및 재시도 기능

key, value 형태로 운영할 수 있다

• key는 topic 지정, value는 보낼 데이터
• 하지만 key를 사용하다가 partition을 늘리는 경우에 일관성 보장 X(새로 생긴 partition은 key 종속이 안되어 있어 기존의 key들이 해당 partition에 들어갈 수 있다)
  
  
  
  
  
  

broker, replication, ISR

broker

: kafka가 설치되어 서버 단위를 말한다

• 보통 3개 이상 broker 구성 추천
  
  

replication

: 원본 partition + 복제본 partition 갯수를 의미

• 서버에 문제가 발생했을 때 가용성을 위해 운영(고가용성을 위해)
• 원본을 Leader partition, 복제본을 Foller partition
• ack라는 옵션 존재
  • ack=0 : Leader partition에 복제, response 없음(속도 빠르지만 정상적인 작동 유무 판단 불가)
  • ack=1 : 응답값(response) 받음, Leader partition 외 나머지 partition에 복제되었는지 알 수 없음
    • Leader partition 받자마자 사고 난다면 데이터 유실 가능성 존재
  • ack=all : Leader, Follwer 전체 partition의 response 모두 받음(데이터 유실 없음, 하지만 0과 1에 비해 확인하는 부분 많기 때문에 속도 현저히 느림)
• replication 늘어날수록 broker의 resource 사용량도 증가
  • Follwer partition 존재하는 broker(=server) 늘어나기 때문
    
    

ISR

: In Sync Replica

• Leader, Foller partition을 합친 전체를 의미
  
  
  
  
  
  

Consumer

broker, clients 버전호환성 유의

기본적으로 Topic에 데이터를 가져온다

• 가져오는 작업을 Polling이라고 한다
• 다른 Messaging system에서는 Consumer가 데이터를 가져가면 데이터가 사라지지만 kafka에서는 데이터가 사라지지 않는다
• 특정 topic 전체 혹은, topic 내 일부 partition의 데이터만 가져올 수 있다

Partition offset 위치 기록

• partition에 있는 데이터의 번호
• 정확히는 Consumer가 partition에 어느 부분까지 읽었는지 확인하는 용도
• 이는 consumer에 문제가 생겼을 때 데이터의 처리 시점을 알수 있는 고 가용성의 특징을 가지게 된다

Consumer Group(여러 개의 Consumer)을 통해 병렬처리

• 여러 consumer 병렬처리 위해서는 consumer의 갯수가 partition보다 적거나 같아야 한다
  • 하나의 partition은 하나의 consumer Group에만 매칭되기 때문
  • 만약 다른 consumer group이라면 상관 X
  • ex) 데이터를 hadoop, ELK 두 가지로 저장소로 저장한다고 할 때 Consumer Group이 다르므로 서로 다른 offset을 저장하며 데이터를 읽는데 문제 없이 분산 처리가 가능하다
  • 즉 consumer group들은 각자 다른 작업 목적으로 서로 영향을 주지 않으며 다양한 분산 처리 작업이 가능하다