Реализация 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 дней.