Один скрейпер способен положить всё API — достаточно 10 000 запросов в секунду, чтобы за 30 секунд исчерпать ресурсы бэкенда. Блокировка по IP часто затрагивает легитимных пользователей: 80% атак используют пул адресов, поэтому IP-фильтрация неэффективна. Rate limiting решает проблему, анализируя IP, идентификатор пользователя, API-ключ, эндпоинт и историю запросов. Например, для финтех-платформы мы внедрили адаптивный rate limiting — количество инцидентов снизилось на 90%, а среднее время отклика уменьшилось на 30%, что позволило сэкономить $500 ежемесячно на облачных ресурсах. Мы внедряем многоуровневую систему, которая адаптирует лимиты динамически, сохраняя доступность для 99% клиентов даже во время атаки.
Почему важен многоуровневый контроль?
Один уровень по IP недостаточен: скрейпер может использовать пул адресов. Мы вводим три уровня: по пользователю (аутентифицированные), по IP (остальные) и глобальный (защита от DDoS). Например, при атаке на регистрацию мы блокируем IP, но не трогаем аутентифицированных — 99% легитимного трафика проходит без задержек. Многоуровневый подход снижает количество ложных блокировок на 80% и экономит до 40% серверных ресурсов.
Как работает 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 раза при пиковых нагрузках и обеспечивает более плавное ограничение.
Адаптивное снижение лимитов по риску
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.
Что получаете в итоге и как начать
В рамках работы вы получаете код с декораторами и middleware (Python/Node.js/PHP — по вашему стеку), документацию по развертыванию и настройке, интеграцию с существующей инфраструктурой (Redis, Kong, Nginx), настройку мониторинга и алертов, а также обучение команды. Гарантируем стабильность работы в течение месяца после запуска.
Свяжитесь с нами для аудита вашего API — мы оценим нагрузку и предложим оптимальную конфигурацию. Закажите реализацию и получите стабильную защиту за пару дней. Получите консультацию — мы расскажем, как адаптивный rate limiting решит ваши проблемы.