Amazon Aurora MySQL Bài 38: Xây dựng Event-Driven Architecture kết hợp Aurora MySQL với Debezium và Kafka

Trong các hệ thống backend hiện đại quy mô lớn, việc các services gọi trực tiếp qua lại bằng HTTP REST API hay gộp chung một cơ sở dữ liệu lớn (Monolith Database) sẽ tạo ra điểm nghẽn cổ chai và làm hệ thống mất đi tính linh hoạt. Mô hình Event-Driven Architecture (Kiến trúc hướng sự kiện) ra đời để giải quyết bài toán này.

Bài viết này sẽ mổ xẻ cách kết hợp Aurora MySQL với Debezium (Change Data Capture - CDC) và Apache Kafka để truyền phát dữ liệu theo thời gian thực chuẩn Enterprise.

1. Vấn đề của cách làm truyền thống (Dual-Write / Polling)

Khi có một sự kiện thay đổi dữ liệu trong Aurora (ví dụ: khách hàng tạo một đơn hàng mới), lập trình viên thường hay làm theo 2 cách truyền thống:

1. Làm trực tiếp trong ứng dụng (Dual-Write): Vừa chạy lệnh INSERT vào Aurora, vừa gọi API gửi message sang Kafka hoặc gọi service khác. Nếu bước gọi Kafka bị lỗi mạng, dữ liệu trong database và hệ thống thông điệp sẽ bị lệch pha (Inconsistent State).

2. Quét định kỳ (Polling): Viết Cronjob liên tục chạy SELECT * FROM orders WHERE status = 'pending' mỗi phút một lần. Cách này làm ngốn tài nguyên database và tạo ra độ trễ lớn.

2. Giải pháp chuẩn Cloud-Native: Change Data Capture (CDC) với Debezium & Kafka

Thay vì bắt ứng dụng phải tự đi "kể" rằng dữ liệu vừa thay đổi, ta để công nghệ CDC đứng ngoài "lắng nghe" trực tiếp những thay đổi ngầm bên dưới của cơ sở dữ liệu và tự động phát tán sự kiện (Events).

• Luồng hoạt động chuẩn:

  1. Ứng dụng backend thực hiện INSERT, UPDATE, hoặc DELETE vào Aurora MySQL.

  2. Aurora MySQL ghi các thay đổi đó vào tệp Binlog (Binary Log).

  3. Debezium (chạy dưới dạng Kafka Connect connector) liên tục đọc tệp Binlog này theo thời gian thực.

  4. Ngay khi phát hiện một dòng mới được ghi, Debezium lập tức đóng gói sự kiện đó thành một thông điệp chuẩn (JSON / Avro) và bắn thẳng lên Apache Kafka Topics tương ứng (ví dụ: topic db-changes.orders).

  5. Các microservices khác (Notification Service, Inventory Service, Analytics Service) chỉ việc subscribe vào Kafka Topic đó để xử lý nghiệp vụ tiếp theo một cách độc lập hoàn toàn.

3. Cấu hình Binlog trong Aurora MySQL cho CDC

Để Debezium hoặc các công cụ CDC có thể đọc được dữ liệu thay đổi từ Aurora MySQL, bạn cần cấu hình các tham số bắt buộc trong Parameter Group của cụm Aurora:

• binlog_format = ROW: Bắt buộc cấu hình dạng Row-based logging để Aurora ghi lại chi tiết từng dòng dữ liệu thay đổi cụ thể thay vì chỉ ghi câu lệnh SQL.

• binlog_row_image = FULL: Đảm bảo Debezium lấy được đầy đủ cả giá trị cũ (before) và giá trị mới (after) của dòng dữ liệu khi có hành động UPDATE.

• server_id: Đảm bảo mỗi instance có một ID định danh duy nhất để phục vụ tiến trình replication log.

4. Lợi ích vượt trội của kiến trúc này

• Decoupling tuyệt đối (Giải phóng phụ thuộc): Ứng dụng Backend ghi dữ liệu vào Aurora cực nhanh và không cần bận tâm hệ thống bên dưới xử lý thông điệp ra sao.

• Đảm bảo không mất mát dữ liệu (At-least-once Delivery): Kafka lưu trữ thông điệp bền vững, nếu một microservice xử lý thông điệp bị lỗi sập giữa chừng, nó có thể đọc lại offset cũ từ Kafka để xử lý tiếp mà không lo mất dữ liệu.

• Real-time Streaming: Mọi thay đổi dữ liệu từ kho hàng, tài khoản, đơn hàng đều được lan truyền sang các hệ thống tìm kiếm (OpenSearch), kho dữ liệu (Data Warehouse) chỉ trong vòng vài mili-giây.

5. Góc nhìn vận hành cho Backend Engineer

• Quản lý Schema Evolution: Khi bạn thay đổi cột trong bảng Aurora MySQL (ví dụ thêm cột phone_number), cấu trúc dữ liệu trên Kafka Topic cũng sẽ thay đổi theo. Hãy sử dụng các định dạng tuần tự hóa dữ liệu như Avro kết hợp Schema Registry để quản lý tính tương thích ngược của schema, tránh làm sập các consumer ở phía microservices.

• Giám sát Kafka Lag: Luôn theo dõi chỉ số Consumer Lag trên Kafka để đảm bảo các worker tiêu thụ sự kiện không bị tụt lại phía sau so với tốc độ ghi dữ liệu cực nhanh của Aurora MySQL Writer.