Реалізація кешування відповідей на рівні API Gateway

Реалізація кешування відповідей на рівні API Gateway

Кеш на рівні gateway працює до того, як запит доходить до бекенду. Правильно налаштоване кешування прибирає 30–70% навантаження з сервісів без змін їхнього коду. Неправильно налаштоване — віддає чужі дані чужим користувачам або тримає застарілі відповіді днями.

Що кешувати, а що ні

Безпечно кешувати:

• GET-запити з публічними даними (каталог, довідники, статті)
• Відповіді з явним Cache-Control: public, max-age=N від upstream
• Endpoints, які не залежать від ID сесії

Не кешувати:

• Будь-які POST, PUT, PATCH, DELETE
• Запити з заголовком Authorization: Bearer ... — якщо тільки не налаштована ізоляція за користувачем
• Відповіді зі статусом 4xx/5xx (крім 404 для публічних ресурсів, якщо це усвідомлено)
• Дані з персональною інформацією

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 — стратегія redis замість memory:

      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

В AWS нативного кешу на рівні gateway немає для HTTP APIs, але є для REST APIs:

{
  "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

Якщо gateway на Nginx:

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: користувач отримує старий виклик миттєво, оновлення йде у фоні. Критично для навантажених endpoints.

Vary та кеш-простори

Якщо API відає різні відповіді залежно від заголовків, налаштуйте ключ кешу правильно. Типовий приклад — багатомовний API:

# Розділяємо кеш за мовою
proxy_cache_key "$scheme$request_method$host$uri$is_args$args$http_accept_language";

В Kong через vary_headers:

    config:
      vary_headers:
        - Accept-Language
        - Accept-Encoding

Без цього перший користувач з Accept-Language: en «займає» кеш, і всі інші отримують англійську відповідь.

Cache stampede

При істеченні TTL популярного ключа кілька воркерів одночасно йдуть до upstream — «кеш-шторм». Захист:

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

Графік

Базова настройка кешу для 2–3 routes: 1 день. Повноцінна стратегія з інвалідацією, Vary, моніторингом hit rate та stale-while-revalidate: 3–5 днів.