MLOps c Kafka Streams и gRPC: 3 способа развернуть ML-модель в production

MLOPS примеры курсы обучение, Kafka Streams Kubernetes Machine Learning MLOps, курсы машинного обучения Kafka MLOps Kubernetes TensorFlow, gRPC Kafka TensorFlow, обучение большим данным, Школа Больших Данных Учебный Центр Коммерсант

Сегодня рассмотрим, как развернуть модель машинного обучения в конвейере Apache Kafka, используя потоковый API технологии удаленного вызова процедур от Google под названием gRPC и сервер ML-моделей TensorFlow Serving.

Краткий ликбез по gRPC

Напомним, gRPC – это технология интеграции систем, включая клиентский и серверный компоненты, основанная на удаленном вызове процедур в редакции 2015 года от Google. Как и многие RPC-технологии, gRPC предполагает определение сервиса и его методов, которые можно вызывать удаленно, с их параметрами и типами возвращаемых значений. По умолчанию gRPC использует бинарный формат Protobuf в качестве языка определения интерфейса (IDL) для описания интерфейса сервиса и структуры сообщений полезной нагрузки. В качестве транспортного протокола gRPC использует HTTP/2 и предоставляет несколько API:

  • унарные RPC, когда клиент отправляет один запрос на сервер и получает один ответ, как в типовых синхронных веб-сервисах;
  • серверные потоковые RPC, когда клиент отправляет запрос на сервер и получает поток для чтения последовательности сообщений. Клиент читает данные из возвращенного потока до тех пор, пока не останется сообщений. Технология gRPC гарантирует упорядочение сообщений в рамках отдельного RPC-вызова.
  • клиентские потоковые RPC, когда клиент записывает последовательность сообщений и отправляет их на сервер, используя предоставленный поток. Как только клиент закончил писать сообщения, он ждет, пока сервер прочитает их и вернет свой ответ. За порядок сообщений в рамках отдельного RPC-вызова отвечает сама технология gRPC.
  • двунаправленные потоковые RPC, когда обе стороны (клиент и сервер) отправляют последовательность сообщений, используя поток чтения-записи. Два потока работают независимо, поэтому клиенты и серверы могут читать и записывать в любом порядке. Например, сервер может дождаться получения всех клиентских сообщений, прежде чем отправлять ответы, или попеременно читать сообщение, а затем отвечать, или комбинировать операции чтения и записи каким-то другим образом. Порядок сообщений в каждом потоке сохраняется.

Начиная с определения службы в файле .proto, gRPC предоставляет подключаемые модули компилятора формата protobuf, которые генерируют клиентский и серверный код. Пользователи gRPC обычно вызывают эти API на стороне клиента и реализуют соответствующий API на стороне сервера. В отличие от других стилей веб-API, таких как REST, SOAP и GraphQL, gRPC-сервис невозможно напрямую вызвать из браузера: необходимо разрабатывать клиентское приложение, которое будет обращаться к серверу, используя любой язык разработки.

На бэкенде сервер реализует методы, объявленные службой, и запускает сервер gRPC для обработки клиентских вызовов. Инфраструктура gRPC декодирует входящие запросы, выполняет методы службы и кодирует ответы службы. На стороне клиента у клиента есть локальный stub-объект, который реализует те же методы, что и сервис. Клиент может просто вызывать эти методы для локального объекта. Эти методы заключают параметры для вызова в соответствующий тип protobuf-сообщения, отправляют запросы на сервер и возвращают protobuf-ответы сервера.

Канал gRPC обеспечивает подключение к gRPC-серверу на указанном узле и порту. Он используется при создании клиентского stub-объекта. Клиенты могут указать аргументы канала, чтобы изменить поведение gRPC по умолчанию, например, включить или выключить сжатие сообщений. Канал имеет состояние, например, подключен и свободен.

Таким образом, gRPC является очень мощной технологией и подходит для потоковой обработки данных благодаря наличию настраиваемых стриминговых API. Поэтому потенциально ее можно использовать в проектах машинного обучения, которые должны переобучаться в режиме реального времени. Как это сделать, рассмотрим далее.

MLOps с Kafka Streams: 3 способа развернуть ML-модель

