Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang vận hành website bán hàng cho một chuỗi mỹ phẩm, và đúng dịp sale 12/12 có 50.000 người cùng lúc bấm vào trang khuyến mãi. Nếu tất cả lượng truy cập đó đổ dồn vào một máy chủ duy nhất, máy đó sẽ nghẽn, CPU chạm trần, và người dùng nhận về màn hình "504 Gateway Timeout". Doanh thu bay hơi trong vài phút vàng.
Load Balancer (bộ cân bằng tải) sinh ra để giải quyết chính vấn đề này. Nó đứng trước một nhóm máy chủ, nhận toàn bộ lưu lượng từ người dùng, rồi phân phối đều xuống các máy phía sau. Nhờ đó bạn có thể chạy 10, 20 hay 100 máy chủ song song, và khi một máy chết thì Load Balancer tự động ngừng gửi request tới nó — người dùng gần như không cảm nhận được sự cố.
Trong hệ sinh thái cloud, Load Balancer là một trong những thành phần nền tảng nhất. Bạn gần như không thể xây dựng một hệ thống chịu tải cao, có tính sẵn sàng (high availability) mà thiếu nó. Ba nhà cung cấp lớn đều có sản phẩm riêng: AWS có ALB, NLB, GLB; Google Cloud có Global/Regional Load Balancer; Azure có Application Gateway và Load Balancer. Bài này sẽ giúp bạn hiểu bản chất, phân biệt được Layer 4 với Layer 7, và biết chọn đúng loại cho từng bài toán thực tế.
Khái niệm cốt lõi
Bản chất của Load Balancer là một điểm vào duy nhất (single entry point) đứng giữa client và tập hợp máy chủ backend. Người dùng chỉ cần biết một địa chỉ — thường là một tên miền như api.shop.vn — còn việc request đó đi tới máy chủ nào thì Load Balancer quyết định.
Để hiểu sâu, bạn cần nắm khái niệm "tầng" (Layer) trong mô hình mạng OSI. Load Balancer hoạt động chủ yếu ở hai tầng: Layer 4 và Layer 7. Đây là ranh giới quan trọng nhất phải phân biệt.
Layer 4 — Network Load Balancer (NLB)
Layer 4 là tầng vận chuyển (transport layer), làm việc với giao thức TCP và UDP. Load Balancer ở tầng này chỉ nhìn vào thông tin ở mức gói tin: địa chỉ IP nguồn, IP đích, cổng nguồn, cổng đích. Nó không mở gói tin ra để đọc nội dung bên trong — không biết bạn đang gọi API /users hay /products, không biết header HTTP là gì, không quan tâm đó là request đăng nhập hay tải ảnh.
Vì không cần phân tích nội dung, NLB cực kỳ nhanh và có độ trễ (latency) rất thấp. Nó có thể xử lý hàng triệu request mỗi giây, chịu được những đợt tăng đột biến (spike) mà gần như không "khởi động" chậm. AWS NLB nổi tiếng vì giữ nguyên được IP gốc của client (source IP preservation) và có thể gắn một địa chỉ IP tĩnh cho mỗi vùng khả dụng.
NLB phù hợp khi: bạn cần thông lượng cực lớn, độ trễ thấp; bạn chạy giao thức không phải HTTP (ví dụ MQTT cho IoT, game server dùng UDP, database proxy); hoặc bạn cần IP tĩnh để đưa vào whitelist của đối tác.
Layer 7 — Application Load Balancer (ALB)
Layer 7 là tầng ứng dụng, nơi Load Balancer thực sự "hiểu" giao thức HTTP/HTTPS. Nó mở gói tin ra, đọc được URL path, HTTP header, cookie, query string, hostname. Nhờ đó ALB có thể ra quyết định định tuyến thông minh dựa trên nội dung request — điều mà NLB không bao giờ làm được.
Ví dụ, cùng một tên miền shop.vn, bạn có thể cấu hình:
- Request tới
/api/*chuyển sang nhóm máy chủ backend API. - Request tới
/images/*chuyển sang nhóm máy chủ phục vụ ảnh. - Request có header
Host: admin.shop.vnchuyển sang cụm quản trị riêng.
Cái giá phải trả là: vì phải phân tích nội dung, ALB có độ trễ cao hơn NLB một chút và thông lượng thấp hơn. Nhưng với 99% ứng dụng web thông thường, sự khác biệt này không đáng kể so với lợi ích về khả năng định tuyến.
GLB — Gateway Load Balancer
GLB (Gateway Load Balancer) là loại đặc biệt hơn, ra đời để phục vụ nhu cầu bảo mật. Thay vì cân bằng tải cho ứng dụng của bạn, GLB dùng để chèn (insert) các thiết bị ảo bên thứ ba vào đường đi của lưu lượng — chẳng hạn firewall, hệ thống phát hiện xâm nhập (IDS/IPS), hoặc công cụ phân tích gói tin sâu.
Nói dễ hiểu: mọi gói tin đi vào hệ thống của bạn sẽ được GLB "lái" qua một dàn thiết bị an ninh trước, kiểm tra xong mới cho đi tiếp. GLB hoạt động ở Layer 3 (tầng mạng) và dùng giao thức GENEVE để đóng gói lưu lượng. Đây là công cụ chuyên dụng cho đội security/network, không phải thứ mà một web developer bình thường phải đụng tới hằng ngày, nhưng bạn nên biết nó tồn tại để không nhầm lẫn.
Thuật toán phân phối và health check
Dù là loại nào, Load Balancer đều cần một thuật toán để quyết định gửi request tới máy nào. Phổ biến nhất:
- Round Robin: lần lượt xoay vòng qua từng máy, đơn giản và công bằng.
- Least Connections: gửi tới máy đang có ít kết nối đang mở nhất, phù hợp khi thời gian xử lý mỗi request chênh lệch nhiều.
- IP Hash: dựa trên IP client để luôn gửi cùng một người dùng tới cùng một máy (một dạng sticky session).
/healthz mỗi 10 giây) tới từng máy backend. Máy nào không trả về mã 200 trong vài lần liên tiếp sẽ bị đánh dấu "unhealthy" và tạm thời loại khỏi vòng phân phối. Khi máy hồi phục, nó tự động được đưa trở lại. Chính cơ chế này biến Load Balancer thành trụ cột của tính sẵn sàng cao.Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử chọn sai loại Load Balancer
Một startup thương mại điện tử tại TP.HCM, gọi là ShopFast, xây dựng hệ thống trên AWS. Đội kỹ thuật ban đầu dùng NLB (Layer 4) vì đọc trên diễn đàn thấy "NLB nhanh nhất". Trong 6 tháng đầu mọi thứ ổn. Nhưng khi họ muốn tách trang blog SEO (/blog/*) sang một cụm máy chủ riêng để không ảnh hưởng tới hiệu năng của trang thanh toán, họ phát hiện NLB không làm được — vì NLB không đọc được URL path, nó chỉ thấy TCP trên cổng 443.
Kết quả là họ phải dựng thêm một tầng Nginx tự quản làm reverse proxy phía sau NLB để định tuyến theo path, tốn thêm 2 tuần công sức và 2 máy chủ chỉ để làm việc mà ALB có sẵn. Bài học rút ra: chọn loại Load Balancer theo nhu cầu định tuyến, không phải theo tốc độ trên giấy. Với một web app cần định tuyến theo path/host, ALB (Layer 7) gần như luôn là lựa chọn đúng ngay từ đầu.
Ví dụ 2 — Nền tảng livestream game dùng NLB cho UDP
Một công ty game ở Đông Nam Á vận hành server cho game bắn súng nhiều người chơi. Lưu lượng game realtime dùng giao thức UDP, đòi hỏi độ trễ dưới 50ms và giữ được IP gốc của người chơi để chống gian lận theo vị trí địa lý. Ở đây ALB hoàn toàn không dùng được — vì ALB chỉ nói HTTP.
Họ chọn NLB (Layer 4) và đây là quyết định chính xác. NLB xử lý được UDP, giữ nguyên source IP để hệ thống anti-cheat phân tích, và có latency cực thấp cho trải nghiệm mượt. Trong đợt giải đấu có 30.000 người chơi đồng thời, NLB phân phối tải qua 40 game server mà độ trễ vẫn ổn định. Bài học: với giao thức không phải HTTP và yêu cầu độ trễ khắc nghiệt, Layer 4 là lựa chọn bắt buộc.
Ví dụ 3 — Ngân hàng số chèn firewall bằng Gateway Load Balancer
Một ngân hàng số tại Việt Nam cần đáp ứng yêu cầu bảo mật của Ngân hàng Nhà nước: mọi lưu lượng ra vào phải đi qua một tường lửa thế hệ mới (NGFW) để kiểm tra. Nếu tự cấu hình từng máy chủ trỏ qua firewall thì cực kỳ rối và dễ sót.
Đội security dùng Gateway Load Balancer để tập trung hóa. GLB "lái" toàn bộ lưu lượng qua một cụm firewall ảo trước khi cho vào các máy chủ ứng dụng. Khi cần scale firewall, họ chỉ việc thêm máy vào cụm phía sau GLB mà không phải sửa cấu hình mạng của từng ứng dụng. Bài học: GLB là công cụ để chèn dịch vụ an ninh một cách minh bạch và có thể mở rộng, đặc biệt hữu ích trong môi trường tuân thủ (compliance) chặt chẽ như ngân hàng.
Hướng dẫn từng bước
Dưới đây là quy trình chung để dựng một Application Load Balancer (Layer 7) trên AWS cho một web app — mô hình phổ biến nhất bạn sẽ gặp trong thực tế.
- Chuẩn bị backend: Tạo ít nhất 2 máy EC2 (hoặc container/task) đặt ở 2 vùng khả dụng (Availability Zone) khác nhau, ví dụ
ap-southeast-1avàap-southeast-1b. Đây là điều kiện để có tính sẵn sàng cao — mất một AZ vẫn còn AZ kia.
- Tạo Target Group: Đây là nhóm đích chứa các máy backend. Bạn khai báo cổng (ví dụ 8080), giao thức (HTTP), và quan trọng nhất là cấu hình health check: đường dẫn
/healthz, ngưỡng healthy sau 3 lần thành công, unhealthy sau 2 lần thất bại, chu kỳ 15 giây.
- Đăng ký máy chủ vào Target Group: Gắn các máy EC2 vào nhóm đích vừa tạo.
- Tạo Load Balancer: Chọn loại Application Load Balancer, đặt nó ở các subnet public thuộc 2 AZ, gắn Security Group cho phép cổng 80 và 443 từ internet.
- Cấu hình Listener và Routing Rules: Tạo listener trên cổng 443 (HTTPS), gắn chứng chỉ SSL. Thêm rule định tuyến: request tới
/api/*chuyển sang Target Group API, mặc định còn lại chuyển sang Target Group web.
- Trỏ DNS: Tạo bản ghi trong Route 53 (hoặc DNS provider của bạn) trỏ tên miền
shop.vntới địa chỉ của Load Balancer bằng bản ghi ALIAS/CNAME.
- Kiểm thử: Truy cập tên miền, tắt thử một máy backend và quan sát — Load Balancer phải tự động ngừng gửi request tới máy đó mà người dùng không thấy lỗi.
Lỗi thường gặp & mẹo
Quên cấu hình health check hoặc để đường dẫn health check quá "nặng". Nếu /healthz của bạn thực hiện query database phức tạp, nó có thể fail khi DB chậm, khiến Load Balancer loại nhầm máy chủ khỏe. Mẹo: giữ health check nhẹ, chỉ kiểm tra máy còn sống, tách riêng khỏi kiểm tra dependency sâu.
Nhầm lẫn giữa health check "shallow" và "deep". Đôi khi máy chủ trả 200 cho /healthz nhưng thực chất kết nối tới database đã hỏng. Với dịch vụ quan trọng, hãy cân nhắc health check kiểm tra được cả dependency thiết yếu — nhưng đừng lạm dụng kẻo gây loại máy hàng loạt (cascading failure) khi DB có sự cố nhỏ.
Bỏ qua bài toán sticky session. Nếu ứng dụng lưu session trong bộ nhớ máy chủ, người dùng bị Load Balancer đẩy sang máy khác sẽ mất đăng nhập. Mẹo tốt nhất: thiết kế ứng dụng stateless, lưu session ở nơi tập trung như Redis, để Load Balancer tự do phân phối. Sticky session chỉ nên là giải pháp tạm.
Chọn NLB rồi lại cần định tuyến theo path. Như ví dụ ShopFast — hãy xác định rõ nhu cầu định tuyến trước khi chọn. Quy tắc nhanh: cần đọc URL/header thì dùng Layer 7 (ALB); cần tốc độ tối đa hoặc giao thức không phải HTTP thì dùng Layer 4 (NLB).
Đặt Load Balancer chỉ trong một AZ. Điều này triệt tiêu mục đích high availability. Luôn trải Load Balancer và backend qua tối thiểu 2 AZ.
Quên giới hạn timeout. ALB có idle timeout mặc định (thường 60 giây). Nếu ứng dụng có request chạy lâu (upload file lớn, xử lý báo cáo), request có thể bị cắt giữa chừng. Điều chỉnh idle timeout cho phù hợp.
Bài tập thực hành
- Phân loại tình huống: Với mỗi trường hợp sau, hãy quyết định nên dùng Layer 4 (NLB) hay Layer 7 (ALB) và giải thích: (a) một API REST cần tách route
/v1và/v2sang hai cụm khác nhau; (b) một broker MQTT cho 100.000 thiết bị IoT; (c) một web app cần giải mã HTTPS tại tầng cân bằng tải.
- Thiết kế health check: Viết mô tả cho một endpoint
/healthzcủa dịch vụ đặt hàng. Xác định: nó nên kiểm tra những gì, không nên kiểm tra những gì, chu kỳ và ngưỡng bao nhiêu là hợp lý. Giải thích lý do.
- Dựng thử (nếu có tài khoản cloud): Trên AWS Free Tier hoặc GCP, tạo 2 máy chủ nhỏ chạy một trang web đơn giản hiển thị hostname của chính nó, đặt sau một ALB. Truy cập nhiều lần và quan sát hostname thay đổi — đó là bằng chứng Load Balancer đang phân phối tải. Sau đó tắt một máy và xác nhận traffic tự chuyển hết sang máy còn lại.
- Phân tích sự cố: Một hệ thống có ALB nhưng người dùng thỉnh thoảng bị đăng xuất ngẫu nhiên. Hãy đưa ra ít nhất 2 giả thuyết nguyên nhân và cách khắc phục tương ứng.
Tóm tắt
Load Balancer là thành phần nền tảng giúp phân phối lưu lượng qua nhiều máy chủ, đảm bảo hệ thống chịu tải cao và có tính sẵn sàng. Điều quan trọng nhất cần nhớ là sự phân biệt giữa hai tầng: Layer 4 (NLB) làm việc với TCP/UDP, cực nhanh, độ trễ thấp, không đọc nội dung — phù hợp cho thông lượng lớn và giao thức không phải HTTP; còn Layer 7 (ALB) hiểu HTTP, đọc được URL/header/cookie nên định tuyến thông minh theo nội dung và kết thúc SSL — lựa chọn mặc định cho hầu hết web app. GLB là loại chuyên dụng để chèn thiết bị an ninh vào đường đi của lưu lượng.
Dù chọn loại nào, hai cơ chế không thể thiếu là thuật toán phân phối và health check — chính health check biến Load Balancer thành người gác cổng tự động loại bỏ máy hỏng. Khi thiết kế, hãy ưu tiên ứng dụng stateless, trải hệ thống qua nhiều vùng khả dụng, và chọn tầng Load Balancer đúng với nhu cầu định tuyến ngay từ đầu để tránh phải làm lại như câu chuyện ShopFast. Nắm vững bài này, bạn đã có một mảnh ghép cốt lõi để xây dựng những kiến trúc cloud thực sự vững vàng.