Zero-Downtime Deployment — Blue-Green, Canary và Rolling Update

Posted on: 4/18/2026 12:11:02 AM

Mỗi lần deploy là một lần hồi hộp. Hệ thống sập 5 phút có thể mất hàng nghìn đơn hàng, hàng triệu đồng doanh thu, và quan trọng hơn — mất niềm tin của người dùng. Trong thế giới mà 99.99% uptime (tương đương chỉ ~52 phút downtime/năm) là kỳ vọng tối thiểu, hiểu và áp dụng đúng chiến lược zero-downtime deployment không còn là "nice to have" mà là yêu cầu bắt buộc.

Bài viết này sẽ phân tích sâu 4 chiến lược deploy phổ biến nhất: Rolling Update, Blue-Green Deployment, Canary Release, và A/B Testing Deployment. Mỗi chiến lược phù hợp với hoàn cảnh khác nhau — không có "one size fits all".

1. Tại sao cần Zero-Downtime Deployment?

Trước khi đi vào từng chiến lược, hãy hiểu rõ vì sao traditional deployment (stop → deploy → start) không còn phù hợp:

graph LR
    A[🔴 Traditional Deploy] --> B[Stop Server]
    B --> C[Copy Files]
    C --> D[Run Migrations]
    D --> E[Start Server]
    E --> F[Health Check]

    G[🟢 Zero-Downtime] --> H[Deploy New Version]
    H --> I[Health Check New]
    I --> J[Switch Traffic]
    J --> K[Drain Old Connections]

    style A fill:#e94560,stroke:#fff,color:#fff
    style G fill:#4CAF50,stroke:#fff,color:#fff
    style B fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style C fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style D fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style E fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style F fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style H fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style I fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style J fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style K fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
  

Với traditional deployment, khoảng thời gian từ bước "Stop Server" đến "Health Check" hoàn tất có thể kéo dài từ vài giây đến vài phút. Trong khoảng đó, mọi request đều thất bại. Zero-downtime đảm bảo luôn có ít nhất một phiên bản healthy đang phục vụ traffic.

2. Rolling Update — Đơn giản và phổ biến nhất

sequenceDiagram
    participant LB as Load Balancer
    participant P1 as Pod 1 (v1)
    participant P2 as Pod 2 (v1)
    participant P3 as Pod 3 (v1)

    Note over LB,P3: Bước 1: Bắt đầu Rolling Update
    LB->>P1: Drain connections
    Note over P1: Terminate v1, Start v2
    P1-->>LB: Health check OK (v2)

    Note over LB,P3: Bước 2: Tiếp tục pod tiếp theo
    LB->>P2: Drain connections
    Note over P2: Terminate v1, Start v2
    P2-->>LB: Health check OK (v2)

    Note over LB,P3: Bước 3: Pod cuối cùng
    LB->>P3: Drain connections
    Note over P3: Terminate v1, Start v2
    P3-->>LB: Health check OK (v2)

    Note over LB,P3: ✅ Hoàn tất - tất cả đều v2
  

Cấu hình Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Tối đa thêm 1 pod mới cùng lúc
      maxUnavailable: 1   # Tối đa 1 pod không khả dụng
  template:
    spec:
      containers:
      - name: api
        image: myapp:2.0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 15"]
      terminationGracePeriodSeconds: 30

3. Blue-Green Deployment — Chuyển đổi tức thì, rollback 1 giây

graph TB
    subgraph "Trước khi deploy"
        U1[Users] --> LB1[Load Balancer]
        LB1 --> B1[🔵 Blue - v1.0
ACTIVE]
        G1[🟢 Green - v0.9
IDLE]
    end

    subgraph "Deploy v2.0 lên Green"
        U2[Users] --> LB2[Load Balancer]
        LB2 --> B2[🔵 Blue - v1.0
ACTIVE]
        G2[🟢 Green - v2.0
TESTING]
    end

    subgraph "Switch traffic"
        U3[Users] --> LB3[Load Balancer]
        B3[🔵 Blue - v1.0
STANDBY]
        LB3 --> G3[🟢 Green - v2.0
ACTIVE]
    end

    style B1 fill:#2196F3,stroke:#fff,color:#fff
    style G1 fill:#f8f9fa,stroke:#e0e0e0,color:#888
    style B2 fill:#2196F3,stroke:#fff,color:#fff
    style G2 fill:#4CAF50,stroke:#fff,color:#fff
    style B3 fill:#f8f9fa,stroke:#e0e0e0,color:#888
    style G3 fill:#4CAF50,stroke:#fff,color:#fff
    style LB1 fill:#2c3e50,stroke:#fff,color:#fff
    style LB2 fill:#2c3e50,stroke:#fff,color:#fff
    style LB3 fill:#2c3e50,stroke:#fff,color:#fff
    style U1 fill:#e94560,stroke:#fff,color:#fff
    style U2 fill:#e94560,stroke:#fff,color:#fff
    style U3 fill:#e94560,stroke:#fff,color:#fff
  

