Bài 18 — Blue-Green Deployment

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là kỹ sư trực đêm cho một sàn thương mại điện tử. Đúng 21h tối thứ Sáu — giờ cao điểm — sếp bảo: "Đẩy bản mới lên đi, đối tác cần tính năng thanh toán mới sáng mai." Bạn deploy trực tiếp lên production, và mười phút sau điện thoại reo dồn dập: trang thanh toán trắng xóa, khách hàng không đặt được đơn. Bây giờ bạn phải vừa run rẩy tìm lỗi, vừa gấp gáp rollback, trong khi mỗi phút trôi qua là hàng chục đơn hàng bị mất.

Đây chính xác là kiểu ác mộng mà Blue-Green Deployment sinh ra để loại bỏ. Ý tưởng của nó đơn giản đến bất ngờ: thay vì sửa nhà đang có người ở, bạn xây một căn nhà y hệt bên cạnh, dọn đồ sang, kiểm tra kỹ, rồi mới chuyển người sang. Nếu căn nhà mới có vấn đề, người ở vẫn còn nguyên căn cũ để quay về ngay lập tức.

Trong chuỗi bài về deployment của khóa học này, Bài 17 đã nói về Rolling Update — cập nhật dần từng phần. Bài 19 tới sẽ nói về Canary — thả một phần nhỏ traffic sang bản mới. Còn Bài 18 hôm nay tập trung riêng vào Blue-Green: một mô hình chuyển đổi toàn bộ traffic từ môi trường cũ sang môi trường mới trong tích tắc, và quan trọng nhất là khả năng rollback gần như tức thời. Nắm vững nó, bạn sẽ deploy vào giờ cao điểm mà tay không còn run.

Khái niệm cốt lõi

Hai môi trường song song: Blue và Green

Trọng tâm của Blue-Green là duy trì hai môi trường production giống hệt nhau về hạ tầng, thường được gọi bằng màu để dễ phân biệt:

• Blue (xanh dương): môi trường đang phục vụ traffic thật của người dùng ngay lúc này. Đây là bản "live".
• Green (xanh lá): môi trường nhàn rỗi (idle), nơi bạn triển khai phiên bản mới lên. Người dùng thật chưa hề chạm tới nó.

Lưu ý quan trọng: màu không gắn cố định với phiên bản. Hôm nay Blue là live, sau khi deploy thành công thì Green trở thành live, và Blue lùi về làm môi trường idle cho lần deploy tiếp theo. Chúng luân phiên đổi vai. Vì thế đừng bao giờ nghĩ "Blue là bản cũ, Green là bản mới" một cách cứng nhắc — vai trò đảo liên tục.

Quy trình chuyển đổi (cutover)

Luồng vận hành chuẩn của một lần Blue-Green diễn ra như sau:

• Blue đang phục vụ 100% traffic. Green đang idle (có thể chạy phiên bản cũ hoặc được dựng mới).
• Bạn deploy phiên bản mới lên Green. Vì không ai dùng Green nên bạn thoải mái deploy, khởi động lại, kiểm tra mà không ảnh hưởng người dùng.
• Chạy smoke test và kiểm thử trên Green (gọi thẳng vào Green qua một URL/endpoint nội bộ) để chắc chắn bản mới hoạt động đúng trong môi trường production thật.
• Cutover — chuyển 100% traffic từ Blue sang Green bằng cách đổi cấu hình định tuyến (load balancer, DNS, hoặc service selector). Đây là khoảnh khắc "bật công tắc".
• Green giờ là live. Bạn giữ Blue nguyên trạng thêm một thời gian (vài phút đến vài giờ) như một "lưới an toàn".
• Nếu Green ổn định, Blue trở thành idle cho lần sau. Nếu Green gặp sự cố, bạn switch ngược về Blue ngay lập tức — đó là rollback.

Cơ chế chuyển traffic — trái tim của Blue-Green

Điểm quyết định thành bại nằm ở cách bạn chuyển traffic. Có ba cơ chế phổ biến:

• Load balancer / Reverse proxy: Đây là cách được khuyến nghị nhất. Bạn trỏ load balancer (như AWS ALB, Nginx, HAProxy) vào target group Blue, khi cutover thì đổi sang target group Green. Chuyển đổi diễn ra trong vài giây và hiệu lực gần như tức thì.
• DNS switching: Đổi bản ghi DNS trỏ về IP của Green. Cách này đơn giản nhưng nguy hiểm vì TTL và cache DNS khiến một số người dùng vẫn bị trỏ về Blue trong nhiều phút, thậm chí hàng giờ. Rollback cũng chậm theo. Hạn chế dùng nếu có thể.
• Kubernetes Service selector: Trong K8s, bạn có hai Deployment (blue và green) với label khác nhau, và một Service dùng selector để chọn tập pod nào. Cutover chỉ là đổi selector từ version: blue sang version: green — có hiệu lực gần như tức thì trong cụm.

