MySQL CDC 및 디비지움 정리

MySQL CDC with 디비지움

 

마이크로서비스에서 B 서비스에서 A 서비스가 소유한 데이터베이스의 데이터가 필요하다. 

- API 호출로 A서비스로의 데이터 조회가 가능하지만, B서비스는 전체적으로 이러한 조회가 굉장히 빈번하기 때문에 대량의 API 호출을 유발한다.

B 서비스에서는 A 서비스가 소유한 데이터베이스에서 데이터를 가져와야 하지만 A서비스의 데이터베이스가 소유한 데이터를 제외하고 가져와야 한다.

- 하나의 물리적 데이터베이스라면 LEFT 조인을 하면 되는 상황이지만, 불가능하다. 

- 이러한 연산을 API에서 처리하기에는 너무 느리다.

A 서비스가 어느정도의 호출을 감당할 수 있는지 장담할 수 없다.

 

결론을 애기하자면, 마이크로 서비스 아키텍처에서 각자의 도메인이 소유한 데이터외 타 도메인의 데이터도 필요한 상황이 생긴다. 하지만 서비스들 사이의 데이터 조회를 위해 API를 호출하는 방식은 너무 느리고 성능적인 영향이 있는지 없는지 확인해야할 지점이 생기게 된다.

 

전통적인 방식

몇 가지 전통적인 방식 중 가장 많이 사용하는 방식은 데이터 변경이 일어날때마다 이벤트를 발생시켜 주는 것이다.

Message que publish -> subscribe

하지만 이 경우에는 다음과 같은 잠재적인 문제가 존재한다.

• 운영, 버그 등의 이슈로 데이터베이스 데이터를 직접 변경해야 하는 경우 이벤트가 누락될 수 있다. 물론 이벤트를 수동으로 발생시킬 수도 있겠지만, 변경이 일어난 대상을 특정하기 어렵다면 얘기는 달라진다.
• 데이터 변경 행위에 대한 이벤트를 발생시키기 위해 추가적인 코드가 필요하다. 데이터 변경이 단일 애플리케이션이나 서비스에서만 일어난다면 코드를 추가하는 것은 어렵지 않겠지만, 그렇지 않다면 코드 추가는 다소 부담스러워진다. 레거시 시스템들은 대부분 이런 부분에 있어 파악이 어렵거나 코드 추가가 어려운 경우가 많다.
• 애플리케이션 버그 및 이벤트 스토어 장애에 의해 이벤트가 누락될 수 있다.

그외 배치, 리플리케이션 데이터베이스를 사용하는 방법도 있으나 배치는 실시간 처리가 힘들고 서로 다른 서비스가 서로 다른 도메인의 전체 데이터베이스를 참조하는 것은 좋은 디자인이라 할 수 없다. 서비스는 각자 독립적으로 성장할 수 있어야 하고 최대한 느슨한 결합을 가지는 것이 좋다.

 

CDC(Change Data Capture)

CDC는 변경 데이터 포착을 뜻한다. 주로 데이터베이스 같은 스토어의 데이터 변경을 포착하여 ETL, 감사(audit), 캐싱과 같은 다양한 후속 처리를 하는데 사용된다.

 

디비지움은 CDC를 수행하기 위한 오픈소스 분산 플랫폼이다.

CDC는 마이크로 서비스 아키텍처에서 중요한 역할을 수행할 수 있다. 서비스 사이에서 데이터를 교환하고 다른 서비스가 소유한 데이터의 로컬 뷰를 유지하면 동기식 API 호출에 의존하지 않고도 독립성이 높아진다.

 

디비지움을 사용하는 일반적인 아키텍처 구성은 다음과 같다.

 

데이터베이스의 변경을 포착해 kakfa에 이벤트를 푸시하고 특정 이벤트에 관심을 가지는 서비스들이 소비하는 구조

 

특징 및 제약조건

• 스키마 변경, INSERT, UPDATE, DELETE 모두 변경 포착 가능
• MySQL Replication Slave처럼 동작
• MYSQL 관련

 

구성적 강점

• 이벤트 발생을 위한 추가 코드가 애플리케이션 서비스에 필요하지 않음. (능동적 데이터 포착 가능)
• 리플리케이션 로그 포지션을 잃어버리지 않는 한 이벤트 누락이 발생하는 일은 없음.
• 다른 서비스에 대한 데이터베이스 의존성을 완화할 수 있음

작성자료:

https://m0rph2us.github.io/mysql/cdc/debezium/2020/05/23/mysql-cdc-with-debezium-1.html