Load balancer là gì? Cách hoạt động và vì sao hệ thống lớn đều cần

Máy tính nào rồi cũng có ngày hỏng, và một con server đơn lẻ thì thường hỏng đúng vào lúc bạn ít mong đợi nhất. Khi hệ thống phải gánh hàng triệu người dùng, bạn không thể cứ nhồi thêm CPU với RAM cho một máy chủ duy nhất mãi được: dù có khỏe tới đâu, nó vẫn là điểm chết duy nhất (Single Point of Failure).

, đảm bảo tối ưu tài nguyên và hệ thống luôn sẵn sàng (High Availability).

Hình dung nó như người điều phối trong nhà hàng: đón thực khách ngay ở cửa rồi dẫn thẳng tới bàn của nhân viên đang rảnh tay nhất, chứ không để khách tự đi lang thang tìm chỗ. Nếu không có load balancer, một vài server sẽ bị nghẽn trong khi số khác lại ngồi chơi.

Load balancer là gì?

Về mặt kỹ thuật, load balancer đứng ra làm Điểm truy cập duy nhất (Single Point of Contact - SPOC) cho mọi request từ phía máy khách. Nó có thể là một hộp phần cứng chuyên dụng (như A10 Thunder ADC), hoặc là phần mềm (như Nginx, HAProxy) chạy trên server tiêu chuẩn, và với đa số hệ thống thì tôi thấy bản phần mềm là quá đủ.

Cái hay của cách bố trí này là nó giấu toàn bộ sự phức tạp của kiến trúc backend đi. Máy khách chỉ cần biết đến một địa chỉ duy nhất gọi là Virtual IP (VIP). VIP là một địa chỉ IP ảo, không gán cố định cho bất kỳ giao diện mạng vật lý (interface) của một server cụ thể nào mà đại diện cho cả một pool máy chủ. Khi traffic đi vào VIP, load balancer sẽ ánh xạ (mapping) gói tin đến địa chỉ IP vật lý của server backend phù hợp. Nhờ vậy bạn thêm server, gỡ server hay lôi một node ra bảo trì lúc nửa đêm mà phía người dùng cuối không phải đổi lấy một dòng cấu hình.

Load balancer hoạt động như thế nào?

Quy trình cơ bản của một request:

1. DNS lookup: Máy khách truy vấn DNS để lấy IP của dịch vụ. Tuy nhiên, DNS load balancing có những hạn chế lớn: các recursive resolver thường lưu bộ nhớ đệm (caching) lâu hơn giá trị TTL (thời gian sống của bản ghi), khiến việc thay đổi IP không được cập nhật ngay lập tức. Ngoài ra, máy chủ DNS không thấy được IP thực của máy khách (trừ khi dùng phần mở rộng EDNS0), dẫn đến việc điều hướng địa lý không chính xác. Nói thẳng ra, cân bằng tải bằng DNS là cách rẻ nhất và cũng là cách bạn ít tin được nhất vào đúng lúc có sự cố.
2. Tiếp nhận packet: Load balancer nhận packet tại VIP.
3. Chọn máy chủ: Dựa trên thuật toán phân phối và trạng thái health check.
4. Chuyển tiếp: Chuyển tiếp packet đến backend.

Sau khi đã chọn được máy chủ, gói tin đi tiếp theo một trong ba cơ chế, và chọn sai cơ chế ở đây là chỗ nhiều người trả giá bằng băng thông:

• Packet Encapsulation (GRE): Load balancer bọc gói tin gốc vào một packet IP khác sử dụng giao thức GRE (Generic Routing Encapsulation). Cơ chế này tạo ra một khoảng overhead là 24 bytes. Server backend khi nhận được sẽ gỡ lớp vỏ ngoài để xử lý packet gốc.
• Direct Server Response (DSR - Passthrough): Cực kỳ hiệu quả cho các dịch vụ như video streaming hoặc image hosting. Load balancer chỉ xử lý các request nhỏ (inbound), còn server backend sẽ gửi phản hồi lớn (outbound) trực tiếp cho máy khách mà không đi ngược lại qua load balancer. Nhờ vậy thiết bị điều phối không phải gánh chiều ra, vốn là chiều nặng nhất, và tránh được nghẽn cổ chai ngay tại chính nó.
• Network Address Translation (NAT) / Terminating: Load balancer đóng vai trò reverse proxy, thiết lập kết nối riêng với máy khách và một kết nối khác với backend.

Cấu hình upstream cơ bản trong Nginx để gom nhóm máy chủ:

