Миграция на «облако»: как провести процесс переноса сервисов, чтобы все работало

Азизхон Ишанхонов – инженер-программист, .Net разработчик, эксперт в области облачных технологий (Azure, AWS).

В борьбе “облачные технологии VS свой дата-центр” все чаще побеждают первые по целому ряду причин, среди которых экономия, доступность и надежность. Однако процесс миграции на “облако” не так прост, как кажется. Что нужно учесть при переносе сервисов, чтобы не налететь со всей скорости на невидимые облачные барьеры? Разбираемся вместе.

В современном мире все больше компаний переносят свою инфраструктуру в облако.

Облачные технологии имеют множество преимуществ по сравнению поддержанием собственного дата-центра. К преимуществам можно отнести следующие:

• Экономия: можно сократить расходы на серверное оборудование, обслуживание и электроэнергию. 
• Масштабируемость: ресурсы можно легко и быстро добавлять и удалять по мере необходимости. 
• Доступность: доступ к данным и приложениям возможен круглосуточно из любой точки мира. 
• Надежность: поставщики облачных услуг обеспечивают высокую степень безопасности данных и непрерывность обслуживания. 

Однако переход на облачную платформу — это не простая задача, и требует тщательного планирования и исполнения, особенно если дело касается больших компаний.

В этой статье мы рассмотрим основные этапы миграции в облако и дадим практические советы, которые помогут сделать этот процесс легким и эффективным на основе опыта переноса многомиллиардной продуктовой компании.

Этап 1. Определение целей и задач миграции

В первую очередь нужно определить цели и задачи миграции:

• Какие сервисы вы хотите перенести в облако (полностью или частично)? 
• Каких целей вы надеетесь достичь (сократить расходы, повысить производительность, увеличить доступность)? 
• С какими ограничениями вы сталкиваетесь (бюджет, время, технические возможности)?

Так, например, наша компания решила перенести все сервисы кроме базы данных, так как в БД хранились большое количество персональных данных, и основная ценность компании выражалась именно в наличии этой информации.

Мы поставили следующие цели при миграции:

1. Технологически:

• Переход к без серверным (serverless) технологиям;
• Низкая связанность (loosely coupled) компонентов;
• Разделение на отдельные бизнес домены.

2. Организационно:

• Команды отвечают за компоненты в бизнес-домене;
• Команды объединены в бизнес-домен и владеют экспертизой по бизнес-домену.

3. К менеджменту/Agile подход

• Уменьшение длительности итерации;
• Уменьшение количеств церемоний, взаимодействий между командами.

Что касается ограничений, в зависимости от масштаба компании, требуемое время на перенос и бюджет могут сильно вас подвести. Есть немало случаев, когда отсутствие грамотного планирования и взвешенной оценки своего бюджета делают компании банкротами, чаще всего это происходит со стартапами. Нужно учитывать, что в период переноса затраты на инфраструктуру могут быть в два раза больше, чем обычно, а процесс миграции может занять несколько месяцев.

Этап 2. Выбор поставщика облачных услуг

На этом этапе нужно:

• рассмотреть услуги различных поставщиков; 
• сравнить цены, возможности, безопасность и поддержку; 
• убедиться, что провайдер соответствует вашим требованиям. 

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

Источник:https://www.channele2e.com/news/cloud-market-share-2018-aws-microsoft-google

Этап 3. Планирование миграции

Здесь предстоит:

• разработать подробный план миграции; 
• определить этапы миграции; 
• оценить возможные риски и разработать план по их минимизации. 

Первую очередь нужно подготовить инфраструктуру в облаке и определить модель инфраструктуры, в нашем случае в качестве модели была выбрана IaaS.

Источник:https://campus.datacamp.com/courses/understanding-cloud-computing/introduction-to-cloud-computing?ex=8

