# Spinner Rate limit ## Rate Limiting là gì? Rate limit là tùy chọn tính năng của Sun Spinner cho phép người dùng cài đặt giới hạn lượng request tiếp nhận trên mỗi route. Trong đó route là một địa chỉ kết nối mà người dùng lựa chọn để {ref}`expose dịch vụ ra ngoài Internet` Điều này có nghĩa số lượng request sẽ bị giới hạn trước khi container phải tiếp nhận và xử lý. ## Tác dụng của Rate Limiting Trong một số trường hợp người dùng sẽ muốn giới hạn số lượng request có thể tiếp nhận của ứng dụng. * Ngăn chặn DDoS/brute force: Các hành vi này có điểm chung là tạo ra một lượng lớn request đột biến, khác hẳn hành vi truy cập hoặc sử dụng ứng dụng một cách bình thường. Khi hệ thống xảy ra DDoS hoặc các hành vi brute force qua request, hệ thống sẽ chặn các request vượt ngoài policy limit, giúp bảo vệ hệ thống và giảm nguy cơ hệ thống bị treo và downtime * Giảm nguy cơ data scraping: Thông thường các hệ thống không muốn bị khai thác dữ liệu ví dụ như các content về hình ảnh sản phẩm, nội dung bài viết. Một ví dụ điển hình cho Data Scraping là crawler data từ các website thương mại điện tử. * Giới hạn tài nguyên có hạn: Tài nguyên xử lý(CPU/RAM) của container hoặc performance của ứng dụng không đủ để xử lý một lượng lớn request. ## Cách hoạt động ```{thumbnail} ../../../_static/img/spinner/reference/spinner-rate-limit-new-1.png :width: 80 % :alt: Step :align: center :title: Giao diện rate limit của Sunteco Cloud. :show_caption: True ``` Theo lý tuyết thật toán Rate limit hoạt động dựa trên việc tracking địa chỉ IP và số lượng request từ địa chỉ đó, từ đó đưa ra quyết định có giới hạn các request hay không. Rate limit sẽ giải quyết các vấn đề cốt lõi. * Giới hạn số lượng IP được truy cập đến hệ thống trong cùng một thời điểm (`i`) * Giới hạn số lượng max request từ mỗi IP gọi đến hệ thống cùng một thời điểm (`rpi`) Để đơn giản hóa quá trình cài đặt Sun Spinner sẽ ẩn đi cả hai thông số này, người dùng chỉ cần cung cấp số lượng tổng request mà route chấp nhận trong một thời điểm. `R` là tổng số request route chấp nhận. `R = i *rpi` Trong đó `R` là số lượng request người dùng nhập trên giao diện, `i` có giá trị bằng 10 do hệ thống mặc định, `rpi` sẽ được tính toán bằng `R/i`. Ví dụ với: `R= 200 request/s` , `rpi = 20`, `i =10` Khi áp dụng lý thuyết rate limiting vào thực tế, mặc dù hệ thống được thiết lập để cho phép **10 IP** thực hiện mỗi **20 request/giây**, nhưng kết quả thực tế có thể thấp hơn và đạt một giá trị tương đối gần đúng, vì có nhiều yếu tố kỹ thuật ảnh hưởng đến hiệu suất và khả năng xử lý của hệ thống. Dưới đây là một số nguyên nhân chính dẫn đến sự sai lệch giữa lý thuyết và thực tế: ### 1. Network Latency (Độ trễ mạng): * **Mô tả**: Độ trễ mạng xảy ra khi có sự chậm trễ trong việc gửi và nhận các request do khoảng cách vật lý, tình trạng mạng hoặc thời gian xử lý từ các thành phần mạng. * **Ảnh hưởng**: Khi IP gửi request đến hệ thống, có thể bị trễ từ phía client hoặc do vấn đề hạ tầng mạng, khiến hệ thống không nhận đủ lượng request như mong đợi trong một thời điểm nhất định. ### 2. Connection Overhead (Chi phí kết nối): * **Xử lý request**: Mỗi request đều yêu cầu hệ thống thực hiện các tác vụ như phân tích, xác thực, xử lý và trả lời. Quá trình này tiêu tốn tài nguyên CPU và bộ nhớ, làm giảm khả năng xử lý đồng thời của hệ thống. * **Lưu trữ trạng thái**: Hệ thống cần lưu trữ thông tin về số lượng request từ mỗi IP để thực hiện việc giới hạn. Việc truy xuất và cập nhật liên tục các thông tin này cũng tiêu tốn tài nguyên. * **Giao tiếp giữa các component**: Nếu hệ thống rate limit được phân tán thành nhiều component, việc giao tiếp giữa chúng sẽ gây ra độ trễ và tiêu tốn thêm tài nguyên. * **Ảnh hưởng**: Khi số lượng kết nối tăng lên, việc thiết lập và duy trì chúng tốn tài nguyên của hệ thống, dẫn đến việc hệ thống không thể xử lý đủ số lượng IP theo như tính toán lý thuyết, đặc biệt với các kết nối ngắn ngủi và liên tục đóng mở. ### 3. Đặc điểm của traffic: * **Burst traffic**: Các đoạn traffic ngắn nhưng có cường độ cao (burst traffic) có thể làm quá tải hệ thống tạm thời, ngay cả khi trung bình traffic không vượt quá giới hạn. * **Phân bố không đồng đều**: Nếu traffic tập trung vào một số IP hoặc một số endpoint cụ thể, hệ thống có thể dễ dàng bị quá tải tại các điểm đó. * **Loại request**: Các loại request khác nhau có thể có độ phức tạp xử lý khác nhau, ảnh hưởng đến khả năng xử lý đồng thời của hệ thống. ### 4. Client Behavior (Hành vi của client): * **Mô tả**: Các client gửi request có thể không liên tục và đồng đều. Một số IP có thể gửi ít request hơn dự kiến hoặc gặp phải giới hạn ở phía client (giới hạn băng thông, năng lực xử lý). * **Ảnh hưởng**: Điều này dẫn đến việc số lượng request tổng cộng từ phía client không đạt mức kỳ vọng, gây ra sự khác biệt giữa lý thuyết và thực tế. ### 5. Application-Level Throttling (Giới hạn ở mức ứng dụng): * **Mô tả**: Ứng dụng có thể có các giới hạn khác nhau liên quan đến việc xử lý request (như giới hạn ở mức API, giới hạn các kết nối cơ sở dữ liệu). * **Ảnh hưởng**: Nếu các giới hạn này chặt chẽ hơn so với thông số lý thuyết, hệ thống sẽ không thể xử lý đúng số lượng request mong đợi. Với những giới hạn truy cập như trên, nếu các request đến từ người dùng native vẫn có thể được hệ thống chấp nhận và xử lý, các request có dấu hiệu vi phạm sẽ bị chặn. Người dùng có thể tùy chọn tắt tính năng này nếu việc limit không phù hợp với kịch bản thực tế của ứng dụng. ## Giải pháp đề xuất: Để cải thiện hiệu suất của hệ thống rate limit, bạn có thể xem xét một số các giải pháp đề xuất của Sunteco như sau: * **Cải thiện cấu hình hệ thống**: Nâng cấp phần cứng, tối ưu hóa hệ điều hành và các phần mềm liên quan. * **Sử dụng caching**: Sử dụng caching để giảm tải cho hệ thống chính. * **Theo dõi và điều chỉnh**: Theo dõi chặt chẽ hiệu suất của hệ thống và điều chỉnh các thông số cấu hình khi cần thiết. Theo dõi tải hệ thống, thời gian phản hồi, và số lượng request. Điều này giúp bạn điều chỉnh kịp thời khi phát hiện sự cố hoặc hệ thống hoạt động dưới mức hiệu quả.