Hệ thống rate limit toàn cầu của Uber

• Uber đã xây dựng Global Rate Limiter (GRL) trong môi trường hàng nghìn microservice xử lý hàng trăm triệu RPC mỗi giây, qua đó thiết lập một cơ chế bảo vệ quá tải thống nhất
• GRL sử dụng kiến trúc vòng lặp phản hồi 3 tầng gồm client-aggregator-controller, cho phép đánh giá request cục bộ đồng thời vẫn điều phối ở quy mô toàn cầu trong vài giây
• Hệ thống đã chuyển từ mô hình token bucket ban đầu sang mô hình drop xác suất để giải quyết các vấn đề về công bằng và khả năng mở rộng, đồng thời giảm tối đa độ trễ trên hot path
• So với limiter dựa trên Redis, độ trễ P99.5 được cải thiện tới 90%, đồng thời hệ thống hấp thụ được cả mức tăng lưu lượng gấp 15 lần và các cuộc tấn công DDoS mà không làm suy giảm dịch vụ
• Rate Limit Configurator (RLC) phân tích các mẫu lưu lượng lịch sử để tự động cập nhật giới hạn, giúp hệ thống tiến hóa từ cấu hình tĩnh sang một hệ thống tự điều chỉnh

---

Vấn đề của rate limiting truyền thống

• Trong môi trường microservice ban đầu của Uber, mỗi team tự triển khai throttling theo cách riêng bằng business logic, middleware tùy chỉnh, bộ đếm dựa trên Redis
• Điều này dẫn đến các vấn đề như cấu hình thiếu nhất quán, tăng thêm độ trễ do Redis, phải redeploy server khi thay đổi giới hạn, và khó ứng phó sự cố vì có những limiter không được tài liệu hóa
• Một số lượng đáng kể các dịch vụ nhỏ thậm chí còn vận hành mà không có rate limiting, và mỗi limiter lại báo metric và lỗi theo cách khác nhau nên không thể có observability thống nhất
• Cách dùng Redis làm bộ đếm tập trung gây ra độ trễ không thể chấp nhận được và vấn đề nhất quán liên vùng trong môi trường có hàng trăm nghìn host, hàng trăm triệu request mỗi giây và nhiều region
  • Ngay cả khi áp dụng sharding và replication thì vẫn cần đến hàng trăm Redis cluster, đồng thời làm phát sinh thêm các kiểu lỗi mới
• Phương pháp đồng bộ bộ đếm định kỳ tuy giảm overhead mạng nhưng bị loại bỏ vì dữ liệu không đủ mới và phản ứng chậm trước các đợt tăng lưu lượng đột ngột
• Kết luận cuối cùng là chỉ có kiến trúc phân tán hoàn toàn, nơi proxy cục bộ đưa ra quyết định dựa trên tải đã được tổng hợp, mới có thể đồng thời đạt độ trễ thấp và khả năng mở rộng toàn cầu

Tầm nhìn về limiter thống nhất ở tầng hạ tầng

• Giải pháp là tích hợp rate limiting vào service mesh của Uber, tức lớp hạ tầng dành cho lưu lượng RPC giữa các service
• Việc nhúng limiter vào lớp này cho phép kiểm tra và đánh giá mọi request trước khi đến đích, không phụ thuộc vào ngôn ngữ hay framework của bên gọi
• Mục tiêu: cung cấp một dịch vụ rate limiting thống nhất để các team có thể cấu hình quota theo caller và theo procedure mà không cần thay đổi code
• Hệ thống cần mở rộng với độ trễ bổ sung tối thiểu trên quy mô hàng trăm triệu request mỗi giây, hàng chục nghìn cặp service và đội host trải khắp nhiều region địa lý

Kiến trúc GRL: vòng lặp phản hồi 3 tầng

