AWS представила два сценария кросс-аккаунтного управления моделями машинного обучения, основанных на синхронизации MLflow и SageMaker ИИ Model Registry. Материал опубликован в блоге AWS Machine Learning Blog и продолжает серию статей о том, как организовать управление моделями в масштабе предприятия. Первая часть описывала настройку одного аккаунта, где с помощью IAM-условий разделялись роли дата-сайентиста и governance-офицера. Теперь AWS расширяет подход на несколько аккаунтов, что актуально для крупных организаций, разделяющих разработку и продакшн на уровне аккаунтов.
В организациях с несколькими командами разработки часто используется центральный аккаунт для управления и governance. Первый сценарий, hub-and-spoke, предполагает, что MLflow-приложение и центральный Model Registry размещаются в аккаунте-хабе, который делится с аккаунтами-спицами (разработки) через AWS Resource Access Manager (AWS RAM). Это позволяет дата-сайентистам в аккаунтах разработки регистрировать модели в общем MLflow, при этом Model Package Group и версия создаются в аккаунте хаба. Governance-офицер утверждает модель централизованно, после чего через CI/CD она разворачивается в аккаунте разработки. Такой подход обеспечивает изоляцию рабочих нагрузок разработки, но централизует управление.
| Сценарий | Описание | Когда использовать |
|---|---|---|
| Hub-and-spoke | Централизованное управление через общий MLflow и Model Registry | Организации с несколькими командами, где нужен централизованный контроль |
| Гибридный | Изоляция аккаунтов разработки от governance-хаба | Регулируемые среды с жесткими требованиями к изоляции |
Второй сценарий — гибридный — предназначен для регулируемых сред, где предъявляются жесткие требования: аккаунты разработки не могут иметь доступ на запись в аккаунты продакшена. В этом случае аккаунты разработки полностью изолированы от governance-хаба. В каждом аккаунте разработки есть свой MLflow и Model Registry, а утверждение модели происходит локально модель-оунером перед продвижением в хаб. Это добавляет дополнительный уровень контроля, но требует больше ручной работы.
В hub-and-spoke MLflow-приложение шарится через AWS RAM, а регистрация моделей происходит в центральном аккаунте.
Оба сценария требуют предварительной настройки: два AWS-аккаунта (разработки и governance), CloudFormation-стек для развертывания SageMaker ИИ Studio, MLflow-приложения и необходимых ролей. В статье также описаны роли администратора, который выполняет разовую настройку кросс-аккаунтного доступа, и модель-оунера в гибридной топологии.
Выбор между топологиями зависит от требований организации к изоляции и централизации. Hub-and-spoke подходит для организаций, где допустимо, чтобы аккаунты разработки имели доступ к общему MLflow, но при этом нужен централизованный контроль. Гибридный сценарий — для регулируемых отраслей, где требуется строгая изоляция. AWS также приводит примеры настройки через AWS RAM, включая использование внешних принципалов для шаринга между аккаунтами, не входящими в одну организацию.
Для практического применения AWS предоставляет рабочие ноутбуки в GitHub-репозитории, а также CloudFormation-шаблоны для автоматизации развертывания. Это позволяет инженерам быстро воспроизвести описанные сценарии в своей инфраструктуре.
