Flask‑прокси даёт HTTPS‑доступ к Amazon SageMaker MLflow без использования MLflow SDK

В статье показано, как реализовать безопасный промежуточный сервис на Flask, который вместе с Application Load Balancer обеспечивает HTTPS‑доступ к Amazon SageMaker MLflow и устраняет необходимость в MLflow SDK для клиентских приложений.

В посте описана реализация прокси‑сервиса на Flask, позволяющего стандартным HTTPS‑эндпойнтам обращаться к Amazon SageMaker MLflow без установки MLflow SDK у клиентов. Это важно для команд, которые из‑за корпоративных политик безопасности, сетевых ограничений или унаследованной инфраструктуры не могут применять SDK-прокси сохраняет существующие рабочие процессы при миграции в облако. Для инженеров ключевое практическое преимущество — доступ через привычные HTTPS‑интерфейсы при централизованном управлении аутентификацией и снижении накладных расходов на поддержку клиентов.

Архитектура решения состоит из трёх основных компонентов: Application Load Balancer (ALB) для входящего трафика, Python‑приложения на Flask в роли MLflow‑прокси и управляемого сервиса Amazon SageMaker MLflow. ALB выполняет распределение трафика, маршрутизацию, поддержку пользовательских доменов и SSL‑терминацию; Flask‑прокси перехватывает HTTPS‑запросы, обрабатывает AWS‑аутентификацию, при необходимости пред‑подписывает URL и преобразует запросы перед пересылкой. SageMaker MLflow в этой связке предоставляет режимы MLflow Tracking Server и MLflowApp, а также хранение метаданных и артефактов, обеспечивая совместимость с функциональностью MLflow.

Материал подчёркивает практические приложения и преимущества подхода для организаций: бесшовная интеграция с унаследованными системами при соблюдении требований безопасности, уменьшение зависимости от клиентских библиотек и упрощение сопровождения SDK‑клиентов. Авторы указывают, что вместо ALB при необходимости можно использовать альтернативные маршрутизаторы, например Nginx, если это лучше соответствует корпоративным требованиям. Отсутствие прямой зависимости от MLflow SDK облегчает взаимодействие с существующими сервисами и снижает барьеры при переходе команд в облако.

Внедрение потребует настройки IAM‑аутентификации, управления пред‑подписанными URL и реализации логики трансформации запросов в прокси, но в итоге упрощает интеграцию и централизует контроль доступа. Поток запросов реализован следующим образом: клиент отправляет HTTPS‑запрос на ALB; ALB перенаправляет его в Flask‑прокси; прокси выполняет AWS‑аутентификацию, при необходимости пред‑подписывает и преобразует URL и пересылает аутентифицированный запрос в SageMaker MLflow; ответ возвращается через прокси клиенту. Такой подход сохраняет совместимость с корпоративными сетями и позволяет централизовать управление доступом, снижая сложность сопровождения клиентских SDK.