Налаштуйте розподіл витрат на рівні підприємства для середовищ і робочих навантажень ML за допомогою тегування ресурсів в Amazon SageMaker

Перевидано Платоном

читають: 0

Оскільки компанії та ІТ-лідери прагнуть прискорити впровадження машинного навчання (ML), зростає потреба розуміти витрати та розподіл витрат для вашого середовища ML, щоб відповідати вимогам підприємства. Без належного управління витратами ваші витрати на ML можуть призвести до сюрпризів у вашому щомісячному рахунку AWS. Amazon SageMaker – це повністю керована платформа машинного навчання в хмарі, яка надає нашим корпоративним клієнтам інструменти та ресурси для встановлення заходів розподілу витрат і покращення видимості детальних витрат і використання вашими командами, бізнес-підрозділами, продуктами тощо.

У цій публікації ми ділимося порадами та найкращими практиками щодо розподілу витрат для вашого середовища SageMaker і робочих навантажень. Майже в усіх службах AWS, включаючи SageMaker, застосування тегів до ресурсів є стандартним способом відстеження витрат. Ці теги можуть допомогти вам відстежувати, звітувати та контролювати свої витрати на машинне навчання за допомогою готових рішень, як-от AWS Cost Explorer та Бюджети AWS, а також спеціальні рішення, створені на основі даних з Звіти про вартість і використання AWS (CURs).

Позначення розподілу витрат

Процес розподілу витрат на AWS складається з трьох етапів:

Приєднувати теги розподілу вартості до ваших ресурсів.
Активуйте свої теги в Теги розподілу вартості розділ платіжної консолі AWS.
Використовуйте теги для відстеження та фільтрування звітів про розподіл витрат.

Після того як ви створите та прикріпите теги до ресурсів, вони з’являться в платіжній консолі AWS Теги розподілу вартості розділ під Визначені користувачем теги розподілу вартості. Після створення тегів може минути до 24 годин. Потім вам потрібно активувати ці теги, щоб AWS почав відстежувати їх для ваших ресурсів. Як правило, після активації тегу потрібно приблизно 24–48 годин, щоб теги відобразилися в Cost Explorer. Найпростіший спосіб перевірити, чи працюють ваші теги, — знайти новий тег у фільтрі тегів у Cost Explorer. Якщо він є, ви готові використовувати теги для звітування про розподіл витрат. Потім ви можете вибрати групування результатів за ключами тегів або фільтрування за значеннями тегів, як показано на наступному знімку екрана.

Зауважте одне: якщо ви використовуєте Організації AWS і мають пов’язані облікові записи AWS, теги можна активувати лише в обліковому записі основного платника. За бажанням ви також можете активувати CUR для облікових записів AWS, які дозволяють звіти про розподіл витрат у вигляді файлу CSV із вашим використанням і витратами, згрупованими за вашими активними тегами. Це дає вам більш детальне відстеження ваших витрат і полегшує налаштування ваших власних рішень для звітування.

Додавання тегів у SageMaker

На високому рівні тегування ресурсів SageMaker можна згрупувати в два сегменти:

Додавання тегів до середовища блокнота SageMaker також Студія Amazon SageMaker домени та користувачі домену або екземпляри блокнота SageMaker
Додавання тегів до завдань, керованих SageMaker (маркування, обробка, навчання, налаштування гіперпараметрів, пакетне перетворення тощо) і ресурсів (таких як моделі, робочі групи, конфігурації кінцевих точок і кінцеві точки)

У цьому дописі ми розглядаємо їх більш детально та пропонуємо деякі рішення щодо того, як застосувати контроль управління, щоб забезпечити належну гігієну тегування.

Позначення доменів і користувачів SageMaker Studio

Studio — це веб-інтегроване середовище розробки (IDE) для ML, яке дозволяє створювати, навчати, налагоджувати, розгортати та контролювати ваші моделі ML. Ви можете швидко запускати ноутбуки Studio та динамічно підключати або зменшувати базові обчислювальні ресурси, не перериваючи роботу.

Щоб автоматично позначати ці динамічні ресурси, потрібно призначити теги домену SageMaker і користувачам домену, яким надано доступ до цих ресурсів. Ви можете вказати ці теги в параметрі тегів створити домен or створити профіль користувача під час створення профілю чи домену, або ви можете додати їх пізніше за допомогою додати теги API. Studio автоматично копіює та призначає ці теги блокнотам Studio, створеним у домені або окремими користувачами. Ви також можете додавати теги до доменів SageMaker, редагуючи налаштування домену на панелі керування Studio.

Нижче наведено приклад призначення тегів профілю під час створення.