• Trọng tâm của GRL là cấu trúc vòng lặp phản hồi 3 tầng
  • Rate-limit client (data plane của service mesh): đưa ra quyết định cho từng request ở cục bộ theo chỉ thị nhận từ aggregator, đồng thời báo cáo số request mỗi giây theo host tới aggregator ở cấp zone
  • Aggregator (theo từng zone): thu thập metric từ mọi client trong cùng zone, tính mức sử dụng ở cấp zone rồi gửi lên controller
  • Controller (theo region, ở quy mô toàn cầu): tổng hợp dữ liệu từ các zone để xác định mức sử dụng toàn cục, sau đó truyền ngược chỉ thị tỷ lệ drop đã cập nhật xuống aggregator và client
• Cách tổng hợp theo phân cấp này giúp vừa duy trì độ trễ thấp trên hot path (vì quyết định được đưa ra cục bộ) vừa đạt được điều phối toàn cầu trong vòng vài giây
• Khi control plane gặp sự cố, client sẽ hoạt động theo cơ chế fail-open, tiếp tục cho lưu lượng đi qua để tránh tự gây ra outage

Sự tiến hóa của logic rate limiting

• Cách tiếp cận token bucket ban đầu

  • Ban đầu, Uber áp dụng thuật toán token bucket tại từng proxy trong data plane mạng
  • Mỗi proxy theo dõi số request cục bộ, nạp lại token theo thời gian, rồi cho phép hoặc từ chối request tùy theo số token còn sẵn
  • Tốc độ nạp token được tính theo tỷ lệ giữa tải cục bộ của proxy và giới hạn toàn cục: ratio × limitRPS
  • Để xử lý burst traffic, các token chưa dùng được lưu trong circular buffer, mặc định giữ trong 10 giây (có thể cấu hình tối đa 20 giây)
  • Trong production, mô hình này bộc lộ vấn đề về công bằng và khả năng mở rộng: khi số caller vượt quá giới hạn thì không thể phân phối công bằng dung lượng, và burst traffic ở từng host riêng lẻ có thể bị drop sớm ngay cả khi vẫn còn dưới giới hạn toàn cục

• Giới thiệu Drop-by-Ratio

  • Khi tải toàn cục đã được tổng hợp vượt quá giới hạn cấu hình, client sẽ drop ngẫu nhiên một tỷ lệ nhất định các request
  • Ví dụ: nếu RPS tổng hợp của caller bằng 1,5 lần giới hạn thì mọi instance sẽ drop khoảng 33%, theo công thức: drop_ratio = (actual_rps - limit_rps) / actual_rps
  • Đây là tín hiệu drop toàn cục được control plane cập nhật vài giây một lần, giúp throttle đều lưu lượng vượt mức trên mọi instance của caller
  • Cơ chế này đặc biệt hiệu quả với các dịch vụ kiểu gateway quy mô lớn có từ hàng trăm đến hàng nghìn instance caller

• Chuyển sang mô hình xác suất thống nhất

  • Khi GRL trưởng thành hơn, Uber đã loại bỏ hoàn toàn token bucket và thống nhất về mô hình drop xác suất dựa trên control plane
  • Lý do là việc vận hành đồng thời hai thuật toán làm tăng độ phức tạp cấu hình và overhead mạng
  • Việc hợp nhất về một mô hình duy nhất giúp đơn giản hóa cấu hình, giảm băng thông control plane và thống nhất mọi quyết định rate limiting dưới một cơ chế toàn cục nhất quán
  • Đánh đổi là hệ thống phụ thuộc vào dữ liệu tổng hợp toàn cục được cập nhật mỗi giây nên có độ trễ áp dụng 2–3 giây
    • Trong thực tế, mức này gần như không đáng kể với phần lớn workload và chỉ ảnh hưởng đến các burst cực ngắn, cực lớn