До переноса, в старой инфраструктуре нужно снять все необходимые метрики (все возможные тесты, лог нагрузок в течение года и их влияние на ресурсы). Наличие инструментов мониторинга может сильно упростить вашу работу. Все должно быть задокументировано, чтобы можно было сравнить “яблоко с яблоком” после переноса. Мы создали унифицированный CI/CD в старой инфраструктуре и прогнали все сервисы через этот пайплайн пройдя все “quality gates”, который позволял одинаково оценивать состояние каждого из сервисов. На этом этапе выделение небольшого capacity для рефакторинга на каждую итерацию только сэкономит время на поддержку сервиса в дальнейшем, чтобы не таскать очевидные рудименты в облако.

Источник:https://aws.amazon.com/blogs/devops/blue-green-deployments-with-application-load-balancer/

Для минимизации расходов мы переносили по одному сервису, начиная с dev-среды. Первопроходцами были команды с наиболее большими компетенциями, у которых был сервис с наименьшими зависимостями. Это помогало быстрее выявлять проблемы и решать их эффективнее.

Также важно развертывать инфраструктуры в нескольких регионах, так как даже у крупных облачных сервисов могут быть перебои. Для переключения реального трафика использовали подход «Canary deployment», то есть постепенно пускали настоящий трафик в новую версию, так как клиентский трафик может быть непредсказуемым и отличатся от всех тестов.

Этап 4. Тестирование и оптимизация.

На этом этапе предстоит:

• провести тщательное тестирование перенесенных сервисов; 
• оптимизировать их для работы в облачной среде. 

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

1. Создание координационного документа, где описывались зависимости сервиса, планирование тестирования, согласование команд, а также результаты тестирования.

Интересно, что эти навыки тестирования применяются не только в процессах миграции в облако, но и в разработке маркетплейсов. Если вы QA-спец и вдруг ищите работу, пока читаете эту статью - возможно вам будет интересно узнать больше о вакансии Fullstack QA в команде СберДруг. Все подробности по ссылке ниже! 

2. Хаос-тестирование – делали мы это через AWS Runbooks. Оно включало в себя:

• CPU stress – симуляцию сверх нагрузки на ЦПУ; 
• Memory stress – симуляцию сверх нагрузки на ОЗУ; 
• Break dependency – симуляцию, когда один из или все зависимости сервиса “отваливаются”, например БД или сервис аутентификации;

			sudo iptables -I FORWARD -s XX.YY.ZZ.II -j DROP
sudo iptables -I FORWARD -s XX.YY.ZZ.II -j DROP
		

• Dependency latency – симуляцию задержки; 

			sudo tc qdisc add dev eth0 root netem delay 3000ms
sleep 600s
sudo tc qdisc del dev eth0 root netem delay 3000ms
		

• Instance termination – симуляцию ситуации, когда виртуальные машинки перезагрузятся или “отвалятся”. 

3. Normal and Peak Usage/Peak load – симуляция обычной/средней и самой большой нагрузки.

4. Right Sizing – результаты пункта 3 помогали примерно оценить какой тип инстансов нужно выбрать, но также учитывали характер, предназначение сервиса. Были случаи, когда правильно подобранные конфигурации были на 75% финансово выгоднее, при этом обрабатывали тот же трафик.

5. Monitoring validation – убедиться, что все метрики и логи имеются и правильно отображаются.

Этап 5. Процесс вывода из эксплуатации старых сред

Здесь нужно:

• Наладить канал коммуникации;
• Разработать план безопасного удаление старой инфраструктуры.

Стоит отметить, что процесс удаления старых сред, виртуальных машин может быть еще интересней. Когда вашим продуктам более 20 лет, бывают случаи, когда ваши API, сервисы кем-то используются, о ком вы не слышали уже 10 лет. А, когда старый сервис перестает работать, начинают приходить с криком, поэтому наладка канала коммуникации поможет избежать непредвиденных работ. Также процесс проходил два этапа. Начиная с dev среды сначала отключали сам сервис и затем ждали некоторое время (например, неделю), после чего удаляли все связанные ресурсы и так до production среды.

…

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