Tweet
Môt khảo sát về Load Balancer — “người điều phối thầm lặng” phía sau các hệ thống cloud và AI hiện đại
Như chúng ta có thể đã biết, khi người dùng truy cập một ứng dụng lớn như Facebook, GitHub, Netflix hay ChatGPT, phía sau thường không phải là “một server”. Thực tế có thể là hàng chục, hàng trăm, thậm chí hàng ngàn compute nodes đang cùng phục vụ ứng dụng đó. Một trong những vấn đề đặt ra là làm sao phân phối traffic giữa các node này? Đó là lúc Load Balancer xuất hiện.
Trong kiến trúc distributed application hiện đại mà bài viết trước VnPro đã có dịp trình bày, load balancer đóng vai trò như một “traffic controller”. Người dùng chỉ truy cập vào một địa chỉ duy nhất, ví dụ app.company.com. Nhưng phía sau địa chỉ truy cập đơn giản đó có thể là rất nhiều backend servers khác nhau. Load balancer sẽ quyết định request nào sẽ được gửi tới backend server nào.
Điều thú vị là các tầng layer trong hệ thống hiện đại có thể scale độc lập để giải quyết vấn đề cân bằng tải này. Thật vậy, Frontend có thể scale riêng, Business logic có thể scale riêng. Database tier cũng có thể scale riêng.
Ví dụ với các frontend React.js, một phần workload được đẩy xuống client-side browser thay vì xử lý hoàn toàn ở backend. Điều này giúp giảm tải cho application servers.
Trong business tier, các application instances thường được nhân bản (replica) thành nhiều node. Client không kết nối trực tiếp tới từng node mà đi qua load balancer. Load balancer sẽ phân phối traffic dựa trên các thuật toán mà chúng ta quen thuộc nhưRound Robin, Least Connections, Source IP Hash, Fastest Response. Ví dụ thuật toán Round Robin:
Request 1 -> Server 1
Request 2 -> Server 2
Request 3 -> Server 3
Sau đó lặp lại vòng phân phối tiếp theo. Một điểm cực kỳ quan trọng trong các hệ thống phân tán distributed systems là Compute nodes trở nên “disposable”. Nếu một node chết, hệ thống vẫn hoạt động bình thường. Người dùng gần như không nhận ra chuyện gì vừa xảy ra. Kubernetes hoạt động dựa rất nhiều trên triết lý này. Pod bị lỗi? Orchestrator tự tạo pod mới. Node bị down? Workload được reschedule sang node khác. Đây cũng là lý do các nền tảng cloud-native ngày nay phụ thuộc rất mạnh vào Kubernetes, Containers, Service Mesh, HAProxy, NGINX và Envoy.
Một trong những giải pháp load balancing mã nguồn mở nổi tiếng nhất là HAProxy (quan điểm cá nhân thôi nha). HAProxy được sử dụng trong nhiều hệ thống lớn như GitHub, Instagram, Twitter. Nó có thể hoạt động như Layer 4 Load Balancer hoặc Layer 7 Load Balancer. Ví dụ một cấu hình backend đơn giản:
backend web-backend
balance roundrobin
mode http
server web1 web1.example.com:80 check
server web2 web2.example.com:80 check
Trong cấu hình này:
Layer 4 Load Balancing
Forward traffic dựa trên IP và TCP/UDP port. Ví dụ toàn bộ traffic port 80 sẽ được chuyển tới web backend. Đây là kiểu load balancing đơn giản và hiệu năng cao. Anh em network quen thuộc với thuận toán này lắm!
Layer 7 Load Balancing
Thông minh hơn Layer 4 nhiều. Load balancer có thể đọc nội dung HTTP request và điều hướng traffic dựa trên URL path. Ví dụ:
/images -> img-backend
/api -> api-backend
Điều này cho phép nhiều services chạy chung domain nhưng được xử lý bởi các backend khác nhau. Ví dụ frontend configuration của HAProxy có dạng như sau:
frontend http
bind *:80
mode http
acl url_img path_beg /images
use_backend img-backend if url_img
default_backend web-backend
Nếu URL bắt đầu bằng /images, traffic sẽ được chuyển sang cụm image servers riêng. Nếu chúng ta nhìn rộng hơn, những gì mà chúng ta vừa đọc chính là nền móng của API Gateway (MCP servers của AI, vụ này đang nổi), Kubernetes Ingress, Service Mesh, AI Model Serving, Distributed AI Inference...Ngay cả các hệ thống AI hiện đại cũng đang dùng các nguyên lý load balancing tương tự để phân phối inference requests giữa nhiều GPU nodes khác nhau. Load Balancer chính là “người điều phối lưu lượng traffic” của toàn bộ hệ thống....
Như chúng ta có thể đã biết, khi người dùng truy cập một ứng dụng lớn như Facebook, GitHub, Netflix hay ChatGPT, phía sau thường không phải là “một server”. Thực tế có thể là hàng chục, hàng trăm, thậm chí hàng ngàn compute nodes đang cùng phục vụ ứng dụng đó. Một trong những vấn đề đặt ra là làm sao phân phối traffic giữa các node này? Đó là lúc Load Balancer xuất hiện.
Trong kiến trúc distributed application hiện đại mà bài viết trước VnPro đã có dịp trình bày, load balancer đóng vai trò như một “traffic controller”. Người dùng chỉ truy cập vào một địa chỉ duy nhất, ví dụ app.company.com. Nhưng phía sau địa chỉ truy cập đơn giản đó có thể là rất nhiều backend servers khác nhau. Load balancer sẽ quyết định request nào sẽ được gửi tới backend server nào.
Điều thú vị là các tầng layer trong hệ thống hiện đại có thể scale độc lập để giải quyết vấn đề cân bằng tải này. Thật vậy, Frontend có thể scale riêng, Business logic có thể scale riêng. Database tier cũng có thể scale riêng.
Ví dụ với các frontend React.js, một phần workload được đẩy xuống client-side browser thay vì xử lý hoàn toàn ở backend. Điều này giúp giảm tải cho application servers.
Trong business tier, các application instances thường được nhân bản (replica) thành nhiều node. Client không kết nối trực tiếp tới từng node mà đi qua load balancer. Load balancer sẽ phân phối traffic dựa trên các thuật toán mà chúng ta quen thuộc nhưRound Robin, Least Connections, Source IP Hash, Fastest Response. Ví dụ thuật toán Round Robin:
Request 1 -> Server 1
Request 2 -> Server 2
Request 3 -> Server 3
Sau đó lặp lại vòng phân phối tiếp theo. Một điểm cực kỳ quan trọng trong các hệ thống phân tán distributed systems là Compute nodes trở nên “disposable”. Nếu một node chết, hệ thống vẫn hoạt động bình thường. Người dùng gần như không nhận ra chuyện gì vừa xảy ra. Kubernetes hoạt động dựa rất nhiều trên triết lý này. Pod bị lỗi? Orchestrator tự tạo pod mới. Node bị down? Workload được reschedule sang node khác. Đây cũng là lý do các nền tảng cloud-native ngày nay phụ thuộc rất mạnh vào Kubernetes, Containers, Service Mesh, HAProxy, NGINX và Envoy.
Một trong những giải pháp load balancing mã nguồn mở nổi tiếng nhất là HAProxy (quan điểm cá nhân thôi nha). HAProxy được sử dụng trong nhiều hệ thống lớn như GitHub, Instagram, Twitter. Nó có thể hoạt động như Layer 4 Load Balancer hoặc Layer 7 Load Balancer. Ví dụ một cấu hình backend đơn giản:
backend web-backend
balance roundrobin
mode http
server web1 web1.example.com:80 check
server web2 web2.example.com:80 check
Trong cấu hình này:
- balance roundrobin xác định thuật toán phân phối tải
- mode http bật Layer 7 proxying
- check dùng để health-check backend servers
Layer 4 Load Balancing
Forward traffic dựa trên IP và TCP/UDP port. Ví dụ toàn bộ traffic port 80 sẽ được chuyển tới web backend. Đây là kiểu load balancing đơn giản và hiệu năng cao. Anh em network quen thuộc với thuận toán này lắm!
Layer 7 Load Balancing
Thông minh hơn Layer 4 nhiều. Load balancer có thể đọc nội dung HTTP request và điều hướng traffic dựa trên URL path. Ví dụ:
/images -> img-backend
/api -> api-backend
Điều này cho phép nhiều services chạy chung domain nhưng được xử lý bởi các backend khác nhau. Ví dụ frontend configuration của HAProxy có dạng như sau:
frontend http
bind *:80
mode http
acl url_img path_beg /images
use_backend img-backend if url_img
default_backend web-backend
Nếu URL bắt đầu bằng /images, traffic sẽ được chuyển sang cụm image servers riêng. Nếu chúng ta nhìn rộng hơn, những gì mà chúng ta vừa đọc chính là nền móng của API Gateway (MCP servers của AI, vụ này đang nổi), Kubernetes Ingress, Service Mesh, AI Model Serving, Distributed AI Inference...Ngay cả các hệ thống AI hiện đại cũng đang dùng các nguyên lý load balancing tương tự để phân phối inference requests giữa nhiều GPU nodes khác nhau. Load Balancer chính là “người điều phối lưu lượng traffic” của toàn bộ hệ thống....
Attached Files