Điều làm Blue-Green khác biệt

So với Rolling Update (Bài 17), nơi bản cũ và bản mới cùng tồn tại trong một khoảng thời gian, Blue-Green tại mọi thời điểm chỉ có một phiên bản phục vụ người dùng thật. Điều này mang lại ba lợi ích lớn:

• Rollback tức thời: chỉ cần switch ngược, không phải build lại hay deploy lại.
• Không có trạng thái hỗn hợp: bạn không rơi vào cảnh một nửa server chạy v1, một nửa chạy v2 gây khó lường về hành vi.
• Cửa sổ downtime bằng không (zero-downtime) nếu cutover được làm đúng.

Cái giá phải trả: bạn cần gấp đôi hạ tầng trong lúc chuyển đổi, và phải xử lý cẩn thận các trạng thái chia sẻ như database.

Tình huống thực tế

Ví dụ 1 — Sàn TMĐT "ShopViet" và đêm Black Friday

ShopViet là một sàn thương mại điện tử giả định tại TP.HCM, phục vụ khoảng 2 triệu lượt truy cập/ngày, cao điểm gấp 5 lần vào các dịp sale. Trước đây họ deploy kiểu "in-place" — dừng service, cập nhật, khởi động lại — chấp nhận downtime 3-5 phút mỗi lần. Vào một đợt sale 11/11, một bản deploy lỗi khiến trang giỏ hàng sập trong 40 phút vì team loay hoay rollback thủ công. Ước tính họ mất khoảng 800 triệu đồng doanh thu chỉ trong 40 phút đó.

Sau sự cố, team hạ tầng dựng mô hình Blue-Green trên AWS: hai Auto Scaling Group đứng sau một Application Load Balancer, cutover bằng cách đổi target group. Đêm Black Friday năm sau, họ deploy bản mới lên Green lúc 20h, chạy smoke test trong 15 phút, rồi cutover đúng lúc traffic đang cao. Người dùng không hề nhận ra có deploy diễn ra. Khi phát hiện một API tính phí ship trả sai số liệu sau cutover 6 phút, họ switch ngược về Blue chỉ trong 11 giây.

Bài học rút ra: Giá trị thật của Blue-Green không phải ở lúc mọi thứ suôn sẻ, mà ở khoảnh khắc bạn cần rollback. 11 giây so với 40 phút là khác biệt giữa "không ai để ý" và "mất gần một tỷ đồng".

Ví dụ 2 — Fintech "PayGo" và bài học về database

PayGo (giả định), một ví điện tử ở Đông Nam Á, áp dụng Blue-Green cho backend xử lý giao dịch chạy trên Kubernetes. Lần đầu triển khai, họ tự tin cutover sang Green mang bản v2. Vấn đề: v2 đi kèm một migration đổi tên cột user_balance thành wallet_balance trong database — mà database thì dùng chung giữa Blue và Green.

Ngay khi Green nhận traffic, migration chạy và đổi tên cột. Green hoạt động tốt, nhưng khi họ cần rollback vì một lỗi khác, Blue (vẫn dùng tên cột cũ) không thể đọc database nữa vì schema đã đổi. Lưới an toàn của Blue-Green bị vô hiệu hóa hoàn toàn. Họ phải chữa cháy khẩn cấp trong 25 phút.

Sau đó PayGo áp dụng nguyên tắc backward-compatible schema migration (mở rộng chi tiết ở Bài 31): thay đổi database phải tương thích ngược với cả phiên bản cũ. Thay vì đổi tên cột, họ thêm cột mới wallet_balance, ghi vào cả hai cột trong giai đoạn chuyển tiếp, rồi mới dọn cột cũ ở một release sau. Nhờ vậy cả Blue lẫn Green đều đọc được database ở mọi thời điểm.

Bài học rút ra: Blue-Green chỉ bảo vệ tầng ứng dụng (stateless). Với tầng dữ liệu dùng chung, bạn phải tự đảm bảo tính tương thích ngược, nếu không rollback sẽ chỉ là ảo tưởng.

Ví dụ 3 — Startup SaaS nhỏ và bài toán chi phí

