MSA 환경에서 필요한 CDC 개념 이해, Kafka Connector와 Debezium으로 데이터 동기화 구조 살펴보기

안녕하세요. J4J입니다.

 

이번 포스팅은 msa 환경에서 필요한 cdc 개념 이해와 kafka connector, debezium에 대해 이해하는 시간을 가져보려고 합니다.

 

 

 

CDC 소개

 

cdc라고 하는 것은 change data capture의 약자로, 데이터베이스의 변경 사항 (생성, 수정, 삭제 등) 들을 감지하고 변경된 사항들을 외부 시스템 및 애플리케이션에서 실시간으로 사용할 수 있도록 도와주는 기술입니다.

 

cdc의 동작에 대해서 가볍게 표현해 보면 다음과 같습니다.

 

CDC 동작 흐름

 

 

 

mysql, postgresql 등 데이터를 보관하고 있는 데이터베이스에서 변경 사항들이 발생되었을 때 kafka topic과 같은 곳에 실시간으로 데이터가 전송되고, 데이터 정보가 필요한 곳에서 topic에 담겨 있는 메시지 정보를 소비하는 구조라고 얘기할 수 있습니다.

 

이를 통해 각 도메인과 프로젝트에서 관리하는 데이터가 아니지만 데이터 동기화가 이루어진 상태의 데이터 사용을 보장하도록 도와줍니다.

 

 

 

cdc를 사용하는 경우로는 다음과 같은 예시들을 얘기해볼 수 있습니다.

 

• msa 환경에서 서로 다른 서비스에서 사용하고 있는 데이터의 변경 사항 동기화가 필요한 경우
• 사용되는 데이터를 동기화가 필요하지만 운영을 위해 사용되는 db와 별도로 데이터 관리를 하고 싶은 경우
• ETL 기반 배치 작업을 통해 데이터 전달하지 않고, 실시간으로 데이터를 전달받아야 하는 경우
• db에 변경된 데이터 정보를 캐싱되어 있는 데이터와 동기화 하고 싶은 경우
• es 등 검색을 위해 사용되는 정보에 변경된 데이터가 동기화가 필요한 경우

 

이 외에도 각자의 개발 프로젝트에서 데이터베이스에 변경된 데이터들이 실시간으로 사용되어야 하는 곳이 있다면 언제든 cdc를 활용해볼 수 있습니다.

 

개인적으로는 cqrs 기반의 아키텍처를 적용하기 위해 개념 공부를 하다가 cdc에 대해 처음 숙지하게 되었고 cdc를 활용하여 cqrs 아키텍처 구조를 잡는 데 사용하려고 합니다.

 

 

반응형

 

 

그래서 msa 환경에서 cdc가 필요한 이유는 무엇일까요 ?

 

cdc가 무엇인지에 대해 가볍게 이해를 했다면, msa 환경에서 마이크로 서비스 간 필요한 데이터들에 대해서 어떻게 공유해야 되는지에 대해 고민을 하고 있었다면 이미 필요성에 대해서 많이 깨달았을 수 있습니다.

 

msa 환경에서 cdc가 필요한 케이스에 대해서 얘기를 해보자면 다음과 같은 상황이 있을 수 있습니다.

 

사용자 정보 조회 cdc 케이스

---

배송지 조회 cdc 케이스

 

 

 

위의 케이스는 제가 겪어 봤던 상황을 기반으로 임의로 발생할 수 있는 케이스를 적어봤습니다.

 

먼저, msa 기반으로 아키텍처를 구성했다면 사용자 정보의 경우 인사 정보를 관리하는 별도의 마이크로 서비스가 존재할 가능성이 높습니다.

 

그리고 인사 정보를 제공하는 서비스를 통해 각 도메인 비즈니스에서 사용자 정보를 활용하고 있을 겁니다.

 

그러면 고민될 수 있는 상황이 "사용자의 정보는 항상 변화될 수 있는데 어떻게 각각의 도메인에서 사용자 정보를 동기화할 수 있을까?" 입니다.

 

이 고민에 대한 해결책으로 cdc가 선택될 수 있습니다.

 

사용자 정보를 관리하고 있는 테이블의 데이터 변경 사항을 감지하고 변경 정보를 외부에서 확인할 수 있도록 공유한다면 각 도메인 비즈니스에서는 자유롭게 데이터를 가져와 사용할 수 있고 동기화를 하는데 문제가 없게 됩니다.

 

 

 

두 번째 경우도 주문과 배송에 대한 서비스를 별도로 구분하여 개발하고 있다면 겪어 볼 수 있는 상황입니다.

 

주문 서비스 쪽에서는 사용자의 요청에 의해 배송지 정보를 변경했지만, 변경된 배송지 정보에 배송 처리하는 배송 서비스에서는 동기화되지 않은 상황입니다.

 

그러면 구매자 입장에서는 배송지 정보가 정상적으로 변경되었지만 배송되는 위치는 변경 전의 배송지 정보로 전달될 수가 있습니다.

 