aws sagemaker create-user-profile --domain-id  --user-profile-name data-scientist-full --tags Key=studiouserid,Value= --user-settings ExecutionRole=arn:aws:iam:::role/SageMakerStudioExecutionRole_datascientist-full

Щоб позначити існуючі домени та користувачів, використовуйте add-tags API. Потім мітки застосовуються до будь-яких нових блокнотів. Щоб застосувати ці теги до наявних блокнотів, потрібно перезапустити програму Studio (шлюз ядра та сервер Jupyter), що належить цьому профілю користувача. Це не призведе до втрати даних блокнота. Зверніться до цього Вимкніть і оновіть SageMaker Studio та програми Studio щоб дізнатися, як видалити та перезапустити програми Studio.

Позначення екземплярів блокнота SageMaker

У разі примірника блокнота SageMaker теги застосовуються до самого примірника. Теги призначаються всім ресурсам, що працюють в одному екземплярі. Ви можете вказати теги програмно за допомогою параметра тегів у create-notebook-instance API або додайте їх через консоль SageMaker під час створення екземпляра. Ви також можете будь-коли додати або оновити теги за допомогою додати теги API або через консоль SageMaker.

Зауважте, що це виключає завдання та ресурси, якими керує SageMaker, як-от навчання та завдання обробки, оскільки вони знаходяться в середовищі служби, а не в екземплярі. У наступному розділі ми детальніше розглянемо, як застосовувати теги до цих ресурсів.

Позначення керованих завдань і ресурсів SageMaker

Для завдань і ресурсів, керованих SageMaker, теги повинні бути застосовані до tags як частину кожного запиту API. Ан SKLearnProcessor приклад проілюстровано в наступному коді. Ви можете знайти більше прикладів того, як призначити теги іншим керованим завданням і ресурсам SageMaker на GitHub репо.

from sagemaker import get_execution_role
from sagemaker.sklearn.processing import SKLearnProcessor

