Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA của một sàn thương mại điện tử Việt Nam. Bình thường hệ thống chạy êm ru, mỗi giây vài trăm người dùng. Rồi tới 0h ngày 11/11 — sự kiện Double 11. Trong vòng 60 giây đầu tiên, lượng truy cập nhảy vọt lên gấp 40 lần. Một server đơn lẻ, dù mạnh tới đâu, cũng sẽ "gục" như một chiếc xe máy chở 10 người. Khi nó sập, toàn bộ sàn ngừng hoạt động, mỗi phút downtime là hàng trăm triệu đồng doanh thu bốc hơi và hàng nghìn khách hàng bực bội.
Câu hỏi đặt ra: làm sao để một hệ thống phục vụ được lượng người dùng khổng lồ, lại vừa không "chết" khi một máy chủ gặp sự cố? Câu trả lời nằm ở một thành phần hạ tầng mà bạn sẽ gặp đi gặp lại trong mọi tài liệu kiến trúc: Load Balancer (bộ cân bằng tải).
Là một BA, bạn không cần tự tay cấu hình load balancer — đó là việc của DevOps. Nhưng bạn bắt buộc phải hiểu nó làm gì, vì nó ảnh hưởng trực tiếp tới những yêu cầu phi chức năng (non-functional requirements) mà bạn viết: tính sẵn sàng (availability), khả năng mở rộng (scalability), và trải nghiệm khi triển khai (zero-downtime deployment). Khi đối tác hỏi "Hệ thống chịu được bao nhiêu người dùng đồng thời?" hay "Bảo trì có làm gián đoạn dịch vụ không?", load balancer chính là mảnh ghép giúp bạn trả lời tự tin. Bài này sẽ trang bị cho bạn cách tư duy đó.
Khái niệm cốt lõi
Load balancer là gì?
Load balancer là một thành phần đứng trước nhóm máy chủ ứng dụng của bạn, đóng vai trò "người điều phối giao thông". Mọi request từ người dùng (qua trình duyệt, app mobile, hay hệ thống khác gọi API) đều đi vào load balancer trước, rồi nó quyết định gửi request đó tới máy chủ nào trong nhóm để xử lý.
Hãy hình dung load balancer giống như nhân viên xếp hàng ở sân bay Tân Sơn Nhất. Thay vì để hành khách tự chọn quầy (dẫn tới quầy thì kẹt cứng, quầy thì trống), nhân viên đứng đầu hàng sẽ điều phối: "Anh qua quầy 3, chị qua quầy 7". Nhờ vậy tải được dàn đều, không quầy nào quá tải.
Về mặt kỹ thuật, người dùng chỉ biết đến một địa chỉ duy nhất — ví dụ api.tiki.vn. Họ không hề biết đằng sau đó là 1 hay 50 máy chủ. Load balancer che giấu toàn bộ sự phức tạp này.
Ba lý do cốt lõi vì sao cần load balancer
1. Phân tải (distribute traffic). Một server có giới hạn về CPU, RAM, số kết nối đồng thời. Khi vượt ngưỡng, nó phản hồi chậm rồi sập. Bằng cách chạy nhiều server giống hệt nhau (gọi là horizontal scaling — mở rộng theo chiều ngang) và đặt load balancer phía trước, bạn có thể chia 100.000 request cho 10 máy, mỗi máy chỉ gánh 10.000 — vừa sức.
2. Tính sẵn sàng cao (high availability). Server có thể chết bất cứ lúc nào: lỗi phần cứng, hết RAM, deploy lỗi. Load balancer liên tục "khám sức khỏe" từng server (health check). Nếu phát hiện một máy không phản hồi, nó tự động ngừng gửi request tới máy đó và dồn sang các máy còn khỏe. Người dùng gần như không nhận ra có sự cố.
3. Bảo trì không gián đoạn (zero-downtime maintenance). Khi cần nâng cấp phần mềm, bạn không tắt cả hệ thống. Thay vào đó, bạn rút từng server ra khỏi load balancer, cập nhật, kiểm tra, rồi đưa lại vào. Cứ thế lần lượt từng máy. Người dùng vẫn được phục vụ liên tục bởi các máy còn lại.
Health check — trái tim của khả năng tự phục hồi
Health check là cơ chế load balancer định kỳ gửi một request kiểm tra tới mỗi server, thường tới một endpoint chuyên dụng như GET /health. Server khỏe sẽ trả về 200 OK. Nếu một server không trả lời sau vài lần thử (ví dụ 3 lần liên tiếp trong 30 giây), load balancer đánh dấu nó là "unhealthy" và loại khỏi danh sách nhận traffic. Khi server hồi phục và trả 200 trở lại, nó được tự động đưa vào lại.
Là BA, khi viết spec cho một API mới, bạn nên nhắc đội phát triển: "Cần có endpoint health check trả về trạng thái thực sự của dịch vụ (cả kết nối database) chứ không chỉ trả 200 cứng." Đây là một chi tiết nhỏ nhưng cực kỳ quan trọng.
Các thuật toán phân phối phổ biến
Load balancer dùng "thuật toán" để quyết định gửi request tới máy nào. Bạn không cần thuộc lòng cách cài đặt, nhưng nên hiểu ý nghĩa để trao đổi với kỹ thuật:
- Round Robin (luân phiên): gửi request lần lượt máy 1, máy 2, máy 3, rồi quay lại máy 1. Đơn giản, công bằng khi các máy mạnh ngang nhau.
- Least Connections (ít kết nối nhất): gửi request tới máy đang xử lý ít kết nối nhất. Tốt khi các request có thời gian xử lý chênh lệch nhiều.
- Weighted (có trọng số): máy mạnh hơn nhận tỷ lệ request cao hơn. Ví dụ máy 16 nhân (core) nhận gấp đôi máy 8 nhân.
- IP Hash: dựa trên địa chỉ IP của người dùng để luôn gửi họ tới cùng một máy. Hữu ích khi cần "session stickiness" (xem phần lỗi thường gặp).
Lớp 4 và lớp 7 — một phân biệt BA nên biết
Bạn sẽ nghe DevOps nói về "L4 load balancer" và "L7 load balancer":
- Layer 4 (L4): cân bằng dựa trên thông tin mạng cơ bản (IP và cổng - port). Nhanh, nhẹ, nhưng "mù" — không hiểu nội dung request.
- Layer 7 (L7): hiểu được nội dung HTTP (đường dẫn URL, header, cookie). Nhờ vậy nó làm được việc thông minh hơn, ví dụ: request tới
/api/paymentthì gửi sang nhóm server thanh toán, request/api/searchthì gửi sang nhóm tìm kiếm. Đây gọi là content-based routing.
Tình huống thực tế
Tình huống 1: Sàn TMĐT chống chọi ngày sale 12/12
Một sàn TMĐT Việt Nam (gọi là ShopViet) bình thường chạy 4 server ứng dụng phía sau một load balancer, mỗi server xử lý khoảng 500 request/giây — tổng 2.000 request/giây, dư sức cho ngày thường.
Trước sự kiện 12/12, đội DevOps dự báo lưu lượng tăng 20 lần, lên ~40.000 request/giây. Họ cấu hình auto-scaling: load balancer kết hợp với hệ thống tự động tăng số server từ 4 lên 80 khi traffic tăng. Khi sự kiện kết thúc lúc 2h sáng, hệ thống tự thu nhỏ về 4 server để tiết kiệm chi phí.
Diễn giải: load balancer là điều kiện tiên quyết để auto-scaling hoạt động. Khi server mới được khởi tạo, nó tự đăng ký vào load balancer; khi bị thu hồi, load balancer ngừng gửi traffic trước khi tắt máy (gọi là connection draining — chờ các request đang dở hoàn tất rồi mới ngắt). Nếu không có load balancer, việc thêm/bớt server động như vậy là bất khả thi.
Bài học rút ra: khi BA viết yêu cầu phi chức năng cho sự kiện cao điểm, đừng chỉ ghi "hệ thống phải chịu được tải cao". Hãy cụ thể: "Hệ thống phải tự mở rộng để xử lý đỉnh 40.000 request/giây và tự thu nhỏ sau sự kiện." Con số cụ thể giúp DevOps cấu hình ngưỡng auto-scaling chính xác.
Tình huống 2: Một server chết lúc 3h sáng mà không ai phải dậy
Một fintech ở Singapore vận hành API cho ví điện tử, chạy 6 server qua một load balancer. Lúc 3h12 sáng, server số 3 gặp lỗi rò rỉ bộ nhớ (memory leak) và treo cứng, ngừng phản hồi.
Health check của load balancer phát hiện server 3 không trả 200 OK sau 3 lần thử trong 15 giây. Nó lập tức loại server 3 khỏi danh sách. Toàn bộ traffic được chia lại cho 5 server còn lại. Người dùng vẫn nạp tiền, chuyển khoản bình thường — không một ai nhận thấy sự cố. Sáng hôm sau đội kỹ thuật mới khởi động lại server 3 trong giờ hành chính, thong thả.
Diễn giải: đây chính là giá trị "high availability". Nếu chỉ có một server, sự cố lúc 3h sáng sẽ thành cuộc khủng hoảng: hệ thống sập, khách hàng không chuyển được tiền, đội trực phải bật dậy xử lý khẩn. Với load balancer và nhiều server, một máy chết chỉ là chuyện nhỏ — gọi là graceful degradation (suy giảm có kiểm soát) thay vì sập hoàn toàn.
Bài học rút ra: trong SLA (cam kết mức dịch vụ) bạn ký với khách hàng — ví dụ "99,95% uptime" — con số đó chỉ khả thi khi kiến trúc loại bỏ single point of failure (điểm hỏng đơn lẻ). Một server đơn không bao giờ đạt được 99,95%. BA cần đảm bảo yêu cầu uptime được phản ánh đúng trong thiết kế hạ tầng.
Tình huống 3: Triển khai phiên bản mới giữa ban ngày mà không downtime
Một công ty SaaS quản lý nhân sự phục vụ 200 doanh nghiệp tại Việt Nam. Trước đây, mỗi lần cập nhật phần mềm, họ phải gửi email "Hệ thống bảo trì từ 22h–23h, mong quý khách thông cảm". Khách hàng khó chịu vì có những doanh nghiệp làm ca đêm.
Sau khi áp dụng load balancer với 8 server, họ chuyển sang rolling deployment: cập nhật lần lượt từng server. Quy trình: rút server 1 khỏi load balancer → chờ connection draining → deploy phiên bản mới → chạy health check → đưa lại vào → chuyển sang server 2. Cứ thế cho đến hết. Trong suốt quá trình, luôn có ít nhất 7 server phục vụ. Người dùng không hề biết hệ thống vừa được cập nhật.
Diễn giải: load balancer biến việc deploy từ "sự kiện căng thẳng phải làm ban đêm" thành "hoạt động thường ngày làm giữa giờ hành chính". Nó cũng mở đường cho các kỹ thuật nâng cao như blue-green hay canary deployment (sẽ học ở bài khác).
Bài học rút ra: khi BA thu thập yêu cầu, hãy hỏi stakeholder về kỳ vọng cập nhật: "Việc bảo trì có được phép gây gián đoạn không?". Nếu câu trả lời là "không", bạn đã có lý do nghiệp vụ rõ ràng để yêu cầu kiến trúc nhiều server có load balancer — và bạn biết cách giải thích vì sao chi phí hạ tầng cao hơn lại đáng giá.
Hướng dẫn từng bước
Đây là cách một BA tiếp cận và làm việc với khái niệm load balancer trong dự án thực tế:
Bước 1 — Xác định yêu cầu phi chức năng liên quan. Khi phỏng vấn stakeholder, hãy hỏi rõ về ba trục: (a) Số người dùng đồng thời tối đa dự kiến? (b) Mức uptime cam kết là bao nhiêu? (c) Việc bảo trì có được phép gây downtime không? Ghi lại bằng con số cụ thể.
Bước 2 — Đọc hiểu sơ đồ kiến trúc. Khi nhận sơ đồ từ kiến trúc sư, tìm khối hình chữ nhật thường ghi "LB" hoặc "Load Balancer" đứng trước nhóm server. Xác nhận: traffic người dùng vào đâu đầu tiên? Có bao nhiêu server phía sau? Có điểm hỏng đơn lẻ nào không (ví dụ chỉ một database duy nhất)?
Bước 3 — Đặt câu hỏi về health check. Hỏi đội kỹ thuật: "Health check kiểm tra những gì? Chỉ kiểm tra server còn sống, hay kiểm tra cả kết nối tới database?" Một health check tốt phải phản ánh khả năng phục vụ thực sự.
Bước 4 — Làm rõ chiến lược triển khai. Xác nhận với DevOps cách deploy: rolling, blue-green, hay canary? Điều này ảnh hưởng tới việc bạn truyền đạt với khách hàng về lịch cập nhật.
Bước 5 — Phản ánh vào tài liệu. Viết các yêu cầu phi chức năng đo lường được. Ví dụ: "Hệ thống đạt 99,9% uptime, tự mở rộng tới 30.000 request/giây vào giờ cao điểm, và mọi cập nhật phần mềm phải thực hiện không gián đoạn dịch vụ."
Lỗi thường gặp & mẹo
Lỗi 1: Quên session stickiness. Nếu ứng dụng lưu trạng thái đăng nhập trong bộ nhớ của một server cụ thể, người dùng sẽ bị đăng xuất khi load balancer chuyển request của họ sang server khác. Cách xử lý đúng là làm cho server "stateless" (không lưu trạng thái cục bộ) — đẩy session ra một nơi dùng chung như Redis. Mẹo cho BA: khi viết yêu cầu, hãy ghi rõ "phiên đăng nhập phải hoạt động liên tục dù request được phục vụ bởi bất kỳ server nào".
Lỗi 2: Tưởng load balancer giải quyết được mọi nút thắt. Load balancer chỉ phân tải tầng ứng dụng. Nếu tất cả server đều dùng chung một database và database mới là chỗ nghẽn, thêm bao nhiêu server cũng vô ích. Hãy luôn hỏi: "Đâu là single point of failure còn lại trong hệ thống?"
Lỗi 3: Bản thân load balancer trở thành điểm hỏng đơn lẻ. Nếu chỉ có một load balancer, nó chết thì cả hệ thống chết. Hệ thống production thực thụ luôn chạy load balancer ở chế độ dự phòng (HA pair — một cặp active/standby). Mẹo: khi review kiến trúc, hỏi "Nếu load balancer này chết thì sao?"
Lỗi 4: Health check quá hời hợt. Một health check chỉ trả 200 cứng mà không kiểm tra gì sẽ khiến load balancer tiếp tục gửi traffic tới server đã hỏng ngầm bên trong (ví dụ mất kết nối database). Hãy yêu cầu health check phản ánh trạng thái thực.
Mẹo bổ sung: đừng nhầm load balancer với CDN hay API Gateway. CDN phân phối nội dung tĩnh ở rìa mạng; API Gateway xử lý xác thực, rate limiting, định tuyến API. Chúng có thể đứng cùng nhau trong một kiến trúc nhưng vai trò khác nhau — bạn sẽ học riêng ở các bài sau.
Bài tập thực hành
- Vẽ sơ đồ: Hãy vẽ kiến trúc đơn giản cho một app đặt món ăn có 3 server ứng dụng phía sau một load balancer. Đánh dấu đường đi của một request từ điện thoại người dùng. Sau đó, chỉ ra single point of failure còn lại trong sơ đồ của bạn.
- Viết yêu cầu phi chức năng: Cho tình huống một ngân hàng số ra mắt tính năng mới, dự kiến 50.000 người dùng đăng ký trong tuần đầu, cam kết uptime 99,95%. Hãy viết 3 yêu cầu phi chức năng cụ thể, đo lường được, liên quan đến phân tải và tính sẵn sàng.
- Tình huống xử lý sự cố: Một server trong nhóm 5 server bị treo lúc cao điểm nhưng load balancer vẫn gửi request tới nó, khiến nhiều người dùng gặp lỗi. Theo bạn, nguyên nhân kỹ thuật khả dĩ nhất là gì, và bạn sẽ đặt câu hỏi gì cho đội DevOps?
- So sánh: Giải thích bằng lời của bạn sự khác nhau giữa L4 và L7 load balancer, và cho một ví dụ tình huống mà L7 hữu ích còn L4 thì không.
Tóm tắt
Load balancer là "người điều phối giao thông" đứng trước nhóm máy chủ, ẩn sau một địa chỉ duy nhất mà người dùng nhìn thấy. Nó tồn tại để giải quyết ba bài toán cốt lõi: phân tải giữa nhiều server để chịu được lưu lượng lớn, tính sẵn sàng cao bằng cách tự loại bỏ server hỏng nhờ health check, và bảo trì không gián đoạn thông qua rolling deployment.
Những điểm BA cần nhớ: load balancer là điều kiện tiên quyết cho horizontal scaling và auto-scaling; health check phải phản ánh trạng thái thực của dịch vụ; server nên stateless để tránh lỗi session; và bản thân load balancer cũng cần dự phòng để không trở thành điểm hỏng đơn lẻ. Phân biệt L4 (nhanh, dựa IP/port) với L7 (thông minh, hiểu nội dung HTTP) giúp bạn trao đổi chính xác với đội kỹ thuật.
Quan trọng nhất, là BA, bạn không cấu hình load balancer — nhưng bạn định hình các yêu cầu phi chức năng buộc kiến trúc phải dùng nó. Khi bạn viết "99,95% uptime, không downtime khi bảo trì, chịu đỉnh 40.000 request/giây", bạn đang gián tiếp yêu cầu một thiết kế có load balancer. Hiểu rõ thành phần này giúp bạn nói cùng ngôn ngữ với đội kỹ thuật và bảo vệ trải nghiệm của người dùng cuối.