Debezium은 database에서 발생하는 변경사항을 추적할 수 있는 일종의 Apache Kafka Connect의 source connector입니다. 각각의 connector은 해당 데이터베이스의 CDC(change data capture)와 관련된 기능을 활용해서 변경된 데이터에 대한 정보를 가져옵니다. 성공적으로 commit이 발생한 데이터에 대해서만 변경사항이 전파되기 때문에 실패한 트랜잭션은 고려할 필요가 없다고 합니다. Debezium은 변경사항을 디스크에 저장하기 때문에 데이터의 변경사항을 전달받아야 하는 애플리케이션이 다운되더라도 문제가 없습니다.
Change Data Capture이란 데이터의 변경사항을 식별하고 추적할 수 있는 소프트웨어 디자인 패턴입니다. CDC의 목적은 데이터의 변경이 발생했을 때 부가적인 동작을 취하기 위함입니다.
데이터의 변경사항을 전파하는 또 다른 방법으로는 database의 trigger 기능을 활용할 수 있습니다. 하지만 별도의 외부 시스템과 통신하기 위해서는 구현이 복잡해지고 DBMS 별로 구현 방법이 다릅니다. Debezium은 애플리케이션이 여러 DBMS와 호환이 될 수 있도록 middleware 역할을 할 수 있습니다.
Architecture
Debezium은 Kafka와 Kafka Connect를 활용함으로써 durability, reliability, fault tolerance을 보장합니다. Kafka를 활용하기 때문에 확장성이 있고 복제를 통해 신뢰성을 보장합니다. 애플리케이션은 데이터의 변경사항을 exactly-once 또는 at-least-once 방법 중 선택해서 전달받을 수 있습니다. 높은 신뢰성이 보장될 필요가 없다면 애플리케이션은 별도의 Kafka 없이 직접 Debezium과 연결해서 사용할 수 있습니다. 아래의 그림은 Debezium을 통해 CDC pipeline을 구축하는 형태입니다.
별도의 Debezium 서버를 구축해서 운영하는 방법도 존재합니다.
Common Use Cases
Cache Invalidation
캐시 기능을 구현할 때 가장 주의할 점 중 하나는 캐시에 저장된 데이터에 변경사항이 발생했을 때, 해당 데이터를 무효화시키는 것(invalidate) 일 겁니다. Debezium을 활용해서 특정 데이터에 변경사항이 발생하면 캐시에 저장된 해당 데이터를 무효화시킬 수 있습니다. Application에서 캐시 무효화 로직을 분리할 수 있다는 장점이 있습니다.
Simplifying Monolithic Application
개발을 하다 보면 데이터베이스의 데이터를 수정하고, 캐시를 무효화하고, 카프카에 관련 데이터를 전송하는 등 여러 외부 시스템으로 쓰기 작업을 하나의 트랜잭션으로 묶어서 원자성을 보장해야 하는 경우가 있습니다(dual-write). 이는 하나의 트랜잭션으로 잘 묶이지 않을뿐더러 중간에 데이터 손실이 발생할 수 있기 때문에 운영 비용을 높일 수 있습니다. Debezium을 활용하면 database와 관련된 작업만 하나의 transaction 묶고 Debezium의 CDC 기능을 활용해서 외부 시스템에 변경사항을 전달할 수 있습니다.
Sharing Databases
하나의 데이터베이스를 여러 애플리케이션이 함께 사용하는 경우 A라는 애플리케이션이 특정 데이터의 변경사항이 발생했을 때 별도의 애플리케이션 B는 해당 데이터의 변경사항을 추적하는 게 쉽지 않습니다. Message bus를 활용할 수 있지만 근본적인 dual-write 문제는 해결되지 않습니다. Debezium을 활용하면 여러 애플리케이션에서 특정 데이터의 변경사항을 쉽게 추적할 수 있습니다.
Data Integration
하나의 데이터가 항상 하나의 시스템에만 저장되지는 않을 수 있습니다. 형태가 바뀌거나 저장소의 종류가 바뀔 수 있습니다. 이와 같이 여러 시스템에 특정 데이터를 일관되게 저장하기 위해서 Debezium을 활용할 수 있습니다.
CQRS
Command Query Responsibility Separation은 수정을 위한 데이터 모델과 읽기를 위한 데이터 모델을 별도로 분리하는 설계 방식입니다. 데이터에 수정이 발생하면 읽기를 위한 데이터도 업데이트가 돼야 합니다. Debezium을 통해 수정을 위한 데이터 모델과 읽기를 위한 데이터 모델을 동기화하는 로직의 복잡도를 낮출 수 있습니다.
Debezium 특징
로그기반 CDC를 활용하는 Debezium은 다음과 같은 특성을 지닙니다.
1. 모든 데이터의 변경사항이 추적됩니다.
- Debezium은 데이터베이스의 로그를 읽기 때문에 모든 데이터의 변경사항을 추적할 수 있습니다.
- Debezium이 다운되더라도 데이터베이스의 로그가 사라지지 않기 때문에 안전합니다.
2. Polling 방식을 활용하지 않기 때문에 변경된 데이터의 추적속도가 빠르더라도 CPU의 사용량이 급격히 증가하지 않습니다.
- Polling의 경우 데이터의 변경사항을 더욱 빠르게 확인하기 위해 polling interval을 줄이게 됩니다. Polling interval이 줄면 데이터의 변경사항을 더 빠르게 확인할 수 있지만 그만큼 CPU 사용량이 증가합니다.
- Debezium의 Log based CDC를 통해 CPU 사용량의 증가 없이 데이터의 변경사항을 준 실시간으로 추적할 수 있습니다.
3. 변경사항을 추적하기 위해 데이터 모델에 별도의 필드를 추가하거나 변경을 수행하지 않아도 됩니다.
- Polling의 경우 데이터가 변경됨을 식별하기 위해 LAST_UPDATE_TIMESTAMP와 같이 별도의 필드가 필요합니다. Debezium은 이와 같은 필드 없이도 데이터의 변경을 식별할 수 있습니다.
4. 데이터 삭제도 추적할 수 있습니다.
- Polling의 경우 삭제된 데이터에 대해서는 추적이 불가능합니다.
Debezium 기능 +
Debezium은 데이터의 변경사항을 추적하는 기능 이외에도 다양한 기능을 제공합니다.
- Snapshot: Debezium이 source database와 처음으로 연결됐거나 또는 모든 로그가 존재하지 않을 경우 활용하는 방식입니다.
- Filters: schema, table, column 별로 필터링 여부를 결정할 수 있습니다.
- Masking: 특정 컬럼의 데이터를 masking 할 수 있습니다. 민감한 데이터(예를 들어 개인정보)를 취급할 때 유용한 기능입니다.
- Monitoring: JMX를 통해 connector을 모니터링할 수 있습니다.
- Message transformation: 메시지를 수정할 수 있는 기능입니다.
Message transformation의 세부 기능으로 다음과 같은 기능이 존재합니다.
- Topic routing: 목적 topic name을 기준으로 regular expression을 적용해서 다른 topic으로 메시지를 전달할 수 있습니다.
- Content based routing: event content를 기준으로 rerouting을 수행합니다.
- Message filtering: 불필요한 데이터를 content를 통해 필터링할 수 있습니다.
Supported Databases
Debezium을 사용하기 앞서 현재(2022-11-06) Debezium에서 지원하는 데이터베이스에 대해 살펴보겠습니다.
- MongoDB
- MySQL
- PostgreSQL
- SQL Server
- Oracle
- Db2
- Cassandra(Incubating)
- Vitess(Incubating)
참고로 Incubating 표시된 데이터베이스와 관련된 Debezium connector은 추후 버전에서 backward incompatible 할 수 있음을 의미합니다.
Reference
Debezium 공식 웹사이트: https://debezium.io/
Debezium github: https://github.com/debezium/debezium
'Open Source > Debezium' 카테고리의 다른 글
| [Debezium] Embedded Debezium Spring Boot 연동 (0) | 2022.11.07 |
|---|