Blue-green deployment cho website nhỏ: có đáng dùng không?

Blue-green deployment là cách duy trì hai môi trường ứng dụng gần như giống nhau: một môi trường đang phục vụ traffic và một môi trường nhận release mới. Khi môi trường mới đã pass kiểm tra, traffic được chuyển từ blue sang green; nếu có lỗi, chuyển ngược lại. Với website nhỏ, mô hình này có thể giảm downtime nhưng không phải lúc nào cũng đáng với chi phí chạy song song và độ phức tạp của database, session, upload và DNS.

Bài viết tập trung vào câu hỏi thực tế: website nhỏ có nên dùng blue-green không, triển khai ở mức nào là vừa đủ và khi nào một release directory cùng symlink current đã đáp ứng tốt hơn. Các ví dụ ưu tiên VPS, reverse proxy và ứng dụng PHP/Node.js thay vì giả định hạ tầng cloud lớn.

1. Blue-green deployment là gì?

Trong mô hình blue-green, blue là phiên bản đang nhận traffic còn green là phiên bản mới được chuẩn bị song song. Bộ cân bằng tải, reverse proxy hoặc DNS quyết định traffic đi vào môi trường nào. Chuyển đổi có thể là đổi upstream, đổi target service, cập nhật load balancer hoặc thay symlink tùy kiến trúc.

Blue-green giảm thời gian chuyển đổi traffic, nhưng không tự động giải quyết migration database, session và dữ liệu ghi đồng thời.Tóm lược dựa trên AWS Prescriptive Guidance — Blue/Green deployments.

2. Khi website nhỏ nên cân nhắc blue-green?

Blue-green đáng cân nhắc khi downtime có tác động kinh doanh rõ, release thường xuyên, ứng dụng có thể chạy hai phiên bản cùng lúc và đội ngũ có khả năng kiểm tra môi trường mới trước khi chuyển traffic. Website thương mại điện tử nhỏ, API có SLA hoặc blog có quy trình publish nghiêm ngặt có thể hưởng lợi, nhưng cần đo chi phí thay vì mặc định áp dụng.

• Release có thể chuẩn bị độc lập mà không chạm vào phiên bản đang phục vụ.
• Có endpoint health và smoke test có thể chạy trước khi nhận traffic.
• Có cách chuyển traffic nhanh và quan sát lỗi sau chuyển đổi.
• Database schema và API contract tương thích trong thời gian hai phiên bản cùng tồn tại.
• Chi phí chạy môi trường thứ hai chấp nhận được.

Nếu website chỉ deploy một lần mỗi tháng, downtime vài giây đã được bảo vệ bằng maintenance page, hoặc server chỉ có ít RAM, release directory có health check thường hợp lý hơn. Không nên chạy blue-green chỉ vì thuật ngữ nghe “production-grade”.

3. Các mức triển khai từ đơn giản đến đầy đủ

Có thể triển khai theo bốn mức. Mức một là hai thư mục release trên cùng VPS và symlink current. Mức hai là hai process hoặc hai container với port khác nhau, reverse proxy chuyển upstream. Mức ba là hai VM/instance độc lập với load balancer. Mức bốn thêm weighted traffic, canary và tự động rollback. Chọn mức thấp nhất đáp ứng mục tiêu availability.

# Hai container trên cùng host
services:
  app_blue:
    image: registry.example.com/app:blue
    ports: ["127.0.0.1:8101:8080"]
  app_green:
    image: registry.example.com/app:green
    ports: ["127.0.0.1:8102:8080"]

# Nginx chỉ trỏ traffic vào một upstream tại một thời điểm
upstream app_current {
    server 127.0.0.1:8101;
}

Mức hai phù hợp với VPS nếu application stateless hoặc session được lưu ngoài process. Tuy nhiên, hai container không thể cùng bind một port public; reverse proxy là lớp chuyển traffic. Khi đổi upstream, cần reload Nginx có kiểm tra syntax và theo dõi connection đang mở.

4. Chuyển traffic và kiểm tra health

Health check nên kiểm tra đúng khả năng phục vụ, không chỉ kiểm tra process còn sống. Một endpoint có thể xác nhận app khởi động, kết nối dependency cần thiết và trả response trong thời gian giới hạn. Deep health check gọi database hoặc service ngoài có thể làm monitoring phụ thuộc dây chuyền; nên tách liveness và readiness để biết nguyên nhân.

# Kiểm tra syntax trước khi reload
sudo nginx -t
sudo systemctl reload nginx

# Smoke test private port trước khi chuyển traffic
curl --fail --silent --show-error --max-time 5   http://127.0.0.1:8102/health
curl --fail --silent --show-error --max-time 10   -H 'Host: example.com' https://example.com/health

Sau khi chuyển traffic, theo dõi tỷ lệ 5xx, latency, log ứng dụng, log reverse proxy và các chỉ số business quan trọng. Đừng rollback chỉ vì một request lỗi ngẫu nhiên; nhưng cũng đừng đợi nhiều giờ khi error rate tăng rõ. Cần đặt ngưỡng và cửa sổ quan sát trước release.

