Как мы мигрировали с железа на AWS: проблемы и решения
Меня зовут Илья, я CTO компании Wikr Group. Мы занимаемся созданием и развитием контент-проектов во всем мире. Ежемесячно наши ресурсы посещают более 100 млн уникальных пользователей.
Изначально все наши проекты были созданы на WordPress, а серверы проекта хостились на железе. С ростом географии сервисов по всему миру мы были вынуждены покупать сервера в Бразилии, Штатах, Германии — во всех точках присутствия. Это было неудобно с точки зрения администрирования: возникали трудности с сетапами, добавлением новых инстансов. Когда нужно было масштабироваться, мы тратили по несколько дней на ожидание, пока новый сервер доставят в стойку. И после — пока получим ответ от службы поддержки. Ввиду всего этого нам хотелось быть гибкими, быстро деплоиться и управлять всем из одного места.
К тому же наш продукт — это контент, а работа с контентом подразумевает большое количество статики, в нашем случае картинок. Ежемесячно со всех наших ресурсов мы отдаем около 100 Тб статики. Обслуживать с железных дисков такие объемы данных стало неудобно.
Так было решено переехать в облако. Это надежно, удобно и позволяет гарантировать целостность данных. Выбрали Amazon Web Services.
Почему AWS?
Amazon — лидер, именно он диктует правила клауда в мире. С AWS конкурируют Google Cloud, Microsoft Azure, Digital Ocean и т. д. Но так сложилось исторически, что на тот момент мы уже пользовались некоторыми сервисами Amazon — к примеру, Route 53 DNS Service для балансинсировки запросов. Нам было проще расширяться, интегрировать и синхронизировать остальные сервисы уже оттуда.
К тому же, у Amazon есть очень много дата-центров по всему миру, которые связаны между собой. Как я писал выше, наши серверы тоже размещались в разных странах Европы и Америки, и поэтому мы намеревались переехать на ту же структуру — только теперь соединенную в одну сеть намного более быстрыми каналами.
Переход на S3 и EFS
S3 — это хранилище объектов, один из сервисов в AWS. Первым делом мы интегрировали этот сервис в наши внутренние (не контентные) сайты: порядка 12 аналитических и других приложений, написанных на PHP 7 и Symfony 3. Переписали код, чтобы раздавать внутреннюю статику напрямую из S3, однако контентные сайты все равно продолжали работать на железе. Часть проблем осталась: нам все еще приходилось поднимать WordPress во всех регионах, где мы запускались.
Следующим этапом миграции был переход на сетевую файловую систему EFS.
На этом этапе мы столкнулись с проблемой, которая обошлась нам в сутки простоя. Amazon EFS использует кредитную систему для определения того, когда файловые системы могут исчерпать выделенные для них ресурсы. Есть такое понятие, как пропускная способность: мы можем прогнать через сетевую файловую систему определенное количество трафика с определённой скоростью. Если эти кредиты исчерпываются, то пропускная способность и скорость становится равна 0. Именно это с нами и случилось: в один прекрасный день отдача файлов прекратилась.
Написали в саппорт, и нам в ответ скинули статью, где рассказано, как все рассчитывается, предложили нам самостоятельно рассчитать необходимые размеры трафика. Оказалось, что чем больше его объем, тем больше кредитов предоставляется. Таким образом, для корректной работы пришлось «раздуть» EFS файлами-заглушками из 4 Гб (это был только код, так как все картинки в S3) до 30 Гб.
Теперь мы уже заранее рассчитываем, какое количество трафика нам будет обеспечено. Когда необходимо, предварительно увеличиваем размер файловой системы, чтобы получить больший кредит.
Специфика работы RDS
У нас есть несколько регионов. Мастер-база находится только в одном из этих регионов, а слейвы — в каждом. Для того чтобы подключиться к мастеру, нам нужно разрешить подключение из других зон. В рамках одного региона это можно реализовать, указав source секьюрити-группы инстансов, которым нужен доступ к мастеру. Но с инстансами из другого региона так сделать не получится. Потому необходимо прописывать их внешние IP как разрешенные.
В результате приходится считаться с тем, что этот фактор мешает динамически кросс-регионно скейлить инстансы, которым необходим доступ к мастер-базе.
Единая админка
Мы работаем на 7 разных локациях по всему миру, и, соответственно, у нас 7 редакционных команд. Очень много ребят оттуда работает удаленно — это локальные редакторы, переводчики, создатели контента, специалисты по постпродакшену. Они все работают с контентом через админку.
Поэтому возникла задача на уровне AWS логически разделять, как будет работать роутинг в административной и фронтовой частях наших сайтов.
Нашли такое решение: сделали одну мастер-базу в Европе. Записывать новые данные мы можем только на мастер, а считываем с региональных слейвов. Чтобы все записывать в одно место, мы сделали между регионами ipsec-туннель — VPN, который пропускает трафик через шифрованный туннель в Европу, в локацию админки. Таким образом, к примеру, когда контент-редакторы из Бразилии редактируют материалы, информация идет по цепочке из Южной Америки в Европу.
Наша текущая архитектура
Денежные вопросы
Минус миграции с железа в облако может быть только один — это дорого. С нашими масштабами эти затраты оправданы. Но если идет речь о небольшом стартапе, то, возможно, будет проще купить VPS.
Работа в облаке учит работать с ресурсами, все тщательно просчитывать и избавляет от необходимости брать сервера «на вырост». Мы берём только те сервера, которые подходят именно под наши задачи. Например, если нужно 3 двухъядерных инстанса — столько и возьмем. Так не приходится платить больше и терять на простое.
Сэкономить возможно и на оптимизации хостинга. AWS предлагает обратить внимание на так называемые спот-инстансы — инстансы, которые продаются на их бирже по принципу аукциона. Так можно поймать самые низкие цены. Однако надо понимать, что позже их цена может повыситься, и они «схлопнутся». Потому на них нельзя построить основную рабочую группу, но вполне можно крутить те задачи, для которых даунтайм не критичен. Например, один из уровней кэша.
Другой способ сэкономить — использовать резерв инстансов. Мы пока что им не пользовались, так как у наших проектов идет активный рост, и нам пока что сложно точно спрогнозировать масштабы.
При этом нужно понимать, что Amazon — это не всегда панацея. К примеру, у AWS дорогой CDN. Мы используем сервис компании CloudFlare — это обходится в десятки раз дешевле. Если комбинировать услуги разных поставщиков, можно добиться большей эффективности — и в плане работы системы, и в плане траты средств.
Итоги и выводы
Мы начали миграцию весной, и она продолжается до сих пор. Самое сложное — перенос «живого» трафика с
Главные рекомендации — тщательно считать трафик и рассматривать комбинации сервисов, которые позволят сэкономить. И ещё не допускать беспорядка в именованиях, группах, тегах, документации — это касается не только облака. Порядок — залог успеха :)
Из литературы могу посоветовать книгу «AWS Certified Solutions Architect Official Study Guide» — там доступно рассказано о принципах работы с Amazon. Есть также одноименные видеоуроки.
Если вы только начинаете работать с AWS, обязательно пообщайтесь с теми людьми, кто уже имеет такой опыт. Мы всегда готовы подсказать и дать совет: пишите в комментариях или в личные сообщения.
