Миграция оркестрации процессов с AWS на решение с открытым исходным кодом

Amazon SWF позволяет разработчикам создавать, запускать и масштабировать фоновые задания с параллельными или последовательными этапами выполнения. Этот сервис представляет собой полностью автоматизированное средство отслеживания и координирования заданий в облаке.

Чтобы написать код, который будет запускаться через SWF, необходимо использовать Flow Framework от Amazon доступный для Java, .Net, PHP и Ruby.

Причины для миграции

Зависимость от поставщика

SWF - это облачный сервис поставляемый и управляемый Amazon Web Services. Ни один из российских поставщиков облачных технологий не поставляет аналогичного решения с совместимым SDK, что не позволяет перевести инфраструктуру полностью на серверы РФ.

Усложнение процесса онбординга

Нашим внутренним операторам важно знать о текущем статусе выполнения процесса, уметь запускать и останавливать процессы. Для этого администратор должен выдать доступ к AWS новым операторам. Затем нужно научить новых пользователей пользоваться старым и не интуитивно-понятным интерфейсом в SWF. Все это увеличивает длительность и затраты на онбординг.

Риск новых санкций

Появление новых санкций сегодня - это дело времени. Так как Amazon американская компания, есть риск новых санкции, из-за которых работа сервисов AWS будет блокироваться из РФ. Или наоборот, внутри РФ может быть ограничен доступ к Amazon, что сделает невозможным его использование с российских серверов.

Отсутствие развития

Amazon не развивает данный сервис. Графическая оболочка приложения сильно устарела, а новый функционал не появлялся с 2020 года.

Технологический стек

Чтобы пользоваться SWF необходимо писать код с использованием средств разработчика от Amazon. Имеется SDK: Java, .Net, PHP и Ruby. Несколько лет назад приложение было написано на Java, но основной язык разработки внутри TraceAir со временем поменялся на Python. Поэтому, нам хотелось иметь рабочее SDK на языке Python.

Требования к новому решению

Были сформированы такие требование к новому решению:

Новое решение должно не уступать существующему по функционалу. Очень важно сохранить возможность масштабирования инфраструктуры при увеличении нагрузки Интерфейс должен быть понятным, внутренним пользователям должно быть легко поменять платформу Внутреннему пользователю не нужно создавать аккаунт в AWS. Должно быть достаточно корпоративного аккаунта Сервис можно запустить на любом из облачных провайдеров. В России есть спрос на возможность развертывания системы “в подвале”, желательно, чтобы такая возможность имелась у нашей платформы. Минимизация рисков при появлении новых санкций. Это может быть похожее решение с открытым исходным годом или разрабатываемое в РФ. Новое решение, которое заместит SWF, разрабатывается и поддерживается разработчиками. Критерий: за последний год должен появится новый функционал. Наличие SDK, чтобы писать код для сервиса на языке Python и Java. Наличие Java SDK позволит сохранить старый код в рабочем состоянии, а Python SDK можно использовать для реализации нового функционала.

Поиск замены

Чтобы уменьшить количество необходимого для рефакторинга кода, мы искали решение, которое максимально было похожим на SWF. Удалось выяснить, что у истоков разработки SWF стоит Максим Фатеев, он был главным архитектором этой системы, после чего, он разрабатывал систему Cadence Workflow для Uber, и сейчас у него есть свой стартап Temporal. Изучив документацию Temporal стало понятно, что концептуально он похож на SWF, у этих решений много схожих терминов, а самый первый SDK был сделан для Java. У темпорал имеется Python SDK, весь исходный код находится в открытом доступе на гитхаб. Имеется хорошая документация, в которой описано, как настроить темпорал на собственных серверах. Также, темпорал предоставляет возможность настройки oauth2 с гуглом. Таким образом, данное решение идеально подходило под наши требования, но это не было “серебряной пулей” и темпорал имеет ряд недостатков.

В процессе выполнения нашим операторам необходимо уметь останавливать или запускать процесс. Данный функционал реализован через командную строку, но этот вариант не подходит, так как сложен для освоения и администрирования доступа. Поэтому, первый недостаток - отсутствие интерфейса для управления процессами. Следующий минус, это отсутствие API для управления процессами в кластере Temporal. Например, чтобы запускать процессы из других сервисов. Но, на момент написания статьи, уже опубликован python-sdk. Отсутствие визуализации ориентированного ациклического графа выполнения процесса, что неудобно, когда нужно разобраться в последовательности выполняемых шагов. Такая визуализация очень помогает, когда в процессе выполнения что-то пошло не так.

Мы продумали архитектурный дизайн и приступили к рефакторингу кода.

План миграции и архитектурный дизайн

Способ запуска процессов

Ранее, наши процессы запускались с помощью сервиса AWS Lambda, а так как нам нужно автономное решение, их нужно было чем-то заменить. Для этого был придуман веб сервис, целью которого является запуск процессов в SWF. Под капотом, сервис запускает командную строку, для взаимодействия с кластером Temporal. На данный момент команда разработки Temporal уже опубликовала python-sdk, поэтому не обязательно реализовывать взаимодействие через командную строку.

Изменение в кодовой базе

Сначала, нужно было переписать наше текущее ПО, чтобы оно использовало temporal-sdk вместо Flow Framework. В нашем случае, пришлось копировать файлы с существующей логикой и точечно подменять Temporal там, где используется SWF. Также, изменениям подверглись наши сервисы, которые запускали сами процессы исполнения, так как ранее они использовали для этого AWS Lambda, после миграции - это будет осуществляться через упомянутый ранее веб-сервис.

Реализация интерфейса для управления процессами

У самого temporal имеется собственный интерфейс, но он не позволяет управлять процессами, только следить за статусом. Возможность управления процессом выполнения является важной частью нашего бизнес домена, поэтому, нужно предоставить операторам функционал для самостоятельного запуска и остановки процессов исполнения. Для этого, мы придумали фронтэнд приложение, которое позволяло бы нашим оператором имея учетную запись внутри платформы управлять процессами. Всего на нашей платформе 6 процессов, оператор может выбрать любой из них, ввести необходимые параметры и запустить процесс, отслеживание можно процессов производится непосредственно через сам temporal web ui.

Архитектурный дизайн миграции

Нашей командой был предложен такой дизайн для новой системы. На данной диаграмме workflow-worker наше основное приложение, которое и выполняет основную работу по запросу от Temporal. Operator UI - это приложение, с помощью которого наши внутренние операторы могут запускать или прерывать процессы.

Затраты на миграцию

Для реализации были задействованы ресурсы почти всей команды из 5 человек. Рефакторинг кода под temporal-sdk не вызвал сложностей, всего надо было перевести 6 типов процессов на Temporal, в общей сумме было изменено примерно 10000 строк кода в коде проекта workflow-worker. Собственный Temporal API был реализован примерно за месяц на языке Python. Вдобавок, потребовалось создать инфраструктуру для работы самого Temporal.

Для реализации Operator UI, к помощи привлекли фронтенд разработчика из другой нашей команды. Реализация потребовала меньше месяца.

Нам очень повезло, что у нас имеются End-to-end тесты. Это позволило на этапе разработки обнаружить некоторые баги и добавляло уверенности при релизе решения в продакшн.

Кирилл Гладких