Cân bằng tải (Load Balancing) và phân phối lưu lượng L4/L7

1. Tổng quan

Cân bằng tải (Load Balancing) là công nghệ đồng thời là nguyên tắc kiến trúc phân phối có quy tắc các yêu cầu của nhiều máy khách tới nhiều máy chủ (hoặc tài nguyên xử lý), nhằm ngăn tải tập trung vào một tài nguyên cụ thể và bảo đảm tính sẵn sàng, khả năng mở rộng và hiệu năng phản hồi.

Kiến trúc dùng một máy chủ duy nhất để xử lý mọi yêu cầu gặp phải ba giới hạn. Thứ nhất, giới hạn trên của năng lực xử lý là rõ ràng, nên khi lưu lượng tăng sẽ phát sinh độ trễ phản hồi và timeout. Thứ hai, khi máy chủ đó gặp sự cố, toàn bộ dịch vụ ngừng hoạt động — nó trở thành điểm lỗi đơn (SPOF, Single Point of Failure). Thứ ba, khó triển khai và vá lỗi không gián đoạn, nên khi bảo trì phải dừng dịch vụ. Cân bằng tải gom các máy chủ đảm nhận cùng vai trò thành một dịch vụ logic và đặt một tầng chia lưu lượng phía trước, qua đó giảm nhẹ đồng thời cả ba vấn đề này.

Bối cảnh khiến cân bằng tải trở nên cần thiết là sự thay đổi của mô hình lưu lượng. Các tình huống yêu cầu tăng đột biến (Spike) hàng chục lần trong khoảnh khắc như sự kiện giảm giá của thương mại điện tử, thời điểm mở tiếp nhận của hệ thống đặt chỗ công, hay phát hành nội dung mới của dịch vụ streaming đã trở nên thường nhật. Ví dụ, các trang đặt vé lớn tại Hàn Quốc nhận lưu lượng gấp 30~50 lần bình thường trong vài phút ngay sau khi mở bán vé, điều mà một máy chủ đơn lẻ về mặt vật lý không thể gánh nổi. Ngoài ra, khi đám mây và tự động mở rộng (autoscaling) trở nên phổ biến, trong môi trường số lượng máy chủ thay đổi theo thời gian thực, việc phân phối thông minh chỉ gửi lưu lượng “tới những máy chủ đang sống” đã trở thành yếu tố bắt buộc.

Cân bằng tải không đơn giản là “chia đều các yêu cầu”. Cần hiểu nó là một hệ thống quản lý lưu lượng tổng hợp bao gồm kiểm tra tình trạng (Health Check) để nhận diện máy chủ còn sống, duy trì phiên (Session Persistence) để gửi các yêu cầu của cùng một người dùng tới cùng một máy chủ, lựa chọn thuật toán phân phối phù hợp với đặc tính lưu lượng, cho đến phân phối giữa các trung tâm dữ liệu phân tán về địa lý (GSLB).

A. Giá trị cốt lõi mà cân bằng tải mang lại

Hiệu quả của cân bằng tải được tóm tắt bằng ba thuộc tính chất lượng. Thứ nhất là tính sẵn sàng (Availability). Vì nhiều máy chủ cung cấp cùng một dịch vụ, khi một số máy chết thì các máy còn lại hấp thụ lưu lượng, và kiểm tra tình trạng tự động cô lập máy chủ lỗi. Nhờ đó điểm lỗi đơn bị loại bỏ, và có thể triển khai không gián đoạn, cập nhật cuốn chiếu (rolling update).

Thứ hai là khả năng mở rộng (Scalability). Khi yêu cầu tăng, chỉ cần mở rộng ngang (scale-out) máy chủ và thêm vào pool, bộ cân bằng tải sẽ chuyển lưu lượng tới máy chủ mới. Khác với mở rộng dọc (thay bằng máy chủ lớn hơn), không có giới hạn trên về vật lý, và khi kết hợp với autoscaling thì dung lượng được điều chỉnh tự động tỷ lệ với lưu lượng.