• Thiết kế cuối cùng: drop xác suất theo chỉ thị của control plane

  • Trong GRL hiện tại, việc thực thi diễn ra hoàn toàn ở lớp client của network data plane
  • Luồng xử lý khi request đến:
    • Ghép request vào bucket đã cấu hình (được định nghĩa theo caller, procedure, hoặc cả hai)
    • Nếu bucket đó có chỉ thị tỷ lệ drop đang hoạt động thì thực hiện drop xác suất theo tỷ lệ đó
    • Nếu không có chỉ thị drop thì chuyển tiếp bình thường
  • Hot path cực kỳ gọn nhẹ: không cần tính token cục bộ hay giao tiếp với control plane cho từng request, chỉ cần lấy mẫu xác suất đơn giản để ra quyết định trong tiến trình
  • Aggregator và controller thực hiện các phép tính phức tạp ngoài forwarding plane mỗi giây (tổng hợp số request, so sánh với ngưỡng, tính tỷ lệ drop mới)
  • Thiết kế này cho phép mở rộng tới hàng trăm triệu request mỗi giây mà vẫn giữ độ chính xác áp dụng toàn cầu trong vòng vài giây

Cấu hình giới hạn

• Chủ sở hữu dịch vụ định nghĩa các bucket rate limiting trong file cấu hình
  • Scope: toàn cục, theo region, theo zone
  • Quy tắc khớp: tên caller, procedure, hoặc cả hai
  • Hành vi: deny (áp dụng thực tế) hoặc allow (shadow mode để thử nghiệm)
• Việc áp dụng diễn ra minh bạch với dịch vụ đích mà không cần thay đổi code

Kết quả vận hành

• Giảm độ trễ và loại bỏ overhead

  • Trước GRL, nhiều dịch vụ dùng limiter dựa trên Redis yêu cầu network round-trip cho mỗi request
  • Việc chuyển sang đánh giá cục bộ trong data plane của service mesh đã loại bỏ thêm hop và giảm mạnh độ trễ
  • Độ trễ P50 giảm khoảng 1ms, P90 giảm vài chục ms, còn P99.5 giảm từ hàng trăm ms xuống vài chục ms, tương đương cải thiện tới 90%

• Đơn giản hóa vận hành và hiệu quả tài nguyên

  • Việc tập trung rate limiting vào data plane của service mesh đã đơn giản hóa hạ tầng
  • Không còn cần datastore hoặc lớp cache riêng để áp quota
  • Uber đã giải phóng đáng kể số instance Redis trước đây chuyên dùng cho rate limiting, qua đó cải thiện đáng kể hiệu quả sử dụng compute

• Nâng cao độ ổn định và ứng phó sự cố

  • Sau khi triển khai, GRL nhiều lần ngăn quá tải trong các tình huống spike, failover và retry storm
  • Bằng cách shed lưu lượng vượt mức theo xác suất ngay trong service mesh, hệ thống vẫn giữ được thời gian phản hồi ổn định ngay cả khi tải đầu vào tăng đột ngột
  • Một dịch vụ cốt lõi đã chịu được mức tăng lưu lượng gấp 15 lần, từ 22K lên 367K RPS mà không bị suy giảm
  • Hệ thống cũng hấp thụ các cuộc tấn công DDoS trước khi chúng chạm tới hệ thống nội bộ
  • Trong quá trình ứng phó sự cố, đội production engineering dùng GRL để áp dụng rate limit có mục tiêu cho các caller/procedure có lưu lượng cao; cập nhật từ control plane được lan truyền mỗi giây nên có thể phản ứng với quá tải trong vài giây
  • Có thể throttle nhanh và an toàn các pattern lưu lượng cụ thể mà không cần redeploy service
  • Ở quy mô toàn hệ thống: khoảng 80 triệu request mỗi giây, với quota động được áp dụng trên hơn 1.100 service

Tự động hóa rate limiting: Rate Limit Configurator (RLC)

