Kubernetes с Argo для победы
Kubernetes - это обычно неиспользованный вычислительный ресурс. Это та незнакомая территория между IaaS и PaaS. Многие инженеры опасаются его использовать, ИТ-руководство боится добавлять его в стек, а технологи продолжают упрашивать его использовать - но почему?
- Еще одна абстракция для развертывания кода конвейера для инженеров - это еще одна технология, которую «компания» требует от них изучить.
- Это еще одна технология для поддержки менеджмента, а это означает больше вещей и больше долгов.
- Для технолога это тупые мысли (да, у каждого технолога колоссальное эго) - нет причин сдерживать прогресс, если вы можете модернизироваться и двигаться вперед с более совершенными инструментами.
Что ж, все они ошибаются - и все они правы. Вопрос в том, как с этим примириться. Для этого вам понадобится бизнес-кейс, над которым нужно работать. В этой ситуации давайте обратимся к выполнению конвейеров, разработанных Data Scientist.
Пример использования. Наша программа по анализу данных при переходе в облако становится повсеместной. Им не удалось выработать последовательный и надежный подход к решению проблем машинного обучения, и нам сказали, что проблема в их рабочих процессах. Сообщалось, что каждый специалист по данным, инженер по машинному обучению и т.п. в разных подразделениях моей компании используют разные подходы к построению конвейеров, созданию своих инструментов и запуску кода в нескольких системах, что требует перемещения данных, которые могут не потребоваться. . Мы хотим найти решение, которое позволяет создавать все рабочие процессы одним способом, принудительно выполняя код в указанной и благоприятной среде. Мы не хотим, чтобы специалисты по обработке данных знали или беспокоились о том, где это. Поскольку мы новичок в облаке и хотим быть готовыми к будущему - мы не хотим играть в догонялки сейчас, чтобы сыграть в него снова в короткие сроки - но не хотим, чтобы большинству наших технических сотрудников приходилось беспокоиться о как мы модернизировались (например, изучаем много новых технологий, чтобы быть продуктивными).
Хотя есть много разных способов, с этим можно справиться. При консультациях мы хотели бы найти гораздо больше информации, чтобы предложить наиболее подходящий вариант для вашей организации; тема здесь - Kubernetes и Argo. И да, эта конкретная комбинация - хороший выбор - и по большему количеству причин, чем указано в примерах использования здесь. И зрелая реализация будет больше, чем то, что мы обсуждаем здесь, но это будет хорошей отправной точкой, чтобы заставить вас задуматься над этим и его осуществимостью в вашей организации.
Kubernetes
Во-первых, что такое Kubernetes и почему технологи так его любят? (мы тоже - ведь мы технологи). Во-первых, желательна возможность создания приложения, упакованного в развертываемый модуль, который можно развернуть практически в любой системе. Представьте, что вам не нужно делать его «слишком» разным для разных систем - это означает, что вам нужно меньше беспокоиться о рабочем пространстве. Это большая часть того, где появляется DevOps (другое обсуждение). Я говорю о Docker - одной из величайших технологий виртуализации. Kubernetes (для краткости k8s) предоставляет среду для последовательного управления (или оркестровки) этих контейнеров распределенным образом (на нескольких машинах) и взаимодействия между ними с использованием общих парадигм развертывания.
Наличие согласованной среды для оркестровки этих контейнеров - это одно, но также важно, как вы это делаете. Kubernetes предоставляет декларативный интерфейс, который позволяет инженерам четко и последовательно определять, как вещи собираются и развертываются. Эти объявления делаются в файлах YAML, известных как манифесты, которые обычно используются для указания конфигурации приложения. Это означает, что объявления эквивалентны определению того, как настроено приложение - удобно, верно!
Этим конфигурациям или файлам манифеста, которые объявляют развернутую конфигурацию ваших приложений, присваиваются типы, которые представляют абстракции того, что они настраивают. Эти файлы конфигурации представляют собой абстракции в Kubernetes, такие как контроллеры (задания, развертывания и демоны, которые выполняются на всех узлах), которые развертывают поды (наименьшие единицы работы) и другие абстракции, такие как службы, которые помогают управлять взаимодействием контроллеров. Техническим расширением этих концепций являются операторы, которые добавляют дополнительные возможности или инкапсулируют программные модули с возможностью многократного использования.
Теперь вы можете слышать, как часто встречается термин Cloud Native, но что это означает? Чтобы быть ясным, создание чего-то для запуска с использованием облачных сервисов поставщиков не делает ваше приложение нативным для облака, а использование облачного приложения не делает ваше приложение нативным для облака. Что делает его облачным, так это то, что он контейнерный (например, Docker) и может развертываться на платформе оркестровки контейнеров (например, Kubernetes), чаще всего с использованием современных инструментов DevOps и методов разработки.
Поскольку эти платформы могут быть развернуты (или являются сервисом) во многих облачных средах и могут использоваться в качестве основного компонента частного облака, эти решения, естественно, очень портативны. Хотя в средах будут небольшие различия - после подготовки одного развертывания работа, необходимая для адаптации к новой среде, минимальна.
Арго
Теперь, когда вы знаете, что такое Kubernetes, нам нужно обсудить Арго. Argo - это кастомный оператор Kubernetes. Это оператор, который предназначен для обеспечения уровня оркестровки рабочего процесса над пошаговыми процессами с зависимостями. Эти пошаговые процессы с зависимостями в большинстве современных вычислительных решений называются DAG.
Быстрый поиск приведет вас к другим инструментам, связанным с DAG; возможно, вы знакомы с некоторыми из них: Apache Airflow, Prefect, Luigi и т. д. - но эти технологии не являются облачными. Как и все остальное в Kubernetes, Argo декларативен, создан для работы в разных средах и управления контейнерными рабочими нагрузками. Фактически, как только он будет установлен в вашем кластере Kubernetes и расширит CLI Kubernetes, вы можете развернуть манифест Argo, который декларативно абстрагирует идею DAG.
Предположим, что у нас есть рабочий процесс машинного обучения, изображенный ниже:
Каждый шаг записывается в образ докера и выполняется декларативно, где DAG полностью указывается в манифесте Argo. Это позволяет определять повторно используемые образы докеров, в которых есть общие заранее подготовленные процедуры, для повторного использования в Kubernetes в рамках рабочего процесса - мое обсуждение использования Docker для работы с машинным обучением можно найти здесь. Позволяя манифесту Argo указывать конвейер, вы объявляете порядок, в котором шаги должны выполняться в вашем конвейере - и при этом вы также говорите, что все будет выполняться в кластере Kubernetes и что Argo позаботится планирования, мониторинга и отслеживания прогресса вашего конвейера.
Преимущества (UI)
Пользовательский интерфейс Argo просто потрясающий. Он обеспечивает просмотр всех версий конвейера по мере его выполнения. Хотя возможность визуализировать каждый конвейер - это одно, и функция, которая очень важна как в целом, так и после нее, это не единственная функция, которую предоставляет Argo.
Пользовательский интерфейс Argo отслеживает при каждом выполнении журналы STDIO каждой фазы выполнения - полезно для выявления проблем выполнения, когда они возникают.
Теперь, когда вы часто запускаете свой код и обучение ваших моделей занимает больше времени, чем вы ожидали, вам нужно отследить, какой этап занимает больше всего времени. Арго отслеживает эту информацию для вас и обеспечивает визуальное представление этой информации в пользовательском интерфейсе. Эта функция покажет вам, какие этапы выполняются дольше всего.
В любом случае, почему ML с Арго?
Машинное обучение - естественно составной процесс. Каждый этап рабочего процесса или набор этапов можно сгруппировать в один «атомарный» этап обработки. Как правило, они сшиваются вместе в пользовательских процессах, иногда с помощью Airflow. Но почти всегда это сводится к индивидуальному процессу, даже к чрезвычайно жесткому решению, созданному внутри компании (обычно написанному разработчиками программного обеспечения, которые практически не имеют опыта в области науки о данных). Или, что еще хуже, ваша оркестровка выполняется вручную, и вам нужно перемещать вещи (данные, модели и т. Д.) В разные среды. Не делай этого! Примите меры для перехода к более автоматизированным средам. И среда Kubernetes с документированными рабочими процессами - отличный первый шаг в этом направлении.
Наука о данных - это практика разработки программного обеспечения, хотя многие специалисты по данным не думают об этом. Но это все равно. И при этом вы должны централизованно отслеживать все различные этапы обучения. Арго обеспечивает это возможностью наблюдать за состоянием трубопроводов и результатами каждого этапа. Речь идет не об отслеживании результатов машинного обучения, а о программном компоненте того, что вы делаете. См. Мою статью о MLflow о подходах к решению этой уникальной потребности.
Следующим и, возможно, самым важным для специалиста по данным является необходимость поддержки полиглотизма - разработки решения с использованием нескольких языков программирования. Это одна из основных причин того, что многие процессы выполняются вручную. Разные потребности диктуют разную среду. Сегодня в этом нет необходимости. Контейнерные решения - отличное решение для поддержки полиглотизма.
Теперь, когда вы подписываетесь на поставщика облачных услуг и используете его инструменты (надеюсь, не догматически), вы в конечном итоге запираетесь в его пространстве и заставляете своих специалистов по данным использовать их инструменты, а не инструменты, подходящие для ваших целей. Это не означает, что вам следует избегать использования решений от облачного провайдера - вам нужно правильно подбирать подходящие решения - и, возможно, часть их пространства решений подойдет вам. Но всегда будь внимателен. Облачное решение, основанное на развертываниях Kubernetes, предоставляет структуру, которая дает вам возможность перейти к новому провайдеру и перейти на него более легко, чем при использовании решения облачного провайдера. Хотя перемещение данных при миграции достаточно сложно, перемещение процессов обработки данных сложнее - намного сложнее.
Плохой (ручная работа по созданию DAG)
Строить DAG в Арго не очень приятно. С точки зрения специалиста по данным, это намного больше, чем хотелось бы. И создание / управление многими из этих конвейеров, возможно, с небольшими вариациями, немного беспорядочно. Эта оперативная работа - это немного больше, чем мне, честно говоря, нравится (все инженеры ленивые факты). У меня нет особого желания указывать шаблон для каждого этапа: где расположены изображения, какова точка входа в мой код и т. Д. - все это еще даже без создания DAG.
Хорошее (следите за ссылками)
Было бы гораздо лучше написать абстракцию, которая строит эти файлы для вас из минимизированного объявления DAG - и, к счастью, такой инструмент существует. См. Этот блог на LearningAwps. Это гибкая структура, предназначенная для того, чтобы помочь вам развернуть код машинного обучения с минимальными изменениями существующих процессов в операционно управляемую среду - с легкостью приближая вас к производственному коду - подход MLOps.
Как Hashmap может помочь
Следующие шаги - решить, должен ли MLflow быть частью решения для анализа данных для вашей организации. Hashmap может вам здесь помочь. Наши специалисты по машинному обучению и MLOps готовы помочь вам в вашем путешествии - вывести вас и вашу организацию на новый уровень. Позвольте нам помочь вам опередить ваших конкурентов и стать действительно эффективным в области анализа данных.
Если вам понадобится помощь в пути, свяжитесь с нами.
Hashmap предлагает ряд обучающих семинаров и услуг по оценке, услуги по модернизации и миграции облака, науку о данных, MLOps и различные другие консультационные услуги в области технологий.
Другие инструменты и контент, которые могут вам понравиться
Джон Авен, доктор философии, технический директор Hashmap, предоставляющий решения для данных, облачных вычислений, Интернета вещей и искусственного интеллекта / машинного обучения, а также консультации по всем направлениям. отрасли с группой инновационных технологов и экспертов в предметной области, ускоряющие получение ценных бизнес-результатов для наших клиентов. Обязательно свяжитесь с Джоном в LinkedIn и узнайте больше о перспективах и информации о том, как ускорить достижение бизнес-результатов, основанных на данных.
