Зачем это нужно
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 мал).
POST /jobs→ job id (быстрый ответ).Argo Workflow или internal queue обрабатывает batch.
GET /jobs/{id}→ result из MinIO.
Gateway защищает только лёгкие endpoints; тяжёлая работа — за очередью.
Что сделать после занятия
Опишите для своего scorer: где auth, где rate limit, как versioning модели.
Проверьте, какие headers прокидывает платформа после auth (user id, tenant).
Сформулируйте один сценарий, когда sync predict через gateway недостаточен и нужен async job.