Если вы свои проекты ранее создавали на WordPress или другой CMS, а серверы хостились на железе, скорее всего, появлялись проблемы с сетапами, с новыми инстансами, масштабированием, быстродействием службы поддержки и подобные. Прекрасным вариантом избежать всего перечисленного является переход в облако, создание облачного офиса. Специалисты утверждают, что такой выход предоставляет надежную гарантию целостности данных. В качестве примера рассмотрим AWS – Amazon Web Services.
Недостатки и преимущества перехода с железа в Amazon
Те, кто уже испытал на себе все нюансы миграции в Amazon, говорят о ее дороговизне. Но, все же, утверждают, что затраты оправданы (хотя если стартап небольшой, проще приобрести VPS).
«Плюсов» перехода в облако с железа множество:
- работа в облаке способствует грамотно распределять ресурсы (тщательно просчитывать, брать сервера подходящие под конкретные задачи), что позволяет экономить финансы и не терять на простоях:
- экономия на оптимизации хостинга (покупка на бирже AWS спот-инстансов для решения задач с некритичным даунтаймом);
- использование резерва инстансов и т.д.
Не для всех миграция в Amazon будет панацеей решения всех проблем. Для функционирования системы с большей эффективностью, экономии на затратах возможна комбинация услуг различных поставщиков.
Основные этапы перехода в облако
AWS признан лидером среди облачных интернет-сервисов. Эта компания ничуть не уступает общеизвестным облачным сервисам от Google, Digital, Microsoft. При этом ее дата-центры функционируют по всему миру.
- Первый этап миграции в Amazon – переход на S3, сервис данной компании, который представляет собой хранилище объектов. Его можно интегрировать во внутренние сайты, приложения на PHP, Symfony3 (переписывается код для раздачи внутренней статистики прямо из S3).
- Второй – перейти на EFS от Amazon. Особенность этой сетевой системы в том, что она работает, как кредитная, определяя ресурсность файловых систем. Но здесь может подстерегать опасность исчерпывания кредитов, когда пропускная способность, а, соответственно, и скорость прогона определенного количества трафика станет равна 0. Оказывается, при большем объеме трафика предоставляется большее число кредитов. Решение проблемы: настроить корректную работу (например, если «раздуть» EFS). Но лучше всего предварительно рассчитать необходимое количество трафика, чтобы изначально кредитов было больше.
- Третий – подключение к мастер-базе из различных региональных зон. Здесь нужно учитывать специфичность функционирования RDS. Если размещение мастер-базы и слейвов в одном регионе, то реализация данного этапа упрощается: для доступа к мастер-базе указываются source секьюрити-группы инстансов. Что же делать, если инстансы не из этого региона? Решение: как разрешенные прописываются их внешние IP.
- Четвертый этап – логическое разделение работы роутинга в фронтовой и административной частях сайтов, если большинство удаленных специалистов передают контент через административную службу. Возможное решение: единая мастер-база. На мастер будут записываться только новые данные, при этом считывание производится со слейвов из других регионов. Для этого между регионами можно сделать ipsec-туннель (VPN). Он и будет пропускать в локацию трафик для административной службы.
- Пятый этап – отладка автоскейлинга. Благодаря этому появляется возможность добавить в период максимальных нагрузок дополнительные инстансы с последующим их отключением.
Рекомендации профессионалов
Мы советуем во время миграции в Amazon обращать внимание на следующие нюансы:
- тщательно просчитывать трафик;
- подобрать отптимальную инфраструктуру, возможно гибридную;
- рассматривать возможные комбинации сервисов;
- не допускать беспорядка в документации.
Планирование и реализация миграции сервисов в облако, обращайтесь [email protected]