카프카가 데이터베이스 꿈을 꾸었는지(전편)

이 항목은 Distributed computing Advent Calendar 2021의 12/1개 항목입니다.
개시하다
아파치 카프카는 정보 브로커이자 저장 역할을 하는 등 이전 MQ의 세계관과는 조금 다른 기능성을 지녔다.또 데이터 그룹 토픽의 구성과 카프카를 사용하는 고객 설정에 따라 완전히 다른 워크로드를 같은 클러스터에서 처리할 수 있다.
Kafka 창세기에 마이크로 서비스 간의 비동기적인 교류, Data Lake에 데이터 투입, IoT, 서버/응용 로그처럼 대량의 데이터를 처리하는 용도에 광범위하게 응용되었다.이후 Kafka Connect와 Kafka Streams의 등장으로 데이터 원본/숙박과의 관련 및 흐름 처리, Exactly Once Semantics 방법이 주목을 받아 사용자 사례가 Kafka의 흐름 처리로 확대되었다.
여기서 카프카를 최초 사상Stream-Talble Duality(스트리밍/테이블 쌍)으로 보는 현실적인 방법과 다시 카프카를'일치성을 유지하고 데이터를 전송하는 데이터 기반'으로 보는 운동이 기업화에서 활발해졌다.정보 브로커부터 데이터 플랫폼까지 카프카에 대한 시장의 시각도 이 시기에 바뀌었다.
이 항목에서는 Kafka의 데이터 모델과 그 처리의 논리적 구성, Stream-Talble Duality와 데이터의 통합성에 대한 생각을 설명한다.
이 프로젝트는 며칠 전(2021/09/24)에 Apache Kafka Meetup Japan#9에 등장한 내용을 모방했다.
참고 자료
Apache Kafka Meetup Japan #9
등단 자료: "카프카 데이터베이스 꿈꿨어?"
Kafka의 데이터 모델 - Staream 및 Log
Kafka에 이벤트를 보낼 때 "관련된 이벤트가 무엇인지"를 지정하는 Topic 보내기.Kafka는 각 Topic 컬렉션 이벤트를 도착하는 순서대로 저장합니다.이 집합은 논리적으로는 Stream으로 간주되고 물리적으로는 Log로 저장됩니다.이 스트림과 로그는 서로 다른 측면에서 같은 것을 포착하는 견해로, 때로는 같은 물건처럼 설명하기도 하고, 때로는 다른 물건으로 다루기도 하며, 관찰의 관점에 따라 사용 방법도 다르다.

이때는 이벤트의 순서가 엄격하게 처리돼 차라리 카프카의 물리적 데이터 보존 방법에 따라 자연스럽게 촘촘해진다.구체적으로 말하면 모든 이벤트의 순서와 데이터 자체는 보편적이다(Immutable). 새로운 이벤트는 항상 부가 형식으로 추가된다.항상 이븐트를 사실(Fact)이라고 생각하고 해석에 따라 달라지지 않기 때문에 로고라고 부르는 것은 보존 방법이다.

이 저장 방법은 데이터의 일치성을 유지하는 중요한 요소로 각 이벤트가 보편적일 뿐만 아니라 이벤트의 순서도 데이터의 일치성을 유지하는 데 필수적인 요소이다.
체스 및 데이터베이스
장기, 장기, 바둑 등 바둑판 게임에서 플레이어의 손이 한 손 한 손 빠지지 않고 순서대로 기록하면 바둑판의 변화를 재현할 수 있다.바둑의 기보에는 수백 년 전 전설의 대국 기보가 남아 있는데, 현재의 기사들은 기보를 통해 시간을 초월해 기국을 재현할 수 있다.

이 사상은 데이터 세계에서도 유효하다.
데이터베이스 응용은 카프카가 등장하기 전부터 있었던 기술이지만 서로 다른 사이트에 설치된 두 데이터베이스의 데이터는 같은 상태를 유지할 수 있다.일반적으로 이러한 데이터베이스는 Primby와 Secondary로 지정되고 데이터 업데이트는 Primary에서만 발생한다.업데이트는 Premiary에 있으며 Secondary에서도 Premiary에서 발생하는 데이터 업데이트를 반영합니다.
이 프로그램은 Priamy의 데이터 Export를 Secondary에 Import하는 것이지, Primary에 대한 조회를 Secondary에 발행하는 것이 아닙니다.전자는 쓰기 상태의 Primary를 완전히 캡처하기 어렵고 후자는 조회를 전송해야 할 뿐만 아니라 조회가 실패할 때 실행하는 것도 고려해야 한다.실제로는 전송 응용 프로그램인 Primary에서 발생한 거래 로그(Oracle의 Redo 로그와 MySQL의 binlog)를 통해 이루어진 것이다.

