Kafka 기타 기능 살펴보기

 

 

3. Kafka 소개

Kafka가 무엇인지 소개하는 시간을 가져보자

 

 

 

 

 

 

 

Contents

1. Kafka 역사
2. Kafka 소개
3. Kafka 아키텍처
4. Kafka 중요 개념
5. Kafka 설치
6. Kafka Python 프로그래밍

 

 

 

 

 

 

 

 

 

 

Kafka 기타 기능 살펴보기

 

 

 

 

 

 

 

Kafka Connect란? (1)

 

Kafka Connect는 Kafka 위에 만들어진 중앙집중 데이터 허브

○ 별도의 서버들이 필요하며 Kafka Connect는 별도의 오픈소스 프로젝트임
○ 데이터 버스 혹은 메세지 버스라고 볼 수 있음

 

두 가지 모드가 존재

○ Standalone 모드: 개발과 테스트
○ Distributed 모드

 

데이터 시스템들 간의 데이터를 주고 받는 용도로 Kafka를 사용하는 것

○ 데이터 시스템의 예: 데이터베이스, 파일 시스템, 키-값 저장소, 검색 인덱스 등등
○ 데이터 소스와 데이터 싱크

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka Connect란? (2)

Broker들 중 일부나 별개 서버들로 Kafka Connect를 구성

○ 그 안에 Task들을 Worker들이 수행. 여기서 Task들은 Producer/Consumer 역할

    ■ Source Task, Sink Task

    ■ Source Task는 Data Producer, Sink Task는 Data Consumer
○ 외부 데이터(Data Source)를 이벤트 스트림으로 읽어오는 것이 가능
○ 내부 데이터를 외부(Data Sink)로 내보내어 Kafka를 기존 시스템과 지속적으로 통합 가능
    ■ 예: S3 버킷으로 쉽게 저장, 이 때 S3가 Data Sink가 됩니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka Connect란? (3)

 

Kafka Cluster가 데이터 송수신을 위한 매개체 역할을 합니다. 왼쪽의 Kafka Connect는 사람들이 많이 사용하는 Source의 데이터를 코딩없이 환경설정만으로 Kafka Cluster의 Topic으로 저장하는 Data Producer역할을 합니다.

 

오른쪽의 Kafka Connect는 Kafka Cluster의 Topic으로부터 데이터를 읽어 Sink내의 목적지가 되는 데이터 시스템에 저장하는 Data Consumer 역할을 합니다.

 

많은 경우 어떤 데이터 시스템은 상황에 따라 Source와 Sink의 역할을 맡기도 합니다. 한 시스템의 데이터를 다른 시스템으로 복제하려는 용도로 Kafka Cluster와 Kafka Connect를 사용하기도 합니다. 즉, ETL과 비슷한 역할을 하며 실제 ETL 역할을 Kafka가 하기도 합니다.

 

 

 

 

 

 

 

 

 

 

Kafka Schema Registry (1)

 

Schema Registry는 Topic 메시지 데이터에 대한 스키마를 관리 및 검증하는데 사용

 

Producer와 Consumer는 Schema Registry를 사용하여 스키마 변경을 처리

 

 

Topic(의 메시지)별로 어떤 데이터 포맷이 들어갈지 Schema Registry를 이용해 관리 및 검증합니다.

 

 

 

 

 

 

 

 

 

 

참고! Serialization and Deserialization

 

Serialization (직렬화)

○ 객체의 상태를 저장하거나 전송할 수 있는 형태로 변환하는 프로세스
○ 보통 이 과정에서 필요하다면 데이터 압축등을 수행. 가능하다면 보내는 데이터의 스키마 정보 추가

 

Deserialization (역직렬화)

○ Serialized된 데이터를 다시 사용할 수 있는 형태로 변환하는 Deserialization
○ 이 과정에서 데이터 압축을 해제하거나 스키마 정보 등이 있다면 데이터 포맷 검증도 수행

 

 

 

 

 

Why Serialization & Deserialization in Kafka?

 

Serialization and deserialization are fundamental concepts in Kafka, and they serve a crucial role in data processing. Here's why:

1. Serialization: Kafka stores and transmits data in byte arrays. When you produce a message to Kafka, you're often dealing with structured data objects (like strings, integers, or more complex data structures). These objects need to be converted into a format that can be stored or transmitted over the network. This process is called serialization. It's the conversion of data structures or object state into a format that can be stored and resurrected later in the same or another computer environment.
2. Deserialization: When you consume a message from Kafka, you receive a byte array. To process this data, you need to convert it back into its original data structure or object. This process is called deserialization.

The reason Kafka uses serialization/deserialization is to ensure efficient storage and transmission of data. By converting data to byte arrays, Kafka can store and send data more efficiently, which is crucial for a high-throughput system like Kafka.

In Kafka, you can use different serializers and deserializers based on your data format. Kafka provides built-in serializers and deserializers for simple types like strings and integers, but you can also implement your own for more complex types or other data formats like Avro, Protobuf, or JSON.

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka Schema Registry (2)

 

Schema ID(와 버전)를 사용해서 다양한 포맷 변천(Schema Evolution)을 지원

