«Управление, а не настройка»: AWS разложила администрирование SageMaker HyperPod на четыре уровня контроля

Проблема не в настройке, а в управлении

Amazon SageMaker HyperPod даёт командам машинного обучения доступ к большим пулам ускоренных вычислений для обучения и донастройки моделей. Пока такой кластер есть у одной команды, его техническая настройка обычно не вызывает трудностей; сложное начинается, когда кластер делят несколько команд, — тогда нужно решить, кому вообще можно им пользоваться, сколько ёмкости получает каждая команда, что происходит, когда нагрузки конкурируют за ресурсы, и кто отвечает, когда использование отходит от политики.

Amazon SageMaker Unified Studio добавляет ещё одно измерение: кластер HyperPod можно подключить к проекту, и участники смогут запускать нагрузки прямо из рабочего пространства проекта, просматривать сведения о кластере и задачах и открывать рабочий процесс JupyterLab. Удобство это ценное, но как только несколько команд получают видимость одного и того же кластера, контроль над тем, кто и что может делать, становится ещё важнее. Руководство AWS показывает, как администрировать HyperPod через Unified Studio, не теряя базовых средств управления, и предлагает повторяемую модель: команды ML получают одобренные вычисления в контексте своих проектов, а операции с кластером остаются у инфраструктурной команды.

Четыре слоя контроля

AWS разбирает четыре границы, каждая из которых отвечает на свой вопрос и опирается на свой набор средств. Организацию регулируют домены и доменные единицы SageMaker Unified Studio, связанные аккаунты, профили проектов и политики авторизации — они определяют, кто может создавать проекты, какие аккаунты и регионы доступны проектам и какие инструменты им открыты.

Проект задаёт контекст совместной работы и доступные участникам ресурсы AWS: его регулируют членство в проекте, роли и подключения SageMaker HyperPod. Кластером управляют административные роли HyperPod, записи доступа Amazon EKS, управление доступом на основе ролей (RBAC) и EKS Pod Identity — либо средства Slurm; это отвечает за конфигурацию кластера, доступ к планировщику, пространства имён, задачи и инфраструктурные операции. Рабочую нагрузку регулируют распределение вычислений, классы приоритета, политики «одалживания» и «заимствования» ёмкости и права на задачи — то есть кто может отправлять работу и как распределяется общая ёмкость.

Подчёркивается, что это именно слои: подключение HyperPod добавляет одобренный кластер в проект, но не заменяет контроль IAM, Amazon EKS или Slurm. Роль проекта, роль доступа подключения, записи доступа EKS и RBAC (или средства Slurm), идентичность рабочей нагрузки, политики данных и ключей AWS KMS, сетевые политики, ограничения видимости задач и политику планировщика следует рассматривать вместе — и открывать кластер командам только после того, как эти средства согласованы между собой.

Проект — это не граница безопасности

AWS прямо предупреждает: проекты SageMaker Unified Studio — это границы сотрудничества, а не сильные границы безопасности времени выполнения. Кластер HyperPod, планировщик и дефицитную ускоряющую ёмкость рекомендуется держать в одном выделенном аккаунте ёмкости, а доступ из аккаунтов-потребителей выдавать через одобренные кросс-аккаунтные роли, вместо того чтобы делать каждый аккаунт-потребитель самостоятельным администратором ёмкости.

Для кластеров Amazon EKS публикация советует выделять пространство имён на арендатора вместе с RBAC, отдельными сервисными аккаунтами и ролями EKS Pod Identity, сетевыми политиками по принципу «запрещено по умолчанию» и отдельными правами на хранилище и ключи AWS KMS. Для кластеров Slurm — учёт с иерархическими аккаунтами и ассоциациями, quality of service, политики приоритета и fair-share, а также партиции, плюс идентичность и права файловой системы операционной системы, сетевые ограничения и отдельные пути к данным. Доступ к бакетам Amazon S3, ключам AWS KMS, секретам, реестрам контейнеров и другим сервисам данных AWS советует выдавать ролями и ресурсными политиками IAM, а не одним лишь членством в проекте; политики проектов и доменных единиц нужны для сотрудничества и делегирования. Для более жёсткой изоляции внутри кластера публикация предлагает выделенные узлы или группы узлов и средства контроля допуска, а когда этого требуют юридические, регуляторные или связанные с безопасностью условия, — отдельный кластер или аккаунт.

Идентичность и видимость задач

Контролировать нужно не только действия, но и видимость: неправильно заданные имена задач, пространства имён, запросы ресурсов и шаблоны использования могут раскрывать информацию о работе другой команды. По документации, пользователи SageMaker AI Studio по умолчанию видят все задачи кластера Amazon EKS, а в кластерах Slurm каждый пользователь Studio может просматривать доступные задачи, управлять ими и взаимодействовать с ними; поэтому ограничения видимости задач нужно настраивать до того, как к кластеру подключат несколько команд. Членство в проекте при этом не является границей безопасности уровня кластера.

