Zalando tối ưu hóa hạ tầng: Xây dựng Load Balancer nội bộ xử lý 1 triệu request mỗi giây

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Zalando chuyển đổi từ load balancer tập trung (Skipper) sang mô hình client-side load balancer nội bộ cho các luồng traffic có độ phân tán cao.
• Giải pháp giúp giảm chi phí vận hành hạ tầng từ 450 USD xuống còn 110 USD mỗi ngày và tối ưu hóa độ trễ.
• Sử dụng thuật toán nhất quán (consistent hashing) để đảm bảo tính ổn định khi mở rộng hoặc thu hẹp số lượng endpoint.

Khi hệ thống của bạn đạt đến ngưỡng 1 triệu request mỗi giây, mọi mili-giây độ trễ đều trở thành một bài toán sống còn. Tại Zalando, một trong những nhà bán lẻ thời trang lớn nhất châu Âu, Product Read API phải đối mặt với áp lực khổng lồ khi một request đơn lẻ có thể phân tách thành 100 cuộc gọi song song tới các pod sản phẩm. Việc phụ thuộc vào một load balancer tập trung như Skipper đã tạo ra các nút thắt cổ chai không mong muốn, khiến đội ngũ kỹ sư khó lòng tách biệt độ trễ của hạ tầng với logic nghiệp vụ.

Bài toán về độ trễ và sự phụ thuộc hạ tầng

Trong kiến trúc microservices hiện đại, việc quản lý giao tiếp giữa các dịch vụ đòi hỏi sự tinh tế. Khi một request đi qua nhiều lớp trung gian, khả năng quan sát (observability) bị suy giảm đáng kể. Zalando nhận thấy rằng việc sử dụng Skipper cho mọi loại traffic không còn là lựa chọn tối ưu. Thay vì tiếp tục gánh chịu sự bất ổn từ các hop trung gian mà họ không kiểm soát được, đội ngũ kỹ sư đã quyết định đưa quyết định định tuyến (routing decision) vào bên trong tiến trình (in-process).

Lưu ý: Việc chuyển đổi sang client-side load balancing không có nghĩa là loại bỏ hoàn toàn các giải pháp như Skipper. Skipper vẫn đóng vai trò quan trọng cho các traffic ở biên (edge traffic) và các yêu cầu GET đơn lẻ.

Kiến trúc Client-Side Load Balancer

Giải pháp của Zalando tập trung vào việc tái hiện thuật toán của Skipper ngay trong thư viện client. Bằng cách sử dụng xxHash64 và 100 virtual nodes cho mỗi endpoint, hệ thống đảm bảo rằng cả hai con đường (cũ và mới) đều tạo ra các vòng băm (hash rings) giống hệt nhau. Điều này cực kỳ quan trọng trong quá trình di chuyển (migration) để tránh hiện tượng phân tách cache (cache splits).

Sơ đồ luồng dữ liệu đơn giản hóa:
[Client Process] ---> [In-Process LB] ---> [Product Pods]

Việc thay thế cơ chế polling lỗi thời bằng Kubernetes informer dựa trên watch đã giúp rút ngắn thời gian cập nhật cấu hình từ hàng giờ xuống còn vài giây. Điều này cũng liên quan mật thiết đến cách chúng ta quản lý các quyết định kiến trúc, tương tự như việc áp dụng Architecture Decision Records: Bí quyết ghi chép kiến trúc giúp team không bao giờ lạc lối để đảm bảo mọi thay đổi đều có căn cứ.

Kết quả đo lường hiệu năng

Sự thay đổi này mang lại những con số ấn tượng về hiệu quả tài chính và kỹ thuật:

Việc tối ưu hóa này không chỉ dừng lại ở hạ tầng, nó còn mở ra hướng đi mới cho việc Tối ưu hóa quy trình giám sát AI: Tự động hóa logging API OpenAI và Anthropic chỉ với một dòng code nhằm đảm bảo hệ thống luôn trong tầm kiểm soát.

Đánh giá & Lời khuyên Thực tiễn

Từ góc nhìn của một Senior Tech Lead, giải pháp của Zalando là một ví dụ điển hình về việc tối ưu hóa kiến trúc dựa trên nhu cầu thực tế.

• Ưu điểm: Giảm đáng kể độ trễ mạng, tăng cường khả năng quan sát và kiểm soát trực tiếp từ code, giảm chi phí hạ tầng.
• Nhược điểm: Tăng độ phức tạp của mã nguồn client, đòi hỏi sự đồng bộ chặt chẽ giữa các phiên bản thư viện load balancer trên các service khác nhau.
• Phạm vi ứng dụng: Phù hợp cho các hệ thống có lưu lượng truy cập cực lớn (high fan-out) nơi độ trễ của load balancer trung gian trở thành điểm nghẽn.

Mẹo hay: Khi triển khai client-side load balancing, hãy luôn sử dụng các tính năng như feature toggles để ramp-up traffic từ 1% đến 100% một cách an toàn, tránh rủi ro gây sập hệ thống ngay lập tức.

Nếu bạn đang gặp vấn đề với các hệ thống kiểm thử chậm chạp do kiến trúc, hãy xem xét lại Tại sao bộ Test Suite của bạn không chậm mà đang tích tụ những quyết định sai lầm? để có cái nhìn tổng quan hơn.

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

Tại sao Zalando không dùng Service Mesh thay vì tự viết load balancer?

Service Mesh có thể cung cấp các tính năng tương tự nhưng thường đi kèm với overhead về tài nguyên và độ phức tạp vận hành. Với Zalando, việc kiểm soát trực tiếp trong process giúp họ đạt được độ trễ thấp nhất có thể.

Làm thế nào để đảm bảo tính nhất quán khi cập nhật endpoint?

Zalando sử dụng thuật toán consistent hashing với số lượng virtual nodes cố định, đảm bảo rằng khi một node thay đổi, chỉ một phần nhỏ (1/N) các key bị remap, giảm thiểu tối đa cache churn.

Rủi ro lớn nhất khi triển khai giải pháp này là gì?

Đó là việc quản lý phiên bản thư viện. Nếu thư viện load balancer có lỗi, bạn phải deploy lại toàn bộ các service đang sử dụng nó, thay vì chỉ cập nhật cấu hình ở load balancer tập trung.

Kết luận

Việc Zalando xây dựng thành công in-process load balancer là minh chứng cho thấy tư duy kỹ thuật đúng đắn có thể giải quyết các bài toán quy mô lớn mà không cần phụ thuộc vào các công cụ cồng kềnh. Đây là bài học quý giá cho bất kỳ đội ngũ kỹ thuật nào đang vận hành hệ thống microservices phức tạp. Hãy tiếp tục theo dõi hi_dev để cập nhật những xu hướng kiến trúc mới nhất và đừng quên chia sẻ bài viết này nếu bạn thấy hữu ích!