○ 보통 AVRO를 데이터 포맷으로 사용 (Protobuf, JSON)

 

포맷 변경을 처리하는 방법

○ Forward Compatibility: Producer부터 변경하고 Consumer를 점진적으로 변경
○ Backward Compatibility: Consumer부터 변경하고 Producer를 점진적으로 변경
○ Full Compatibility: 둘다 변경

 

 

 

누가 메세지의 serialization과 deserialization을 담당하는가?
보통 Kafka 관련 라이브러리를 사용해 Producer와 Consumer를 만들면 라이브러리들이 알아서 해줌

다만 Topic을 만들 때 메시지의 포맷이 AVRO냐, Protobuf냐, JSON이냐 등 무엇인지는 정해주어야 합니다.

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - REST Proxy

보통 Kafka를 쓰게 될 때는 Kafka와 같은 네트워크안에 Producer와 Consumer를 구현해 아까 얘기한 AVRO 포맷 등으로 Serialized된 데이터를 보내 Deserialize하게 됩니다. 이 때 성능상의 이유로 모든 컴포넌트를 같은 네트워크에 두게 되고 따라서 네트워크 외부에서는 네트워크 내부의 Kafka에 접근해 작업을 실시하는게 쉽지 않습니다.

 

네트워크 외부에서 내부 Kafka Cluster의 Topic에 데이터를 새로 쓰거나 읽는 경우 쓰는 데이터의 실시간성이 크지 않고 데이터의 크기가 크지 않다는 전제하에 Kafka Topic을 API형태로 외부에 노출 시켜주는 것을 REST Proxy라고 합니다.

 

클라이언트가 API 호출을 사용하여 Kafka를 사용 가능하게 해줌

○ 메시지를 생성 및 소비하고, 토픽을 관리하는 간단하고 표준화된 방법을 제공
○ REST Proxy는 메세지 Serialization과 Deserialization을 대신 수행해주고 Load Balancing도 수행

 

특히 사내 네트워크 밖에서 Kafka를 접근해야할 필요성이 있는 경우 더 유용

 

 

REST Proxy를 쓰면 Producer를 만들어 Kafka REST Proxy의 API를 사용해 Kafka 클러스터의 Topic을 만들어 그곳에 메시지를 저장할 수 있고 반대로 REST Proxy의 API로 Consumer를 만들 수도 있습니다.

 

즉, Kafka의 디테일을 몰라도 REST Proxy의 파라미터와 리턴 값만 이해하면 Kafka의 Topic을 메시지 큐로 사용할 수 있다는 것입니다.

 

REST Proxy는 로드 밸런싱 이슈로 보통 다수의 서버로 구현하는 것이 일반적입니다.

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - Streams와 KSQL

 

KSQL은 더 이상 쓰이지 않고 뒤에서 설명드릴 ksqlDB로 대체되었습니다.

 

Kafka Streams: Kafka Topic을 소비하고 생성하는 실시간 스트림 처리 라이브러리

○ Spark Streaming으로 Kafka Topic을 처리하는 경우는 조금 더 micro batch에 가까움 (적은 수지만 다수의 레코드들을 동시에)
○ Kafka Streams로 Kafka Topic을 처리하는 것은 조금더 Realtime에 가까움 (레코드 단위로 레코드 하나씩 처리)

○ 라이브러리이며 Kafka를 구성하는 컴포넌트가 아닙니다.

 

KSQL: Confluent에서 개발한 Kafka용 오픈 소스 SQL 엔진

○ SQL을 사용해 스트리밍 데이터를 실시간으로 쿼리, 분석, 처리할 수 있는 방법 제공 (Continuous Query)
○ SQL로 코드 작성의 복잡성을 추상화하여 스트림 처리 애플리케이션 개발을 간소화

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - ksqlDB

 

Kafka Streams로 구현된 스트림 처리 데이터베이스로 KSQL을 대체

○ Kafka Streams를 사용하며 위에서 돌아가는 별도의 서비스

○ SQL과 유사한 쿼리 언어. 필터링, 집계, 조인, 윈도우잉 등과 같은 SQL 작업 지원
○ 연속 쿼리(Continuous Query): ksqlDB를 사용하면 데이터가 실시간으로 도착할 때 지속적으로 처리하는 연속 쿼리 생성 가능
○ 지속 업데이트되는 뷰 지원: 실시간으로 지속적으로 업데이트되는 집계 및 변환 가능

 

Spark에서 보는 것과 비슷한 추세: SQL이 대세

Spark에서 보았듯이 구조화된 데이터를 다루는데 있어서는 SQL이 최고

 

ksqlDB를 다르게 생각하면 Kafka 토픽을 스토리지로 쓰고 그 스토리지에 저장된 토픽을 SQL로 계산할 수 있게 해주는 서비스라고 보시면 됩니다.

 

위의 쿼리문과 같은 형태로 뷰나 테이블을 쉽게 만들 수 있습니다. 즉, locations가 Kafka에 있는 Topic이고 이 토픽으로 activePromotions라는 새로운 토픽을 만든 것입니다.