Основные подходы к миграции решений и сервисов
Вы уже изучили концепцию облачных вычислений, теперь пора воспользоваться преимуществами облака на практике. Как и в любом квартирном переезде, нужно сперва сформировать план упаковки вещей по коробкам, чтобы организованно и надёжно переехать в новый дом. Перед вами же стоит задача миграции веб-приложения и данных вместе с СУБД.
Проработка стратегии — это фундаментальный шаг в миграции. Требования бизнеса, сложность распределённых решений, а также аппаратные ограничения — всё это факторы для выбора подхода миграции.
Подходы к миграции
В этом уроке мы разберём концепцию миграции 6R — 6R Migration Strategy. Она была впервые предложена Amazon Web Services (AWS) как часть их стратегии миграции приложений в облако. Это набор подходов к миграции приложений в облако, каждый из которых различается по степени сложности реализации:
- Retain. В рамках этого подхода выделяются отдельные компоненты решения, которые остаются в текущем on-Premise окружении. Обычно используется в контексте других подходов к миграции.
- Retire. Вывод решения или его компонента из эксплуатации. Например, после подключения облачного сервиса пропала необходимость в конкретном функционале. Часто происходит в рамках другой стратегии миграции, когда используются иные методы для перехода на новые технологии, упрощения инфраструктуры и снижения затрат на поддержку.
- Rehost, или Lift and Shift. Наименее затратный подход к миграции решения без изменений. Проще говоря, «как есть».
- Repurchase. Ещё это подход называют Drop and Shop. Он подразумевает отказ использования существующего решения и полную замену на облачный сервис (например, SaaS). Это релевантно, когда старое решение устарело и миграция становится экономически нецелесообразной.
- Replatform. Его ещё называют Lift and Reshape. Подход к миграции с минимальными изменениями в коде или архитектуре, чтобы воспользоваться преимуществами облачной платформы.
- Refactor. Этот подход также известен как Re-architect. Самый ресурсоёмкий и продолжительный подход с глубокой переработкой решения под облачную среду. В этом случае меняется не только окружение, но и сама архитектура приложения.
💡 Стратегия миграции — это комплекс подходов к миграции решения, который зависит от нужд компании.
В этом уроке разберём три подхода: Rehost, Replatform и Refactor. С ними вы столкнётесь на практике с наибольшей вероятностью. Все остальные подходы — это так или иначе частные случаи этих трех.
Rehost (Lift and Shift)
Этот подход заключается в миграции решения с данными в облако «как есть», без изменений в окружении или в архитектуре. Часто используется для быстрой миграции без высоких затрат, а также считается первым шагом на пути к Cloud Native. Про эту концепцию мы расскажем в уроке чуть позже.
Миграция может выполняться как из on-Premise, так и из других облачных провайдеров.
Хотя этот подход и считается менее затратным по ресурсам, но требует комплексной проработки.
Пример
Некая компания хочет перенести веб-приложение в облако из-за роста числа клиентов. Аппаратная инфраструктура компании уже не справляется, возникают проблемы с производительностью сервисов на бэке. Для компании важно, чтобы миграция прошла незаметно для клиентов и безопасно для самого процесса миграции, в рамках которого перенесут виртуальную среду без потери информации.
Сформулируем основные аспекты миграции для такой ситуации с использованием подхода Rehost.
💡 Rehost часто рассматривается как первый шаг к реализации концепции Cloud Native.
1. Непрерывность
Что главное для бизнеса в запущенном продукте? Непрерывность!
Приложение должно продолжать работать как после миграции, так и во время миграции. А это требует подготовительных шагов.
Сперва определяем границы нашего решения: серверы приложений, СУБД, интеграционные сервисы. А также инфраструктуру: сетевые сегменты, интеграционные взаимодействия компонентов решения и сетевые интерфейсы.
Далее нужно подготовить целевую инфраструктуру в облаке с учётом выделения виртуальных ресурсов и вспомогательных сервисов миграции, которые предоставляют сами провайдеры в виде сервиса например, Hystax Acura. Это решение обеспечивает безопасную миграцию данных виртуальной среды, которые хранятся как в оперативной памяти, так и в файловой системе.
💡 Ключевой аспект непрерывности — это сохранение и поддержание текущего состояния виртуальной и системной среды при миграции.
2. Данные
Этот этап также вытекает из первого. Все приложения работают с клиентскими данными, и для этого также требуется непрерывность миграции.
💡 Убедитесь, что миграция не нарушает законодательные требования в отношении клиентских данных. Оценка требований к безопасности для новой облачной инфраструктуры — важный момент планирования миграции решения.
Существует два механизма непрерывной миграции данных. Вы уже разбирали их в ранее: репликация данных с помощью СУБД и с помощью CDC — сервисов (Change Data Capture) на стороне облачного провайдера (например, Yandex Data Transfer). Yandex Data Transfer переносит снапшот базы данных от источника к приемнику, после чего к приёмнику применяются все изменения, произошедшие в источнике с момента взятия снапшота. В итоге в облаке получается асинхронная реплика базы данных.
Оба метода часто взаимосвязаны при миграции данных, но имеют некоторые особенности. Если репликация передаёт полные наборы данных и включает в себя целостное копирование данных из одной БД в другую, то CDC-сервис передаёт только изменения в БД, что снижает объём передаваемой информации и нагрузку на сеть.
💡 CDC работает на основе журналов транзакций БД, отслеживая изменения и передавая информацию в целевую БД. Этот метод хорош для решений, требующих мгновенного ответа на изменения данных, но более сложен в настройке.
3. Управление пользовательским трафиком
Последний этап миграции, на котором стоит остановиться подробно.
План миграции может быть описан с разной степенью детализации и не ограничиваться тремя стратегиями. Мы выделяем ключевые, которые при необходимости могут быть декомпозированы на несколько подэтапов в зависимости от сценария миграции.
С помощью переадресации трафика можно сделать незаметной миграцию решения в облачную среду для клиента. Это может быть веб-приложение с GUI вроде Яндекс Маркета или решение по типу API Management, в котором нет интерфейса прямого взаимодействия с пользователем клиента.
Большинство облачных провайдеров предоставляет вспомогательные сервисы для управления трафиком и нагрузкой при миграции — например, Application Load Balancer от Yandex Cloud. ALB предоставляет детальную настройку маршрутизации запросов клиента между разными экземплярами приложения для плавного переноса нагрузки с старой версии приложения на новую.
Как видите, Rehost-подход хотя и считается менее ресурсоёмким, но требует значительной проработки и формулирования каждого шага миграции с описанием решения и архитектуры миграции.
Что почитать про инструменты для Rehost?
Replatform (Lift and Reshape)
Подход Replatform характеризуется миграцией приложения с подключением дополнительных сервисов провайдера. Например, заменой локальной СУБД на полноценный PaaS c преднастроенным кластером, автоматическим масштабированием, обновлением и мониторингом БД. При этом код и архитектура приложения остаются прежними.
Рассмотрим кейс с применением этого подхода.
Пример
МедТех-компания имеет множество решений и сервисов для научных и медицинских учреждений, но тренды вынуждают предоставлять всё более технологичные сервисы. Компания решает разработать своего AI-консультанта, который будет помогать научному и медицинскому персоналу.
Руководство компании понимает, что требуется производительная аппаратная инфраструктура и среда для разработки таких решений. Закупка инфраструктуры требует больших вложений, которых у компании нет. Выход один — найти инфраструктуру и компетенции вместе с нужным окружением для разработчиков. Тут и уместен подход Replatform.
Облачный провайдер готов выполнить требование заказчика и подключить к своей платформе (PaaS) MLOps со всем необходимым окружением и конфигурацией.
MLOps — это набор практик, направленных на управление жизненным циклом моделей машинного обучения (ML), начиная с их разработки и заканчивая развертыванием в производственной среде. Очень часто MLOps интегрирован в DevOps процесс.
В итоге заказчик получит всё, что нужно для организации процесса разработки своего сервиса.
💡 Этот кейс может рассматриваться как в контексте первого шага к облачной миграции, так и как шаг, следующий за Rehost. Подходы Rehost и Replatform часто используют в рамках одной стратегии миграции.
Этот подход затратнее предыдущего, но значительно снижает траты на обслуживание инфраструктуры уже в краткосрочной перспективе.
Refactor (Re-architect)
Подход Refactoring подразумевает изменение архитектуры и кода приложения под облачную среду, чтобы задействовать все её преимущества. Часто этот подход применяют при задачах по микросервисной декомпозиции монолитных решений, где требуется не только разделение кодовой базы и определение границ будущих сервисов, но и реализация других технологий — контейнеризации и оркестрации.
Чтобы сформировать представление о подходе Refactor, вспомните пример предыдущего кейса. Напомним, что компания решила мигрировать в облако и подключить платформу для разработки ML-моделей как услуги.
Пример
Допустим, что МедТех-компания успешно завершила разработку и выпустила своего AI-ассистента на Django в продакшн. Приложение стало востребованным, от клиентов приходит всё больше запросов на новые функции и сервисы. Но так как приложение является монолитом, то дальнейшее его масштабирование становится всё более сложным и ресурсоёмким.
Для решения проблемы требуется поэтапная переработка архитектуры путём микросервисной декомпозиции. Часто микросервисная декомпозиция влечёт за собой необходимость контейнеризации, сервисов и оркестрации, что облачный провайдер тоже готов предоставить в виде услуги.
Если задача проработана на стороне кода приложения, то начинается проработка будущего окружения и среды исполнения приложения на стороне облака. Командам требуется определить и изучить необходимые облачные сервисы и способы их интеграции с приложением.
💡 Микросервисная декомпозиция — поэтапный процесс, который включает в себя глубокую проработку как на уровне бизнеса, так и IТ-команды. Есть множество техник (паттернов), которые применяются для разбиения монолитных приложений.
Как видите, подход Refactor подразумевает комплексную проработку ещё до миграции решения.
После применения этого подхода ваше решение фактически становится Cloud Native.
Немного о Cloud Native
Cloud Native — это подход к проектированию и разработке решений и сервисов под облачную среду и иногда в облачной среде. Одно из главных преимуществ Cloud Native решений в том, что они используют возможности облака на максимум. Очевидная реализация этой концепции — это проектирование микросервисной архитектуры в облаке с использованием контейнеризации и оркестрации. Решения Cloud Native обычно интегрированы в облачный CI/CD-процесс.
Важно помнить, что этот подход имеет и свои явные минусы. Например, зависимость от провайдера, о которой мы уже упоминали. Если решение разрабатывалось с использованием специальных сервисов для конкретной облачной платформы, это может сильно затруднить миграцию на платформу другого провайдера.
Сравнение подходов
Вероятнее всего, в рамках вашей стратегии миграции вы будете применять несколько подходов или сразу все три. Чтобы всё прошло гладко, учитывайте особенности каждого из них.
Таблица сравнения характеристик каждого подхода показывает, что вопрос миграции решения требует глубокой проработки на начальном этапе, так как каждый подход имеет свою «цену».
Задание 1
Распределите характерные признаки каждого подхода.
Итоги
- Есть шесть подходов к миграции приложений в облако, каждый из которых различается по степени сложности реализации: Retire, Rehost, Repurchase (Drop and Shop), Replatform (Lift and Reshape), Refactor (Re-architect) и Retain. Стратегия миграции — это более общее понятие, она индивидуальна для каждой компании и может включать в себя сразу несколько подходов.
- Rehost, Replatform и Refactor — это подходы, с которыми вы столкнётесь на практике с наибольшей вероятностью.
- Подход Rehost заключается в миграции решения с данными в облако «как есть», без изменений в окружении или в архитектуре. Часто используется для быстрой миграции без высоких затрат, а также считается первым шагом на пути к Cloud Native.
- Подход Replatform характеризуется миграцией приложения с подключением дополнительных сервисов провайдера. Например, заменой локальной СУБД на полноценный PaaS c преднастроенным кластером, автоматическим масштабированием, обновлением и мониторингом БД. При этом код и архитектура приложения остаются прежними.
- Подход Refactoring подразумевает изменение архитектуры и кода приложения под облачную среду, чтобы задействовать все её преимущества. Часто этот подход применяют при задачах по микросервисной декомпозиции монолитных решений, где требуется не только разделение кодовой базы и определение границ будущих сервисов, но и реализация других технологий — контейнеризации и оркестрации.