데이터 엔지니어링 63일차 TIL

학습내용

Kafka란?
: 실시간 데이터를 처리하기 위해 설계된 오픈소스 분산 스트리밍 플랫폼
        - 데이터 재생이 가능한 분산 커밋 로그(Distributed Commit Log)
- Scalability와 Fault Tolerance를 제공하는 Publish-Subscription메시징 시스템(Producer-Consumer)
- High Throughput과 Low Latency 실시간 데이터 처리에 맞게 구현됨
- 분산 아키텍처를 따르기 때문에 Scale Out이란 형태로 스케일 가능
        - 서버 추가를 통해 Scalability달성(서버=Broker)
- 정해진 보육기한(retention period) 동안 메시지를 저장

Kafka의 주요기능 및 이점
- 스트림 처리
        - 실시간 스트림 처리를 목표로 만들어진 서비스
        - ksqlDB를 통해 SQL로도 실시간 이벤트 데이터 처리가 가능하다.
- High Throughput (높은 처리량)
        - Kafka는 초당 수백만 개의 메시지 처리가 가능하다.
- Fault Tolerance (내결함성)
        - Kafka는 데이터 복제 및 분산 커밋 로그 기능을 제공하여 장애 대응이 용이하다.
- Scalability (확장성)
        - Kafka의 분산 아키텍처는 클러스터에 브로커를 추가하여 쉽게 수평 확장이 가능하다.
- 풍부한 생태계의 존재
        - 커넥터와 통합 도구로 구성된 풍부한 에코시스템을 갖추고 있어 다른 데이터 시스템 및 프레임워크와 쉽게 연동 가능하다.
        - Kafka Connect, Kafka Schema Registry

데이터 이벤트 스트림
- 데이터 이벤트 스트림을 Topic이라고 부른다.
        - Producer는 Topic을 만들고 Consumer는 Topic에서 데이터를 읽어오는 구조
        - 다수의 Consumer가 같은 Topic을 기반으로 읽어들이는 것이 가능하다.

Message(Event) 구조 : Key, Value, Timestamp
- 최대 1MB
- Timestamp는 보통 데이터가 Topic에 추가된 시점
- Key 자체도 복잡한 구조를 가질 수 있다.
        - Key가 나중에 Topic데이터를 나눠서 저장할 때 사용됨(Partitioning)
- Header는 선택적 구성요소로 경량 메타 데이터 정보(Key-value pairs)

Kafka 아키텍쳐 - Topic과 Partition
- 하나의 Topic은 확장성을 위해 다수의 Partition으로 나뉘어 저장됨
- 메세지가 어느 Partition에 속하는지 결정하는 방식에 키의 유무에 따라 달라진다.
        - 키가 있다면 Hashing값을 Partition의 수로 나눈 나머지로 결정
        - 키가 없다면 라운드 로빈으로 결정(비추천)
- 하나의 Partition은 Fail-over를 위해 Replication Partition을 가짐
- 각 Partition별로 Leader와 Follower가 존재
        - 쓰기는 Leader를 통해 이뤄지고 읽기는 Leader/Follower들을 통해 이뤄진다.
        - Partition별로 Consistency Level을 설정 가능하다(in-sync replica - "ack")
- Topic의 파라미터
        - 이름, Partition의 수, 복제본의 수, Consistency Level("acks"), 데이터 보존 기한(기본 일주일), 메세지 압출 방식 등


Kafka 아키텍처 - Broker : 실제 데이터를 저장하는 서버
- Kafka Server 혹은 Kafka Node라고 부르기도 한다.
- Topic의 Partition들을 실제로 관리한다.
        - 한 Broker는 최대 4000개의 partition을 처리 가능하다.
- Kafka 클러스터는 기본적으로 다수의 Broker로 구성된다.
        - 원활한 관리와 부가 기능을 위한 다른 서비스들이 추가됨(Zookeeper)
        - 한 클러스터는 최대 20만개까지 partition을 관리 가능하다.
        - Broker들이 실제고 Producer/Consumer들과 통신을 수행한다.
- Broker는 물리서버 혹은 VM 위에서 동작한다.
        - 해당 서버의 디스크에 Partition 데이터들을 기록한다.
- Broker의 수를 늘림으로써 클러스터 용량을 늘릴 수 있다.(Scale Out)

Kafka 아키텍처 - 메타 정보 관리
- Broker 리스트 관리(Broker Membership)
        - Controller = Controller Election
- Topic 리스트 관리 (Topic Configuration)
        - Topic을 구성하는 Partition 관리
        - Partition별 Replica 관리
- Topic별 ACL(Access Control Lists) 관리
- Quota 관리

Producer, Broker, Consumer, Controller, Consumer Group

 

Topics, Partitions, Segments

Topic
- Consumer가 데이터(Message)를 읽는다고 없어지지 않는다.
- Consumer별로 어느 위치의 데이터를 읽고 있는지 위치 정보를 유지한다.
- Fault Tolerance를 위해 이 정보는 중복 저장된다.

Topic과 Partiton와 Replication
- 하나의 Topic은 다수의 Partition으로 구성(Scalability)
- 하나의 Partiton은 Fail-over를 위해 Replication Partition을 가짐
- 한 Partition에는 Leader와 Follower가 존재
        - 쓰기는 Leader를 통해 하고 읽기는 모든 Leader와 Follower를 통해 한다.

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

로그 파일의 특성 (Segment의 특성)
- 항상 뒤에 데이터(Message)가 쓰여짐 : Append Only
- 한번 쓰여진 데이터는 불변(Immutable)
- Retention period에 따라 데이터를 제거하기도 한다.
- 데이터에는 번호(offset)가 주어짐

Broker의 역할
- Topic은 다수의 시간순으로 정렬된 Message들로 구성
- Producer는Topic을 먼저 생성하고 속성 지정
- Producer는 Message들을 Broker로 전송
- Broker는 이를 Partition으로 나눠 저장(중복 저장)
        - Replication Factor : Leader & Follower
- Consumer는 Broker를 통해 메세지를 읽음
- 하나의 Broker는 다수의 Partition들을 관리/운영한다.

Producer
- 대부분의 프로그래밍 언어로 작성 가능
- 하나의 Topic은 다수의 Partition으로 구성되며 이는 Producer가 결정
- Producer가 사용가능한 Partition 선택방법
        - 기본 Partition 선택 : hash(key) % Partition의 수
        - 라운드로빈 : 돌아가면서 하나씩 사용
        - 커스텀 Partition로직을 구현

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

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

Kafka Schema Registry
- Schema Registry는 Topic 메시지 데이터에 대한 스키마를 관리 및 검증하는데 사용
- Producer와 Consumer는 Schema Registry를 사용하여 스키마 변경을 처리