Предположим, ML-модели разрабатываются и поддерживаются с помощью MLOps-фреймфорка TensorFlow Serving  — гибкой, высокопроизводительной системы обслуживания моделей машинного обучения для производственных сред. TensorFlow Serving упрощает развертывание новых алгоритмов и экспериментов, сохраняя исходную архитектуру сервера и API. TensorFlow Serving обеспечивает готовую интеграцию с моделями TensorFlow, но может быть расширен для обслуживания других типов моделей и данных.

Пусть за обработку в реальном времени входного потока данных, на которых ML-модель должна выполнить прогноз, отвечает приложение Kafka Streams. Сервер ML-модели, развернутый в TensorFlow Serving, взаимодействует с приложением Kafka Streams через HTTP или gRPC.

Взаимодействие приложения Kafka Streams ML TensorFlow Serving gRPC
Взаимодействие приложения Kafka Streams с сервером ML-моделей TensorFlow Serving по gRPC

Такой способ развертывания может обслуживать несколько ML-моделей или несколько версий одного алгоритма, позволяя управлять ими без изменения кода клиента и поддерживая оптимальную скорость обработки данных. Однако, перехват сетевого исключения между приложением Kafka Streams и MLOps-сервером TensorFlow Serving  должен обрабатываться в потоковых приложениях Kafka Stream, что не очень просто, поскольку может включать вызов другого приложения.

Альтернативой является потоковая обработка со встроенными ML-моделями. Вместо внешнего использования TensorFlow-сервера ML-моделей и обращения к нему с использованием gRPC API можно встроить модель машинного обучения непосредственно в приложение Kafka Streams или KSQL. Также можно клиентский API Kafka, написав собственный код на Java, Scala, Python или Go.

Kafka Streams ML TensorFlow Serving
Потоковая обработка со встроенными ML-моделями

В этом варианте производительность ML-системы будет выше из-за отсутствия обращения к внешним системам. Но потребление памяти в этом случае сильно возрастает, что может увеличить задержку обработки данных. Также необходимо решить традиционные MLOps-вопросы обновления модели, управление версиями и их A/B-тестирования для выбора наилучшей модели. Для этого можно использовать контейнеризацию, запуская для каждой ML-модели новый под Kubernetes. Перенаправление трафика при этом будет осуществляться самой инфраструктурой Kubernetes, без обновления Docker-контейнера с помощью замены весов ML-модели. Публиковать и использовать модели машинного обучения можно через топики Kafka, а благодаря облачному характеру Kubernetes развертывание будет происходить в реальном времени изолировано и масштабируемо. Если необходимо использовать функции сервера ML-моделей, включая их A/B-тестирование, в облаке, пригодится шаблон sidecar, который включает обслуживание TensorFlow в том же поде и использованием RPC-вызовов.

ML Kafka Streams TensorFlow Serving Kubernetes
Облачное развертывание ML-системы с Kafka Streams и TensorFlow Serving в Kubernetes

Наконец, можно совместить оба рассмотренных подхода, объединив gRPC-сервер потоковой передачи с приложениями Kafka Streams. Это позволяет разделить задачи, предоставляя сервер ML-модели со всеми нужными функциями без использования RPC-вызовов через HTTP или gRPC. Вместо этого сервер ML-моделей будет взаимодействовать с клиентским приложением через собственный протокол Kafka и топики этой распределенной платформы потоковой передачи событий. 

В заключение отметим, что помимо разработки ML-модели еще необходимо организовать MLOps-инфраструктуру для ее полноценного сопровождения. Как это сделать, читайте в нашей новой статье.

Как применять эти и другие средства MLOps в проектах аналитики больших данных и машинного обучения, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://grpc.io/docs/what-is-grpc/core-concepts/
  2. https://learn.microsoft.com/ru-ru/aspnet/core/grpc/performance?view=aspnetcore-7.0
  3. https://medium.com/@nishantoli95/deploying-an-ml-model-in-kafka-3bdb42def982
Контакты авторизированного учебного центра
«Школа Больших Данных»
Адрес:
127576, г. Москва, м. Алтуфьево, Илимская ул. 5 корпус 2, офис 319, БЦ «Бизнес-Депо»
Часы работы:
Понедельник - Пятница: 09.00 – 18.00
Остались вопросы?
Звоните нам +7 (495) 414-11-21 или отправьте сообщение через контактную форму. Также вы можете найти ответы на ваши вопросы в нашем сборнике часто задаваемых вопросов.
Оставьте сообщение, и мы перезвоним вам в течение рабочего дня
Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.
Или напишите нам в соц.сетях
Поиск по сайту