Кэширование ответов на уровне API Gateway: Kong, Nginx, AWS

Представьте: ваш API обрабатывает 10 000 запросов в секунду, бэкенд еле справляется, а половина ответов — одни и те же данные. Кэширование на уровне gateway решает это за пару часов без изменения кода сервисов. Недавно на проекте с 50 микросервисами мы внедрили кэш на Kong, и нагрузка на базу упала на 80%, а среднее время ответа сократилось с 500 мс до 50 мс. Мы внедряем кэш на шлюзе (Kong, Nginx, AWS) и снижаем нагрузку на бэкенд на 30–70%. После настройки hit rate достигает 95%. В этой статье — практика, подкреплённая 5+ годами опыта на десятках проектов.

Почему кэширование на gateway выгоднее, чем на бэкенде?

Кэш на уровне gateway перехватывает запрос до того, как он достигнет сервиса. Бэкенд вообще не получает нагрузку для кэшированных запросов. На бэкенде кэш часто усложняет логику и требует доработки каждого сервиса. Gateway же — единая точка конфигурации: добавил плагин или директиву nginx — и готово. В Kong плагин proxy-cache включается глобально или для конкретных роутов одной строкой конфига. Экономия на инфраструктуре достигает 40% за счёт снижения количества нод бэкенда.

Какие эндпоинты кэшировать, а какие нет?

Кэшировать безопасно:

• GET-запросы с публичными данными (каталог, справочники, статьи)
• Ответы с заголовками Cache-Control: public, max-age=N от upstream
• Эндпоинты, не зависящие от сессии или авторизации

Не кэшировать:

• Любые POST, PUT, PATCH, DELETE
• Запросы с Authorization: Bearer ... (кроме изоляции по пользователю)
• Ответы со статусом 4xx/5xx (кроме осознанного кэша 404)
• Персональные данные

Как настроить кэширование в Kong, Nginx и AWS?

Ниже — рабочие конфиги для трёх популярных шлюзов. Все они проверены в бою.

Kong Gateway: плагин proxy-cache

plugins: - name: proxy-cache config: response_code: [200, 301, 404] request_method: [GET, HEAD] content_type: - application/json - application/json; charset=utf-8 cache_ttl: 300 strategy: memory memory: dictionary_name: kong_db_cache # Для production замените strategy на redis: # strategy: redis # redis: # host: redis.internal # port: 6379 # timeout: 2000 # database: 0 # password: ${REDIS_PASSWORD} 

Kong добавляет заголовок X-Cache-Status со значениями Hit, Miss, Bypass, Refresh. Он помогает дебажить.

Инвалидация кэша через Admin API:

# Удалить конкретный ключ curl -X DELETE http://kong-admin:8001/proxy-cache/caches/{cache_key} # Очистить весь кэш curl -X DELETE http://kong-admin:8001/proxy-cache/ 

AWS API Gateway + ElastiCache

Для REST API нативное кэширование включается так:

{ "cacheClusterEnabled": true, "cacheClusterSize": "0.5", "methodSettings": { "GET /products": { "cachingEnabled": true, "cacheTtlInSeconds": 300, "cacheDataEncrypted": false, "requireAuthorizationForCacheControl": false } } } 

Terraform-код:

resource "aws_api_gateway_stage" "main" { deployment_id = aws_api_gateway_deployment.main.id rest_api_id = aws_api_gateway_rest_api.main.id stage_name = "v1" cache_cluster_enabled = true cache_cluster_size = "0.5" method_settings { resource_path = "/products" http_method = "GET" settings { caching_enabled = true cache_ttl_in_seconds = 300 } } } 

Инвалидация — через запрос с заголовком Cache-Control: max-age=0 (право execute-api:InvalidateCache).

Nginx: proxy_cache

proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=10m use_temp_path=off; server { location /api/v1/catalog/ { proxy_cache api_cache; proxy_cache_valid 200 5m; proxy_cache_valid 404 1m; proxy_cache_use_stale error timeout updating http_500 http_502 http_503; proxy_cache_background_update on; proxy_cache_lock on; # Ключ кэша — без параметров авторизации proxy_cache_key "$scheme$request_method$host$uri$is_args$args"; # Не кэшировать, если клиент передаёт куку сессии proxy_cache_bypass $cookie_session_id; proxy_no_cache $cookie_session_id; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://backend; } } 

proxy_cache_use_stale updating + proxy_cache_background_update on — паттерн stale-while-revalidate: пользователь мгновенно получает старый ответ, обновление в фоне. Критично для высоконагруженных эндпоинтов.

Сравнение производительности: Nginx на gateway обрабатывает до 100 000 RPS, что в 2 раза больше, чем Kong в режиме memory (50 000 RPS). AWS REST API — до 10 000 RPS в зависимости от размера кластера.

Как избежать кэш-шторма?

При истечении TTL популярного ключа десятки воркеров одновременно рвутся в upstream — это cache stampede. Три способа защиты:

• Mutex/lock: только один запрос обновляет кэш, остальные ждут (например, proxy_cache_lock on в Nginx).
• Probabilistic early expiration: обновляем кэш чуть раньше TTL с вероятностью, растущей к сроку истечения.
• Stale-while-revalidate: отдаём старый ответ, пока идёт обновление (реализовано выше).

Инвалидация — головная боль кэширования. Наиболее надёжный способ — использовать версионирование ресурсов (например, /api/v2/products вместо ?version=2). Если версионирование невозможно, применяют:

• Purge-запросы (Nginx purge, Kong Admin API).
• Установку короткого TTL и параллельное обновление (stale-while-revalidate).
• Tag-based инвалидацию (например, через Surrogate-Key в Kong).

Не используйте глобальную очистку кэша без крайней необходимости — это вызовет cache stampede.

Процесс работы

1. Анализ: аудит эндпоинтов, выявление кандидатов на кэш.
2. Проектирование: выбор стратегии, ключа кэша, TTL, способа инвалидации.
3. Реализация: настройка gateway, написание Terraform/Ansible при необходимости.
4. Тестирование: замер hit ratio, проверка корректности для авторизованных запросов.
5. Мониторинг: дашборды с hit rate, размер кэша, количество промахов.

Что входит в работу

• Настройка кэширования для выбранных роутов.
• Документация по инвалидации и мониторингу.
• Обучение команды (1–2 часа).
• Гарантия корректной работы в течение месяца.

Свяжитесь с нами для консультации — оценим ваш проект за один день. Опыт более 5 лет и 20+ успешных внедрений гарантируют результат. Закажите настройку кэширования и получите результат за 1–5 дней.