Недавно мы перенесли наши сервисы машинного обучения с Google Kubernetes Engine (GKE) на Cloud Run. Я дам вам краткий обзор того, что мы сделали, как выглядит наша архитектура и как прошла миграция. Цель этой статьи — поделиться своими знаниями и описать, почему первая итерация не дала желаемого результата.
Во Части 2 мы расскажем, как нам удалось, наконец, снизить стоимость на 50% по сравнению с исходной настройкой и дополнительно сократить время обработки рекомендации с 20 до менее 1 секунды.
Архитектура системы
Работая для Опинари, мы вовлекаем читателей, задавая правильные вопросы в новостных статьях. Как специалисты по обработке и анализу данных, Эктор Отеро Медьеро и я отвечаем за интеграцию наиболее подходящего контексту опроса в новостные статьи.
Представьте, что вы читаете статью на своем любимом новостном сайте о том, должны ли быть ограничения скорости на автомагистралях. Мы стремимся интегрировать опрос в эту статью, задавая вам что-то вроде следующего:
Рекомендовать и интегрировать этот вопрос в эту статью — это успех. Но что на самом деле происходит на заднем плане? Есть много служб, участвующих в отображении этого опроса в вашей новостной статье. Сервисы рекомендаций, на которых мы сосредоточимся, показаны ниже:
Система рекомендаций начинается с URL статьи, для которой следует рекомендовать опрос. Возьмем статью с заголовком:
Петиция об ограничении скорости и запрете на автомобили по воскресеньям поступила в парламент
URL-адрес статьи помещается в очередь Pub/Sub, которая представляет собой очередь, ориентированную на обмен сообщениями, для обработки входящих задач. Служба рекомендаций извлекает новую задачу из очереди для ее обработки. Узнайте больше о pub/sub здесь.
Затем служба рекомендаций организует другие службы, запрашивая их в следующем порядке, одну за другой:
- Служба Article-Scraper-Service для очистки текста статьи.
- Служба Encoder-Service для кодирования текста в текстовые вложения.
- Служба Brand-Safety-Service для классификации того, является ли текст безопасным для интеграции и не содержит ли он описаний трагических событий, таких как смерть, убийство или несчастный случай.
После этого со всей собранной информацией служба рекомендацийрекомендует опрос по интересующей статье. В приведенном выше примере он порекомендует для статьи Петиция об ограничении скорости и воскресеньях без автомобилей поступает в парламент, опрос с вопросом об ограничении скорости.
До миграции все службы и база данных Redis работали в кластере Kubernetes.
Почему мы захотели мигрировать?
Нашей главной целью, когда мы решили мигрировать, была экономия средств. Мы хотели платить только за те ресурсы, которые использовали. С GKE кластер и сервисы доступны круглые сутки, и вы все время платите. Поскольку ночью в Европе у нас гораздо меньше трафика, мы хотели, чтобы услуги уменьшались, когда они не нужны, и увеличивались, когда в систему поступает много запросов. Наконец, в нашей команде нет специального инженера по данным, поэтому решение должно быть максимально простым в обслуживании. CloudRun кажется хорошим решением для нашего варианта использования.
Что это за облачный забег?
Cloud Run — управляемая бессерверная платформа от Google. Бессерверность означает, что облачный провайдер выделяет машинные ресурсы по вашему требованию, заботясь об управлении серверами. Cloud Run прост в использовании и позволяет развернуть приложение Docker за считанные секунды. Он масштабируется из коробки в соответствии с входящим HTTP-запросом, и вы платите только за использование.
Требования, которые следует учитывать перед переездом
Поскольку службы Cloud Run масштабируются с учетом входящих HTTP-запросов, каждая служба должна иметь конечную точку HTTP для приема запросов. Можно легко настроить push-подписки Pub/Sub для обработки запросов. Кроме того, для быстрого масштабирования вверх и вниз выгодно, если сервисы имеют быстрое время запуска.
Новая архитектура — что изменилось?
Самым важным изменением стал переход с подписки по запросу на подписку по запросу. Служба рекомендаций после выполнения одной задачи извлекает новую задачу из очереди публикации/подписки. Теперь очередь отправляет работу рекомендателю всякий раз, когда она поступает, и контейнер рекомендателя в Cloud Run должен ответить в течение определенного периода времени.
Кроме того, мы используем соединители VPC для подключения сервисов Cloud Run к сети VPC. Службы и Redis больше не работают вместе в защищенном кластере. Службы теперь являются независимыми службами Cloud Run, и мы перешли от Redis внутри GKE к Memorystore, службе GCP в памяти для Redis. Memorystore защищен от Интернета с помощью сетей VPC, и для доступа к хранилищу службам необходимо подключаться через коннекторы VPC. Подробнее о настройке здесь.
Как это было (неправильно)?
После миграции у нас есть хорошо масштабируемая система, которая автоматически масштабируется, если поступает больше запросов. Однако служба рекомендаций стала ОЧЕНЬ дорогой, потому что она была организована и, следовательно, ожидала всех других служб. В результате многие экземпляры рекомендательного контейнера работали, но, по сути, ничего не делали, кроме ожидания. Поэтому политика оплаты по факту использования Cloud Run приводит к высокой стоимости этой услуги.
Это не конец истории, только первая итерация. О том, как мы заставили систему работать красиво с помощью Cloud Run и какие улучшения мы сделали по ходу дела, вы можете прочитать в Часть 2.
Краткое содержание
Переход с K8s на CloudRun прост, однако учтите следующее:
- Наши затраты сначала увеличились за счет перехода на Cloud Run, читайте часть 2.
- Он лучше подходит для небольших/асинхронных процессов.
- Возможно, вам потребуется настроить существующие службы.
- Проблемы с производительностью будут иметь большее влияние.