Thứ ba là hiệu năng (Performance). Khi phân tán tải, thông lượng trên mỗi máy chủ giảm xuống nên độ trễ phản hồi và thời gian chờ hàng đợi giảm, và phân phối theo vị trí (GSLB) gán máy chủ gần người dùng giúp rút ngắn cả độ trễ khứ hồi mạng. Ba giá trị này bổ trợ cho nhau, nên cân bằng tải ngày nay đã trở thành thành phần gần như bắt buộc của kiến trúc dịch vụ quy mô lớn.

2. Cấu trúc tổng thể và luồng xử lý của cân bằng tải

Hệ thống cân bằng tải gồm máy khách, bộ cân bằng tải (Load Balancer), pool máy chủ (Server Pool), mô-đun kiểm tra tình trạng, và kho lưu phiên/chính sách. Bộ cân bằng tải phơi ra cho máy khách một IP ảo (VIP, Virtual IP) và cổng dịch vụ, còn bên trong thì chuyển tiếp yêu cầu tới nhiều máy chủ thực (Real Server).

flowchart LR
    CL["Yêu cầu máy khách"] --> VIP["Bộ cân bằng tải (VIP)"]
    VIP --> ALG["Thuật toán phân phối<br/>+ Phán định duy trì phiên"]
    HC["Kiểm tra tình trạng (Health Check)"] -. Danh sách máy chủ còn sống .-> ALG
    ALG --> S1["Máy chủ 1"]
    ALG --> S2["Máy chủ 2"]
    ALG --> S3["Máy chủ 3"]
    S1 & S2 & S3 -. Trạng thái phản hồi .-> HC

Điểm cốt lõi trong hình trên là hai vòng điều khiển chạy đồng thời. Một là đường phân phối đi từ yêu cầu → thuật toán → máy chủ, và hai là đường giám sát trong đó kiểm tra tình trạng định kỳ xác nhận máy chủ còn sống hay không và phản ánh vào thuật toán. Nếu không có đường giám sát, yêu cầu vẫn tiếp tục chảy tới máy chủ đã chết khiến lỗi lan rộng. Trong thực tế, người ta điều chỉnh chu kỳ kiểm tra (ví dụ 5 giây) và ngưỡng thất bại (ví dụ cô lập khi thất bại 3 lần liên tiếp) để cân bằng giữa việc nhanh chóng loại máy chủ lỗi và tránh phát hiện nhầm (false positive) máy chủ bình thường do chậm trễ nhất thời.

A. Nguyên lý và các tầng của kiểm tra tình trạng (Health Check)

Kiểm tra tình trạng là căn cứ để phán đoán “có thể gửi lưu lượng tới máy chủ này không”. Cách đơn giản nhất là dùng ICMP Ping ở tầng L3 để chỉ xác nhận kết nối mạng của máy chủ, nhưng cách này không lọc được trường hợp OS vẫn sống nhưng ứng dụng đã dừng (ví dụ tiến trình web server vẫn chạy nhưng pool kết nối DB đã cạn).

Do đó trong thực tế người ta nâng tầng kiểm tra lên. Kiểm tra L4 xác nhận TCP 3-way handshake diễn ra bình thường để chứng minh cổng đang mở. Kiểm tra L7 gửi yêu cầu HTTP thực (ví dụ GET /healthz) và xác nhận cả phản hồi 200 lẫn một chuỗi nội dung cụ thể, nên có thể phán định cả tính bình thường về mặt logic của ứng dụng. Các dịch vụ trưởng thành hiện thực kiểm tra chuyên sâu (Deep Health Check) trong đó endpoint /healthz kiểm tra cả kết nối DB, bộ đệm và API bên ngoài rồi trả về kết quả tổng hợp.

