Technical SEO

Load Balancing

Kỹ thuật phân phối lưu lượng truy cập giữa nhiều máy chủ để đảm bảo tính sẵn sàng và hiệu năng cao.

3 lượt xem Cập nhật: 26/05/2026

Load Balancing là gì?

Load Balancing (cân bằng tải) là kỹ thuật tự động phân phối lưu lượng truy cập từ người dùng vào nhiều máy chủ hoặc tài nguyên backend — như máy chủ web, cơ sở dữ liệu hoặc dịch vụ API — nhằm tránh tình trạng một máy chủ bị quá tải trong khi các máy khác còn dư sức. Đây không phải là công cụ SEO trực tiếp, nhưng là nền tảng kỹ thuật ảnh hưởng sâu sắc đến tốc độ, độ ổn định và khả năng phục hồi của website — ba yếu tố Google xếp hạng rõ ràng trong báo cáo Core Web Vitals và tiêu chí Page Experience.

Tại sao quan trọng trong SEO?

Google ưu tiên các trang web đáp ứng nhanh, hoạt động liên tục và xử lý được lưu lượng cao — đặc biệt khi có sự kiện lớn (sale, viral content, chạy quảng cáo). Load balancing góp phần trực tiếp vào:

  • Tốc độ tải trang: Giảm thời gian phản hồi (TTFB) nhờ chuyển yêu cầu tới máy chủ gần nhất hoặc ít tải nhất;
  • Tỷ lệ lỗi 5xx: Ngăn tình trạng 503 Service Unavailable hoặc 504 Gateway Timeout khi máy chủ sập hoặc chậm — những lỗi làm giảm chỉ số Crawl Budget và gây mất xếp hạng tạm thời;
  • Tính sẵn sàng (Uptime): Đảm bảo website luôn online >99,9%, giúp bot Googlebot thu thập nội dung đều đặn, không bỏ sót trang mới hoặc cập nhật;
  • Hỗ trợ mở rộng quy mô: Khi traffic tăng đột biến (ví dụ: bài viết lên top Google), hệ thống tự động scale — không cần dừng site để nâng cấp hạ tầng.

Một nghiên cứu năm 2023 của Backlinko cho thấy 72% trang top 10 có thời gian TTFB dưới 200ms — điều gần như không thể đạt được nếu thiếu load balancing hiệu quả ở tầng infrastructure.

Cách hoạt động

Load balancer đóng vai trò như "người gác cổng": nhận toàn bộ request từ người dùng, sau đó chọn máy chủ phù hợp dựa trên thuật toán và trạng thái thực tế. Quá trình gồm 3 bước chính:

  1. Đón nhận yêu cầu: Tất cả traffic đi qua địa chỉ IP hoặc tên miền của load balancer (ví dụ: lb.example.com hoặc thông qua DNS).
  2. Đánh giá & chọn máy chủ: Kiểm tra sức tải hiện tại (CPU, RAM, số kết nối đang mở), độ trễ mạng (latency), trạng thái sức khỏe (health check) và áp dụng thuật toán phân phối.
  3. Chuyển tiếp yêu cầu: Gửi request tới máy chủ đã chọn, đồng thời theo dõi phản hồi để xử lý lại nếu có lỗi.

Load balancer có thể triển khai ở nhiều lớp: phần cứng (F5 BIG-IP), phần mềm (NGINX, HAProxy), hoặc dạng cloud (AWS ALB, Google Cloud Load Balancing, Cloudflare Load Balancing).

Hướng dẫn thực hiện

Dưới đây là hướng dẫn triển khai cơ bản với NGINX (phổ biến nhất cho website WordPress, Laravel, hoặc static site):

  1. Cài đặt NGINX làm reverse proxy: Cập nhật cấu hình /etc/nginx/conf.d/loadbalancer.conf với khối upstream:
upstream backend {
    least_conn;
    server 192.168.1.10:80 weight=3;
    server 192.168.1.11:80 weight=2;
    server 192.168.1.12:80 max_fails=2 fail_timeout=30s;
}
  1. Kích hoạt health check: Thêm dòng health_check interval=5 fails=3 passes=2; trong khối location để NGINX tự loại máy chủ lỗi.
  2. Cấu hình SSL và HTTP/2: Đảm bảo load balancer xử lý chứng chỉ HTTPS, giảm tải cho backend và tăng tốc độ truyền tải.
  3. Thiết lập DNS đúng cách: Trỏ tên miền về IP của load balancer (không phải IP máy chủ gốc), và bật TTL thấp (300s) để dễ cập nhật khi cần thay đổi.
  4. Test và giám sát: Dùng curl -I https://example.com kiểm tra header X-Upstream hoặc Server; theo dõi log NGINX và sử dụng công cụ như Prometheus + Grafana để đo tỷ lệ thành công, latency, và failover.