processing_tags = [{' Key':"cost-center','Value':'TF2WorkflowProcessing'}]
sklearn_processorl = SKLearnProcessor(framework_version='0.23-1' ,
									 role=get_execution_role(),
									 instance_type='ml.m5.xlarge',
									 instance_count=2,
									 tags=processing_tags)

Позначення конвеєрів SageMaker

У випадку конвеєрів SageMaker ви можете позначити тегами весь конвеєр загалом, а не кожен окремий крок. Конвеєр SageMaker автоматично поширює теги на кожен крок конвеєра. У вас все ще є можливість додати додаткові окремі теги до окремих кроків, якщо це необхідно. В інтерфейсі користувача Studio теги конвеєра відображаються в розділі метаданих.

Щоб застосувати теги до конвеєра, використовуйте SageMaker Python SDK:

pipeline_tags = [ {'Key': 'pipeline-type', 'Value': 'TF2WorkflowPipeline'}]
pipeline.upsert(role_arn=role, tags=pipeline_tags)
execution = pipeline.start()

Примусове додавання тегів за допомогою політик IAM

Незважаючи на те, що додавання тегів є ефективним механізмом для впровадження стратегій управління хмарою, забезпечити правильну поведінку тегів може бути складно, якщо ви просто залишите це кінцевим користувачам. Як запобігти створенню ресурсу ML, якщо певний тег відсутній, як переконатися, що застосовано правильні теги та як запобігти видаленню користувачами наявних тегів?

Ви можете зробити це за допомогою Управління ідентифікацією та доступом AWS (IAM). Наступний код є прикладом політики, яка запобігає таким діям SageMaker, як CreateDomain or CreateNotebookInstance якщо запит не містить ключа середовища та одного зі значень списку. The ForAllValues модифікатор з aws:TagKeys умова ключ вказує, що тільки ключ environment дозволено в запиті. Це запобігає випадковому використанню користувачами інших ключів Environment замість environment.

"sagemaker:CreateTrainingJob"
      ],
      "{
      "Sid": "SageMakerEnforceEnvtOnCreate",
      "Action": [
        "sagemaker:CreateDomain",
        "sagemaker:CreateEndpoint",
        "sagemaker:CreateNotebookInstance",
        Effect": "Allow",
      "Resource": "*",
  "Condition": {
            "StringEquals": {
                "aws:RequestTag/environment": [
                    "dev","staging","production"
                ]
            },
            "ForAllValues:StringEquals": {"aws:TagKeys": "environment"}
        }
      }

Політика тегів та політики контролю послуг (SCP) також може бути хорошим способом стандартизації створення та маркування ваших ресурсів ML. Щоб отримати додаткові відомості про те, як реалізувати стратегію тегування, яка забезпечує та перевіряє теги на рівні організації, зверніться до Серія блогів про розподіл витрат №3: Застосування та перевірка тегів ресурсів AWS.

Звіт про розподіл витрат

Ви можете переглянути теги, відфільтрувавши перегляди в Cost Explorer, переглянувши a щомісячний звіт про розподіл витрат, або перевіривши CUR.

Візуалізація тегів у Cost Explorer

Cost Explorer — це інструмент, який дає змогу переглядати та аналізувати свої витрати та використання. Ви можете досліджувати своє використання та витрати за допомогою основного графіка: звіти про витрати та використання Cost Explorer. Перегляньте коротке відео про використання Cost Explorer Як я можу використовувати Cost Explorer для аналізу своїх витрат і використання?

За допомогою Cost Explorer ви можете відфільтрувати перегляд своїх витрат AWS за тегами. Групувати за дозволяє фільтрувати результати за ключами тегів, наприклад Environment, Deploymentабо Cost Center. Фільтр тегів допомагає нам вибрати потрібне значення незалежно від ключа. Приклади включають Production та Staging. Майте на увазі, що ви повинні запустити ресурси після додавання та активації тегів; інакше Cost Explorer не матиме жодних даних про використання, а значення тегу не відображатиметься як фільтр або група за параметром.

Наступний знімок екрана є прикладом фільтрації за всіма значеннями BusinessUnit бирка.

Перевірка тегів у CUR

Звіт про вартість і використання містить найповніший набір доступних даних про вартість і використання. Звіт містить рядки для кожної унікальної комбінації продукту AWS, типу використання та операції, яку використовує ваш обліковий запис AWS. Ви можете налаштувати CUR для агрегування інформації за годинами або днями. Щомісячний звіт про розподіл витрат – це один із способів налаштувати звіт про розподіл витрат. Ви можете налаштувати a щомісячний звіт про розподіл витрат який містить перелік використання AWS для вашого облікового запису за категоріями продуктів і користувачами зв’язаного облікового запису. Звіт містить ті самі рядки, що й детальний платіжний звіт і додаткові стовпці для ваших ключів тегів. Ви можете налаштувати його та завантажити свій звіт, дотримуючись кроків у Щомісячний звіт про розподіл витрат.

На наступному знімку екрана показано, як визначені користувачем ключі тегів відображаються в CUR. Визначені користувачем ключі тегів мають префікс user, Такі, як user:Department та user:CostCenter. Ключі тегів, згенеровані AWS, мають префікс aws.

Візуалізуйте CUR за допомогою Amazon Athena та Amazon QuickSight

Амазонка Афіна це інтерактивна служба запитів, яка полегшує аналіз даних в Amazon S3 за допомогою стандартного SQL. У Athena немає серверів, тому немає інфраструктури для керування, і ви платите лише за запити, які виконуєте. Щоб інтегрувати Athena з CUR, див Запит звітів про витрати та використання за допомогою Amazon Athena. Потім ви можете створити спеціальні запити для запиту даних CUR за допомогою стандартного SQL. Наступний знімок екрана є прикладом запиту для фільтрації всіх ресурсів, які мають значення TF2WorkflowTraining для cost-center бирка.

select * from {$table_name} where resource_tags_user_cost-center= 'TF2WorkflowTraining'

У наступному прикладі ми намагаємося з’ясувати, для яких ресурсів відсутні значення cost-center бирка.

SELECT
 bill_payer_account_id, line_item_usage_account_id, DATE_FORMAT((line_item_usage_start_date), '%Y-%m-%d') AS day_line_item_usage_start_date, line_item_resource_id, line_item_usage_type, resource_tags_user_cost-center
FROM
{$table_name} 
WHERE
 resource_tags_user_cost-center IS NULL
AND line_item_product_code = 'AmazonSageMaker'

Додаткову інформацію та приклади запитів можна знайти в Бібліотека запитів AWS CUR.

Ви також можете вводити дані CUR Amazon QuickSight, де ви можете нарізати його будь-яким способом для створення звітів або візуалізації. Інструкції щодо введення даних CUR у QuickSight див Як отримати та візуалізувати звіт про вартість і використання AWS (CUR) в Amazon QuickSight.

Моніторинг бюджету за допомогою тегів

AWS Budgets — чудовий спосіб завчасного попередження, якщо витрати несподівано зростуть. Ви можете створювати власні бюджети, які сповіщатимуть вас, коли ваші витрати на ML і використання перевищуватимуть (або за прогнозами перевищуватимуть) встановлені користувачем порогові значення. За допомогою AWS Budgets ви можете контролювати загальні щомісячні витрати на ML або фільтрувати свої бюджети, щоб відстежувати витрати, пов’язані з певними параметрами використання. Наприклад, ви можете встановити обсяг бюджету, щоб включити витрати на ресурси SageMaker, позначені тегом as cost-center: ML-Marketing, як показано на наступному знімку екрана. Щоб отримати додаткові параметри та докладні інструкції щодо налаштування бюджетів AWS, див тут.

з сповіщення про бюджет, ви можете надсилати сповіщення, коли обмеження вашого бюджету перевищено (або ось-ось буде) перевищено. Ці сповіщення також можна опублікувати на Служба простих сповіщень Amazon Тема (Amazon SNS). Ан AWS Lambda потім викликається функція, яка підписується на тему SNS, і можна виконати будь-які програмно реалізовані дії.

AWS Budgets також дозволяє налаштувати бюджетні заходи, що є кроками, які ви можете вжити, коли бюджетний поріг перевищено (фактична або прогнозована сума). Цей рівень контролю дозволяє зменшити ненавмисні перевитрати на вашому рахунку. Ви можете налаштувати конкретні відповіді на витрати та використання у вашому обліковому записі, які застосовуватимуться автоматично або через процес затвердження робочого процесу, коли цільовий бюджет буде перевищено. Це дійсно потужне рішення, яке гарантує, що ваші витрати на машинне навчання відповідають цілям бізнесу. Ви можете вибрати тип дії. Наприклад, якщо порогове значення бюджету перевищено, ви можете перемістити певних користувачів IAM з дозволів адміністратора на лише читання. Для клієнтів, які використовують організації, ви можете застосувати дії до всього організаційного підрозділу, перемістивши їх із режиму адміністратора в режим лише для читання. Докладніше про те, як керувати витратами за допомогою бюджетних дій, див Як керувати перевитратами у вашому середовищі з кількома обліковими записами AWS – Частина 1.

Ви також можете створити звіт для щоденного, щотижневого або щомісячного моніторингу ефективності наявних бюджетів і надіслати цей звіт до 50 електронних адрес. с Звіти про бюджети AWS, ви можете об’єднати всі пов’язані з SageMaker бюджети в один звіт. Ця функція дає змогу відслідковувати ваш слід SageMaker з одного місця, як показано на наступному знімку екрана. Ви можете вибрати отримання цих звітів щодня, щотижня чи щомісяця (я вибрав Weekly для цього прикладу) і виберіть день тижня, коли ви хочете їх отримати.

Ця функція корисна, щоб інформувати зацікавлених сторін про ваші витрати та використання SageMaker і допомогти їм побачити, коли витрати не відповідають очікуваним.

Після налаштування цієї конфігурації ви повинні отримати електронний лист, подібний до такого.

Висновок

У цій публікації ми показали, як можна налаштувати теги розподілу витрат для SageMaker, і поділилися порадами щодо найкращих методів додавання тегів для вашого середовища та робочих навантажень SageMaker. Потім ми обговорили різні варіанти звітування, як-от Cost Explorer і CUR, щоб допомогти вам покращити видимість ваших витрат на ML. Нарешті, ми продемонстрували бюджети AWS і підсумковий звіт про бюджет, щоб допомогти вам контролювати витрати вашої організації на ML.

Щоб отримати додаткові відомості про застосування та активацію тегів розподілу вартості, див Визначені користувачем теги розподілу витрат.

Про авторів

Шон Морган є архітектором рішень AI/ML в AWS. Він має досвід у галузі напівпровідників і наукових досліджень і використовує свій досвід, щоб допомогти клієнтам досягти своїх цілей на AWS. У вільний час Шон є активним учасником і супроводжувачем відкритого вихідного коду, а також є керівником спеціальної групи за інтересами для додатків TensorFlow.

Брент Рабовскі фокусується на науці про дані в AWS і використовує свій досвід, щоб допомогти клієнтам AWS у їхніх власних проектах з науки про дані.

Нілеш Шетті займає посаду старшого технічного менеджера з роботи з клієнтами в AWS, де він допомагає клієнтам корпоративної підтримки оптимізувати свої хмарні операції на AWS. Він захоплюється машинним навчанням і має досвід роботи консультантом, архітектором і розробником. Поза роботою любить слухати музику та дивитися спорт.

Джеймс Ву є старшим архітектором рішень для AI/ML у AWS. допомога клієнтам у проектуванні та створенні рішень AI/ML. Робота Джеймса охоплює широкий спектр випадків використання машинного машинного навчання, з головним інтересом до комп’ютерного зору, глибокого навчання та масштабування машинного машинного навчання на підприємстві. До того, як приєднатися до AWS, Джеймс був архітектором, розробником і технологічним лідером понад 10 років, у тому числі 6 років у галузі інженерії та 4 роки в галузі маркетингу та реклами.