[Kafka] Kafka 중요 개념

Programmers TIL

PTJ 2023. 7. 12. 16:41

- Topics, Partitions, Segments 개념도

- Topic

- Partition과 Segment

하나의 Partition은 다수의 Segment로 구성됨
- Segment는 변경되지 않는 추가만 되는 로그 파일이라고 볼 수 있음 (Immutable, Append-Only) - Commit Log
각 Segment는 디스킇상에 존재하는 하나의 파일
Segment는 최대 크기가 있어서 이를 넘어가면 새로 Segment파일을 만들어냄
- 그래서 각 Segment는 데이터 오프셋 범위를 갖게 됨
- Segment의 최대 크기는 1GB 혹은 일주일치의 데이터

- 로그 파일의 특성 (Partiton의 특성 => 정확히는 Segment의 특성)

* Commit Log란?

Sequential, Immutable, Append-Only
WAL (Write Ahead Logging)
- 데이터 무결성과 신뢰성을 보장하는 표준 방식
- 데이터베이스에 대한 모든 변경 사항을 먼저 Commit Log라는 추가 전용 파일에 기록
Replication과 Fault Tolerance의 최소 단위
Data Recovery나 Replay에 사용 가능

- Broker의 역할

Topic은 다수의 시간순으로 정렬된 Message들로 구성
Producer는 Topic을 먼저 생성하고 속성 지정
Produceer가 Message들을 Broker로 전송
Broker는 이를 Partition으로 나눠 저장 (중복 저장)
- Replication Factor: Leader & Follower
Consumer는 Broker를 통해 메세지를 읽음
하나의 Kafka 클러스터는 다수의 Broker로 구성됨
하나의 Broker는 다수의 Partition들을 관리/운영
한 Topic에 속한 Message들은 스케일을 위해 다수의 Partition들에 분산 저장
다수의 Partition들을 관리하는 역할을 하는 것이 Broker들
- 한 Broker가 보통 여러 개의 Partition들을 관리하며 이는 Broker가 있는 서버의 디스크에 저장됨
- Broker들의 전체적으로 저장된 Partition/Replica의 관리는 Controller의 역할
하나의 Partition은 하나의 로그 파일이라고 볼 수 있음
- 각 Message들은 각기 위치 정보(offset)를 갖고 있음
이런 Message들의 저장 기한은 Retention Policy로 지정

- Producer 기본

- Producer의 Partition 관리 방법

하나의 Topic은 다수의 Partition으로 구성되며 이는 Producer가 결정
Partition은 두 가지 용도로 사용됨
- Load Balancing
- Semantic Partitioning (특정 키를 가지고 레코드를 나누느 경우)
Producer가 사용 가능한 Partition선택 방법
- 기본 Partition 선택 : hash(key) % Partiton의 수
- 라운드 로빈: 돌아가면서 하나씩 사용
- 커스텀 Partition로직을 구현할 수도 있음

- Consumer 기본

Topic을 기반으로 Message를 읽어들임 (Subscription이란 개념 존재)
Offset을 가지고 마지막 읽어들인 Message위치정보 유지
Command Line Consumer 유틸리티 존재
Consumer Group이라는 개념으로 Scaling 구현
- Backpressure 문제 해결을 위한 방법
Consumer는 다시 Kafka에 새로운 토픽을 만들기도 함
- 아주 흔히 사용되는 방법으로 하나의 프로세스가 Consumer이자 Producer역할 수행

Kafka 기타 기능 살펴보기

- Kafka Connect

Kafka Connect는 Kafka위에 만들어진 중앙집중 데이터 허브
- 별도의 서버들이 필요하며 Kafka Connect는 별도의 오픈소스 프로젝트
- 데이터 버스 혹은 메세지 버스라고 볼 수 있음
두 가지 모드가 존재
- Standalone 모드: 개발과 테스트
- Distributed 모드
데이터 시스템들 간의 데이터를 주고 받는 용도로 Kafka를 사용하는 것
- 데이터 시스템의 예: 데이터베이스, 파일 시스템, 키 - 값 저장소, 검색 인덱스 등등
- 데이터 소스와 데이터 싱크
Broker들 중 일부나 별개 서버들로 Kafka Connect를 구성
- 그 안에 Task들을 Worker들이 수행, 여기서 Task들은 Producer/Consumer 역할
  - Source Task, Sink Task
- 외부 데이터(Data Source)를 이벤트 스트림으로 읽어오는 것이 가능
- 내부 데이터를 외부(Data Sink)로 내보내어 Kafka를 기존 시스템과 지속적으로 통합 가능
  - 예: S3 버킷으로 쉽게 저장할 수 있음

- Kafka Schema Registry

* Serialization and Deserialization이란?

Serialization (직렬화)
- 객체의 상태를 저장하거나 전송할 수 있는 형태로 변환하는 프로세스
- 보통 이 과정에서 데이터 압축등을 수행, 가능하다면 보내는 데이터의 스키마 정보 추가
Deserialization (역직렬화)
- Serialized된 데이터를 다시 사용할 수 있는 형태로 변ㄴ환하는 Deserialization
- 이 과정에서 데이터 압축을 해제하거나 스키마 정보 등이 있다면 데이터 포맷 검증도 수행

Schma ID를 사용해서 다양한 포맷 변천(Schema Evolution)을 지원
- 보통 AVRO를 데이터 포맷으로 사용 (Protobuf, JSON)
포맷 변경을 처리하는 방법
- Forward Compatibility: Producer부터 변경하고 Consumer를 점진적으로 변경
- Backward Compatibility: Consumer부터 변경하고 Producer를 점진적으로 변경
- Full Compatibility: 둘다 변경

- REST Proxy

클라이언트가 API호출을 사용하여 Kafka를 사용 가능하게 해줌
- 메시지를 생성 및 소비하고, 토픽을 관리하는 간단하고 표준화된 방법을 제공
- REST Proxy는 메세지 Serialization과 Deserialization을 대신 수행해주고 Load Balancing도 수행
특히 사내 네트워크 밖에서 Kafka를 접근해야할 필요성이 있는 경우 더 유용

- Kafka Streams

Kafka Topic을 소비하고 생성하는 실시간 스트림 처리 라이브러리
- Spark Streaming으로 Kafka Topic을 처리하는 경우는 조금더 micro batch에 가까움 (특정한 주기로 다수의 레코드를 처리)
- Kafka Streams로 Kafka Topic을 처리하는 것은 조금더 Realtime에 가까움 (레코드 단위 처리)

- KsqlDB

Kafka Streams로 구현된 스트림 처리 데이터베이스로 KSQL을 대체
- SQL과 유사한 쿼리 언어. 필터링, 집계. 조인, 윈도우잉 등과 같은 SQL작업 지원
- 연속 쿼리 : ksqlDB를 사용하면 데이터가 실시간으로 도착할 때 지속적으로 처리하는 연속 쿼리 생성 가능
- 지속 업데이트되는 뷰 지원: 실시간으로 지속적으로 업데이트되는 집계 및 변환 가능