A Series — Частина 0: Огляд
Як і більшість моїх проєктів у портфоліо, цей також базується на Magic: The Gathering. Цього разу, однак, акцент буде більше на архітектурі та менше на завершеному додатку. В кінці ми повинні отримати повний pipeline, який автоматично завантажує зображення карт, як тільки виходять нові набори; виконує їх тесселяцію, переклад і морфінг для кращого тренування; і відправляє їх на кластер KubeFlow для навчання моделі.
Проходячи через цю серію статей, зверніть увагу, що це НЕ є покроковим керівництвом. Хоча я сподіваюся, що читачі можуть чогось навчитися з моїх помилок, це більше можливість продемонструвати мій процес мислення щодо того, як я ділю великий проєкт на менші частини, а також причини вибору певних компонентів. У кожній статті я буду не тільки показувати проєктування та реалізацію кожної частини, але й детально описувати труднощі, які мені довелося подолати. Розглядайте кожну статтю як ретроспективу спринту.
Передумови
Я є Cloud та DevOps інженером у великій консалтинговій технологічній компанії, і в моїй повсякденній роботі мені часто доводиться виконувати різні ролі, одна з яких — архітектура нових рішень для клієнтів.
Цей проєкт є повністю самостійним; це просто спосіб спробувати деякі з цих інструментів і створити доказ концепції для майбутніх клієнтів. Архітектура сама по собі значно перевантажена для досягнення мети тренування моделі такого розміру. Однак, з постійним випуском нових наборів Magic: The Gathering, а отже й нових карток для навчання моделі, це здалося ідеальним кандидатом для автоматизованого проєкту ML Ops.
Крім того, я хотів зробити це так, щоб це можна було використовувати для корпоративних навантажень. Як проєкт розвиватиметься, я надам більше деталей про рішення щодо кожного інструменту в кожній статті, але вибір на користь GCP для хостингу навантажень слідує за тенденцією, яку я спостерігаю у багатьох моїх клієнтів, які розміщують свої дані та платформи машинного навчання, особливо нові проєкти, на GCP. Google все ще є королем великих даних.
Архітектура
Архітектура потоку даних; червоні лінії — це Pull запити, зелені лінії — Push запити
Архітектура потоку даних не є надто складною. Зображення карт будуть завантажуватися з Gatherer, бази даних карт Magic: The Gathering, коли виходять нові набори, автоматично обрізатимуться, перекошуватимуться та з ними виконуватимуться інші тесселяції за допомогою GCP Dataflow для збільшення доступних даних для навчання, і зберігатимуться в Cloud Storage blob storage. Після цього Kubernetes KubeFlow зможе забирати дані і тренувати моделі за допомогою розподіленої моделі навчання Tensor Flow. Після завершення моделі ми можемо зберігати її або в реєстрі моделей Vertex AI на GCP, або як артефакт в Artifact Registry. Модель можна потім знову завантажити і перенавчити, якщо необхідно, з новими коригуваннями алгоритму або з новими даними від нових зображень карт.
У поточній версії я планую спробувати Dataflow, щоб отримати досвід роботи з цим інструментом. Я відкритий до використання Kubeflow pipelines в майбутньому, якщо це буде доцільніше.
Крім того, автоматизований тригер (на даний момент це Cloud Functions на діаграмі) буде використовуватися для ініціації workflow GitHub Actions для створення ресурсів за допомогою Terraform. Деякі речі, такі як обліковий запис сховища, не буде можливим створювати і видаляти, але принаймні я зможу масштабувати GKE Cluster до 0 вузлів, коли він не використовується. Поточний механізм для досягнення цього — це робота в процесі, але я підозрюю, що це буде підписка на потік або якась форма планованого опитування.
Якщо це має стати таким, очікуйте оцінки витрат на постійну роботу Cloud Function проти просто збереження інфраструктури в стані, коли вона вимкнена, але все ще існує.
Для робочого процесу розробки я симулюватиму роботу центральної інфраструктурної команди, яка керує центральним репозиторієм Terraform модулів, що можуть визначати шаблони проєктування, які окремі команди потім можуть використовувати. Я використаю цю парадигму для налаштування центрального репозиторію з визначеннями для VPC та структури мережевого трафіку, а також заздалегідь налаштованими визначеннями для того, як нові мережі VPC будуть додаватися до корпоративної мережі. Кожен інший репозиторій буде викликати ці шаблони Terraform за потребою для налаштування необхідних компонентів цього репозиторію.
Більш детальну діаграму мережної архітектури буде надано у першій частині цієї серії, але вимоги до дизайну наступні:
- весь трафік у корпоративній мережі, незалежно від того, чи він входить, виходить, чи маршрутується в інший VPC, повинен проходити через transit VPC для централізованого ведення журналів мережі
- мережна архітектура повинна слідувати моделі хаба та spoke, щоб нові проєкти можна було запитувати і легше додавати до корпоративної мережі, дотримуючись правила 1
- мережні компоненти у spoke повинні бути шаблонізовані таким чином, щоб коли буде запитано нове середовище або spoke, вся мережна конфігурація здійснювалася автоматично для підключення до мережі hub/transit VPC.
Список справ
Як проєкт буде розвиватися, ці пункти будуть замінені посиланнями на інші частини цієї серії. Ці частини будуть організовані в такі ж частини, як я б делегував командам для розгортання і керування цими сегментами додатку. Я мав досвід роботи як з одним репозиторієм, так і з кількома репозиторіями на своїй поточній посаді і помітив, що інженери даних вкрай не люблять все, що стосується IaC. Для цього проєкту ми зберігатимемо їх в окремих репозиторіях, і кожен сегмент зазвичай слідуватиме цьому шаблону проєктування.
- Центральний репозиторій Terraform, який визначатиме основні компоненти мережі хаба і шаблони для використання іншими репозиторіями
- Репозиторій для шаблонів GCP Dataflow з CICD для побудови та розгортання їх Docker-образів
- Репозиторій для Kubernetes для хостингу основних архітектурних маніфестів
- Репозиторій KubeFlow для специфічних маніфестів Kubernetes для розробників і коду Python TensorFlow
- Репозиторій Terraform для налаштування реєстру моделей GCP Vertex AI (це може бути об'єднано з репозиторієм KubeFlow)
Додатково
Ніхто не має безмежного часу. Ось деякі додаткові функції, які я зроблю згодом, якщо не частина цього проєкту. Я вважатиму проєкт «завершеним» без них, якщо час не дозволяє.
- Безперервне навчання на старих даних — це одна з основних складових ML Ops, але це трохи не в моїй компетенції як інженера інфраструктури. Я розумію основи: брати той самий набір даних і автоматизувати налаштування ваг і зміщень різними способами, поки не отримаємо кращу модель. Однак це потребує значно більше досліджень, ніж інші елементи серії.
- Хостинг моделі на вебсайті — із трьох додаткових функцій, це найменш ймовірно, що я зможу завершити в рамках цього проєкту. Це, ймовірно, забере стільки часу, скільки і решта елементів, якщо я не зберу щось швидко в Flask або Django.
- 把此篇文章翻成國語 — Я хочу писати більше технічних документів китайською мовою, але зазвичай у мене дуже мало часу. Можливо, колись у мене буде час і для цього, щоб переписати цю статтю китайською.
Поза межами проєкту
На відміну від додаткових функцій, ці елементи точно не будуть частиною проєкту.
- FinOps — Так, у GCP є чудові інструменти для бюджету. Однак все, що виходить за межі простої перевірки бюджету, щоб переконатися, що я випадково не витрачу всю свою зарплату на цей проєкт, виходить за межі проєкту.
- Логування — Я планую повернутися до цього в рамках іншого проєкту. Я маю намір включити деякі визначення експорту журналів як частину шаблонів ресурсів Terraform, але налаштування повної інфраструктури логування в хабі — це не буде частиною цього проєкту.
Цей проєкт має стати хорошою відправною точкою для майбутнього проєкту, заснованого на логуванні.
Перекладено з: Architecting a Magic: The Gathering Image Recognition ML Ops Project