Lỗi thường gặp

1. Session không bền (Session stickiness bị mất)
→ Triệu chứng: Người dùng đăng nhập xong lại bị đăng xuất khi chuyển sang máy chủ khác.
→ Nguyên nhân: Load balancer phân phối ngẫu nhiên mà không gắn session với một máy chủ.
→ Khắc phục: Bật ip_hash (dựa trên IP người dùng) hoặc dùng sticky cookie trong NGINX Plus / ALB; hoặc chuyển session sang Redis/Database chung.

2. Health check sai cấu hình
→ Triệu chứng: Máy chủ vẫn hoạt động nhưng bị loại khỏi pool, hoặc ngược lại — máy chủ lỗi vẫn nhận traffic.
→ Nguyên nhân: Đường dẫn health check trả mã 200 dù ứng dụng crash; hoặc timeout quá ngắn gây false positive.
→ Khắc phục: Dùng endpoint riêng (ví dụ: /healthz) kiểm tra cả DB và cache; đặt fail_timeout=10s, max_fails=3 — tùy trường hợp.

3. Cookie hoặc header bị mất khi chuyển tiếp
→ Triệu chứng: Googlebot thấy trang trắng hoặc lỗi 400 do thiếu User-Agent, Accept-Encoding.
→ Nguyên nhân: NGINX không forward đầy đủ header.
→ Khắc phục: Thêm vào khối location:
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header User-Agent $http_user_agent;

Ví dụ thực tế

Một website tin tức Việt Nam (traffic trung bình 150.000 phiên/ngày, đỉnh 1,2 triệu phiên/giờ trong sự kiện bầu cử 2024) từng gặp tình trạng:
– Tỷ lệ lỗi 504 tăng 40% mỗi lần có bài nóng;
– Thời gian TTFB trung bình lên 1.200ms vào giờ cao điểm;
– Google Search Console báo “Crawl errors – Server errors” tăng đột biến.

Sau khi triển khai AWS Application Load Balancer với cấu hình:
– Thuật toán: Least outstanding requests;
– Health check: GET /health, timeout 5s, 3 lần thất bại;
– Sticky session bật cho khu vực quản trị;
– Kết hợp Cloudflare CDN và cache tĩnh ở tầng LB,
→ Kết quả sau 1 tuần:
– Tỷ lệ lỗi 5xx giảm còn 0,02%;
– TTFB trung bình giảm còn 180ms;
– Số trang được thu thập hàng ngày tăng 27%;
– 3 bài viết mới lên top 3 Google trong vòng 5 ngày.

Câu hỏi thường gặp

Load balancing có làm chậm website không?

Không — nếu cấu hình đúng. Độ trễ thêm từ load balancer thường dưới 5ms. Ngược lại, thiếu load balancing khiến một máy chủ quá tải → TTFB tăng hàng trăm ms hoặc gây lỗi hoàn toàn. Hiệu quả phụ thuộc vào vị trí đặt LB (gần người dùng hay gần backend) và tối ưu hóa kết nối (keep-alive, HTTP/2).

Có cần load balancing cho website nhỏ?

Tùy trường hợp. Nếu website dùng shared hosting hoặc VPS đơn lẻ, chưa có nhu cầu. Nhưng nếu đã dùng VPS/Vultr/DigitalOcean và có hơn 5.000 lượt truy cập/tháng, việc thêm NGINX làm load balancer (thậm chí chỉ 2 máy chủ) giúp tăng độ ổn định đáng kể — chi phí gần như bằng 0.

Cloudflare Load Balancing có thay thế được NGINX không?

Không hoàn toàn. Cloudflare LB hoạt động ở tầng DNS và HTTP (layer 4–7), tốt cho phân vùng địa lý và failover toàn cầu. Còn NGINX/HAProxy kiểm soát sâu hơn: cân bằng theo CPU, hỗ trợ sticky session chi tiết, rewrite URL, chặn bot… Thường người ta dùng cả hai: Cloudflare ở ngoài cùng (bảo mật + DNS LB), NGINX ở trong (backend LB).

Loại Load Balancer Ưu điểm Hạn chế Phù hợp với
NGINX Open Source Miễn phí, cấu hình linh hoạt, hỗ trợ đầy đủ HTTP/2, gzip, caching Không có GUI, không hỗ trợ sticky session nâng cao (cần Plus) Website vừa và nhỏ, đội dev có kỹ năng Linux
AWS ALB Tích hợp auto-scaling, giám sát CloudWatch, hỗ trợ WAF Chi phí tăng theo traffic và số rule; khó debug khi có vấn đề Ứng dụng trên AWS, cần độ tin cậy cao
Cloudflare LB Failover toàn cầu, chống DDoS, DNS-based routing Không kiểm soát được tầng application, không xử lý session Website đa quốc gia, cần bảo mật và phân vùng người dùng