Triển khai với AWS ECS

{
  "deploymentController": {
    "type": "CODE_DEPLOY"
  },
  "deploymentConfiguration": {
    "deploymentCircuitBreaker": {
      "enable": true,
      "rollback": true
    }
  }
}

AWS CodeDeploy với ECS hỗ trợ Blue-Green natively. Cấu hình trong appspec.yaml:

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:region:account:task-def/myapp:2"
        LoadBalancerInfo:
          ContainerName: "web-api"
          ContainerPort: 8080
Hooks:
  - BeforeAllowTraffic: "LambdaFunctionForValidation"
  - AfterAllowTraffic: "LambdaFunctionForSmokeTest"

Triển khai với Nginx (self-managed)

upstream blue {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

upstream green {
    server 10.0.2.10:8080;
    server 10.0.2.11:8080;
}

# Sử dụng map để chuyển traffic
map $cookie_deployment $backend {
    default blue;       # ← Đổi thành "green" khi switch
    "green" green;
}

server {
    listen 80;
    location / {
        proxy_pass http://$backend;
        proxy_set_header X-Deployment-Target $backend;
    }
}

4. Canary Release — Deploy an toàn với kiểm soát % traffic

graph LR
    U[Users
100%] --> LB[Load Balancer
Traffic Split]
    LB -->|95%| V1[Version 1.0
Stable]
    LB -->|5%| V2[Version 2.0
Canary]
    V2 --> M[Metrics
Monitoring]
    M -->|OK| INC[Tăng lên 25%
→ 50% → 100%]
    M -->|Lỗi| RB[Rollback
0% canary]

    style U fill:#e94560,stroke:#fff,color:#fff
    style LB fill:#2c3e50,stroke:#fff,color:#fff
    style V1 fill:#2196F3,stroke:#fff,color:#fff
    style V2 fill:#4CAF50,stroke:#fff,color:#fff
    style M fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style INC fill:#4CAF50,stroke:#fff,color:#fff
    style RB fill:#e94560,stroke:#fff,color:#fff
  

Cấu hình Canary trên Kubernetes với Istio

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web-api
spec:
  hosts:
  - web-api.example.com
  http:
  - route:
    - destination:
        host: web-api
        subset: stable
      weight: 95
    - destination:
        host: web-api
        subset: canary
      weight: 5
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: web-api
spec:
  host: web-api
  subsets:
  - name: stable
    labels:
      version: v1
  - name: canary
    labels:
      version: v2

Automated Canary với Flagger

Flagger là công cụ progressive delivery cho Kubernetes, tự động hóa toàn bộ quy trình canary dựa trên metrics:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: web-api
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  service:
    port: 8080
  analysis:
    # Tăng 10% mỗi interval nếu metrics đạt
    interval: 1m
    threshold: 5          # Số lần fail trước khi rollback
    maxWeight: 50         # Tối đa 50% traffic cho canary
    stepWeight: 10        # Tăng 10% mỗi bước
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99            # Yêu cầu 99%+ success rate
      interval: 1m
    - name: request-duration
      thresholdRange:
        max: 500           # P99 latency < 500ms
      interval: 1m
    webhooks:
    - name: smoke-test
      type: pre-rollout
      url: http://flagger-loadtester/
      metadata:
        cmd: "curl -s http://web-api-canary:8080/health"

5. A/B Testing Deployment — Deploy dựa trên user segments

# Istio VirtualService với header-based routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web-api
spec:
  hosts:
  - web-api.example.com
  http:
  # Route internal team đến version mới
  - match:
    - headers:
        x-user-tier:
          exact: "internal"
    route:
    - destination:
        host: web-api
        subset: v2
  # Route premium users
  - match:
    - headers:
        x-user-tier:
          exact: "premium"
    route:
    - destination:
        host: web-api
        subset: v2
  # Còn lại → stable
  - route:
    - destination:
        host: web-api
        subset: v1

6. So sánh tổng hợp

7. Database Migration trong Zero-Downtime

Đây là phần khó nhất. Khi 2 version chạy song song (Rolling, Canary), cả v1 và v2 phải tương thích với cùng một database schema. Quy tắc vàng: Expand-and-Contract pattern.

graph TB
    subgraph "Phase 1: Expand"
        E1[Deploy v2 code] --> E2[Add new column
nullable/default]
        E2 --> E3[v1 và v2 đều chạy OK
v2 bắt đầu ghi column mới]
    end

    subgraph "Phase 2: Migrate"
        M1[Backfill data
cho column mới] --> M2[v2 đọc/ghi column mới]
        M2 --> M3[Retire v1 hoàn toàn]
    end

    subgraph "Phase 3: Contract"
        C1[Drop column cũ] --> C2[Remove code xử lý cũ]
        C2 --> C3[Schema clean]
    end

    E3 --> M1
    M3 --> C1

    style E1 fill:#2196F3,stroke:#fff,color:#fff
    style E2 fill:#2196F3,stroke:#fff,color:#fff
    style E3 fill:#2196F3,stroke:#fff,color:#fff
    style M1 fill:#4CAF50,stroke:#fff,color:#fff
    style M2 fill:#4CAF50,stroke:#fff,color:#fff
    style M3 fill:#4CAF50,stroke:#fff,color:#fff
    style C1 fill:#e94560,stroke:#fff,color:#fff
    style C2 fill:#e94560,stroke:#fff,color:#fff
    style C3 fill:#e94560,stroke:#fff,color:#fff
  

Ví dụ: Đổi tên column

Muốn đổi user_name thành display_name? Không thể đơn giản ALTER TABLE RENAME COLUMN — v1 sẽ crash ngay. Thay vào đó:

-- Phase 1: Expand (deploy trước code change)
ALTER TABLE users ADD COLUMN display_name VARCHAR(255);

-- Trigger để sync 2 columns trong transition period
CREATE TRIGGER sync_display_name
BEFORE INSERT OR UPDATE ON users
FOR EACH ROW
BEGIN
    IF NEW.display_name IS NULL THEN
        SET NEW.display_name = NEW.user_name;
    END IF;
    IF NEW.user_name IS NULL THEN
        SET NEW.user_name = NEW.display_name;
    END IF;
END;

-- Phase 2: Backfill existing data
UPDATE users SET display_name = user_name WHERE display_name IS NULL;

-- Phase 3: Sau khi v1 retire hoàn toàn
ALTER TABLE users DROP COLUMN user_name;
DROP TRIGGER sync_display_name;

8. Health Check — Nền tảng của mọi chiến lược

Không có health check tốt, mọi chiến lược deploy đều vô nghĩa. Health check cần phân biệt 3 trạng thái:

// .NET Minimal API health check example
app.MapHealthChecks("/health/live", new HealthCheckOptions
{
    // Liveness: app có đang chạy không?
    Predicate = check => check.Tags.Contains("live")
});

app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
    // Readiness: app đã sẵn sàng nhận traffic chưa?
    Predicate = check => check.Tags.Contains("ready")
});