5. Database migration là giới hạn lớn nhất

Blue-green không làm database thành hai phiên bản độc lập. Blue và green thường cùng đọc/ghi một database, vì vậy schema mới phải tương thích với code cũ trong giai đoạn chuyển đổi. Chiến lược expand-and-contract thêm cột hoặc bảng trước, deploy code đọc được cả cũ và mới, backfill dữ liệu, rồi mới xóa phần cũ ở release sau.

Nếu migration không thể backward-compatible, blue-green chỉ che giấu rủi ro trong vài phút đầu. Hãy backup, test migration trên bản sao và coi việc rollback schema là một dự án riêng.

6. Session, upload và queue

Ứng dụng stateful có thể làm blue-green khó hơn. Session lưu trong memory của blue sẽ không có ở green khi traffic chuyển; hãy lưu session trong Redis hoặc database dùng chung và kiểm tra compatibility. Upload ghi vào local disk của một instance sẽ biến mất khi request kế tiếp đến instance khác; dùng object storage hoặc shared volume có backup.

Queue worker cũng cần versioning. Job được tạo bởi code cũ có thể được worker code mới đọc và ngược lại. Khi thay đổi payload, giữ compatibility trong một khoảng thời gian. Nếu dùng cron, tránh để blue và green cùng chạy một job định kỳ gây duplicate; cần distributed lock hoặc chỉ bật scheduler trên môi trường active.

7. DNS switch hay reverse proxy switch?

Đổi DNS đơn giản nhưng phụ thuộc TTL và cache resolver; không phải client nào chuyển ngay. Reverse proxy hoặc load balancer switch có kiểm soát hơn vì traffic đi qua một điểm routing, nhưng cần thiết kế proxy và health check. Trên VPS nhỏ, Nginx upstream switch thường dễ kiểm soát hơn DNS, miễn là đã test reload và giữ cấu hình phiên bản trước.

# upstream green sau khi green pass smoke test
upstream app_current {
    server 127.0.0.1:8102;
}

# kiểm tra rồi mới reload
sudo nginx -t && sudo systemctl reload nginx

8. Rollback và cửa sổ quan sát

Rollback nên là thao tác đã thử trong staging, không phải một câu lệnh được viết lần đầu khi production lỗi. Ghi lại active color, release digest, thời điểm switch và release trước. Sau switch, đặt cửa sổ quan sát đủ dài để bắt lỗi background job, cache warm-up và traffic thực tế. Nếu lỗi chỉ nằm ở một endpoint, cân nhắc fix forward; nếu error rate và latency vượt ngưỡng, switch về môi trường cũ.

1. Giữ green cũ hoặc blue cũ còn sẵn sàng trong thời gian quan sát.
2. Xác nhận database schema vẫn chạy với code cũ trước khi switch ngược.
3. Ghi lại routing state và release digest trước thao tác rollback.
4. Chạy health check sau rollback, không chỉ nhìn HTTP 200 của proxy.
5. Mở incident note để tìm nguyên nhân thay vì xóa release lỗi ngay.

9. Blue-green có thể làm tăng chi phí và độ phức tạp

Website nhỏ thường bị giới hạn bởi RAM, database connection và chi phí storage trước khi cần mô hình hai môi trường đầy đủ. Chạy hai container có thể nhân đôi memory; chạy hai VM có thể nhân đôi chi phí. Ngoài ra, monitoring, log, secret, certificate, cache và backup đều cần biết cả blue lẫn green.

Một lựa chọn nhẹ hơn là build artifact bất biến, release directory, health check và symlink current. Bài Bash backup server giúp chuẩn bị dữ liệu phục hồi; bài GitHub Actions deploy qua SSH trình bày release và rollback trên VPS nhỏ.

10. Checklist quyết định có nên dùng blue-green

1. Định lượng downtime hiện tại và tác động nếu release lỗi.
2. Xác nhận server có đủ CPU/RAM/storage cho hai môi trường.
3. Thiết kế readiness/liveness và smoke test có thể tự động.
4. Kiểm tra session, upload, cache, queue và cron khi chạy song song.
5. Thiết kế migration backward-compatible và backup database.
6. Chọn routing switch phù hợp: symlink, reverse proxy, load balancer hoặc DNS.
7. Chuẩn bị rollback đã kiểm thử và cửa sổ quan sát sau switch.
8. Ghi nhận release digest, log và người phê duyệt.

11. Kết luận

Blue-green deployment đáng dùng khi website có yêu cầu downtime thấp, release thường xuyên và đội vận hành kiểm soát được hai môi trường. Với nhiều website nhỏ, một quy trình release bất biến có health check và rollback rõ ràng đã mang lại phần lớn lợi ích với chi phí thấp hơn. Hãy chọn theo failure mode và ngân sách thật, không chọn theo tên gọi.

Tài liệu tham khảo

1. AWS — Blue/Green Deployments introduction.
2. Google Cloud — Application deployment and testing strategies.
3. AWS Prescriptive Guidance — Blue/Green deployments.