Một startup SaaS 8 người tại Hà Nội muốn áp dụng Blue-Green nhưng lo ngại chi phí gấp đôi hạ tầng. Họ chạy 6 server ứng dụng; nếu duy trì Green idle 24/7 thì phải trả tiền cho 12 server.

Giải pháp của họ: chỉ dựng Green ngay trước khi deploy. Nhờ Infrastructure as Code (Terraform), họ scale Green từ 0 lên 6 server chỉ khi cần deploy, giữ trong khoảng 30 phút để cutover và quan sát, rồi hủy Blue cũ sau khi Green ổn định. Chi phí gấp đôi chỉ tồn tại trong đúng nửa tiếng mỗi lần deploy, không phải cả ngày. Chi phí tăng thêm mỗi tháng chỉ khoảng vài trăm nghìn đồng thay vì gấp đôi hóa đơn.

Bài học rút ra: "Gấp đôi hạ tầng" của Blue-Green là gấp đôi tạm thời, không nhất thiết là thường trực. Với đám mây và IaC, bạn trả tiền cho môi trường thứ hai chỉ trong cửa sổ chuyển đổi.

Hướng dẫn từng bước

Dưới đây là quy trình triển khai Blue-Green thực tế trên Kubernetes — môi trường phổ biến nhất hiện nay. Nguyên tắc tương tự áp dụng được cho load balancer truyền thống.

Bước 1 — Chuẩn bị hai Deployment với label phân biệt. Tạo hai Deployment giống hệt nhau ngoại trừ label version:

# blue deployment đang chạy phiên bản hiện tại
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shopviet-blue
spec:
  replicas: 3
  selector:
    matchLabels: { app: shopviet, version: blue }
  template:
    metadata:
      labels: { app: shopviet, version: blue }
    spec:
      containers:
        - name: app
          image: shopviet:v1.4.0

Bước 2 — Service ban đầu trỏ vào Blue. Service dùng selector để chọn tập pod:

apiVersion: v1
kind: Service
metadata:
  name: shopviet-svc
spec:
  selector: { app: shopviet, version: blue }   # đang trỏ Blue
  ports:
    - port: 80
      targetPort: 8080

Bước 3 — Deploy phiên bản mới lên Green. Tạo Deployment shopviet-green với image: shopviet:v1.5.0 và label version: green. Green chạy lên nhưng Service chưa trỏ vào, nên chưa có traffic thật.

Bước 4 — Smoke test trên Green. Tạo một Service phụ (hoặc port-forward) trỏ riêng vào Green để kiểm tra. Gọi các endpoint quan trọng: health check, đăng nhập, một luồng nghiệp vụ cốt lõi. Chỉ đi tiếp khi Green xanh hoàn toàn. Bài 52 sẽ đào sâu về smoke test và continuous verification.

Bước 5 — Cutover. Đổi selector của Service chính từ version: blue sang version: green:

kubectl patch service shopviet-svc \
  -p '{"spec":{"selector":{"app":"shopviet","version":"green"}}}'

Từ giây này, 100% traffic đổ vào Green. Blue vẫn chạy nhưng không nhận traffic.

Bước 6 — Quan sát. Theo dõi dashboard error rate, latency, log trong 10-30 phút. Đây là "bake time" — thời gian nướng để xác nhận Green ổn định (Bài 26 nói kỹ về observability của pipeline).

Bước 7a — Nếu ổn: giữ Green làm live. Có thể hạ Blue về idle hoặc xóa để tiết kiệm tài nguyên.

Bước 7b — Nếu lỗi (rollback): patch selector ngược về version: blue. Traffic quay về Blue tức thì. Sau đó bình tĩnh điều tra Green.

Toàn bộ luồng này nên được tự động hóa trong pipeline CI/CD (dùng công cụ như Argo Rollouts, Spinnaker, hoặc script tự viết) thay vì gõ tay, để cutover và rollback nhất quán, có kiểm soát.

Lỗi thường gặp & mẹo

Lỗi 1 — Quên tính tương thích ngược của database. Như ví dụ PayGo: đây là cái bẫy chết người số một. Mọi thay đổi schema phải tương thích với cả phiên bản cũ và mới trong suốt cửa sổ Blue-Green. Áp dụng nguyên tắc "expand and contract": thêm trước, dọn sau.

Lỗi 2 — Bỏ qua kết nối và phiên đang mở (in-flight requests). Lúc cutover, các request đang xử lý dở trên Blue cần được hoàn tất trước khi Blue bị hạ. Hãy cấu hình connection draining (graceful shutdown) trên load balancer, cho Blue thời gian đóng nốt các kết nối đang mở thay vì cắt phũ.

