Meta ra mắt ZGateway: Hệ thống proxy xử lý hơn 1 tỷ yêu cầu mỗi giây cho ZippyDB

Đội ngũ kỹ thuật của Meta đã giới thiệu ZGateway, một tầng proxy nằm giữa các ứng dụng khách và ZippyDB, kho lưu trữ key-value được sử dụng rộng rãi nhất của Meta. ZippyDB hỗ trợ siêu dữ liệu sản phẩm, bộ đếm và cấu hình với hàng tỷ thao tác mỗi giây. ZGateway ban đầu được tạo ra như một giải pháp khắc phục tình trạng kết nối tràn lan trên hơn một triệu máy chủ khách, sau đó phát triển thành nơi xử lý việc gom nhóm (batching), kiểm soát truy cập (admission control), lưu trữ đệm (caching) và dự phòng lỗi (failover).

Tại sao ZippyDB cần một Proxy

Khi truy cập trực tiếp, mỗi client của ZippyDB đều kết nối với mọi máy chủ cơ sở dữ liệu mà nó cần. Một client đơn lẻ có thể chạm tới hàng chục nghìn shard trên hàng trăm nghìn máy chủ, vì vậy cả một client điển hình và một máy chủ cơ sở dữ liệu điển hình đều phải duy trì hàng chục nghìn kết nối TLS. Mỗi kết nối nhàn rỗi đều tiêu tốn bộ nhớ, CPU và file descriptor ở cả hai đầu, và số lượng kết nối đầu vào tăng lên theo từng nhóm client mới. Các đợt bão kết nối lại (reconnection storms) đã gây ra sự cố do cạn kiệt file descriptor và lỗi OOM (hết bộ nhớ); trong một sự cố, lỗi định tuyến đã khiến mọi client mở một kết nối cho mỗi shard và toàn bộ hệ thống rơi vào vòng lặp khởi động lại. Các bản sửa lỗi phía client không khả thi vì có hàng trăm đội ngũ sở hữu các client này.

ZGateway là gì

ZGateway là một tầng proxy không trạng thái (stateless) nằm giữa các client của ZippyDB và đội ngũ máy chủ cơ sở dữ liệu ZServer. Theo Meta, nó xử lý hơn 1 tỷ thao tác mỗi giây và đảm nhận khoảng 40% lưu lượng truy cập của ZippyDB, dự kiến sẽ vượt mức 60%, với mức tiêu tốn tài nguyên tính toán khoảng 6% cho một trường hợp sử dụng trung bình.

Nó vận hành dưới dạng các tầng khu vực được khám phá thông qua ServiceRouter, service mesh của Meta, với hai hình thức: proxy thuần túy và bộ nhớ đệm đọc (read-through cache). Công cụ cốt lõi là client ZippyDB C++ dày (thick client) của Meta, vì vậy ZGateway thực chất là một client ZippyDB được vận hành như một dịch vụ được quản lý.

Một client gửi các yêu cầu thông qua kết nối cố định (sticky connection) đến một máy chủ ZGateway khu vực. Tại đây, kết nối TLS được chấm dứt, yêu cầu được xác thực dựa trên các ACL của trường hợp sử dụng, áp dụng kiểm soát truy cập và định hình lưu lượng theo từng tenant, phân giải shard, kiểm tra bộ nhớ đệm cục bộ trên các tầng caching, gom nhóm yêu cầu với các công việc đang xử lý khác cho shard đó và chuyển tiếp đến các bản sao (replica) chính xác. Các phản hồi được phân tách ngược lại cùng với các chỉ số, dấu vết (trace) và mức sử dụng hạn ngạch (quota) được ghi lại theo từng trường hợp sử dụng. TLS vẫn nằm trong stack Thrift/ServiceRouter và việc lựa chọn bản sao vẫn nằm trong client nhúng.

Phép toán Fan-In và Fan-Out

Meta mô hình hóa đội ngũ máy chủ như những quả bóng được ném vào các thùng: với B shard và H máy chủ, một máy chủ sẽ bị tác động với xác suất E(H,B) = H(1 – e^{-B/h}). Với các số liệu giả định gồm 20 khu vực, 500.000 máy chủ cơ sở dữ liệu, 30.000 máy chủ proxy, 1.000.000 client và 50.000 shard mỗi client, số lượng kết nối trên mỗi máy chủ giảm khoảng 97 đến 98% và tổng số kết nối duy trì giảm khoảng 19 lần. Lợi ích sâu xa hơn nằm ở khả năng mở rộng: fan-in khi truy cập trực tiếp tăng tuyến tính theo số lượng client, trong khi fan-in của ZGateway giảm xuống còn khoảng số khu vực nhân với mật độ shard trên mỗi máy chủ, độc lập với cả hai đội ngũ máy chủ.

Các khả năng được bổ sung

Những điểm chính cần lưu ý

Hãy xem bài đăng trên blog của Meta Engineering và thông báo trên X. Mọi công lao đều thuộc về các nhà nghiên cứu của dự án này. Ngoài ra, hãy thoải mái theo dõi chúng tôi trên Twitter và đừng quên tham gia SubReddit ML 150k+ thành viên của chúng tôi cũng như đăng ký nhận Bản tin. Khoan đã! Bạn có dùng Telegram không? Bây giờ bạn cũng có thể tham gia cùng chúng tôi trên Telegram.

Bạn cần hợp tác với chúng tôi để quảng bá GitHub Repo, trang Hugging Face, bản phát hành sản phẩm hoặc hội thảo trực tuyến, v.v.? Hãy kết nối với chúng tôi.

Michal Sutter là một chuyên gia khoa học dữ liệu với bằng Thạc sĩ Khoa học Dữ liệu từ Đại học Padova. Với nền tảng vững chắc về phân tích thống kê, học máy và kỹ thuật dữ liệu, Michal xuất sắc trong việc chuyển đổi các tập dữ liệu phức tạp thành những thông tin chi tiết có thể áp dụng được.