• Giới hạn của cấu hình thủ công

  • Dù GRL đã thống nhất việc thực thi, quá trình cấu hình giới hạn vẫn cần thao tác thủ công
  • Chủ sở hữu dịch vụ phải định nghĩa quota theo caller và procedure trong file YAML rồi điều chỉnh mỗi khi pattern lưu lượng thay đổi
  • Trong môi trường có hàng trăm microservice liên tục tiến hóa, cấu hình tĩnh nhanh chóng trở nên lỗi thời
    • Nếu quá chặt, hệ thống sẽ throttle ngay cả ở các đỉnh lưu lượng hợp lệ
    • Nếu quá lỏng, giới hạn sẽ cao hơn nhiều so với năng lực thực tế và hiệu quả bảo vệ rất thấp
    • Mọi thay đổi đều phụ thuộc vào phân tích dashboard và tinh chỉnh thủ công

• Cách RLC hoạt động

  • RLC (Rate Limit Configurator) tự động giữ cho cấu hình GRL luôn được cập nhật
  • Theo lịch cố định hoặc ngay khi cấu hình thay đổi, hệ thống chạy chu kỳ tiếp theo:
    • Thu thập metric của vài tuần gần nhất từ nền tảng observability của Uber
    • Tính giới hạn an toàn cho từng caller và procedure dựa trên các đỉnh lịch sử và phần đệm dự phòng
    • Ghi cấu hình đã cập nhật vào kho cấu hình dùng chung
    • Đẩy giới hạn mới vào GRL thông qua control plane hiện có
  • Quy trình closed-loop này giúp giới hạn tiến hóa cùng với lưu lượng thực tế, đồng thời giảm tối đa sự can thiệp thủ công

• Thiết kế có thể mở rộng

  • Ngay từ đầu, RLC đã được thiết kế để hỗ trợ nhiều chiến lược tính rate limit
  • Chính sách mặc định dựa trên dữ liệu RPS lịch sử, nhưng có thể bổ sung các kiểu chính sách mới theo mô-đun
  • Các dịch vụ như dữ liệu bản đồ và vị trí dùng mô hình dự báo phản ánh dự báo lưu lượng và năng lực đã được lập kế hoạch từ trước, thay vì chỉ dựa vào xu hướng quá khứ
  • Hệ thống cũng hỗ trợ cách phân bổ quota cố định theo các thỏa thuận mang tính hợp đồng hoặc vận hành đã xác định sẵn
  • Nhờ giao diện mô-đun, mỗi domain dịch vụ có thể chọn logic tính phù hợp nhất giữa pattern lưu lượng gần thời gian thực, dự báo hoặc quota tĩnh

• Shadow mode và xác minh

  • Để đảm bảo an toàn, giới hạn có thể được tạo và giám sát ở shadow mode mà chưa áp dụng thực tế
  • Chủ sở hữu dịch vụ có thể quan sát hành vi rate limiting trong production trước khi kích hoạt
  • Dashboard và cảnh báo chuyên dụng trực quan hóa lưu lượng quan sát được cùng với lượng drop giả lập, giúp tăng độ tin cậy trước khi rollout

• Tác động của tự động hóa

  • Hàng nghìn rule rate limiting được cập nhật tự động mà không cần chỉnh sửa thủ công
  • Cùng một công thức và nguồn dữ liệu được dùng để tạo chính sách nhất quán trên mọi service
  • Nhờ nhiều loại chính sách khác nhau, các team có thể chọn và mở rộng logic tính phù hợp nhất với workload của mình
  • Shadow mode giúp đảm bảo độ chính xác trước khi áp dụng

Hướng đi tiếp theo

• Sau khi triển khai RLC, Uber tiếp tục mở rộng việc tinh chỉnh buffer, đưa vào rate limit theo region để giảm phạm vi ảnh hưởng của thay đổi cấu hình, và tăng tần suất cập nhật để cải thiện khả năng phản ứng với lưu lượng thực
• Lớp throttler của Uber cũng cung cấp thêm khả năng bảo vệ quá tải ở vị trí gần ứng dụng hơn
• Hiện tại, GRL là một thành phần cốt lõi trong stack ổn định nhiều tầng của Uber, giúp duy trì độ ổn định và công bằng của nền tảng ngay cả dưới tải cực lớn