Один скрейпер здатен покласти все 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 вирішить ваші проблеми.