Миграция данных в облако: как избежать проблем и ошибок?

С какими проблемами можно столкнуться

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

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

Давайте попробуем разобраться, что может пойти не так, и как нам взять максимум от облака после миграции. Спросите себя «Зачем мне облако»? Популярные ответы «сэкономить», «сократить IT-штат», «повысить доступность» или самое прекрасное: «все так делают, чем мы хуже?» являются следствием стереотипов об облаках и облачном хостинге. Чтобы грамотно ответить на вопрос «зачем», стоит сначала посмотреть на преимущества, которые предоставляет облачный хостинг, и исходя из ваших бизнес-задач, выбрать те, которые действительно важны.

Зачем мигрировать

1. Отсутствие капитальных затрат и собственной инфраструктуры. Одним из самых очевидных плюсов с точки зрения затрат – нет необходимости вкладываться в содержание собственной инфраструктуры. Помимо оборудования, которое надо постоянно обновлять, вы должны обеспечить физическую безопасность помещения, озаботиться о системах кондиционирования, видеонаблюдения и пожаротушения.
2. Безопасность. Вам не нужно будет думать о физической безопасности вашей инфраструктуры, достаточно выбрать IT-интегратора, который обеспечивает безопасность по стандартам. Стандарты должны быть прописаны в договоре.
3. Неограниченные ресурсы и гибкая система оплаты. Переходя в облако, вы получаете практический бесконечные ресурсы. Вы можете оплачивать их по схеме pay as you go, и потреблять столько мощностей, сколько вам необходимо в данный момент времени. Для компаний, занимающихся разработкой, это очень большой плюс. Например, можно увеличить ресурсы на тестовом контуре в десятки раз, провести необходимые тесты, и «схлопнуть» инфраструктуру, когда это потребуется. Делать это на своих мощностях, значит либо держать большой объем оборудования, которое не будет использоваться большую часть времени, либо ограничивать свои среды, тем самым потенциально снижая качество тестов, или скорость выхода приложения.
4. Масштабируемость и «самолечение» – autoscaling & autohealing. Если ваша архитектура позволяет масштабироваться, то вы можете настроить правила автоматического масштабирования и восстановления, на основе триггеров систем мониторинга. После внедрения механизмов autohealing ваше приложение сможет самостоятельно восстанавливаться после сбоев, снижая время простоя до минимума.
5. Наличие PaaS сервисов. Представим классическое приложение из нескольких стандартных компонентов: база данных, веб-интерфейс и само приложение, служба или сервис. Для хостинга такого приложения в своем периметре вам скорее всего понадобится несколько серверов. Если ваше приложение критично для бизнеса, оно обязано быть отказоустойчивым, – вы построите ДБ кластер или внедрите мирроринг, сделаете балансировщик нагрузки для веб-сервера и зарезервируете ресурсы для самого приложения. Помимо тестовых сред и для разработки, вам потребуется довольно много серверов и массивная инфраструктура. При переходе в облако вам будут доступны PaaS сервисы, и тогда те же задачи вы сможете реализовать, например, на DBaaS и контейнерах. Вы не будете разворачивать виртуальные машины, базы данных и другие компоненты – это больше не потребуется.
6. Возможность построения гибрида. Если ваше приложение поддерживает микросервисную архитектуру, является cloud native, вы сможете легко балансировать между несколькими облаками. Популярная схема – бизнес-критичные данные хранить в своем периметре, веб-сервер и ДБ в публичных облаках, разделив данные таким образом, чтобы не нарушать закон о персональных данных. Вы не будете зависеть от одного облачного провайдера и получите возможность относительно легкой миграции из одного публичного облака в другое.

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

Чек-лист: как избежать проблем

1. Назначить архитектора миграции и других ответственных. Архитектор миграции – это специалист на уровне системного архитектора, ответственный за планирование и завершение всех аспектов миграции.
2. Определить методику перехода. Нужно решить, будете вы переносить все приложение сразу или же по частям. Для этого определите связи между сервисами и поймите, какие из них зависят друг от друга. 
   У нас был кейс, в котором главной целью было снижение капитальных затрат на оборудование: переезд был инициирован финансовым, а не IT-отделом. Проект разрабатывал заказчик, покупая только IaaS. Был спланирован переезд пары десятков приложений с целью сократить количество физических серверов на собственной площадке на 70%. Они не учли, что при переходе в облако требования к качеству каналов передачи данных растут. Миграция приложений прошла нормально, все облачные сервисы работали штатно, без проблем и отказов – как и ожидалось. Однако, очень скоро стало очевидно, что скорость работы с приложениями сильно снизилась – ширины канала передачи данных не хватало, а частые аварии у операторов связи приводили к простоям. Изначальная цель миграции был достигнута – капитальные расходы значительно сократились, но при этом производительность приложений снизилась. Компании пришлось в срочном порядке менять сетевую инфраструктуру, увеличить пропускную способность интернет-каналов и улучшить их отказоустойчивость. Если бы они провели аудит до начала работ, этого бы удалось избежать.
3. Выбрать одно облако или использовать несколько облаков. Если вы не хотите полностью зависеть от одного провайдера, можно задуматься о мультиклауд подходе – это когда ваша инфраструктура распределена между несколькими облаками для обеспечения высокой отказоустойчивости бизнес-критичных приложений.
4. Установить KPI для облака. Возможно, вы уже определили некоторые ключевые показатели эффективности для своих приложений и служб, но применимы ли они для приложения или сервиса, когда они находятся в облаке? Правильные KPI должны демонстрировать, как проходит текущая миграция, выявляя видимые или невидимые проблемы, которые могут скрываться в вашем приложении.
5. Определить базовые показатели эффективности. Чтобы отслеживать KPI, сначала вам нужно измерить ваши стандартные показатели производительности. Предыдущий пункт определяет, каких результатов вы хотите достичь. Здесь же вы определяете свою «норму».
6. Расставить приоритеты для компонентов миграции. Нужно решить, будете вы переносить все приложение сразу или же по частям. Для этого определите связи между сервисами и поймите, какие из них зависят друг от друга.
7. Создать план переноса данных. Перенос данных – одна из самых сложных частей миграции в облако. Расположение данных может существенно повлиять на производительность приложения.
8. Переключить на продуктовую среду. Когда и как вы переключите производственную систему с устаревшего локального решения на новую облачную версию? Ответ зависит от сложности и архитектуры приложения, и особенно от архитектуры ваших данных и их хранилищ.
9. Распределите мощности приложения. Облако оптимизировано для динамического распределения ресурсов, и когда вы распределяете ресурсы (например, серверы) статически, вы не пользуетесь преимуществами облака.

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

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

Послесловие

Одним из преимуществ миграции в облако, о котором часто забывают, является ее обратимость. Тем, кто сомневается в своей стратегии или своих силах, я напоминаю о том, что всегда можно вернуться туда, откуда компания пришла, поменять провайдера и так далее. Но на моей практике, однако, «обратно» не вернулся никто. Разумеется, бывали и смены хранилищ, и полная переделка инфраструктуры, но общий результат всегда был лучше, чем вчера. Это говорит о том, что решение о миграции – вопрос времени для большинства бизнесов, и с ростом общего уровня цифровизации входной порог требований целесообразности будет снижаться.

Читайте также: