Захист бекенду: налаштування 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 днів.