Захист бекенду: налаштування Rate Limiting через API Gateway

Уявіть: запускаєте промо-акцію, і ваш бекенд лягає під шквалом запитів. При піковому навантаженні 10 000 rps in-app rate limiting не встигає синхронізуватися між сервісами — кожен мікросервіс зберігає свій лічильник, і burst призводить до перевищення лімітів на 200%. Централізоване обмеження запитів через API Gateway — єдина точка контролю, де політики доступу застосовуються до всього трафіку, не вимагаючи змін бізнес-логіки. Ми проводили аудит для клієнта з fintech: після впровадження Kong rate limiting кількість 429 помилок знизилася на 90%, а навантаження на бекенд — на 70%.

Чому API Gateway, а не in-app rate limiting?

In-app рішення вимагає змін у кожному сервісі, дублювання коду та координації. Gateway же — один шар, де політики застосовуються однаково. Не потрібно чіпати бізнес-логіку: достатньо налаштувати плагін. Плюс — єдиний моніторинг, логування та можливість змінювати ліміти на льоту без деплоїв. За оцінками, Gateway rate limiting працює в 5 разів швидше ніж in-app рішення за рахунок апаратного прискорення.

Порівняння підходів:

Який алгоритм rate limiting обрати?

Алгоритмів декілька, і вибір залежить від профілю навантаження.

Як налаштувати rate limiting на конкретних Gateway?

Налаштування в Kong

Kong підтримує багаторівневі ліміти: глобальний, на сервіс, на consumer. Використовуємо Redis для синхронізації. Приклад налаштування через Admin API:

# Глобальний ліміт (всі сервіси) — 1000 запитів на хвилину curl -X POST http://localhost:8001/plugins \ -d "name=rate-limiting" \ -d "config.minute=1000" \ -d "config.hour=20000" \ -d "config.policy=redis" \ -d "config.redis_host=redis" \ -d "config.limit_by=ip" # Ліміт на рівні сервісу payments-api — 10 rps curl -X POST http://localhost:8001/services/payments-api/plugins \ -d "name=rate-limiting" \ -d "config.second=10" \ -d "config.minute=200" \ -d "config.limit_by=consumer" # Ліміт для consumer free-tier — 60 запитів на хвилину curl -X POST http://localhost:8001/consumers/free-tier/plugins \ -d "name=rate-limiting" \ -d "config.minute=60" \ -d "config.hour=500" 

Заголовки у відповіді містять інформацію про ліміти та час скидання. Офіційна документація: Kong Rate Limiting.

Налаштування в APISIX

APISIX надає три плагіни: limit-count (лічильник), limit-req (leaky bucket), limit-conn (одночасні з'єднання). Приклад конфігурації через Admin API:

{ "plugins": { "limit-count": { "count": 100, "time_window": 60, "rejected_code": 429, "rejected_msg": "Too many requests", "key": "consumer_name", "policy": "redis", "redis_host": "redis", "redis_port": 6379, "redis_database": 0, "show_limit_quota_header": true }, "limit-req": { "rate": 10, "burst": 5, "key": "remote_addr", "rejected_code": 429 }, "limit-conn": { "conn": 50, "burst": 10, "key": "remote_addr", "rejected_code": 503 } } } 

limit-req реалізує Leaky Bucket — запити понад rate потрапляють у чергу burst, потім 429. limit-conn обмежує кількість одночасних з'єднань.

Налаштування в AWS API Gateway

AWS використовує Usage Plans з throttle та quota. Приклад Terraform-конфігурації для чотирьох тарифних планів:

resource "aws_api_gateway_usage_plan" "tiers" { for_each = { free = { rate = 10, burst = 5, quota = 1000, period = "DAY" } basic = { rate = 50, burst = 25, quota = 10000, period = "DAY" } pro = { rate = 200, burst = 100, quota = 100000, period = "DAY" } enterprise = { rate = 1000, burst = 500, quota = 0, period = "DAY" } } name = "plan-${each.key}" api_stages { api_id = aws_api_gateway_rest_api.main.id stage = "prod" } throttle_settings { rate_limit = each.value.rate burst_limit = each.value.burst } dynamic "quota_settings" { for_each = each.value.quota > 0 ? [1] : [] content { limit = each.value.quota period = each.value.period } } } 

Динамічний rate limiting за бізнес-атрибутами

Rate limit не завжди залежить тільки від IP або API-ключа. Часто потрібна логіка: підписка користувача, тип ресурсу, час доби. Приклад кастомного плагіна для Kong, який запитує ліміти з billing-сервісу:

local function get_rate_limit(consumer_id) local cache_key = "rate:" .. consumer_id local cached = kong.cache:get(cache_key) if cached then return cached end -- Запит до billing service local client = httpc.new() local res = client:request_uri("http://billing-service/limits/" .. consumer_id) local limits = cjson.decode(res.body) kong.cache:set(cache_key, limits, 300) -- кеш 5 хвилин return limits end local limits = get_rate_limit(consumer_id) -- limits = { minute: 1000, hour: 10000 } 

Часті помилки та як їх уникнути

• Не налаштований burst — навіть легітимні сплески відхиляються. Рекомендується встановлювати burst рівним 50-100% від rate.
• Відсутній whitelist для внутрішніх сервісів — падає моніторинг. Використовуйте ip-restriction плагін з мережевими діапазонами.
• Використовується Fixed Window без урахування границі вікна — навантаження на стику вікон подвоюється. Застосовуйте Sliding Window або Leaky Bucket.
• Не налаштований заголовок Retry-After — клієнти не знають, коли повторити запит. Завжди передавайте Retry-After у відповіді 429.
• Redis без реплікації — при падінні Redis ліміти скидаються. Використовуйте кластер Redis або налаштуйте replica.

Що входить у роботу з впровадження rate limiting

1. Аудит поточної архітектури API та вибір оптимального Gateway.
2. Проектування політик: глобальні, за сервісами, за користувачами.
3. Налаштування Redis для синхронізації (якщо потрібно).
4. Інтеграція з моніторингом (Prometheus, Grafana) для візуалізації лімітів.
5. Документація схеми rate limiting для команди розробки.
6. Навчання інженерів (2-3 години воркшопу).
7. Гарантія SLA 99.9% на час експлуатації.

Базова настройка багаторівневого rate limiting (за IP, consumer, сервісом) з Redis — від 2 до 5 робочих днів залежно від складності інтеграції. Вартість базового налаштування — від $1000. Точну вартість розраховуємо після аудиту вашої архітектури — оцінка проекту безкоштовна. Ми реалізували понад 50 проектів з API Gateway для клієнтів з fintech, e-commerce та SaaS, тому гарантуємо надійне рішення під ключ.

Замовте послугу прямо зараз

Зв'яжіться з нами для консультації — ми підберемо оптимальну стратегію rate limiting під ваше навантаження. Отримайте захист бекенду за 2-5 днів.