Chúng tôi đang tự giới hạn tốc độ các dịch vụ của mình

API của Mythex cho phép 300 yêu cầu mỗi phút từ một địa chỉ mạng. Giới hạn đó tồn tại để bảo vệ chúng tôi khỏi một người hoặc một script đập vào API. Trên production, nó bắt đầu từ chối chính các dịch vụ của chúng tôi — phần biên phục vụ các ứng dụng đã xuất bản và dịch vụ chạy agent AI — vì mỗi dịch vụ gọi API từ chỉ một số ít địa chỉ. Giờ các yêu cầu mang thông tin xác thực nội bộ của chúng tôi được miễn trừ, và mọi người khác vẫn bị giới hạn y như trước.

Triệu chứng

API bắt đầu trả lời một số lời gọi nội bộ của chúng tôi bằng 429 Too Many Requests. Ba loại lời gọi bị ảnh hưởng, và mỗi loại đều quan trọng với ai đó đang dùng Mythex:

• Tra cứu xem ứng dụng nào nằm trên tên miền tùy chỉnh. Khi một người truy cập mở một ứng dụng đã xuất bản trên tên miền riêng, biên của chúng tôi hỏi API xem site đó nằm ở đâu. Một lỗi 429 ở đó nghĩa là một người truy cập không thể vào được site.
• Lưu một lượt agent đang chạy. Trong khi agent làm việc, tiến trình của nó được lưu dần, để một câu trả lời sống sót qua việc làm mới hoặc kết nối bị rớt. Một lỗi 429 ở đó nghĩa là tiến trình không được lưu.
• Kiểm tra quyền truy cập một bản xem trước. Bản xem trước của một ứng dụng bạn đang xây được bảo vệ, và cổng đó hỏi API. Một lỗi 429 ở đó nghĩa là bản xem trước không mở được.

Không cái nào trong số này là người gọi API. Tất cả đều là chúng tôi.

Vì sao điều này xảy ra

Giới hạn tốc độ theo địa chỉ có một giả định: một địa chỉ xấp xỉ một người gọi. Với con người, điều đó đủ gần đúng. Với hạ tầng của chúng tôi, nó sai nghiêm trọng.

• Dịch vụ biên phục vụ các ứng dụng đã xuất bản và bản xem trước gọi API từ một vài địa chỉ đi ra dùng chung. Mọi người truy cập vào mọi ứng dụng đã xuất bản, và mọi kiểm tra bản xem trước, đều đến như thể từ một trong vài địa chỉ đó.
• Orchestrator — dịch vụ chạy các lượt agent — gọi API từ một địa chỉ container. Mọi lượt đang chạy, cho mọi người dùng, đều dùng chung địa chỉ đó.

Vì vậy ngân sách được dành cho một người lại bị chia ra cho toàn bộ lưu lượng của cả một dịch vụ. Các dịch vụ đó dùng hết nó giữa chúng, và bộ giới hạn làm đúng việc được giao: nó từ chối chúng.

Cách sửa

Các dịch vụ nội bộ của chúng tôi vốn đã chứng minh danh tính của chúng. Mọi lời gọi nội bộ mang một token nội bộ, và mọi route trong phần nội bộ của API đều kiểm tra token đó trước khi làm bất cứ việc gì.

Bộ giới hạn tốc độ giờ dùng cùng một kiểm tra. Một yêu cầu có token khớp với token nội bộ nằm trong danh sách cho phép và không bị tính vào ngân sách theo địa chỉ. Mọi thứ khác vẫn được tính đúng như trước: 300 yêu cầu mỗi phút cho mỗi địa chỉ.

Hai chi tiết giúp điều này không trở thành một lỗ hổng:

1. Token sai không được miễn trừ. Danh sách cho phép chỉ khớp với đúng token nội bộ thật. Một yêu cầu với token giả vẫn bị tính và bị giới hạn như mọi yêu cầu khác, và các route nội bộ vẫn từ chối nó với 401 Unauthorized.
2. Bản thân giới hạn không thay đổi. Chúng tôi không nâng con số để có chỗ. Nâng lên sẽ che giấu vấn đề cho đến khi lưu lượng tăng trở lại, và sẽ làm yếu sự bảo vệ cho đúng trường hợp mà giới hạn tồn tại để xử lý.

Chúng tôi chuyển cài đặt của bộ giới hạn vào một hàm nhỏ và viết kiểm thử cho nó. Một kiểm thử gửi 20 yêu cầu với token nội bộ tới một bộ giới hạn đặt cho phép 5, và mong đợi cả 20 đều thành công. Kiểm thử khác gửi các yêu cầu thường từ một địa chỉ và mong đợi năm yêu cầu đầu thành công, các yêu cầu sau bị từ chối. Kiểm thử thứ ba gửi các yêu cầu với token giả và mong đợi chúng bị từ chối theo cùng cách.

Chúng tôi rút ra gì

• Giới hạn mang theo các giả định. “Một địa chỉ, một người gọi” được xây sẵn trong giới hạn theo địa chỉ. Nó không còn đúng khi các dịch vụ nội bộ của bạn đứng sau địa chỉ dùng chung — và nhiều dịch vụ như vậy: load balancer, mạng biên, container, mạng văn phòng.
• Phân biệt lưu lượng của chính bạn theo danh tính, không theo địa chỉ. Địa chỉ là cách lưu lượng đến, không phải ai đã gửi nó. Chúng tôi đã có một thông tin xác thực chứng minh một lời gọi là của mình; bộ giới hạn chỉ chưa nhìn vào nó.
• Đừng sửa bằng cách nâng con số. Một giới hạn lớn hơn sẽ làm các lỗi 429 biến mất một thời gian, bảo vệ kém đi, và rồi lại hỏng sau.
• Hãy xem ai đang bị giới hạn. Một lỗi 429 rơi vào chính dịch vụ của bạn là một báo cáo lỗi về giới hạn của bạn, không phải dấu hiệu bộ giới hạn đang làm việc.

Điều này có nghĩa gì nếu bạn xây trên Mythex

Không có gì bạn cần thay đổi. Các ứng dụng đã xuất bản trên tên miền tùy chỉnh, các lượt agent và bản xem trước giờ không còn phụ thuộc vào mức bận rộn của phần còn lại của Mythex. Lưu lượng của chính ứng dụng bạn là việc của ứng dụng bạn: giới hạn được nói đến ở đây áp dụng cho API của chúng tôi, không phải cho các ứng dụng bạn xuất bản.

Nếu bạn tự chạy một backend, cái bẫy tương tự áp dụng cho mọi giới hạn tốc độ bạn thêm vào. Hướng dẫn của chúng tôi về API là gì và danh sách kiểm tra bảo mật cho ứng dụng xây bằng AI là chỗ tốt để bắt đầu. Và để xem một trường hợp khác của hạ tầng chúng tôi tự cản trở chính nó, xem cách chúng tôi đưa triển khai về không lỗi 502.