PostgreSQL Replication and Automatic Failover Tutorial
데이터베이스는 메모리를 통해 모든 처리를 처리하고 결과를 드라이브와 동기화하여 데이터를 효과적으로 지속시킨다.다른 한편, 메모리는 잃어버리기 쉬운 저장소로 고장이 났을 때 이전의 데이터 상태를 잃어버렸다.사무 로그는 데이터와 달리 로그로 데이터의 업데이트 작업을 영구화하고 고장났을 때 로그를 따라 드라이브에 대한 동기화를 누락되지 않은 처리로 복원합니다.
복제는 내부 구조의 응용으로 데이터가 아닌 거래 로그를 이용하여 데이터를 동기화한다.국제 장기에서 한 손 한 손 순서대로 공을 쳐서 바둑판의 상태를 재현하는 것은 이론적으로 같은 것이다.
Kafka 및 데이터
Kafka Connect는 데이터 원본/숙박과 카프카를 연결하는 기술이다.특히 데이터베이스가 소스라면 조회가 아닌 이벤트로 거래 로그를 추출해 카프카에게 순서대로 넘긴다.방법은 데이터베이스의 응용과 같지만 이 로그를 전송하는 기초로서 카프카는 통용되는 모델이기 때문에 데이터베이스 공급업체 특유의 기술과는 무관하다.
구체적으로 다음과 같습니다.
- 데이터 소스/숙박에 서로 다른 데이터베이스의 데이터 복제 지정
- 특정 테이블에만 적용
- 공동 작업 데이터 필터링
- 필요한 열만 추출 및 가공(여러 열에서 새 열 생성, etc.)
복사 과정에서 포함할 수 있습니다.
이런 방법은 데이터 가공에서 중간 데이터의 저장을 따로 저장할 필요가 없고 대류 자체를 처리할 수 있다.(Stream Processing 스트리밍) 대류에 대한 집합 처리(SUM, COUNT, AVG 등), 조건에 따른 그룹화, 특정 시간대(WINDOW)의 데이터 연산 등 더 복잡한 처리도 가능하다.
Stream-Table Duality
Stream에서 Table의 상태를 재현할 수 있고 Table의 업데이트 정보를 Stream화할 수 있습니다.Stream과Table는 같은 데이터의 다른 측면인데 이런 사상은Stream-Tale Duality(흐름/표대성)이다.Stream은 데이터의 업데이트 추이를 기록할 수 있으며, 다른 한편, 특정한 순간의 데이터 상황을 재현하기 위해서는 모든 이벤트를 순서대로 처리해야 한다.Table는 특정한 시간의 데이터 상태를 나타내고 조회를 통해 유연하게 조합된 데이터를 추출할 수 있지만 데이터의 업데이트 추이를 나타낼 수 없다.

스트림, 테이블은 모두 데이터를 표현하는 데 불완전한 것들로 요구하는 과제에 따라 한쪽이 달성하기 어렵거나 효율이 떨어진다.카프카의 생태계에서는 이 두 가지를 활용함으로써 지금까지 어려웠던 과제에 보다 유연한 접근법을 제공한다.스트림에서 테이블로, 테이블에서 스트림으로, 스트림과 테이블의 JOIN과 스트림 사이의 JOIN 등 스트림 테이블 둘리티를 통해 데이터 처리 방법을 깊이있게 할 수 있다.

끝말
이 항목은 Apache Kafka가 데이터에 대한 사상에 대해 심도 있는 설명을 했다.이런 사상은 카프카 탄생 당시 구상으로, 기능 추가와 기술 성숙에 따라 기업에서 활용할 수 있는 영역까지 도달했다.또 카프카에 새로운 역할을 선사하면서 기능 개선과 성장, 그리고 시간이 지날수록 낡은 디자인과 코드를 버리면서 진화를 이어가고 있다.
Distributed computing Advent Calendar 2021다음 흐름 처리에 관하여에서 Cloud Native Kafka의 성장을 소개한다.
덤
"카프카 만져볼래?"이런 느낌의 여러분은 반드시 모든 관리를 위한 Confluent Cloud를 시도해 보세요.인터랙티브 튜토리얼과 한즈안 프레젠테이션 등 많은 자원을 함께 사용할 수 있다.
Confluent Cloud
시용에서 400달러짜리 신용카드를 사용할 수 있고KAFKA101 표준코드는 101달러를 더 추가할 수 있다.
developer.confluent.io 아파치 카프카 101을 필두로 ksqlDB와 카프카 스트림스 등 카프카 생태계에 다양한 기술의 튜토리얼 시리즈를 준비했다.