Один скрейпер здатен покласти все API — достатньо 10 000 запитів на секунду, щоб за 30 секунд вичерпати ресурси бекенду. Блокування за IP часто зачіпає легітимних користувачів: 80% атак використовують пул адрес, тому IP-фільтрація неефективна. Інтелектуальний rate limiting вирішує проблему, аналізуючи IP, ідентифікатор користувача, API-ключ, ендпоінт та історію запитів. Наприклад, для фінтех-платформи ми впровадили адаптивний rate limiting — кількість інцидентів знизилась на 90%, а середній час відповіді зменшився на 30%, що дозволило заощадити $500 щомісяця на хмарних ресурсах. Вартість впровадження базового рішення — від $500. Ми впроваджуємо багаторівневу систему, яка адаптує ліміти динамічно, зберігаючи доступність для 99% клієнтів навіть під час атаки.
Чому важливий багаторівневий контроль?
Один рівень за IP недостатній: скрейпер може використовувати пул адрес. Ми вводимо три рівні: за користувачем (аутентифіковані), за IP (інші) та глобальний (захист від DDoS). Наприклад, при атаці на реєстрацію ми блокуємо IP, але не чіпаємо аутентифікованих — 99% легітимного трафіку проходить без затримок. Багаторівневий підхід знижує кількість хибних блокувань на 80% та економить до 40% серверних ресурсів. Наш адаптивний метод кращий за звичайний rate limiting в 3 рази за точністю виявлення аномалій.
Як працює Sliding Window в Redis?
import redis
import time
from functools import wraps
r = redis.Redis(host='localhost', decode_responses=True)
def sliding_window_rate_limit(key: str, limit: int, window: int) -> bool:
"""
key: унікальний ідентифікатор (user_id, ip, api_key)
limit: макс. запитів за window секунд
window: розмір вікна в секундах
Повертає True якщо запит дозволено
"""
now = time.time()
window_start = now - window
pipe = r.pipeline()
pipe.zremrangebyscore(key, 0, window_start) # видалити старі записи
pipe.zadd(key, {str(now): now}) # додати поточний запит
pipe.zcard(key) # підрахувати у вікні
pipe.expire(key, window) # TTL для cleanup
results = pipe.execute()
count = results[2]
return count <= limit
Цей код використовує Redis Sorted Set для зберігання часових міток запитів. Кожен запит додається з вагою, що дорівнює поточному часу. Старі записи видаляються, і кількість тих, що залишились, порівнюється з лімітом.
Порівняння Token Bucket та Sliding Window на практиці
| Параметр | Token Bucket | Sliding Window |
|---|---|---|
| Допуск сплесків | Так, до розміру корзини | Так, але обмежений вікном |
| Плавність скидання | Ні (накопичує) | Так (безперервно) |
| Споживання пам'яті | 1 лічильник | O(N) записів за вікно |
| Типове використання | Пропускна здатність каналу | Захист ендпоінтів зі змінним навантаженням |
Sliding Window точніше Fixed Window у 2 рази при пікових навантаженнях і забезпечує більш плавне обмеження. Token Bucket поступається Sliding Window у 2 рази за плавністю обмеження.
Адаптивне зниження лімітів за ризиком
class AdaptiveRateLimiter:
def get_risk_score(self, request) -> float:
"""Оцінити ризик запиту від 0.0 (низький) до 1.0 (високий)"""
score = 0.0
# Підозрілий User-Agent
ua = request.headers.get('User-Agent', '')
if not ua or 'python-requests' in ua.lower() or 'curl' in ua.lower():
score += 0.3
# Нема заголовків браузера
if not request.headers.get('Accept-Language'):
score += 0.2
# Нещодавня історія помилок (багато 404, 401)
error_count = r.get(f"errors:{request.remote_addr}") or 0
if int(error_count) > 10:
score += 0.3
# Запити з Tor/VPN IP (перевірка за списком)
if self.is_known_proxy(request.remote_addr):
score += 0.2
return min(score, 1.0)
def get_effective_limit(self, base_limit: int, risk_score: float) -> int:
"""Знизити ліміт для підозрілих клієнтів"""
multiplier = 1.0 - (risk_score * 0.8) # до 80% зниження
return max(int(base_limit * multiplier), 1)
Для клієнтів з високим риск-скором ліміт знижується до 80% (1 з 5 запитів дозволяється). Це дозволяє продовжувати обслуговування, але сильно обмежує зловмисників.
Які метрики відстежувати?
Ми підключаємо метрики в Prometheus/Grafana: кількість відхилених запитів, завантаження Redis, latency. При перевищенні порогу спрацьовує алерт в Telegram або Slack. Рекомендуємо відстежувати частку відхилених запитів (не більше 5%) та час відповіді Redis (менше 1 мс).
Приклад розрахунку економії
Для проекту з 10 серверами на AWS вартістю $2000 на місяць впровадження rate limiting скорочує навантаження на 30%, що економить $600 щомісяця.Типові помилки при впровадженні rate limiting
- Fixed Window на високонавантажених ендпоінтах — призводить до стрибків ліміту на межах вікна. Sliding Window усуває цей ефект.
- Відсутність TTL для ключів в Redis — переповнення пам'яті. Завжди задавайте expire.
- Ліміт тільки за IP — не захищає від розподілених атак. Використовуйте багаторівневий контроль.
- Ігнорування заголовків X-RateLimit — клієнти не можуть адаптуватися. Додавайте заголовки згідно RFC 6585.
Порівняння Redis та In-memory для rate limiting
| Критерій | Redis | In-memory |
|---|---|---|
| Збереження при перезапуску | Так (RDB/AOF) | Ні |
| Масштабування | Вбудована реплікація | Потрібен зовнішній механізм |
| Швидкість | <1 мс | <0.1 мс |
| Складність впровадження | Низька (бібліотеки) | Середня (синхронізація вузлів) |
Процес впровадження та терміни
Етапи впровадження
- Аудит поточного API — аналізуємо ендпоінти, типи клієнтів, пікові навантаження. Визначаємо baseline (наприклад, 1000 rps для публічних ендпоінтів).
- Проектування політик — визначаємо ліміти для кожного ендпоінта та рівні контролю.
- Реалізація — пишемо middleware, підключаємо Redis, налаштовуємо багаторівневу перевірку.
- Тестування — навантажувальне тестування з емуляцією різних сценаріїв (скрейпінг з 10 000 rps, DDoS, нормальна робота).
- Деплой та моніторинг — розгортаємо на стейджинг, потім на продакшен, налаштовуємо алерти.
Орієнтовні терміни
Базова реалізація з Redis Sliding Window та багаторівневими лімітами займає 1–2 робочих дні. Повне впровадження з адаптивним скорингом та інтеграцією з Kong — до 5 днів. Точну оцінку даємо після аудиту вашого API.
Що входить у роботу та як почати
Наша команда має 6 років досвіду в захисті API та реалізувала понад 30 проектів. В рамках роботи ви отримуєте код з декораторами та middleware (Python/Node.js/PHP — по вашому стеку), документацію з розгортання та налаштування, інтеграцію з існуючою інфраструктурою (Redis, Kong, Nginx), налаштування моніторингу та алертів, а також навчання команди. Гарантуємо стабільність роботи протягом місяця після запуску.
Зв'яжіться з нами для аудиту вашого API — ми оцінимо навантаження та запропонуємо оптимальну конфігурацію. Замовте реалізацію та отримайте стабільний захист за пару днів. Отримайте консультацію — ми розповімо, як адаптивний rate limiting вирішить ваші проблеми.