이런 상황에 대한 고민도 cdc가 해결책이 될 수 있습니다.

 

주문 서비스 쪽에서 발생된 데이터를 배송 서비스 쪽에서 확인할 수 있도록 변경 사항을 공유한다면 데이터를 실시간으로 동기화하여 정상적으로 배송이 될 수 있도록 도와줍니다.

 

 

 

이 외에도 msa 환경에서 cdc를 사용하게 되는 경우 서비스 간의 의존성을 최소한으로 가질 수 있도록 도와줄 수 있습니다.

 

예를 들어, 구매자가 물품을 구매한 뒤 배송 처리를 위한 비즈니스 처리와 구매자에게 알림 제공을 위한 비즈니스 처리가 필요할 수 있습니다.

 

물품 구매 이후 비즈니스 발생 케이스

 

 

 

이 상황에서 구매 / 배송 / 알림 처리를 위한 비즈니스가 별도의 마이크로 서비스 단위로 구성되어 있다고 가정하겠습니다.

 

그러면 일반적으로 생각해 볼 수 있는 것은 구매 처리를 수행하는 서비스에서 사용자가 물품 구매를 하는 경우 "배송 서비스의 배송 설정 api"와 "알림 서비스의 알림 전송 api"를 호출하는 것입니다.

 

하지만 만약 cdc를 이용한다면 구매 서비스에서는 단순히 데이터베이스에 구매자가 물품을 구매할 때 처리했던 데이터만 적재해두기만 할 수 있습니다.

 

왜냐하면 변경 사항을 kafka topic 같은 곳에 전달을 하고 배송 서비스와 알림 서비스에서는 필요한 topic 정보에 담겨있는 메시지만 소비하면 되기 때문입니다.

 

즉, 구매 / 배송 / 알림 서비스는 기존 방식처럼 api를 호출해야 한다면 각 서비스의 api 명세를 모두 확인하며 네트워크 상태에 따라 올바르게 처리가 되지 않을 수 있습니다.

 

하지만 cdc를 사용하는 경우에 변경이 발생된 데이터만 공유한다면 메시지를 소비하는 쪽에서는 데이터가 출처가 어디인지도 모르는 상태에서 메시지만 올바르게 전달받을 수 있다면 비즈니스 처리를 수행할 수 있게 됩니다.

 

그러므로 서비스 간 직접적인 호출이 없는 느슨한 결합이 가능하게 되며 안정적으로 확장할 수 있는 구조를 만들 수 있습니다.

 

다른 말로는 이벤트 주도 아키텍처를 구축할 수 있는 것입니다.

 

 

 

 

Kafka Connector 소개

 

데이터베이스의 변경 사항들을 외부 시스템 및 애플리케이션에 전달할 수 있는 방법들은 여러 가지가 존재하겠지만 대표적으로 많이 사용되는 것이 kafka를 이용한 방식입니다.

 

그리고 kafka topic에 데이터베이스의 변경 사항을 전달하도록 도와주는 것이 kafka connector가 됩니다.

 

 

 

하지만 kafka connector를 알기 위해서는 kafka connect에 대해서 먼저 알고 있어야 합니다.

 

kafka connect는 kafka와 데이터 시스템들 간 안정적이고 확장성 있게 데이터 스트리밍을 할 수 있도록 도와주는 도구입니다.

 

그래서 우리가 알고 있는 많은 데이터베이스들과 key-value 저장소, 검색 인덱스, 파일 시스템들 사이에서 중앙 집중화 된 데이터 통합 허브를 제공합니다.

 

kafka connect를 사용하게 된다면 짧은 시간 안에 모든 데이터베이스에 있는 데이터를 수집하여 kafka에 전달할 수 있는 것이고, kafka connect가 구성되어 있어야 필요한 kafka connector를 연결하여 cdc 처리를 수행할 수 있게 되는 것입니다.

 

kafka connect에 대해 더 자세하게 알고 싶으신 분들은 kafka connect confluent 문서를 참고해 주시면 됩니다.

Kafka Connect | Confluent Documentation

 

 

 

 

kafka connect에 대해 알게 되었다면 kafka connector에 대해서 더 자세하게 알아보겠습니다.

 

kafka connect가 kafka와 데이터 시스템들 간 스트리밍을 전체적으로 수행해 주는데 kafka connector는 어떤 역할을 수행하는 것인지 의문을 가질 수 있습니다.

 

kafka connector는 단순하게 kafka connect에 어떤 데이터를 어떻게 연결할지에 대한 스트리밍 처리를 위한 플러그인이라고 이해할 수 있습니다.

 

예를 들어 mysql의 특정 데이터베이스에서 발생된 변경 사항들을 kafka에 전달하고 싶을 때 다음과 같이 구분할 수 있습니다.

 

• kafka connect는 어떤 식으로 kafka와 데이터 시스템이 소통할지에 대해서 설정이 이루어짐
• kafka connector에는 어떤 데이터 시스템(=mysql) 및 어떤 데이터베이스와 소통할지에 대해 정의합니다.

 

