Реализация 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 же — один слой, где политики применяются единообразно. Не нужно трогать бизнес-логику: достаточно настроить плагин. Плюс — единый мониторинг, логирование и возможность менять лимиты на лету без деплоев.

Сравнение подходов:

Какой алгоритм 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 рабочих дней в зависимости от сложности интеграции. Точную стоимость рассчитываем после аудита вашей архитектуры. Мы реализовали более 50 проектов с API Gateway для клиентов из fintech, e-commerce и SaaS, поэтому гарантируем надёжное решение.

Закажите услугу прямо сейчас

Свяжитесь с нами для консультации — мы подберём оптимальную стратегию rate limiting под вашу нагрузку. Получите защиту бэкенда за 2-5 дней.