✏️ 오늘 학습한 내용
1. Kafka Connect란
2. Kafka Schema Registry
🔎 Kafka Connect란
Kafka Connect는 Kafka 위에 만들어진 중앙집중 데이터 허브입니다.
데이터 버스 혹은 메세지 버스라고 볼 수 있으며,
( 다양한 데이터의 송수신을 위한 매개체 )
Kafka Connect는 별도의 서버로 구성이되는 시스템입니다.
( 별도의 오픈소스 프로젝트 )
원래 Kafka에서는 Product나 Consumer 등을 코딩을 해줘야하는데 그런 코딩 없이 많이 사용되는 데이터 시스템들을 미리 Connector라는 것을 만들어,
Kafka 클러스터와 클러스터를 구성하는 서버만 있으면
코딩 없이 환경설정의 형태로 데이터를 Kafka를 통해서 여러 곳으로 전송시킬 수 있는 기능
-
두 가지 모드
- Standalone 모드: 개발과 테스트 용도
- Distributed 모드: Production 용도
-
데이터 시스템들 간의 데이터를 주고 받는 용도로 Kafka를 사용하는 것
-
데이터 시스템의 예시 :
데이터베이스, 파일 시스템, 키-값 저장소, 검색 인덱스 등 -
데이터 소스와 데이터 싱크
- 데이터 소스 : 원본 데이터 (Producer)
- 데이터 싱크 : 목적지가 되는 데이터 시스템 (Consumer)
-
Kafka Connect는 Broker들 중 일부나 별개 서버들로 구성이 됩니다.
Connect 내부의 Task들은 Worker들이 수행합니다.
여기서 Task들은 Producer/Consumer의 역할을 말합니다.
( Source Task(Producer), Sink Task(Consumer) )
Kafka Connect를 사용했을 때의 장점
Kafka Connect를 사용하면 Topic에 저장이 된 event stream을 외부(ex) S3 버킷)에 쉽게 저장할 수 있습니다.
즉, Data Source에서 이벤트 스트림으로 읽어와 Data Sink(외부)로 내보내는 것이 쉬움
( 코딩 없이 환경설정만으로 해결 가능 )
🔎 Kafka Schema Registry
Topic에 어떤 메세지들이 기록이 될 때, 이 메세지 포맷이 정말 맞는 건지 검증하는 것이 중요합니다.
Topic 별로 어떤 형태의 Data Format을 기대하고 있는지, 이 정보를 저장해두는 곳이 Schema Registry입니다.
즉,
-
Schema Registry는 Topic 메시지 데이터에 대한 스키마를 관리 및 검증하는데 사용
-
Topic으로 저장되는 Data Format을 Kafka Schema로 만들어 Schema Registry에 저장
-
Producer와 Consumer는 Schema Registry를 사용하여 스키마 변경을 처리
Data serialized with schema
메세지를 구성하는 데이터를 네트워크를 타고 보내려면 데이터가 순서대로 나열이 되야합니다.
ex)
message 안의 key,value,timestamp 등의 정보들이 네트워크를 타고 송신이 되거나 디스크에 저장이 되거나 하려면 데이터들이 어떠한 형태로든 일렬로 순서대로 기록이 되야함
( key -> value -> timestamp -> head와 같은 순서가 정해져있어야함 )
Product service에서 Kafka로 serialization해서 보내면
-> Kafka에서 그대로 저장했다가
-> Consumer service로 보냄
( 이때, Consumer service에서 deserialization을 진행 )
Serialization and Deserialization
Serialization (직렬화)
-
객체의 상태를 저장하거나 전송할 수 있는 형태로 변환하는 프로세스
( 순서에 맞게끔 정렬 및 압축 ) -
보통 이 과정에서 데이터 압축 등을 수행.
가능하다면 보내는 데이터의 스키마 정보 추가
Deserialization (역직렬화)
-
Serialized된 데이터를 다시 사용할 수 있는 형태로 변환하는 Deserialization
-
이 과정에서 데이터 압축을 해제하거나 스키마 정보 등이 있다면 데이터 포맷 검증도 수행
Schema Registry 흐름
Producer가 데이터를 보낼 때,
Topic에 저장이 될 메세지의 Format을 Schema Registry를 기록을 하면 ScheamID와 버전 정보를 받아옴,
받아온 ID 정보들을 메세지와 함께 Kafka에 보냄,Consumer 측에서 Topic에 있는 데이터를 읽으면 메세지를 구성하는 내용과 SchemaID 및 버전 정보가 있음,
이를 통해서 Schema Registry를 통해 Format 정보를 알아낼 수 있음
포맷 변경을 처리하는 방법
-
Forward Compatibility: Producer부터 변경하고 Consumer를 점진적으로 변경하는 방법
-
Backward Compatibility: Consumer부터 변경하고 Producer를 점진적으로 변경하는 방법
( 대부분의 경우 이 방법을 사용 ) -
Full Compatibility: 둘다 동시에 변경하는 방법