Tuy nhiên kiểm tra chuyên sâu là con dao hai lưỡi. Nếu health check kiểm tra cả DB, khi DB tạm thời chậm đi, mọi máy chủ có thể đồng thời bị phán định “bất thường” và toàn bộ pool máy chủ bị loại ra — gây lỗi dây chuyền (cascading failure). Để ngăn điều này, nên tách kiểm tra nông (tiến trình còn sống) và kiểm tra sâu (trạng thái phụ thuộc), và thiết kế sao cho khi phụ thuộc gặp sự cố thì vẫn tiếp tục nhận lưu lượng nhưng hoạt động ở chế độ suy giảm hiệu năng.

B. Duy trì phiên (Session Persistence, Sticky Session)

HTTP vốn phi trạng thái (stateless), nhưng khi lưu trạng thái người dùng trong bộ nhớ máy chủ như trạng thái đăng nhập hay giỏ hàng, nếu các yêu cầu tiếp theo của cùng người dùng đi tới máy chủ khác thì trạng thái sẽ mất. Cơ chế ngăn điều này là duy trì phiên.

Các phương thức duy trì phiên gồm dựa trên IP nguồn (Source IP Hash), dựa trên cookie (bộ cân bằng tải chèn cookie định danh máy chủ) v.v. Phương thức dựa trên IP dễ hiện thực nhưng khi nhiều người dùng nằm sau cùng một NAT/proxy thì bị dồn về một máy chủ. Phương thức dựa trên cookie có thể cố định chính xác theo từng người dùng nên được dùng rộng rãi trong dịch vụ web.

Tuy nhiên, dưới góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), nhận thức quan trọng hơn là “duy trì phiên xung đột với khả năng mở rộng”. Khi người dùng bị cố định vào một máy chủ cụ thể thì chỉ máy chủ đó bị quá tải, và dù có autoscale tăng máy chủ thì người dùng hiện có cũng không được chuyển sang. Vì vậy kiến trúc hiện đại theo chuẩn mực là tách phiên khỏi bộ nhớ máy chủ, chuyển sang kho phiên bên ngoài như Redis hoặc token phi trạng thái như JWT (ngoại hóa phiên, Session Externalization), và thiết kế để bộ cân bằng tải tập trung vào phân phối thuần túy mà không cần duy trì phiên.

C. Các hình thức hiện thực cân bằng tải

Cân bằng tải được chia thành dạng phần cứng, dạng phần mềm và dạng DNS theo phương thức hiện thực. Dạng phần cứng dùng thiết bị chuyên dụng (dựa trên ASIC), cho xử lý siêu tốc và ổn định nhưng chi phí đầu tư lớn và việc mở rộng bị ràng buộc vào thiết bị vật lý. Dạng phần mềm như NGINX, HAProxy, Envoy chạy trên máy chủ đa dụng, linh hoạt, rẻ và có thể quản lý cấu hình bằng mã (IaC), nên trở thành dòng chính của thời đại đám mây.

Dạng DNS là phương thức đơn giản nhất, luân phiên trả về nhiều IP cho truy vấn tên miền. Có thể phân tán diện rộng mà không cần thiết bị riêng, nhưng do bộ đệm DNS của máy khách và resolver nên thay đổi trạng thái máy chủ không được phản ánh ngay và khó nhận biết tải một cách chi tiết. Vì vậy cấu hình phân tầng phổ biến là dùng dạng DNS làm cửa ngõ bậc 1 của GSLB, còn việc phân phối tinh vi thực tế do bộ cân bằng tải L4/L7 phía sau đảm nhận.

3. So sánh cân bằng tải L4 và cân bằng tải L7

Cân bằng tải được phân chia lớn thành phương thức L4 (tầng giao vận) và phương thức L7 (tầng ứng dụng) tùy theo việc dựa vào thông tin ở tầng OSI nào để chia lưu lượng. Sự phân biệt này là điểm cốt lõi được ra đề thường xuyên nhất trong kỳ thi.

flowchart TB
    REQ["Gói yêu cầu đến"] --> Q{"Tầng căn cứ phân phối"}
    Q -->|"IP + Port(TCP/UDP)"| L4["Cân bằng tải L4<br/>Chỉ kiểm tra header gói"]
    Q -->|"URL·Header·Cookie(HTTP)"| L7["Cân bằng tải L7<br/>Diễn giải nội dung thông điệp"]
    L4 --> L4R["Tốc độ cao·Độ trễ thấp<br/>Không định tuyến theo nội dung"]
    L7 --> L7R["Định tuyến theo nội dung<br/>Kết thúc SSL·Bộ đệm·Liên kết WAF"]

Cân bằng tải L4 quyết định máy chủ chỉ dựa trên địa chỉ IP và số cổng TCP/UDP. Vì không diễn giải payload (nội dung) của gói tin nên gánh nặng xử lý nhỏ, độ trễ thấp, và có thể xử lý hàng triệu kết nối mỗi giây. Ngược lại, vì không biết nội dung yêu cầu nên không thể phân phối theo nội dung như “yêu cầu hình ảnh tới máy chủ hình ảnh, yêu cầu API tới máy chủ API”.

Cân bằng tải L7 diễn giải cả đường dẫn URL, host header, cookie và method của thông điệp HTTP. Ví dụ, có thể định tuyến theo đường dẫn như gửi /api/* tới nhóm máy chủ backend, /static/* tới máy chủ nội dung tĩnh, và cung cấp các chức năng bổ sung như giải mã SSL/TLS (SSL Termination), bộ đệm phản hồi, liên kết WAF (tường lửa ứng dụng web), viết lại yêu cầu. Đổi lại, vì phải phân tích cú pháp và giải mã thông điệp nên tiêu tốn tài nguyên nhiều hơn L4 và độ trễ tăng đôi chút.

Sự khác biệt này đặc biệt nổi bật trong môi trường microservice. Khi dưới một tên miền (shop.example.com), tra cứu sản phẩm thuộc dịch vụ catalog, thanh toán thuộc dịch vụ thanh toán, tìm kiếm thuộc dịch vụ tìm kiếm, bộ cân bằng tải L7 chỉ cần nhìn đường dẫn URL để định tuyến chính xác từng yêu cầu tới pool dịch vụ phụ trách. Chỉ với L4 thì không thể phân phối theo đơn vị dịch vụ như vậy, nên trong kiến trúc microservice và API gateway, cân bằng tải L7 gần như là yếu tố bắt buộc.

Phân loại	Cân bằng tải L4	Cân bằng tải L7
Căn cứ phân phối	IP, cổng TCP/UDP	URL, HTTP header, cookie
Hiệu năng xử lý	Rất cao (độ trễ thấp)	Tương đối thấp (gánh nặng phân tích)
Định tuyến theo nội dung	Không thể	Có thể (theo đường dẫn·tên miền)
Xử lý SSL	Cho qua (passthrough)	Có thể kết thúc·mã hóa lại
Chức năng bổ sung	Hạn chế	Liên kết bộ đệm·nén·WAF·xác thực
Ứng dụng tiêu biểu	Game·DB·Luồng dung lượng lớn	Web·API·Microservice

Lý do căn bản tạo ra sự khác biệt nằm ở “nhìn sâu đến đâu”. L4 chỉ nhìn phong bì (header) để giao nên nhanh nhưng không phán đoán được theo nội dung, còn L7 mở phong bì đọc thư (thông điệp) nên tinh vi nhưng chậm. Hàm ý thực tiễn là kết hợp các tầng. Dịch vụ quy mô lớn thường áp dụng cấu trúc 2 tầng: ở tuyến đầu dùng L4 rải lượng lớn lưu lượng tới nhiều bộ cân bằng tải L7, và thực hiện định tuyến chi tiết cùng xử lý bảo mật ở tầng L7. Cấu hình đặt LB L4 của đám mây phía trước Ingress (L7) của Kubernetes là ví dụ tiêu biểu.

Một điểm khác cần lưu ý là vị trí xử lý SSL/TLS. Khi bộ cân bằng tải L7 kết thúc TLS (SSL Termination), máy chủ chỉ cần xử lý HTTP văn bản thuần nên gánh nặng mã hóa/giải mã của máy chủ biến mất, và bộ cân bằng tải quản lý chứng chỉ tập trung nên việc gia hạn và xoay vòng trở nên đơn giản. Ngược lại, đoạn từ bộ cân bằng tải tới máy chủ trở thành văn bản thuần nên phát sinh rủi ro nghe lén nội bộ, vì vậy trong các ngành bị quản lý (tài chính, y tế) người ta áp dụng SSL Bridging — giải mã tại bộ cân bằng tải rồi mã hóa lại gửi tới máy chủ — để duy trì tính bí mật đầu-cuối. Đây là ví dụ cho thấy lựa chọn tầng không đơn thuần là vấn đề hiệu năng mà gắn trực tiếp với yêu cầu bảo mật và quy định.

4. Thuật toán cân bằng tải

Quy tắc quyết định gửi tới máy chủ nào là thuật toán phân phối, được lựa chọn có xét đến chênh lệch hiệu năng giữa các máy chủ và đặc tính yêu cầu. Thuật toán được chia lớn thành phương thức tĩnh (static) không xét trạng thái và phương thức động (dynamic) phản ánh tải và phản hồi hiện tại của máy chủ. Phương thức tĩnh dễ dự đoán và chi phí tính toán thấp, còn phương thức động phản ánh tải thực tế để phân phối đồng đều hơn nhưng kéo theo chi phí thu thập trạng thái và tính toán.

Round Robin (xoay vòng): Phân phối lần lượt theo thứ tự cho các máy chủ. Dễ hiện thực và hiệu quả khi hiệu năng máy chủ đồng đều, nhưng nếu thời gian xử lý mỗi yêu cầu khác nhau nhiều (ví dụ có yêu cầu 1ms, có yêu cầu 5 giây) thì tải trở nên mất cân bằng.
Weighted Round Robin (xoay vòng có trọng số): Gán trọng số tỷ lệ với cấu hình máy chủ, gửi gấp đôi yêu cầu tới máy chủ có hiệu năng gấp đôi. Hữu ích trong môi trường máy chủ không đồng nhất.
Least Connection (ít kết nối nhất): Gửi tới máy chủ có số kết nối hoạt động hiện tại ít nhất. Trong môi trường thời gian xử lý yêu cầu chênh lệch lớn (ví dụ web có lẫn tải lên tệp), phản ánh tải thực tế tốt hơn round robin.
Least Response Time (thời gian phản hồi ngắn nhất): Xét đồng thời số kết nối hoạt động và độ trễ phản hồi gần đây để chọn máy chủ thực sự phản hồi nhanh nhất.
IP Hash (Source IP Hash): Băm IP nguồn để luôn ánh xạ tới cùng một máy chủ. Dùng cho mục đích duy trì phiên, và vấn đề ánh xạ bị phân bổ lại hàng loạt khi tăng giảm máy chủ được giảm nhẹ bằng băm nhất quán (Consistent Hashing).
Weighted Least Connection (ít kết nối nhất có trọng số): Chia số kết nối hoạt động cho trọng số máy chủ để so sánh, giúp cân bằng tải tương đối đồng đều ngay cả giữa các máy chủ có hiệu năng khác nhau. Được dùng rộng rãi trong môi trường thực tế nơi máy chủ không đồng nhất và yêu cầu chênh lệch lớn cùng tồn tại.
Ngẫu nhiên (Random) và P2C: Chọn ngẫu nhiên hội tụ về đồng đều theo thống kê trong phân tán quy mô lớn, còn P2C (Power of Two Choices) — chọn ngẫu nhiên hai máy chủ rồi lấy máy ít bận hơn — đạt hiệu quả gần với least connection chỉ với ít thông tin trạng thái, nên được ưa chuộng trong service mesh.

Việc chọn thuật toán phụ thuộc vào tính chất lưu lượng. Với API tĩnh có thời gian xử lý đồng đều thì round robin là đủ, nhưng nếu chênh lệch tải giữa các yêu cầu lớn thì họ least connection có lợi hơn. Ví dụ, với tác vụ mất vài giây mỗi yêu cầu như chuyển mã video (transcoding), nếu dùng round robin thì máy chủ tình cờ bị dồn các yêu cầu nặng sẽ quá tải, nên cần least connection hoặc phân phối dựa trên chỉ số tải thời gian thực.

Hiệu quả thực tế của thuật toán được xác nhận bằng số liệu. Giả sử yêu cầu có thời gian phản hồi 100ms và 3 giây trộn theo tỷ lệ 9:1 đổ vào 4 máy chủ, round robin không phân bổ đều các yêu cầu 3 giây nên hàng đợi của một số máy chủ dài ra và độ trễ p99 tăng vọt. Ngược lại, least connection tự nhiên tránh các máy chủ đang xử lý yêu cầu nặng nên trong cùng điều kiện độ trễ đuôi (tail latency) được giảm đáng kể. Tức là dịch vụ càng phải quản lý “độ trễ tệ nhất” thay vì “trung bình” thì giá trị của thuật toán phản ánh trạng thái thời gian thực càng lớn.

Mặt khác, tách biệt với thuật toán, các kỹ thuật tối ưu hóa đường phản hồi cũng quan trọng. Tiêu biểu là trả về trực tiếp từ máy chủ (DSR, Direct Server Return), phương thức trong đó yêu cầu đi qua bộ cân bằng tải nhưng phản hồi được máy chủ gửi trực tiếp tới máy khách. Với các dịch vụ có lưu lượng phản hồi gấp hàng chục lần yêu cầu như tải xuống dung lượng lớn hay streaming, nếu cả phản hồi cũng đi qua bộ cân bằng tải thì băng thông đó trở thành nút cổ chai. DSR cho phản hồi đi vòng, giới hạn gánh nặng của bộ cân bằng tải chỉ ở việc xử lý yêu cầu, nên cùng một thiết bị có thể gánh lưu lượng lớn hơn nhiều. Tuy nhiên do cấu hình mạng phức tạp và khó sử dụng chức năng L7 (viết lại nội dung v.v.), nó được áp dụng có chọn lọc cho các kịch bản L4 mà băng thông là mấu chốt.

A. GSLB (Global Server Load Balancing) và phân tán diện rộng

Vượt ra khỏi phân phối trong một trung tâm dữ liệu, GSLB là việc chia lưu lượng tới nhiều trung tâm dữ liệu hoặc region cách xa nhau về địa lý. Chủ yếu bằng cách điều khiển phản hồi DNS hoặc tận dụng Anycast, nó dẫn người dùng tới trung tâm dữ liệu gần nhất hoặc còn dư năng lực nhất.

Giá trị của GSLB gồm ba điểm. Thứ nhất, giảm thiểu độ trễ — kết nối người dùng Mỹ tới region Mỹ, người dùng Hàn Quốc tới region Seoul để giảm độ trễ khứ hồi (RTT). Thứ hai, khôi phục thảm họa — dù cả một region bị tê liệt, vẫn chuyển phản hồi DNS sang region khác (failover) để duy trì dịch vụ. Thứ ba, tuân thủ quy định — theo yêu cầu chủ quyền dữ liệu (Data Sovereignty), có thể cố định người dùng của một quốc gia vào region của quốc gia đó. Tuy nhiên GSLB dựa trên DNS có giới hạn là chuyển đổi sự cố không tức thời do TTL của bộ đệm DNS, nên được bổ sung bằng cách đặt TTL ngắn hoặc kết hợp Anycast.

Việc các nhà cung cấp streaming và SaaS toàn cầu đặt region ở nhiều châu lục và dẫn người dùng tới region gần nhất là ứng dụng GSLB tiêu biểu. Trong trường hợp này, không chỉ độ gần đơn thuần mà còn phản ánh đồng thời tải thời gian thực và kết quả kiểm tra tình trạng của từng region, áp dụng chính sách thông minh chuyển sang region lân cận khi một region bị bão hòa. GSLB còn gắn trực tiếp với mục tiêu RPO, RTO của chiến lược khôi phục thảm họa (DR), nên cân bằng tải phải được xem vừa là công nghệ hiệu năng vừa là yếu tố thiết kế hạ tầng dưới góc nhìn kinh doanh liên tục (BCP).

5. Chuyên sâu: Sự tiến hóa của cân bằng tải trong môi trường đám mây và container

Cân bằng tải truyền thống là phương thức bố trí một thiết bị phần cứng chuyên dụng riêng (ví dụ F5 BIG-IP) trên đường mạng. Tuy nhiên, khi đám mây và microservice lan rộng, hình thái cân bằng tải đã thay đổi lớn.

Thứ nhất, cân bằng tải phần mềm và được quản lý trên đám mây đã trở thành tiêu chuẩn. ELB của AWS (ALB là L7, NLB là L4), các LB được quản lý của GCP và Azure mở rộng và thu hẹp chỉ bằng lời gọi API mà không cần mua và vận hành phần cứng, và tự động liên kết với nhóm autoscaling để đưa ngay máy chủ mới khởi động vào pool. Nhờ đó môi trường co giãn nơi số lượng máy chủ thay đổi theo từng phút được hỗ trợ một cách tự nhiên.

Thứ hai, điểm cân bằng tải đã di chuyển tới gần dịch vụ. Trong Kubernetes, Service (phân phối L4 dựa trên ClusterIP, kube-proxy) và Ingress (định tuyến L7) đảm nhận phân phối bên trong cluster, còn LB đám mây được gắn ở điểm vào bên ngoài. Hơn nữa, service mesh (Service Mesh) đặt proxy sidecar (ví dụ Envoy) bên cạnh mỗi dịch vụ để xử lý cân bằng tải, thử lại và ngắt mạch (Circuit Breaker) bên ngoài mã ứng dụng. Tức là trọng tâm đang dịch chuyển từ cân bằng tải tập trung sang cân bằng tải phân tán, phía máy khách.

Thứ ba, bộ cân bằng tải đã mở rộng thành cửa ngõ của bảo mật và khả năng quan sát. Bộ cân bằng tải L7 là điểm kết thúc TLS nên trở thành vị trí tự nhiên cho quản lý chứng chỉ, WAF, giảm thiểu DDoS, và thu thập nhật ký yêu cầu, chỉ số độ trễ (Observability). Gần đây, các nỗ lực vượt qua giới hạn hiệu năng của phương thức iptables bằng cân bằng tải ở mức kernel dựa trên eBPF (ví dụ Cilium) cũng rất sôi động.

Thứ tư, sự kết hợp với chiến lược triển khai đã sâu hơn. Khi tầng cân bằng tải có thể kiểm soát tỷ lệ lưu lượng, triển khai canary (Canary) — chỉ cho 5% lưu lượng vào phiên bản mới để quan sát vấn đề rồi dần nâng lên 100% — và triển khai blue-green — chuẩn bị hai môi trường và chuyển đổi tức thì — đã có thể thực hiện chỉ bằng cấu hình bộ cân bằng tải. Điều này giảm rủi ro triển khai và cho phép rollback ngay khi có sự cố, trở thành phương tiện cốt lõi cho triển khai không gián đoạn và phát hành ổn định. Thực tế, các doanh nghiệp SaaS lớn tận dụng tầng cân bằng tải như một nền tảng thử nghiệm bằng cách cho tính năng mới hiển thị trước chỉ với một số khu vực hoặc nhóm người dùng nhất định.

6. Các điểm cần cân nhắc và hàm ý

Thứ nhất (chiến lược áp dụng), hãy kết hợp các tầng và ngoại hóa phiên. Cấu trúc 2 tầng — tiếp nhận lưu lượng lớn bằng L4 ở tuyến đầu và xử lý định tuyến nội dung, bảo mật ở L7 — là chuẩn mực để đạt được đồng thời khả năng mở rộng và tính linh hoạt. Khi đó không được phụ thuộc vào duy trì phiên mà phải tách kho phiên, hướng tới thiết kế phi trạng thái sao cho yêu cầu đi tới máy chủ nào cũng được xử lý như nhau, thì mới tận hưởng trọn vẹn hiệu quả của autoscale.

Thứ hai (đánh đổi), hãy điều chỉnh thận trọng độ nhạy của kiểm tra tình trạng. Chu kỳ kiểm tra ngắn giúp loại nhanh máy chủ lỗi nhưng làm tăng phát hiện nhầm và tải kiểm tra, còn kiểm tra chuyên sâu tuy chính xác nhưng sinh ra rủi ro lỗi dây chuyền khi toàn bộ pool máy chủ bị loại đồng thời lúc phụ thuộc gặp sự cố. Cần thiết kế tách kiểm tra nông và kiểm tra sâu, và chuyển sang chế độ suy giảm hiệu năng (graceful degradation) khi phụ thuộc suy giảm.

Thứ ba (góc nhìn tính sẵn sàng), hãy loại bỏ điểm lỗi đơn của chính bộ cân bằng tải. Khi bộ cân bằng tải chết thì toàn bộ dịch vụ dừng, vì vậy phải bảo đảm tính sẵn sàng cao của chính tầng cân bằng tải bằng cách kết hợp dự phòng kép Active-Standby hoặc Active-Active, chuyển đổi tự động qua VRRP/Floating IP, và ở phạm vi diện rộng là GSLB, Anycast.

Thứ tư (triển vọng và công nghệ liên kết), cân bằng tải đang hội tụ thành nền tảng quản lý lưu lượng. Vượt ra khỏi phân phối đơn thuần, việc điều chỉnh tỷ lệ lưu lượng cho triển khai canary, blue-green, ngắt mạch và thử lại, thu thập khả năng quan sát, thực thi chính sách bảo mật (WAF, Zero Trust) đang được tích hợp vào tầng cân bằng tải. Chỉ khi thiết kế cùng với service mesh, API gateway, autoscaling và CDN thì kiến trúc dịch vụ co giãn và bền vững mới được hoàn thiện.

Thứ năm (góc nhìn chi phí và vận hành), hãy tiết chế số tầng và chức năng phù hợp với yêu cầu dịch vụ. Chức năng L7 và cấu trúc nhiều tầng tuy mạnh mẽ nhưng kéo theo chi phí phân tích cú pháp và giải mã, độ phức tạp quản lý và độ trễ bổ sung. Không phải áp dụng ngăn xếp cân bằng tải cấu hình cao nhất cho mọi dịch vụ, mà nên bố trí có chọn lọc L4 nhẹ cho các đường mà băng thông là mấu chốt, và L7 cho các đường cần định tuyến và bảo mật tinh vi, để tối ưu hiệu quả so với chi phí. Cân bằng tải được quản lý trên đám mây tính phí theo thông lượng và số quy tắc, nên nên kết hợp giám sát chi phí theo góc nhìn FinOps cùng với dự báo lưu lượng.

Tài liệu tham khảo

AWS, "Elastic Load Balancing Features" — https://aws.amazon.com/elasticloadbalancing/features/
NGINX, "What Is Load Balancing?" — https://www.nginx.com/resources/glossary/load-balancing/
Cloudflare, "What is load balancing?" — https://www.cloudflare.com/learning/performance/what-is-load-balancing/
Kubernetes Documentation, "Service" — https://kubernetes.io/docs/concepts/services-networking/service/

Tóm tắt một câu: Cân bằng tải là công nghệ phân phối yêu cầu tới nhiều máy chủ để bảo đảm tính sẵn sàng, khả năng mở rộng và hiệu năng; kiến trúc dịch vụ co giãn và bền vững chỉ được hoàn thiện khi kết hợp L4 tốc độ cao dựa trên IP/cổng với L7 tinh vi dựa trên nội dung, đồng thời thiết kế cùng kiểm tra tình trạng, ngoại hóa phiên, GSLB và dự phòng kép.