Для кластеров Amazon EKS AWS советует сопоставлять каждой команде одобренное пространство имён и права RBAC, а каждому сервисному аккаунту рабочей нагрузки — роль IAM, специфичную для арендатора. Для кросс-аккаунтного доступа к данным сервисный аккаунт связывается с ролью EKS Pod Identity в аккаунте ёмкости, а целевая роль задаётся параметром targetRoleArn: тогда EKS Pod Identity сам выполняет принятие кросс-аккаунтной роли, и коду приложения не нужно вызывать AssumeRole, а целевая роль живёт в аккаунте-потребителе или аккаунте данных. Право лишь просматривать работу публикация предлагает держать отдельно от права создавать, изменять или удалять нагрузки: в примере приводится Kubernetes-роль RBAC, дающая команде доступ только на чтение задач в её собственном пространстве имён, тогда как для создания или удаления нагрузок требуется отдельная роль.

Приоритеты бизнеса — в политику планировщика

Авторизацию и планирование AWS советует держать раздельно: RBAC в Amazon EKS или списки контроля доступа в Slurm определяют, может ли пользователь вообще отправить нагрузку, а task governance в HyperPod для EKS или нативные средства планирования Slurm — когда именно эта авторизованная нагрузка получит вычисления. Использование квоты планировщика как средства контроля доступа, или наоборот, применение средств авторизации как политики планирования, даёт неоднозначное поведение и усложняет разбор инцидентов.

Пример из публикации: команде производственного обучения можно дать гарантированные 60 % ёмкости с высоким классом приоритета, исследовательская команда берёт простаивающую ёмкость по более низкому приоритету, а когда производственная команда отправляет работу, эта заимствованная ёмкость может быть вытеснена. У каждого исключения должен быть ровно один владелец, который его одобряет, — иначе разовые просьбы незаметно становятся нормой. Отдельно оговаривается, что task governance распространяется и на SageMaker HyperPod spaces — самодостаточные среды JupyterLab или Code Editor, работающие прямо на кластере, — поэтому интерактивные среды разработки тоже нужно включать в политику распределения.

Наблюдаемость как контур обратной связи

Наблюдаемость AWS предлагает трактовать как петлю: следить за сигналами, сравнивать их с замыслом политики, принимать решение и корректировать политику и распределение, назначая владельца и реакцию на каждый сигнал. Среди сигналов публикация перечисляет загрузку ёмкости кластера и акселераторов, распределение и использование по командам, время выполнения и ожидания задач, ожидающие и вытесненные задачи, а также события здоровья и восстановления узлов. Каждый такой сигнал превращается в административное решение: например, низкая загрузка требует понять, временная она, вызвана политикой или ограничениями нагрузок, а вытесненные задачи — проверить, совпадают ли результаты планировщика с утверждённой моделью приоритетов.

Для документированных представлений метрик нужен аддон Amazon CloudWatch Observability для EKS: у него свои предварительные условия — версия 2.4.0 или новее и политика CloudWatchAgentServerPolicy, прикреплённая к роли рабочих узлов Kubernetes. Метрики Kueue, питающие представления task governance, после бесплатного уровня могут приводить к расходам CloudWatch. Отдельно AWS предупреждает, что таблица задач в EKS показывает задачи Kubeflow (PyTorch, MPI и TensorFlow), причём PyTorch — по умолчанию, и нагрузки, отправленные другими способами, там могут не отображаться, а для Slurm таблицы показывают задания в текущей очереди планировщика, тогда как исторические данные доступны через учёт Slurm и утилиты вроде sacct.

Жизненный цикл подключения

AWS советует задать расписание проверок для каждого подключения и дополнительно пересматривать их по событиям: при смене владельца проекта, ролей доступа, аккаунта или региона, ёмкости кластера, версии оркестратора, классификации данных или охвата мониторинга. Решение фиксируется в «контракте подключения» — это управленческая запись на стороне клиента (страница вики, тикет, запись в сервис-каталоге или файл в репозитории инфраструктуры как кода), а не функция платформы.

В контракте AWS предлагает фиксировать бизнес-владельца, операционного и финансового владельца; доменную единицу и проект Unified Studio; аккаунт, регион, имя и оркестратор кластера; роль проекта и ARN роли доступа, используемой подключением; одобренные типы нагрузок и классификацию данных; пространства имён EKS или область доступа Slurm; политику планирования и владельца исключений; ожидания по мониторингу, поддержке и выводу из эксплуатации. Такой контракт, по замыслу, даёт проверяющим одну запись для оценки и одобрения всего пути доступа.

Начинать AWS рекомендует с одного не участвующего в проде кластера и тестового проекта: сначала настроить идентичность нагрузок, пространство имён или область Slurm, права на данные, сетевую политику, ограничения видимости задач и task governance для EKS или нативные средства планирования для Slurm, установить аддон Amazon CloudWatch Observability, чтобы представления метрик заполнялись, и только потом добавлять участников. Автоматизировать сбор инвентаря и доказательств стоит там, где это снижает ручную работу, но одобрение должно оставаться за ответственными администраторами; подключения, у которых больше нет бизнес-цели или ответственного владельца, следует отзывать.