[Kafka] 카프카 기초지식 정리
kafka란?
- 다양한 데이터 소스에서 실시간으로 흐르는 데이터를 처리하는 오픈소스 분산 스트리밍 플랫폼(소프트웨어)
- 규모 가변성(scalability)와 내결함성(Fault Tolerance)를 제공하는 Publish-Subscription 메시징 시스템(데이터 처리 시스템)
- hight Throughput(많이)과 Low Latency(빨리) 실시간으로 데이터를 처리할 수 있도록 구현됨
- 서버(Broker) 추가를 통해 Scalability 달성
- 정해진 보유기한(retention period) 동안 메시지(데이터)를 저장
기존 메시징 시스템 및 데이터베이스와의 비교
- 기존 메시징 시스템과 달리, 카프카는 메시지 보유 기간 동안 저장(기본 보유 기간은 일주일)
- 브로커를 통해 메시지를 생산하고 소비함으로써 메시지 생산과 소비를 분리
→ 생산자와 소비자가 각자의 속도에 맞춰 독립적으로 작업이 가능하다
- 한 파티션 내에서는 메세지 순서를 보장해줌
ㅇ 하지만 다수의 파티션에선 Eventually Consistent를 가짐
ㅇ 토픽을 생성할 때 지정 가능함
※ consistency(일관성)
- 같은 쿼리문을 여러번 날렸을때 같은 결과가 나오는 특징
- 분산 시스템에선 update가 발생하면 전체 시스템에 반영되는데 시간이 걸림
- 여기서 Strong Consistency와 Eventual Consistency로 갈림
ㅇ Strong Consistency
- update가 전체 시스템에 반영될 때까지 기다린 후 자료를 리턴해주는 구조
- update 중 쿼리가 날라올 경우 update가 모두 반영된 후 자료를 리턴해주기 때문에 응답 속도가 느릴 수 있다
- 가장 최근 업데이트를 반영한 결과물을 얻을 수 있다(결과물에 대한 신뢰도가 높다)
ㅇ Eventual Consistency
- Update가 전체 시스템에 반영되는 것과 상관없이 가장 최신 자료를 리턴해주는 구조
- Update 중 쿼리가 날라와도 결과물을 바로 리턴해 줄 수 있기 때문에 응답속도가 빠르다
- update 중 쿼리가 날라올 경우 시스템 전체에 updat가 반영되기 까지 시간이 있기 때문에 리턴된 결과물이 가장 최근 업데이트된 것이 아닐 수 있다(결과물에 대한 신뢰도 저하)
Kafka 아키텍처
데이터 이벤트 스트림
- 스트림 -> 데이터가 흐르는 공간
- 이벤트 데이터(메세지)들이 실시간으로 흐르는 공간의 집합 또는 실시간으로 흐르고 있는 이벤트 데이터 흐름의 집
ㅇ 이벤트 데이터(메세지)란 어떤 이벤트에 대해 측정하고자 하는 모든 데이터
- Producer는 Topic을 만들고 Consumer는 Topic으로부터 데이터를 읽어드리는 구조
- 다수의 Consumer가 같은 Topic에서 데이터를 읽어들이는 것이 가능
Message(Event data) 구조
- Headers + Key + Value + Timestamp
- 최대 1MB
- Key
ㅇ 메세지가 추가되는 topic(또는 Partition) 결정할 때 사용되며 다양한 데이터 타입으로 표현할 수 있음
ㅇ 만약, key가 null이면 해당 메세지는 라운드로빈 방식으로 전달된다.
ㅇ 선택사항임
- Header: 선택적 구성요소로서 경량 메타 데이터를 담고있다
Topic과 Partition
Topic
- 데이터의 스트림을 형성하며, 프로듀서(Producer)가 데이터를 보내고 컨슈머(Consumer)가 데이터를 소비하는 중간 매체
- 사용자(or Producer)에 의해 데이터의 유형이나 주제에 따라 구성할 수 있습니다.
- Consumer가 데이터(Message)를 읽는다고 없어지지 않음
- Consumer별로 어느 위치의 데이터를 읽고 있는지 위치 정보(offset)를 유지함
- Fault Tolerance를 위해 이 정보는 중복 저장됨
Partition
- 한 topic의 들어온 다량의 메시지를 병렬화 된 데이터를 담는 곳.
- 참고로 Partition 안에 하나 이상의 segment(물리적 file, commit log)로 구성됨
- 메시지의 키에서 Hashing한 결과에 따라 메세지가 어느 partition으로 담겨질지 결정된다
ㅇ 키 O: hashing된 값은 엄청난 큰 값이기 때문에 Partition의 수로 나눈 나머지로 partion을 결정
ㅇ 키 X: 라운드 로빈으로 결정(비추)
Partition과 복제본(Replication)
- 하나의 Partition에는 Fail-over를 위해 Replication paritition이 존재하고 그 개수는 1~N개이다
- Partition에는 Leader와 Follower가 존재함
ㅇ Follower는 Replication Partition임
ㅇ 쓰기는 Leader에서만 읽기는 Leader/Follower에서 이뤄짐
ㅇ Partition별로 Consistency Level을 설정 가능함
→ Consistency Level(in-sync replica - “ack”)
· Paritition에서 몇개의 복제본에서 작업의 일관성이 확인되어야 하는지
· ack = 0: Producer는 자신이 보낸 메시지에 대한 ack를 기다리지 않는다
· ack = 1: Leader로부터 메시지를 잘 받았는지 ack를 기다린다. Follower들은 확인하지 않는다.
· ack = 2 ~ n: Leader와 n개의 follower로 부터 메시지를 잘 받았는지 ack를 기다린다.
Broker(서버)
- Topic의 Partition들을 실제로 관리해주는 것
- Broker들이 실제로 Producer/Consumer들과 통신 수행
- Kafka 클러스터는 기본적으로 다수의 Broker로 구성됨
ㅇ 한 클러스터는 최대 20만개까지 partition을 관리 가능
ㅇ Broker의 수를 늘림으로써 클러스터 용량을 늘림 (Scale Out)
- 하나의 broker 안에 다수의 Partition들을 관리/운영
- Broker는 물리서버 혹은 VM 위에서 동작
Zookeeper
- Broker 리스트 관리(Broker 들의 목록/설정을 관리)
- Topic 리스트 관리 (Topic Configuration)
ㅇ Topic을 구성하는 Partition 관리
ㅇ Partition별 Replica 관리 Partition들을 ss관리해주는 역할을 하는 것이 Controller
→ 각 Broker들이 갖고 있는 모든 파티션과 복제본에 대한 정보는 하나의 Broker가 갖게 됨 -> 그 broker가 Controller