5/5 - (2 голоса)

Если вы свои проекты ранее создавали на WordPress или другой CMS, а серверы хостились на железе, скорее всего, появлялись проблемы с сетапами, с новыми инстансами, масштабированием, быстродействием службы поддержки и подобные. Прекрасным вариантом избежать всего перечисленного является переход в облако, создание облачного офиса. Специалисты утверждают, что такой выход предоставляет надежную гарантию целостности данных. В качестве примера рассмотрим AWS – Amazon Web Services.

Недостатки и преимущества перехода с железа в Amazon

Те, кто уже испытал на себе все нюансы миграции в Amazon, говорят о ее дороговизне. Но, все же, утверждают, что затраты оправданы (хотя если стартап небольшой, проще приобрести VPS).

«Плюсов» перехода в облако с железа множество:

  1. работа в облаке способствует грамотно распределять ресурсы (тщательно просчитывать, брать сервера подходящие под конкретные задачи), что позволяет экономить финансы и не терять на простоях:
  2. экономия на оптимизации хостинга (покупка на бирже AWS спот-инстансов для решения задач с некритичным даунтаймом);
  3. использование резерва инстансов и т.д.

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

Основные этапы перехода в облако

AWS признан лидером среди облачных интернет-сервисов. Эта компания ничуть не уступает общеизвестным облачным сервисам от Google, Digital, Microsoft. При этом ее дата-центры функционируют по всему миру.

  • Первый этап миграции в Amazon – переход на S3, сервис данной компании, который представляет собой хранилище объектов. Его можно интегрировать во внутренние сайты, приложения на PHP, Symfony3 (переписывается код для раздачи внутренней статистики прямо из S3).
  • Второй – перейти на EFS от Amazon. Особенность этой сетевой системы в том, что она работает, как кредитная, определяя ресурсность файловых систем. Но здесь может подстерегать опасность исчерпывания кредитов, когда пропускная способность, а, соответственно, и скорость прогона определенного количества трафика станет равна 0. Оказывается, при большем объеме трафика предоставляется большее число кредитов. Решение проблемы: настроить корректную работу (например, если «раздуть» EFS). Но лучше всего предварительно рассчитать необходимое количество трафика, чтобы изначально кредитов было больше.
  • Третий – подключение к мастер-базе из различных региональных зон. Здесь нужно учитывать специфичность функционирования RDS. Если размещение мастер-базы и слейвов в одном регионе, то реализация данного этапа упрощается: для доступа к мастер-базе указываются source секьюрити-группы инстансов. Что же делать, если инстансы не из этого региона? Решение: как разрешенные прописываются их внешние IP.
  • Четвертый этап – логическое разделение работы роутинга в фронтовой и административной частях сайтов, если большинство удаленных специалистов передают контент через административную службу. Возможное решение: единая мастер-база. На мастер будут записываться только новые данные, при этом считывание производится со слейвов из других регионов. Для этого между регионами можно сделать ipsec-туннель (VPN). Он и будет пропускать в локацию трафик для административной службы.
  • Пятый этап – отладка автоскейлинга. Благодаря этому появляется возможность добавить в период максимальных нагрузок дополнительные инстансы с последующим их отключением.

переход на Amazon AWS

Рекомендации профессионалов

Мы советуем во время миграции в Amazon обращать внимание на следующие нюансы:

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

Планирование и реализация миграции сервисов в облако, обращайтесь [email protected]