1. Giới Thiệu
Trong việc phát hành hệ thống, việc giảm thiểu thời gian gián đoạn - lý tưởng là đưa nó xuống mức không - luôn là một thách thức không bao giờ ngừng. Khi người dùng trải nghiệm thời gian gián đoạn, điều này sẽ trực tiếp ảnh hưởng đến doanh thu và niềm tin.
Một phương pháp để giải quyết vấn đề này là Triển Khai Blue-Green (Blue-Green Deployment).
Trong bài viết này, chúng ta sẽ tìm hiểu những điều cơ bản về Triển Khai Blue-Green và phân tích sự khác biệt giữa việc áp dụng nó cho ứng dụng và cơ sở dữ liệu. Sau đó, chúng ta sẽ xem xét Triển Khai Blue/Green trên AWS RDS, giải thích chi tiết cách hoạt động, bao gồm vai trò của binlogs (nhật ký nhị phân) và các yếu tố chi phí.
2. Triển Khai Blue-Green Là Gì?
Triển Khai Blue-Green là một chiến lược phát hành chạy hai môi trường sản xuất song song và chuyển đổi lưu lượng giữa chúng để thay thế phiên bản cũ bằng phiên bản mới. Môi trường hiện tại được gọi là “Blue,” trong khi phiên bản mới được gọi là “Green.”
Bạn triển khai ứng dụng của mình vào môi trường Green và kiểm tra nó trong điều kiện giống như sản xuất. Nếu không phát hiện vấn đề gì, bạn sẽ chuyển lưu lượng từ Blue sang Green. Nếu có vấn đề xảy ra, bạn có thể đơn giản quay lại Blue, cho phép phát hành an toàn mà không ảnh hưởng đến người dùng.
Chiến lược này có một số lợi ích lớn:
- Không có thời gian gián đoạn trong quá trình phát hành
- Khôi phục ngay lập tức trong trường hợp có vấn đề
- Khả năng kiểm tra trong môi trường tương đương sản xuất
Tuy nhiên, vì hai môi trường phải được duy trì, chi phí sẽ tăng lên. Hơn nữa, đối với các hệ thống có trạng thái như cơ sở dữ liệu, việc giữ cho cả hai môi trường hoàn toàn đồng bộ là một thách thức lớn.
3. Triển Khai Trong Ứng Dụng
Tại lớp ứng dụng, Triển Khai Blue-Green tương đối đơn giản để thực hiện.
Trên AWS, một phương pháp phổ biến là chuyển đổi nhóm mục tiêu trên một ALB (Application Load Balancer), hoặc cập nhật bản ghi DNS bằng cách sử dụng Route 53. Trong Kubernetes, việc chuyển đổi nhãn dịch vụ hoặc cập nhật tài nguyên Ingress đạt được hiệu ứng tương tự.
Hơn nữa, việc kết hợp với các công cụ CI/CD cho phép tự động hóa toàn bộ quy trình: triển khai vào Green, kiểm tra và chuyển đổi lưu lượng. Với GitHub Actions hoặc AWS CodePipeline, quy trình phát hành có thể được tối ưu hóa trong khi giảm thiểu rủi ro.
4. Thách Thức Trong Cơ Sở Dữ Liệu
Mọi thứ trở nên phức tạp hơn với cơ sở dữ liệu. Cơ sở dữ liệu là một hệ thống có trạng thái, vì vậy việc chỉ sao chép môi trường là không đủ - cần phải duy trì sự đồng bộ hóa. Ví dụ, nếu một người dùng đăng ký trong môi trường Blue, thay đổi đó cũng phải được phản ánh trong Green. Nếu không, việc chuyển lưu lượng sẽ có nguy cơ mất dữ liệu.
Truyền thống, các phương pháp sau đã được sử dụng:
- Sao chép nhật ký nhị phân thủ công: linh hoạt, nhưng phức tạp để vận hành
- RDS Read Replicas: đơn giản, nhưng có giới hạn
- AWS DMS: hỗ trợ di chuyển cơ sở dữ liệu không đồng nhất, nhưng phức tạp để thiết lập
Tất cả những phương pháp này đều có hạn chế, đặc biệt là khi nhắm đến thời gian gián đoạn thực sự bằng không.
5. Cách Hoạt Động Của RDS Blue/Green Deployment
Triển Khai Blue/Green trên AWS RDS là một dịch vụ quản lý được thiết kế để giải quyết những thách thức này. Nó tự động tạo một bản sao Green của môi trường Blue và duy trì sự đồng bộ hóa thông qua sao chép logic sử dụng nhật ký nhị phân (binlogs).
Binlog Là Gì?
Một binlog là một nhật ký các thao tác thay đổi dữ liệu được duy trì bởi các cơ sở dữ liệu dựa trên MySQL. Nó ghi lại các thao tác như INSERT, UPDATE và DELETE. Các bản sao đọc những nhật ký này và áp dụng các thay đổi tương tự vào cơ sở dữ liệu của chúng, đảm bảo rằng cơ sở dữ liệu chính và các bản sao vẫn giữ được tính nhất quán.
Tại Sao Cần Định Dạng ROW?
Các binlog có thể được ghi trong ba định dạng:
- STATEMENT: ghi lại các câu lệnh SQL
- ROW: ghi lại các hàng nào đã thay đổi và cách thức thay đổi
- MIXED: kết hợp cả hai
Triển Khai Blue/Green RDS yêu cầu định dạng ROW. Lý do là nhật ký dựa trên STATEMENT có thể gây ra sự không nhất quán - ví dụ, với các hàm SQL như NOW() hoặc RAND() có thể cho ra kết quả khác nhau trong các môi trường khác nhau. Với định dạng ROW, mỗi thay đổi ở cấp độ hàng được ghi lại một cách rõ ràng, đảm bảo rằng các môi trường Blue và Green vẫn hoàn toàn đồng bộ.
Tại Sao Chi Phí Tăng
Với Triển Khai Blue/Green RDS, một môi trường Green hoàn toàn được tạo ra với cấu hình giống như Blue. Điều này bao gồm các phiên bản, lưu trữ và thiết lập Multi-AZ. Do đó, cho đến khi việc chuyển đổi hoàn tất, chi phí cơ sở dữ liệu của bạn tăng gấp đôi. Bất kỳ kế hoạch phát hành nào cũng phải tính đến sự tăng chi phí tạm thời này.
6. Lợi Ích và Hạn Chế
Cách tiếp cận này cho phép việc chuyển lưu lượng hoàn thành trong vòng 30–60 giây, giảm thiểu đáng kể thời gian gián đoạn. Trong trường hợp có sự cố, việc quay lại Blue là ngay lập tức.
Tuy nhiên, cũng có một số hạn chế:
- Các thay đổi lược đồ hủy hoại (như việc xóa hoặc đổi tên cột) không được hỗ trợ
- Binlogs phải được bật ở định dạng ROW
- Duy trì hai môi trường có nghĩa là chi phí cao hơn
7. Các Tình Huống Sử Dụng
Triển Khai Blue/Green RDS đặc biệt hữu ích trong các trường hợp như:
- Cập nhật phiên bản cơ sở dữ liệu lớn hoặc nhỏ
- Mở rộng lược đồ như thêm cột hoặc tạo chỉ mục
- Kiểm tra trước phát hành trong một môi trường tương đương sản xuất
Mặt khác, nó có thể không phù hợp với các tình huống liên quan đến thay đổi lược đồ hủy hoại hoặc các môi trường có phát hành nhỏ thường xuyên.
8. Kết Luận
Triển Khai Blue-Green là một chiến lược mạnh mẽ để đạt được phát hành không gián đoạn. Mặc dù nó tương đối dễ áp dụng cho các ứng dụng, nhưng cơ sở dữ liệu từ lâu đã đặt ra những thách thức đồng bộ hóa đáng kể.
Với Triển Khai Blue/Green RDS, nhiều thách thức này được giảm thiểu đáng kể. Bằng cách tận dụng binlogs cho việc sao chép đáng tin cậy, Blue và Green có thể giữ được sự đồng bộ, cho phép chuyển đổi an toàn và nhanh chóng. Tuy nhiên, quan trọng là phải hiểu các yêu cầu - binlogs ở định dạng ROW và sự gia tăng chi phí tạm thời - và tích hợp chúng vào thiết kế hệ thống.