Lỗi 3 — Quá tin vào DNS switching. TTL và cache DNS khiến traffic không chuyển ngay và rollback không tức thời. Ưu tiên load balancer hoặc service selector. Nếu buộc phải dùng DNS, hạ TTL xuống rất thấp (ví dụ 30-60 giây) từ trước.

Lỗi 4 — Session dính (sticky session) và state cục bộ. Nếu ứng dụng lưu session trong bộ nhớ của từng server, người dùng đang có phiên trên Blue sẽ bị đăng xuất khi cutover sang Green. Mẹo: đưa session ra ngoài (Redis, database) để ứng dụng thực sự stateless — đây cũng là tinh thần của 12-Factor App ở Bài 37.

Lỗi 5 — Hủy Blue quá sớm. Đừng xóa Blue ngay sau khi cutover. Giữ nó ít nhất qua "bake time" để còn đường rollback. Nhiều sự cố chỉ lộ ra sau vài phút chịu tải thật.

Mẹo — Warm-up cho Green trước khi cutover. Ứng dụng vừa khởi động thường "lạnh" (JIT chưa nóng, cache trống, connection pool chưa đầy). Nếu đổ ngay 100% traffic vào Green lạnh, latency có thể tăng vọt. Hãy gửi một ít traffic mồi hoặc chạy health check kéo dài để "làm ấm" Green trước.

Mẹo — Tự động hóa cả rollback. Đặt ngưỡng cảnh báo (error rate vượt X%, latency vượt Y ms) và cho pipeline tự động rollback khi vi phạm. Con người phản ứng chậm hơn máy, nhất là lúc 3 giờ sáng.

Bài tập thực hành

• Dựng Blue-Green cục bộ. Dùng Minikube hoặc kind, tạo hai Deployment web-blue (nginx trả về trang "V1") và web-green (trả về trang "V2"), cùng một Service trỏ vào Blue. Thực hiện cutover bằng lệnh kubectl patch và xác nhận trình duyệt chuyển từ V1 sang V2. Sau đó rollback về Blue.

• Đo thời gian rollback. Viết một script gửi request liên tục (dùng curl trong vòng lặp hoặc hey) tới Service trong lúc bạn cutover rồi rollback. Ghi lại có bao nhiêu request lỗi/bị gián đoạn. Mục tiêu: đạt zero-downtime hoặc gần như vậy.

• Tình huống database. Viết ra (bằng lời) kế hoạch migration tương thích ngược cho tình huống: bạn cần đổi cột full_name thành hai cột first_name và last_name, trong khi vẫn phải Blue-Green được. Liệt kê các bước "expand" và "contract", và chỉ rõ ở bước nào thì an toàn để rollback.

• Thảo luận. So sánh Blue-Green với Rolling Update (Bài 17): với một dịch vụ nội bộ 200 người dùng ít quan trọng, bạn chọn cái nào và vì sao? Với hệ thống thanh toán quan trọng thì sao? Không có đáp án duy nhất — hãy lập luận dựa trên chi phí, độ phức tạp và yêu cầu rollback.

Tóm tắt

Blue-Green Deployment giải quyết bài toán deploy an toàn bằng cách duy trì hai môi trường production song song — một live (Blue), một idle (Green) — và chuyển toàn bộ traffic giữa chúng bằng một thao tác cutover gần như tức thời. Sức mạnh cốt lõi của nó là rollback trong vài giây: chỉ cần switch traffic ngược lại, không build lại, không deploy lại.

Những điểm cần khắc cốt ghi tâm:

• Màu (Blue/Green) là vai trò luân phiên, không gắn cố định với phiên bản.
• Chuyển traffic bằng load balancer hoặc service selector, tránh phụ thuộc DNS.
• Blue-Green chỉ bảo vệ tầng stateless; database dùng chung buộc bạn phải làm migration tương thích ngược, nếu không rollback là vô nghĩa.
• Chi phí gấp đôi hạ tầng là tạm thời, có thể tối ưu bằng IaC.
• Luôn có bake time và giữ môi trường cũ đủ lâu để còn đường lui; ưu tiên tự động hóa cả cutover lẫn rollback.

Nắm vững Blue-Green, bạn có nền tảng vững để bước sang Bài 19 — Canary Deployment, nơi ta sẽ tinh vi hơn: thay vì chuyển 100% traffic một lần, ta thả từng phần nhỏ để giảm rủi ro hơn nữa. Hai kỹ thuật này bổ sung cho nhau, và một kỹ sư CD giỏi biết khi nào nên dùng cái nào.