app.MapHealthChecks("/health/startup", new HealthCheckOptions
{
    // Startup: dùng cho slow-starting containers
    Predicate = check => check.Tags.Contains("startup")
});

// Register checks
builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy(), tags: new[] { "live" })
    .AddSqlServer(connectionString, tags: new[] { "ready" })
    .AddRedis(redisConnection, tags: new[] { "ready" })
    .AddCheck<WarmupCheck>("warmup", tags: new[] { "startup" });

# Kubernetes probe configuration
containers:
- name: api
  livenessProbe:
    httpGet:
      path: /health/live
      port: 8080
    initialDelaySeconds: 10
    periodSeconds: 15
    failureThreshold: 3      # 3 lần fail → restart container
  readinessProbe:
    httpGet:
      path: /health/ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10
    failureThreshold: 2      # 2 lần fail → remove khỏi Service
  startupProbe:
    httpGet:
      path: /health/startup
      port: 8080
    initialDelaySeconds: 0
    periodSeconds: 5
    failureThreshold: 30     # Cho phép 150s để warmup

9. Graceful Shutdown — Yếu tố thường bị bỏ quên

Khi Kubernetes gửi SIGTERM đến pod, ứng dụng cần:

sequenceDiagram
    participant K8s as Kubernetes
    participant Pod as Application Pod
    participant LB as Service/Endpoint

    K8s->>Pod: SIGTERM
    K8s->>LB: Remove Pod from Endpoints
    Note over Pod: Bắt đầu graceful shutdown
    Pod->>Pod: Stop accepting NEW requests
    Pod->>Pod: Finish in-flight requests (max 30s)
    Pod->>Pod: Close DB connections
    Pod->>Pod: Flush logs/metrics
    Pod-->>K8s: Exit 0

    Note over K8s: Nếu không exit sau
terminationGracePeriodSeconds
→ SIGKILL
  

// .NET graceful shutdown
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

var lifetime = app.Services.GetRequiredService<IHostApplicationLifetime>();

lifetime.ApplicationStopping.Register(() =>
{
    // Đợi in-flight requests hoàn thành
    // preStop hook sleep 15s đảm bảo endpoint đã bị remove
    Log.Information("Shutting down gracefully...");
});

lifetime.ApplicationStopped.Register(() =>
{
    Log.CloseAndFlush();
});

10. Chiến lược nào cho team bạn?

Tham khảo

• Kubernetes Documentation — Rolling Update Deployment
• Flagger — Progressive Delivery with Istio
• AWS CodeDeploy — Blue/Green Deployments on ECS
• Azure Container Apps — Blue-Green Deployment
• Google Cloud — Canary Deployment Strategy
• Martin Fowler — Blue-Green Deployment
• DORA — Accelerate State of DevOps Report