[Kafka] Producer와 Consumer의 한계

 

Kafka는 Producer와 Consumer Client를 통해 메시지를 파이프라인을 쉽게 구성할 수 있다.

 

하지만 전달해야할 DB가 늘어날 때 마다 Producer, Topic, Consumer도 한개씩 늘어나기 때문에 개발 비용, 반복작업이 많아 질 수 있다. 따라서, 더 간편하고 효율적으로 메시지 파이프라인을 구축하는 방법으로 Kafka에서는 Connect와 Connector라는 것이 탄생하게 되었다.

 

 

Connect & Connector 

Connect는 데이터 시스템과 Kafka 간의 데이터를 확장 가능하고, 안전한 방법으로 Streaming하기 위한 도구이다.

Connect를 사용하기 위해서 데이터를 어디로부터 가져오는지, 어디에다가 전달해야 하는지를 알려주는 Connector를 정의해야 한다.

Connector란 메시지 파이프라인에 대한 추상 객체이며, task들을 관리한다.

 

Connect - Framework

 

Connector - Connect안에서 돌아가는 플러그인

 

Connect 프레임워크를 실행하고 특정 Connector 플러그인을 실행시키면 메시지 파이프라인을 쉽게 구축할 수 있다.

이를 통해 개발 비용을 줄이고 반복 작업도 줄일 수 있다.

 

Connector에는 아래와 같은 두 가지 종류의 Connector가 존재한다.

 

Source Connector

• Source system의 데이터를 브로커의 토픽으로 publish하는 Connector이다.
• Producer의 역할을 하는 Connector이다.

 

Sink Connector

• 브로커의 토픽에 있는 데이터를 subscribe해서 target system에 전달하는 Connector이다.
• Consumer의 역할을 하는 Connector이다.

 

Connect&Connector 메시지 파이프라인 구축한 예시는 다음과 같다.

 

 

Connector에 대한 설정 파일만 있으면 개발 비용 없이 간단하게 띄울 수 있다.

 

Source Connector의 경우, Connect의 유형, 연결할 URL, user와 password, 테이블 이름, 토픽의 파티션수, Replication Factor 수 등을 설정해주면 Connect에서 인스턴스로 생성할 수 있다. 

이렇게 생성된 Connector들이 N개의 Producer를 개발하는 것보다는 훨씬 비용이 적고 간편하다.

 

 

Schema Registry

Schema Reistry는 Connect와 함께 쓰인다.

Kafka는 decoupling(의존성 낮음)이라는 특징을 가지고 있다.

• Producer와 Consumer가 존재하고, 서로 의존적이지 않고 완벽히 분리되어 있다. 
• 브로커는 메시지를 한 번에 저장하면 이후에 수정할 수 없다.

 

Kafka는 구조적 특징과 내부 구조로 인해 문제점이 발생한다.

(그림 출처 : https://always-kimkim.tistory.com/entry/kafka101-schema-registry)

Consume Fail

1. Producer 1과 2는 각자 브로커의 토픽 A에 메시지를 보낸다.
2. Consumer는 토픽 A에 있는 메시지를 읽는다.
3. Producer 2가 schema를 변경하여 메시지 (4번)을 발행한다.
4. Consumer는 이 상황을 알지 못하기 때문에, 4번 메시지를 구독하여 처리하는 과정에서 메시지를 읽어들이지 못하고 장애 발생

 

구조적인 결합도는 낮췄지만 내부적인 결합도 문제는 여전히 가지고 있다.

 

이러한 문제에 더하여 동일한 schema의 메시지가 계속 들어오는 경우, 같은 schema를 계속해서 저장해야 하기 때문에 메시지의 크기가 커지며, schema가 중복되어 불필요한 데이터 용량을 차지하게 된다.

 

이러한 문제를 해결하기 위해 Kafka에서는 Schema Registry를 사용한다.

 

다음은 Kafka Connector가 만들어 내는 메시지 구조다.

 

메시지는 key와 value로 구성되어 있으며, 각 Key와 Value는 schema와 payload로 구성되어 있다.

여기서 key는 PK와 같이 데이터를 식별할 수 있는 정보가 들어있고, value는 데이터의 전체 값이 들어있다.

payload는 데이터 값이 저장되며, schema에는 이 데이터 값의 데이터 타입이 명시되어 있다.

 

다음은 Producer, Schema Registry, Kafka 간의 관계이다.

 

1. Producer에서 Kafka의 Serializer(또는 Converter)에게 메시지를 보낸다.
2. Serializer는 메시지를 받아 메시지의 schema를 Schema Registry에 보낸다.
3. 이어서 schema ID를 받고, schema ID와 데이터를 Kafka에게 보낸다.

🐶 Connect와 Connector를 이용할 때는 Serializer를 구현할 필요 없이 Connect를 띄울 때 환경변수로 적어주면 된다.

 

앞에서 이야기했던 schema 중복 문제는 Schema Registry에 key와 value에 명시된 schema를 따로 저장하기 때문에 Connector가 schema 대신 Schema Registry의 schema ID를 명시하여 해결할 수 있게된다. 또 Schema ID를 쓰면 메시지의 크기가 줄어들어 불필요한 데이터 용량도 줄일 수 있다.

 

그리고 "내부적인 결합도 문제"는 Schema Registry에서 제공하는 기능 중 하나인 "schema 호환성 규칙 강제" 기능으로 해결할 수 있다.

 

Schema 호환성 규칙 강제

• schema를 등록하여 사용할 수 있지만, schema 버전 간의 호환성을 강제함으로써 일종의 규칙을 세우는 것.

예시(출처: https://always-kimkim.tistory.com/entry/kafka101-schema-registry)

1. Consumer는 version 1로 메시지 처리
2. Gender라는 column이 version 2에서 추가되었고, Consumer는 version 2의 schema를 메시지를 구독하여 처리
3. Consumer는 새로 추가된 column을 제외하고, 기존 version 1에 맞춰 메시지 처리

 

이렇게 호환성 규칙을 강제하여 schema가 다른 메시지도 읽을 수 있도록 만든다.