즉, kafka connector는 결국 사용하려는 목적에 맞게 mysql connector, postgrelsql connector 또는 서비스 별 목적에 맞는 connector 등 다양하게 파생될 수 있습니다.

 

 

 

kafka connector는 크게 2가지로 나눌 수 있습니다.

 

첫 번째는 source connector입니다.

 

source connector의 역할은 데이터베이스에 있는 모든 데이터들을 수집하고 수집된 데이터들을 kafka topic에 업데이트를 하도록 도와줍니다.

 

그러므로 만약 데이터베이스의 변경 사항들을 kafka topic에 전달하여 외부 시스템 및 애플리케이션에서 사용할 수 있도록 하고 싶다면 source connector를 사용하시면 됩니다.

 

source connector 데이터 처리 방식

 

 

 

두 번째는 sink connector입니다.

 

sink connector는 source connector와 반대의 역할을 수행합니다.

 

kafka topic에 전달된 메시지 정보가 존재한다면 메시지를 소비하며 데이터베이스에 전달합니다.

 

전달된 메시지는 설정된 정보에 맞게 데이터베이스에 자동으로 반영됩니다.

 

그러므로 topic에만 필요한 메세지 정보가 올바르게 전달된다면 부가적인 소스 코드 작성 없이 데이터베이스에서 데이터를 확인할 수 있게 되는 것입니다.

 

sink connector 데이터 처리 방식

 

 

 

 

Debezium 소개

 

debezium은 cdc 처리를 위한 오픈 소스 분산 플랫폼이며 source connector의 역할을 수행할 수 있도록 도와줍니다.

 

source connector의 역할을 수행할 수 있는 것들은 debezium 말고도 aws에서 제공하는 dms부터 여러 상용 솔루션까지 다양하게 존재합니다.

 

물론, 대규모 처리를 하는 곳이거나 GUI 기반의 모니터링 툴 제공 및 여러 가지 편의성과 SLA 등 여러 가지 관점에서 그에 맞는 돈을 지불하는 것에 무리가 없고 source connector 처리가 메인 처리에 해당되는 곳이라면 상용 솔루션을 구매하는 것이 바람직합니다.

 

 

 

하지만 source connector를 구성하기 위해 debezium을 선택하는 것은 일반적인 경우에 해당될 것입니다.

 

작은 단위의 팀이나 스타트 업에서도 source connector가 필요한 경우는 분명히 발생하게 될 것이고 이런 곳에서 상용 솔루션을 사용하는 것은 토끼를 잡기 위해 대포를 사용하는 것과 동일할 수 있습니다.

 

또한 상용 솔루션 만큼은 아니지만 debezium을 사용하더라도 적절한 운영 환경을 적용할 수 있다면 대용량의 데이터를 처리하는 곳에서도 문제없이 사용할 수도 있다고 합니다.

 

그리고 다양한 데이터베이스를 지원하고 있으며 커뮤니티가 활발하여 source connector 들 중 가장 많은 레퍼런스를 확인할 수도 있습니다.

 

 

 

그래서 특별한 케이스가 아니라면 대부분의 source connector는 debezium을 이용한 환경이 설정될 확률이 높을 수 있습니다.

 

만약, kafka connector를 가볍게 사용하는 곳이라면 직접 운영 관리를 해야 하는 번거로움이 있을 수 있지만 debezium을 이용하여 connector를 구성해 보는 것은 좋은 선택지가 될 수 있습니다.

 

더 자세한 내용을 확인하고 싶다면 Debezium 공식 문서를 확인해 주시길 바랍니다.

Debezium Documentation :: Debezium Documentation

 

 

 

 

마지막으로 한 가지 더 얘기해 볼 사항은 debezium이 원래는 source connector만 지원했지만 최근에 sink connector에 대해서도 지원이 가능해졌다는 사항을 확인할 수 있습니다.

 

공식 문서를 확인해보지 않았다면 저도 몰랐던 것처럼 debezium에 대해 얘기할 때 sink connector에 대해서는 완전히 배제되어 있었습니다.

 

공식 문서 기준으로는 2.7 버전 이후부터 sink connector에 대한 문서 정보를 확인할 수 있고 해당 문서는 24년도 12월에 업로드된 것으로 확인됩니다.

 

아무래도 나온 지 얼마 안 된 것들이기 때문에 많은 곳에서 검증이 진행되고 있을 것으로 생각하며 아직까지 기존에 사용되던 sink connector들이 많이 활용되는 것 같아 보이지만 먼 미래에는 sink connector 또한 debezium을 이용한 생태계가 구축될 수도 있지 않을까 생각됩니다.

 

혹시나 debezium의 sink connector에 대해 궁금하신 분들은 Debezium 공식 문서 Sink Connector를 확인해 주시면 됩니다.

Sink Connectors :: Debezium Documentation

 

 

 

 

 

 

 

이상으로 msa 환경에서 필요한 cdc 개념 이해와 kafka connector, debezium에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.