http {
    upstream backend_pool {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
 
    server {
        listen 80;
        location / {
            proxy_pass http://backend_pool;
        }
    }
}

Các thuật toán phân phối lưu lượng phổ biến

Thuật toán phân phối là thứ quyết định backend của bạn chạy đều tay hay có một node è cổ ra gánh trong khi mấy node còn lại ngồi chơi. Chia thô ra, có hai nhóm:

Nhóm thuật toán tĩnh (Static)

• Round-robin: Mặc định trong Nginx, xoay vòng tuần tự qua các server.
• Weighted Round-robin: Gán trọng số dựa trên năng lực phần cứng. Node mạnh nhận nhiều traffic hơn.
• IP Hash: Sử dụng hash IP của máy khách để gán vào server cố định (Sticky Session). Lưu ý: Nếu dùng công thức đơn giản id(packet) mod N, khi một server chết (N thành N-1), hầu hết các kết nối sẽ bị ánh xạ lại sang server khác, gây mất session hàng loạt. Giải pháp cấp SRE (Site Reliability Engineering) là dùng Consistent Hashing để giảm thiểu tối đa việc tái ánh xạ kết nối khi pool thay đổi. Nếu bạn định dính tới sticky session, đây là chỗ tôi khuyên đừng tiết kiệm công.

Nhóm thuật toán động (Dynamic)

• Least Connection: Ưu tiên server có ít kết nối nhất (least_conn;).
• Least Response Time: Chọn server có thời gian phản hồi thấp nhất (least_time).
• Resource-based: Dựa trên tải thực tế (CPU/RAM) được báo cáo từ agent (tiến trình giám sát) chạy trên backend.

Health check: cách load balancer biết một máy chủ đã chết

Một load balancer không biết node nào còn sống thì chỉ là cái máy chia traffic vào hố đen. Health check là phần giữ cho nó tỉnh táo, và có hai kiểu:

• Active Health Check: Chủ động gửi probe (gói tin thăm dò) định kỳ. Với HAProxy, option httpchk mặc định dùng phương thức OPTIONS, nhưng bạn nên dùng GET /health để kiểm tra logic sâu hơn bên trong ứng dụng, vì một web server còn thở chưa chắc đã là một ứng dụng còn dùng được.
  • Thông số: inter (khoảng cách giữa các lần check), fall (ngưỡng đánh dấu chết), rise (ngưỡng sống lại).
  • Dùng rstatus với regex để khớp các mã trạng thái thành công (ví dụ: http-check expect ! rstatus ^5 để loại bỏ các server báo lỗi 5xx).
• Passive Health Check: Quan sát traffic thực tế. Nếu một request người dùng gửi tới backend bị lỗi, load balancer sẽ ghi nhận. Cái giá của nó là phải có traffic chạy qua mới phát hiện được lỗi, tức là người dùng thật đã lãnh trọn cái lỗi đó rồi, khác với active probe gửi lệnh kiểm tra liên tục.

Ví dụ cấu hình HAProxy với kiểm tra sức khỏe nâng cao:

backend apps
  option httpchk GET /health_check
  http-check expect status 200
  default-server inter 3s fall 3 rise 2
  server web1 10.0.0.1:80 check

Layer 4 và Layer 7 khác nhau ở đâu?

Khác biệt nằm ở chỗ thiết bị chịu soi gói tin sâu tới đâu, và bạn trả bao nhiêu CPU cho độ sâu đó:

Vì sao load balancer quan trọng đến vậy?

1. Tính sẵn sàng (Availability): Loại bỏ điểm chết duy nhất (Single Point of Failure). Khi server chết, load balancer tự động định tuyến lại traffic sang node còn sống.
2. Khả năng mở rộng (Scalability): Cho phép scale-out theo chiều ngang. Bạn có thể thêm 10 node trong đợt sale-off và gỡ ra sau đó mà không làm gián đoạn dịch vụ.
3. Bảo mật: Đóng vai trò lá chắn, ẩn IP thật của máy chủ ứng dụng khỏi internet.
4. Hiệu suất (GSLB): Với các hệ thống đa quốc gia, Global Server Load Balancing điều hướng người dùng đến datacenter gần nhất. Không ai cãi được tốc độ ánh sáng trong sợi cáp quang, nên rút ngắn khoảng cách địa lý là cách duy nhất còn lại để giảm latency.

Khi nào bạn thực sự cần một load balancer?

Đừng triển khai load balancer chỉ vì nó nghe có vẻ "pro". Nó làm việc debug khó lên hẳn một bậc, vì mỗi lần có lỗi bạn phải hỏi thêm câu "node nào?", và nó tốn thêm chi phí vận hành.

Bạn chỉ cần nó khi traffic vượt quá ngưỡng xử lý của một server đơn lẻ, khi bạn cần triển khai Zero Downtime Deployment (cập nhật code mà không làm gián đoạn người dùng), khi bạn chạy kiến trúc Microservices cần định tuyến theo URL path, hoặc khi bạn cần một nơi tập trung để quản lý SSL Certificate (SSL Offloading) nhằm giải phóng tài nguyên tính toán cho backend. Còn nếu hiện tại một VPS vẫn phục vụ ngon lành lượng truy cập của bạn, cứ để yên đó đã.

Tài liệu tham khảo

• What is Load Balancing? - Load Balancing Algorithm Explained — AWS
• Using nginx as HTTP load balancer — nginx
• Layer 4 vs Layer 7 Load Balancing — A10 Networks
• Health checks — HAProxy config tutorials
• What is High Availability Load Balancing? — A10 Networks
• What is an Application Load Balancer? — AWS Elastic Load Balancing
• Load Balancing Options — Azure Architecture Center
• Load Balancing at the Frontend — Google SRE Book