Load Balancing: Nghệ thuật Phân tải cho Hệ thống Triệu Request

Posted on: 4/20/2026 7:40:51 AM

Load Balancing là gì và tại sao quan trọng?

Hãy tưởng tượng bạn điều hành một nhà hàng có 10 bàn phục vụ. Nếu tất cả khách đều ngồi vào 1 bàn trong khi 9 bàn còn lại trống, trải nghiệm sẽ cực kỳ tồi tệ. Load Balancer chính là người quản lý nhà hàng — phân bổ khách hàng đều vào các bàn, đảm bảo không ai phải chờ quá lâu.

Trong kiến trúc phần mềm, Load Balancer là thành phần phân phối traffic đến từ client vào nhiều server backend, nhằm tối ưu hiệu suất, tăng tính sẵn sàng (availability), và đảm bảo không server nào bị quá tải.

Layer 4 vs Layer 7: Hai trường phái phân tải

Đây là quyết định kiến trúc đầu tiên khi chọn Load Balancer. Sự khác biệt nằm ở tầng OSI mà LB hoạt động, và điều đó ảnh hưởng trực tiếp đến khả năng routing, hiệu năng và chi phí.

graph TB
    subgraph L4["Layer 4 — Transport"]
        A[Client Request] -->|TCP/UDP| B[L4 Load Balancer]
        B -->|IP + Port| C[Server A]
        B -->|IP + Port| D[Server B]
        B -->|IP + Port| E[Server C]
    end

    subgraph L7["Layer 7 — Application"]
        F[Client Request] -->|HTTP/gRPC| G[L7 Load Balancer]
        G -->|/api/*| H[API Server]
        G -->|/static/*| I[CDN/Static Server]
        G -->|/ws/*| J[WebSocket Server]
    end

    style L4 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style L7 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style B fill:#e94560,stroke:#fff,color:#fff
    style G fill:#e94560,stroke:#fff,color:#fff
    style C fill:#2c3e50,stroke:#fff,color:#fff
    style D fill:#2c3e50,stroke:#fff,color:#fff
    style E fill:#2c3e50,stroke:#fff,color:#fff
    style H fill:#2c3e50,stroke:#fff,color:#fff
    style I fill:#2c3e50,stroke:#fff,color:#fff
    style J fill:#2c3e50,stroke:#fff,color:#fff

6 thuật toán Load Balancing phổ biến nhất

1. Round Robin — Đơn giản nhưng hiệu quả

2. Weighted Round Robin — Khi server không đều

# NGINX config
upstream backend {
    server app1.example.com weight=5;  # 16 CPU, 64GB RAM
    server app2.example.com weight=3;  # 8 CPU, 32GB RAM
    server app3.example.com weight=1;  # 2 CPU, 8GB RAM
}

3. Least Connections — Thích ứng theo tải thực

4. IP Hash — Session Affinity đơn giản

# NGINX config
upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
    server app3.example.com;
}

5. Consistent Hashing — Vua của Distributed Cache

graph TB
    subgraph Ring["Hash Ring — Consistent Hashing"]
        direction TB
        N1["Server A
position: 0°"]
        N2["Server B
position: 120°"]
        N3["Server C
position: 240°"]
        K1["Key 'user:42'
→ Server A"]
        K2["Key 'session:99'
→ Server B"]
        K3["Key 'cart:17'
→ Server C"]
    end

    K1 -.->|hash → 35°| N1
    K2 -.->|hash → 155°| N2
    K3 -.->|hash → 280°| N3

    style Ring fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style N1 fill:#e94560,stroke:#fff,color:#fff
    style N2 fill:#e94560,stroke:#fff,color:#fff
    style N3 fill:#e94560,stroke:#fff,color:#fff
    style K1 fill:#2c3e50,stroke:#fff,color:#fff
    style K2 fill:#2c3e50,stroke:#fff,color:#fff
    style K3 fill:#2c3e50,stroke:#fff,color:#fff

Virtual Nodes là kỹ thuật quan trọng để cải thiện phân bổ đều. Thay vì mỗi server chỉ có 1 vị trí trên ring, ta tạo 100-200 vị trí ảo (virtual node) cho mỗi server vật lý. Điều này giúp:

• Phân bổ key đều hơn đáng kể
• Khi 1 server fail, tải phân tán đều sang nhiều server thay vì dồn hết vào 1 server kế tiếp
• Amazon DynamoDB, Apache Cassandra, và ScyllaDB đều sử dụng kỹ thuật này

// Consistent Hashing với virtual nodes — pseudo code
class ConsistentHash {
    private ring: SortedMap<int, string> = new SortedMap();
    private virtualNodes: int = 150;

    addServer(server: string) {
        for (let i = 0; i < this.virtualNodes; i++) {
            let hash = md5(`${server}:${i}`);
            this.ring.set(hash, server);
        }
    }

    getServer(key: string): string {
        let hash = md5(key);
        // Tìm node gần nhất theo chiều kim đồng hồ
        let entry = this.ring.ceilingEntry(hash);
        return entry ? entry.value : this.ring.firstEntry().value;
    }

    removeServer(server: string) {
        for (let i = 0; i < this.virtualNodes; i++) {
            this.ring.delete(md5(`${server}:${i}`));
        }
        // Chỉ ~1/n key bị remap — không ảnh hưởng toàn bộ
    }
}

6. Random Two Choices — Thuật toán "vừa đủ thông minh"

# NGINX Plus config
upstream backend {
    random two least_conn;
    server app1.example.com;
    server app2.example.com;
    server app3.example.com;
    server app4.example.com;
}

So sánh toàn diện các thuật toán

Công cụ Load Balancing phổ biến

NGINX — Reverse Proxy kiêm Load Balancer

NGINX là lựa chọn phổ biến nhất cho L7 Load Balancing nhờ hiệu năng cao (xử lý hàng triệu concurrent connection), cấu hình đơn giản, và hệ sinh thái module phong phú.

# nginx.conf — Load Balancing hoàn chỉnh
http {
    upstream api_servers {
        least_conn;
        server 10.0.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
        server 10.0.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
        server 10.0.1.12:8080 weight=1 backup;  # Chỉ dùng khi 2 server trên fail
    }

    server {
        listen 443 ssl http2;
        server_name api.example.com;

        # SSL Termination
        ssl_certificate     /etc/ssl/certs/api.crt;
        ssl_certificate_key /etc/ssl/private/api.key;

        # Health check implicit qua max_fails/fail_timeout
        location /api/ {
            proxy_pass http://api_servers;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;

            # Timeout config
            proxy_connect_timeout 5s;
            proxy_read_timeout 60s;
            proxy_send_timeout 10s;
        }
    }
}

HAProxy — Load Balancer chuyên dụng

HAProxy nổi tiếng với khả năng xử lý L4 và L7, được thiết kế chuyên biệt cho load balancing với active health check, chi tiết metrics, và hiệu năng ấn tượng.

# haproxy.cfg
frontend http_front
    bind *:443 ssl crt /etc/ssl/api.pem
    mode http

    # Content-based routing
    acl is_api path_beg /api
    acl is_ws  hdr(Upgrade) -i websocket

    use_backend api_servers if is_api
    use_backend ws_servers  if is_ws
    default_backend static_servers

backend api_servers
    mode http
    balance leastconn
    option httpchk GET /health
    http-check expect status 200

    server api1 10.0.1.10:8080 check inter 5s fall 3 rise 2
    server api2 10.0.1.11:8080 check inter 5s fall 3 rise 2

backend ws_servers
    mode http
    balance source   # IP Hash cho WebSocket sticky
    timeout tunnel 3600s
    server ws1 10.0.2.10:8080 check
    server ws2 10.0.2.11:8080 check

Cloud Load Balancer — Managed và Auto-scaling

Health Check và Failover — Bộ đệm an toàn

Load Balancer mà không có health check thì chẳng khác gì giao thông mà không có đèn tín hiệu. Health check cho phép LB tự động loại bỏ server chết và đưa lại khi server phục hồi.

sequenceDiagram
    participant LB as Load Balancer
    participant S1 as Server A (healthy)
    participant S2 as Server B (failing)
    participant S3 as Server C (healthy)

    loop Health Check (mỗi 5s)
        LB->>S1: GET /health
        S1-->>LB: 200 OK ✓
        LB->>S2: GET /health
        S2-->>LB: 503 Error ✗
        LB->>S3: GET /health
        S3-->>LB: 200 OK ✓
    end

    Note over LB,S2: Server B fail 3 lần liên tiếp → đánh dấu DOWN

    LB->>S1: Route traffic (50%)
    LB->>S3: Route traffic (50%)
    Note over S2: Không nhận traffic

    S2-->>LB: 200 OK ✓ (sau 2 lần check thành công)
    Note over LB,S2: Server B phục hồi → đưa lại vào pool

Có 3 loại health check phổ biến:

• Active Health Check: LB chủ động gửi request kiểm tra (HTTP GET /health, TCP connect, hoặc custom script). HAProxy và cloud LB hỗ trợ mặc định.
• Passive Health Check: LB theo dõi response từ traffic thực — nếu server trả lỗi liên tục (ví dụ 5 lần 5xx trong 30s), tự động đánh dấu down. NGINX Open Source chỉ hỗ trợ loại này.
• Deep Health Check: Kiểm tra cả dependency (database connection, disk space, memory). Trả về chi tiết qua endpoint /health/detailed.

// ASP.NET — Deep Health Check
// Program.cs
builder.Services.AddHealthChecks()
    .AddSqlServer(connectionString, name: "database")
    .AddRedis(redisConnection, name: "cache")
    .AddCheck("disk-space", () =>
    {
        var drive = new DriveInfo("C");
        return drive.AvailableFreeSpace > 1_073_741_824  // > 1GB
            ? HealthCheckResult.Healthy()
            : HealthCheckResult.Degraded("Low disk space");
    });

app.MapHealthChecks("/health", new HealthCheckOptions
{
    Predicate = _ => true,
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});

Kiến trúc triển khai thực tế

Pattern 1: Single-tier LB — Cho hệ thống vừa và nhỏ

graph LR
    Client[Client] --> LB[NGINX / HAProxy
L7 Load Balancer]
    LB --> S1[App Server 1]
    LB --> S2[App Server 2]
    LB --> S3[App Server 3]
    S1 --> DB[(Database)]
    S2 --> DB
    S3 --> DB

    style Client fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style LB fill:#e94560,stroke:#fff,color:#fff
    style S1 fill:#2c3e50,stroke:#fff,color:#fff
    style S2 fill:#2c3e50,stroke:#fff,color:#fff
    style S3 fill:#2c3e50,stroke:#fff,color:#fff
    style DB fill:#4CAF50,stroke:#fff,color:#fff

Pattern 2: Two-tier LB — Cho hệ thống lớn

graph TB
    Client[Client] --> DNS[DNS / GeoDNS]
    DNS --> L4A[NLB - L4
Region A]
    DNS --> L4B[NLB - L4
Region B]

    L4A --> L7A1[ALB/NGINX - L7]
    L4A --> L7A2[ALB/NGINX - L7]

    L4B --> L7B1[ALB/NGINX - L7]

    L7A1 --> API1[API Pods]
    L7A2 --> WEB1[Web Pods]
    L7B1 --> API2[API Pods]

    style Client fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style DNS fill:#ff9800,stroke:#fff,color:#fff
    style L4A fill:#e94560,stroke:#fff,color:#fff
    style L4B fill:#e94560,stroke:#fff,color:#fff
    style L7A1 fill:#2c3e50,stroke:#fff,color:#fff
    style L7A2 fill:#2c3e50,stroke:#fff,color:#fff
    style L7B1 fill:#2c3e50,stroke:#fff,color:#fff
    style API1 fill:#4CAF50,stroke:#fff,color:#fff
    style WEB1 fill:#4CAF50,stroke:#fff,color:#fff
    style API2 fill:#4CAF50,stroke:#fff,color:#fff

Pattern 3: Global Load Balancing — Cho hệ thống toàn cầu

Khi user phân tán khắp thế giới, bạn cần phân tải ở tầng DNS. GeoDNS hoặc Anycast routing sẽ đưa user đến datacenter gần nhất. Cloudflare, AWS Route 53, và Azure Traffic Manager đều hỗ trợ pattern này.

Các lỗi thường gặp và cách khắc phục

# HAProxy slow start
backend api_servers
    server api1 10.0.1.10:8080 check slowstart 60s

Load Balancing trong Kubernetes

Kubernetes có hệ thống load balancing riêng qua Service và Ingress. Hiểu được cách chúng hoạt động giúp tránh trùng lặp hoặc xung đột với external LB.

Checklist triển khai Load Balancer

Tổng kết

Load Balancing không chỉ là "chia đều request" — đó là nghệ thuật phân phối tải sao cho hệ thống vừa nhanh, vừa ổn định, vừa chịu được sự cố. Không có thuật toán "tốt nhất" — chỉ có thuật toán phù hợp nhất cho bối cảnh cụ thể:

• Stateless API → Round Robin hoặc Random Two Choices
• WebSocket / Long-running → Least Connections
• Distributed Cache → Consistent Hashing
• Legacy session-based app → IP Hash (tạm thời, nên migrate sang stateless)
• Multi-region → Global LB (GeoDNS) + Regional L4/L7

Hãy bắt đầu đơn giản với Round Robin, thêm health check, và chỉ phức tạp hóa khi có nhu cầu thực sự. Over-engineering load balancing từ đầu là một trong những lỗi phổ biến nhất trong System Design.

Tham khảo

• NGINX HTTP Load Balancing Documentation
• Understanding Load Balancing Algorithms and Strategies (2026)
• Consistent Hashing Explained — AlgoMaster
• Layer 4 vs Layer 7: Load Balancing and Why It Matters — CloudRPS
• ALB vs NLB: Which AWS Load Balancer Fits Your Needs?
• Edge Computing: Cloudflare Workers Development Guide 2026