3.6.4 · блок 3

API Gateway: паттерны для ML-сервисов

Зачем это нужно

Inference endpoint — публичный API с SLA, биллингом и рисками (злоупотребление, утечка модели). API Gateway pattern — единая точка для auth, rate limiting, routing версий модели, иногда request/response transformation. На MDP это часто реализовано связкой Istio Gateway + AuthorizationPolicy + внешний IdP, а не отдельным Kong — но паттерны универсальны.

ML-инженер должен проектировать контракт API так, чтобы gateway мог его защитить без «дыр» в обход proxy.

Основные идеи

Edge vs in-app auth.

На gateway: JWT validation, API key в header, IP allowlist, OAuth2 introspection. Приложение доверяет заголовкам от mesh (или повторно проверяет — defense in depth).
В приложении: бизнес-логика авторизации («этот user видит только свои predictions»). Не дублируйте на gateway то, что требует БД.

Rate limiting. Защита GPU inference от DDoS и runaway клиентов:

global: 1000 RPS на сервис;
per API key: 10 RPS;
per model version: отдельные quotas для canary.

Реализация: Envoy filter (Istio), external rate limit service, облачный WAF.

Versioning моделей через gateway.

| Подход | Пример |

|--------|--------|

| Path | `/v1/predict`, `/v2/predict` |

| Header | `X-Model-Version: 43` |

| Host | `scorer-v43.ml.mdp.ru` |

| Weight | 90/10 canary на одном host |

Gateway маршрутизирует на разные Deployment или subset без изменения клиентского SDK (если versioning по header/path).

Request size и timeout. Batch inference с JSON 10 MB — лимит max_request_bytes на gateway. Длинный inference — async pattern (202 + callback) или streaming gRPC, не sync HTTP 120s через gateway без настройки.

Observability на edge. Gateway логирует: client_id, latency, status, model route. Корреляция с business metrics (predictions/sec per tenant) — основа для chargeback внутри компании.

Anti-patterns.

Секрет модели или training data через query string — попадёт в access logs gateway.
Публикация /admin/reload-model без auth «внутри VPN» — VPN не замена gateway policy.
Обход gateway прямым NodePort для «нагрузочного теста» в prod.

Связь с KServe/Seldon. Serving frameworks часто добавляют свой routing (InferenceService). Gateway всё равно нужен для north-south TLS и org-wide policies; внутренний router KServe — east-west или второй hop.

Как это выглядит на практике

Схема запроса с API key:


Client: POST /v1/predict
        Header: X-API-Key: ***
        Body: {"features": [...]}

→ Istio Gateway (TLS terminate)
→ AuthorizationPolicy: valid JWT or API key (via ext_authz)
→ VirtualService → Service scorer
→ Sidecar → FastAPI validates tenant from header X-User-Id
→ Response JSON + X-Request-Id для support

Helm values (концептуально):


gateway:
  hostname: scorer.ml.mdp.ru
  rateLimit:
    requestsPerSecond: 50
  auth:
    enabled: true
    issuer: https://auth.mdp.ru

Отладка 401/429.

401 — ключ/JWT; проверьте clock skew, audience claim.
429 — rate limit; смотрите headers Retry-After, метрики gateway.
413 — body too large; уменьшите batch или поднимите лимит согласованно с GPU memory.

Async inference pattern (когда gateway timeout мал).

1. POST /jobs → job id (быстрый ответ).

2. Argo Workflow или internal queue обрабатывает batch.

3. GET /jobs/{id} → result из MinIO.

Gateway защищает только лёгкие endpoints; тяжёлая работа — за очередью.

Что сделать после занятия

[ ] Опишите для своего scorer: где auth, где rate limit, как versioning модели.
[ ] Проверьте, какие headers прокидывает платформа после auth (user id, tenant).
[ ] Сформулируйте один сценарий, когда sync predict через gateway недостаточен и нужен async job.

Официальные материалы

Открыть интерактивную версию