Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как мы мигрировали с железа на 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 — это обходится в десятки раз дешевле. Если комбинировать услуги разных поставщиков, можно добиться большей эффективности — и в плане работы системы, и в плане траты средств.

Итоги и выводы

Мы начали миграцию весной, и она продолжается до сих пор. Самое сложное — перенос «живого» трафика с 70-100 тыс. пользователей онлайн. На повестке дня — работа над автоскейлингом. Это позволит работать с незапланированным трафиком, который наша существующая архитектура может не выдержать. Автоскейлинг позволит добавлять дополнительные инстансы на пиковых нагрузках, а затем их отключать.

Главные рекомендации — тщательно считать трафик и рассматривать комбинации сервисов, которые позволят сэкономить. И ещё не допускать беспорядка в именованиях, группах, тегах, документации — это касается не только облака. Порядок — залог успеха :)

Из литературы могу посоветовать книгу «AWS Certified Solutions Architect Official Study Guide» — там доступно рассказано о принципах работы с Amazon. Есть также одноименные видеоуроки.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




80 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Есть хорошие ресурсы для написания скриптов для AWS?

У нас есть несколько регионов. Мастер-база находится только в одном из этих регионов, а слейвы — в каждом. Для того чтобы подключиться к мастеру, нам нужно разрешить подключение из других зон. В рамках одного региона это можно реализовать, указав source секьюрити-группы инстансов, которым нужен доступ к мастеру. Но с инстансами из другого региона так сделать не получится. Потому необходимо прописывать их внешние IP
как разрешенные.

А что мешает подключить и базы и пхп бэкэнды в один vpc? Они должны видеть друг друга и на разных регионах.
А вывешивать мастер базу на публичный ИП и делать репликацию через интернет — с любой стороны как-то не айс.)

Здравствуйте,

Идет речь о кросс регионной репликации Mysql Aurora.
В одном vpc они никогда не будут.

Для доступа к мастеру к ним можно добавить NAT gateway с Elastic IP и маршрутизировать MySQL port (3306?) для инстансов через него, в то время как http трафик будет идти через IP самих инстансов. В итоге Aurora-master будет всегда видеть фиксированный IP NAT-gateway, который и можно добавить в security group. Недостатки у этого способа в основном стоимость самого NAT-gw и стоимость трафика, но трафик между регионами в любом случае не бесплатный, поэтому надо считать, что выгоднее/проще в зависимости от объёмов данных.

Вспомнился старый прикол про профессиональное развитие:
www.smart-jokes.org/...​programmer-evolution.html

С облаками такая же прогрессия.

— Сначала ты на железе от дремучести и неосведомленности.
— Потом Амазон и щенячий восторг.
— Нагрузка растет, амазоновская тарификация начинает кушать нехилое количество американских дензнаков.
— Перебираешь альтернативные облачные решения в поисках наиболее вменяемого по цене под свой use—case. Забиваешь на Амазон и прыгаешь, к примеру, на Google Apps.
— Еще раз задалбываешься и пробуешь полу—saas наподобие DigitalOcean.
— Возвращаешься обратно к железу.

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

Мы в Cloudsimple сейчас как раз разрабатываем облако которое позволит работать с «железками» с таким же удобством как с public cloud’ом типа AWS/Azure.
Т.е. создавать свой private cloud за пару минут.

в моей практике это первый человек, который смог аргументировать, зачем ему публичное облако

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

Не совсем понятно почему даунтайм кеша не критичен. Если система стабильно работает с 10 инстансами кеша, то потеря одного из них может значит повышение трафика на 50% к базе данных, от чего она может просто упасть. Учтите, что если у вас нет RI, то нет гарантии, что вы сможете быстро получить такой же инстанс на On-Demand.

Я бы использовал spot для какой-то аналитики и фоновых задач, которые можно сделать сейчас, а можно и через месяц.

Артем, спасибо большое за все ваши комментарии!
Обязательно обсудим их с командой

Не совсем понятно, с какой целью используется EFS? Чтоб хостить php код вордпресса? Я бы посмотрел на то чтоб взять EC2 инстансы с EBS/instance storage и деплоить код на каждый инстанс (через Code Deploy, ECS или еще как нравится). Семмарная производительность дисков будет скейлиться в зависимости от кол-ва инстансов (что хорошо), а не в зависимости от размера файловой системы (что, как вы убедились, не очень хорошо.

Если эти файлы readonly и не меняются динамически, не вижу смысла держать их на EFS.

>

Чтоб хостить php код вордпресса?

Да.

Instance storage, как по мне, не много для других целей.
Для системы с небольшим iops efs больше подходит и это не затратно (даже если расширить обьем фс.).

Instance storage, как по мне, не много для других целей.

Для каких?
Тот же m3.large с 32GB SSD может вполне подойти для описанной задачи. Или любой инстанс с нужным EBS

Для системы с небольшим iops efs больше подходит и это не затратно (даже если расширить обьем фс.).

По цене 3X от EBS плюс сколько там нужно будет залить чтоб «раздуть» ее объем — не, спасибо.
Плюс single point of failure (случайно похерил что-то в EFS — все инстансы идут спать).

На этом этапе мы столкнулись с проблемой, которая обошлась нам в сутки простоя. Amazon EFS использует кредитную систему для определения того, когда файловые системы могут исчерпать выделенные для них ресурсы. Есть такое понятие, как пропускная способность: мы можем прогнать через сетевую файловую систему определенное количество трафика с определённой скоростью. Если эти кредиты исчерпываются, то пропускная способность и скорость становится равна 0. Именно это с нами и случилось: в один прекрасный день отдача файлов прекратилась.

Это не похоже на то, что написано в документации (что пропускная способность падает до 0).
В английском языке и русском слово credit/кредит имеет разные (почти противоположные) значения.

В EFS у вас есть baseline пропускная способность, ее вы должны получить несмотря ни на что. Если вы ее не используете, она начинает накапливаться на вашем балансе (до определенного предела), и вы можете ее использовать позже когда у вас есть трафик (пропукная способность будет больше чем baseline throughput но меньше чем max burst throughput. Когда баланс исчерпан, вы возвращаетесь к baseline.

На больших ФС разница между baseline и burst 2x, поэтому это не сильно заметно. На маленьких файловых системах — может быть до 200x, поэтому ситуация может выглядеть будто «все было офигенно а потом упало до нуля», на самом деле упало до baseline, который выше нуля.

Если реально упало до 0 и файловая система была недоступна, то нужно писать в службу поддержки чтоб исправляли, так не должно быть, если я правильно читаю документацию.

почему не похоже? у них был малый обьем. упало не до нуля, а до baseline малого обьема(что для определенной нагрузки означает почти 0). Они обьем увеличили. Теперь у них кредиты в час набираются быстрее, чем расходуются. Так все и есть.

Не совсем понятно к чему относится ваш комментарий, я отвечал на эту часть поста:

пропускная способность и скорость становится равна 0

Как я написал, такого не должно быть, согласно документации. Если так было (это можно было проверить через CloudWatch) — то стоит выяснить с службой поддержки почему так.

Равна нулю она не может быть, но было очень близко.
baseline не хватило чтобы обработать требуемое кол-во трафика.

У нас есть несколько регионов. Мастер-база находится только в одном из этих регионов, а слейвы — в каждом. Для того чтобы подключиться к мастеру, нам нужно разрешить подключение из других зон. В рамках одного региона это можно реализовать, указав source секьюрити-группы инстансов, которым нужен доступ к мастеру. Но с инстансами из другого региона так сделать не получится. Потому необходимо прописывать их внешние IP как разрешенные.

1. Вы добавляете публичные IPv4 адреса в whitelist? Проверьте чтоб это были ElasticIP (которые зарезервированы за вами на длительный срок). Все остальные публичные IP идут из общего пула, и туда же возвращаются, кто-то другой может получить IP который вы раньше использовали и завайтлистили, и подключиться к базе данных

2. Посмотрите в сторону AWS Direct Connect Gateway, в теории с ним можно VPC в разных регионах соединить в одну частную сеть и работать только с приватными IP адресами. (если IP CIDR блоки в разных регионах пересекаются, прийдется пересоздавать инфраструктуру с другими CIDR блоками).

>>

Проверьте чтоб это были ElasticIP

это elastic ips.
>>

Посмотрите в сторону AWS Direct Connect Gateway, в теории с ним можно VPC в разных регионах соединить в одну частную сеть и работать только с приватными IP адресами.

Соединить не проблема, придется сетапить DNS forwarder для резолва хоста базы по приватным ип в другом регионе, т.к эта ситуация возникает из-за vpc provided DNS. Когда будет потребность в авто скейлинге инстансов мы обязательно задумаемся над реализацией.
Спасибо за комментарий.

Судя по всему перед нами антипаттерн. Потому что обычно в облако уходят чтоб было дешевле и быстрее.

Я так понимаю что никакого тестирования перед переездом не проводилось?

дешевле и быстрее

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

Ну это само собой. Просто можно сначала все протестировать и потом переехать.

Удивлен. Обычно переезжают на железо с облака для экономии, а не наоборот. Поэтому появились такие вопросы:

Сколько среверов/ядер у Вас было на момент переезда?
Какова была стоимость обслуживания? (если можно разглашать)
Как выросла цена после переезда? (1-2-3-10х?)
Я так бонял большую часть кушает CDN?
Рассматривали ли вариант — быстрый скейл на облаке, а потом перенос прогнозирумой нагрузки обратно на железо? Если нет — то почему?

P.S. Мы юзаем Роут 53 для роутинга, но хостимся на ДО. Амазон в 2 раза дороже.

Добрый день

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

По вопросам:
1. У нас было где-то 25 серверов. Большинство из них — 4-8 ядер, 32Gb RAM, диски SSD
2-3. К сожалению, не могу разглашать
4. Если по стоимости, то нет, мы используем CDN от ClaudFlare и нам это обходиться относительно дешево. Если по трафику, то да, я писал в статье, что ежемесячно мы отдаем порядка 100 Tb статики.
5. Данный вариант еще не рассматривали, потому что сейчас быстро растем и что-то прогнозировать.

Обычно переезжают на железо с облака для экономии

я не понимаю одного — зачем даже те, кто не продает эти облака, пересказывают этот миф
не может что-то плюс маржа продавца стоить дешевле, чем то же но без маржи продавца
можно трансформировать CAPEX в OPEX, можно купить более дешевый товар
но никто не будет продавать себе в убыток

я не понимаю одного — зачем даже те, кто не продает эти облака, пересказывают этот миф

В чем миф то? Дропбокс уехал, епл уехал, спотифай уехал как и сотни других компаний. Гитлаб планировал, но пока не решились так как у них затраты не такие большие. Когда речь про пару десятков или сотен серверов, то это разговор ни о чем. Когда речь о тысячах это уже совсем другое дело. И экономия в 5-10х имеет смысл для бизнеса. Просто когда бизнес мал и быстро растет гораздо важнее увеличивать выручку, а не сокращать затраты. Когда бизнес стабилен и с прогноизруемым доходом дело доходит до оптимизаций затрат. Все просто.

Дропбокс уехал

вот только направлением ошиблись

Dropbox replaced its public cloud with a high-performance,
on-premises private cloud.

h20195.www2.hpe.com/...​aspx?docname=4AA6-8945ENW

По поводу аргументов, подвигших Dropbox к переходу «на свои хлеба», лучше предоставить слово самому Гупта: "Есть несколько причин такого решения. Во-первых, одним из главных достоинств нашего предложения является производительность. Перемещение хранения под свою крышу позволит осуществить комплексную оптимизацию всех компонентов и улучшить производительность

ko.com.ua/...​otreb_my_indposhiv_114751

епл уехал

:-)

Сотрудничество между IT-гигантами может оказаться очень недолгим. Скорее всего, оно продлится всего два—три года, пока Apple не введет к эксплуатацию собственные дата-центры в Аризоне (США), Ирландии и Дании, первый из которых откроется уже в этом году. Затраты i-компании на строительство ЦОД составляет почти $4 миллиарда.

hitech.vesti.ru/article/625894
по этим цифрам даже можно оценить ROI их собственных ЦОДов в ~ 3-4 года

Когда речь про пару десятков или сотен серверов, то это разговор ни о чем. Когда речь о тысячах это уже совсем другое дело.

как раз публичные облака интересны в первую очередь именно маленьким компаниям, которые просто не в состоянии создать собственную инфрастуктуру

вот только направлением ошиблись

От того, что я свое железо назвал «private cloud» оно не перестает быть моим железом.

комплексную оптимизацию всех компонентов и улучшить производительность

То есть по вашему это не связано с снижением костов?

как раз публичные облака интересны в первую очередь именно маленьким компаниям

Ну я об этом и написал.

а все, понял (прочитал еще раз с чего все началось)
я Вашу фразу, почему-то изначально неправильно понял :-) (что «В облако для экономии»)
в общем с ветряными мельницами воевал :-)
чуствую себя ... почти Дон Кихотом :-)

не может что-то плюс маржа продавца стоить дешевле, чем то же но без маржи продавца

Это в теории.

На практике, например, вы покупаете процессоры у Intel в количестве 10 штук, а гугл покупает в количестве 10 000, цена у вас будет разная. Вы будете покупать серверы у HP, Гугл будет делать серверы по своему кастомному дизайну, предварительно выбросив из него каждый ненужный винтик и конденсатор, не заплатив никому за RnD, сэкономив много $$$ на этом. И так далее.

там разница огромна только в АБСОЛЮТНЫХ величинах на ХХХХХХХ серверов гугулов
а в ПРОЦЕНТНОМ СООТНОШЕНИИ к стоимости сервера — ничтожна
а у местных локальных клоуд-провайдеров в их ЦОДах — те же стандартные HPE, IBM, NetApp, EMC, ...

Т.е. вы согласны с тем, что себестоимость машино-часа в датацентре гугла и в вашем датацентре будет разной, не в вашу пользу. С чем вы не согласны?

данное сравнение вообще бессмысленное — у гугла просто нет серверов, с используемой у меня архитектурой
P.S. кроме стоимости процессоров есть еще масса других факторов — стоимость электроэнергии, расходы на персонал, ...
P.P.S. вы много датацентров видели? (не на ютубе)

данное сравнение вообще бессмысленное — у гугла просто нет серверов, с используемой у меня архитектурой

Сначала было

не может что-то плюс маржа продавца стоить дешевле, чем то же но без маржи продавца

а теперь уже и архитектура разная и сравнение бессмысленное

P.S. кроме стоимости процессоров есть еще масса других факторов — стоимость электроэнергии, расходы на персонал, ...

Energy efficiency у гугла будет выше чем у вас. Если вы запускаете датацентры в одном географическом локейшене, то цены на электроэнергию у вас будет или примерно одинаковой, но скорее всего, у гугла ниже за счет закупаемого объема.
Плюс Гугл и прочие топовые компании строят электростанции для своих датацентров.

Расходы на персонал — какой именно персонал вы имеете в виду?

P.P.S. вы много датацентров видели? (не на ютубе)

сперва добейся?

EFS — не подходит при нагрузке на файловую систему больше 7к i/o операций , при превышении этого порога , проявляются интересные вещи ) такие как — нет доступа к файлу , файл не находит и прочие
Аналогично с s3 , есть уже експириенс когда когда s3 — отдает 500 HTTP status code при большой нагрузке.

Добрый день

У нас не высокий iops на EFS, потому подобных проблем не возникает. В случае с S3 выход — CDN.

По моему опыту работы с EC2 — если вам надо сайт на который заходят 5 человек — ок. Если надо чтото высокопроизводительное, то в 5-10 раз дешевле взять vultr или другого провайдера. Последний кейс — RDS инстанс, 100гб дата сторедж, занято 5. Сменить на 10гб нельзя(поскольку 10гб это не-provisioned iops, тоесть время трансфера неизвестно, уменьшение размера storage не поддерживается), бекап раз в день считает i/o транзакции на все 100GB и стоит 500/месяц!!!

Добрый день

Проектирование инфраструктуры под любой проект — очень индивидуальный кейс и каждый имеет право на жизнь.

Фишка ес2 в том, что там вечно вылазят всякие кейсы «вот так сделатьнельзя, а пока вы не сделаете, мы с вас будем снимать ХХХХХ долларов за текущий набор». Сначала это был входящий траффик(исходящий от DDoS все еще тарифицируется, типа вы не можете его отличить от реального — ваши проблемы), потом всякие чарджи за снапшоты, щас вот на это наткнулися. Обещанные few moments to start превратилися в 15-20 минут. Вобщем если вам ЯВНО не нужно scalability в пределах 1 часа — лучше воспользоваться чемто другим..

Не треба збивати з пантелику людей — нові інстанси AWS EC2 дійсно підіймаються за лічені хвилини. Маю досвід autoscaling-режиму роботи з AWS EC2. В нашому випадку, додаткові інстанци підіймалися з готових образів систем по сигналу від AWS CloudWatch, який відслідковував кількість завдань у AWS SQS.

Иногда за минуту, иногда за 15. Вы, наверно, поднимаете их по расписанию, а система учится. А я поднимаю БЕЗ расписания, максимальное время за прошлый месяц 14:21. Иногда и больше бывает.

По моему опыту работы с EC2 — если вам надо сайт на который заходят 5 человек — ок. Если надо чтото высокопроизводительное, то в 5-10 раз дешевле взять vultr или другого провайдера. Последний кейс — RDS инстанс, 100гб дата сторедж, занято 5. Сменить на 10гб нельзя(поскольку 10гб это не-provisioned iops, тоесть время трансфера неизвестно, уменьшение размера storage не поддерживается), бекап раз в день считает i/o транзакции на все 100GB и стоит 500/месяц!!!

Netflix, Dropbox, Amazon.com это по вашему сайты на которые заходят 5 человек?
Сравнение с другими хостингами не совсем коректное. К примеру, запорожец дешевле мерседеса в обслуживании, но разве их можна сравнивать? AWS это экосистема которая включает в себя набор сервисов на все случаи жизни, а что есть у конкурентов?

А где я пишу, что нельзя использовать для нагруженных систем? Для amazon.com поверьте цены на amazon cloud вообще другие. Просто имеет смысл только если вы используете например sqs вместо rabbitmq либо у вас нет нормальных админов способных организовать облако на другом железе. Либо если ваши задачи подразумевают необходимость жуткого скейлинга. Но опять таки, когда реально надо масштаб, амазон начинает делать задержки по 15 минут. Возможно, для компаний типа дропбокса у них другая ценовая политика — не вкурсе.

Dropbox — ушел из AWS.
Netflix — типичное менеджерское решение. Зафакапили на железе и решили, что облако спасет их от ошибок.
Amazon — ну AWS, сюрприз, для амазона и строился. Фактически это одна и та же компания.

Два из ваших утверждений не верны. Одно не верно по умолчанию, второе стало неверным только недавно :)

Расскажите подробней про опыт EFS и кода. Я пробовал так делать (размещать php код в EFS), столкнулся с проблемой, что EFS очеееень медленный, особенно на куче мелких файлов.

Добрый день
Есть такое понятие, как пропускная способность: мы можем прогнать через сетевую файловую систему определенное количество трафика с определённой скоростью.


То есть, нужно «раздувать» EFS для того, чтобы получить большую пропускную способность, что мы, собственно, и сделали.

То-есть вы просто подкинули файлы но много гигов?

Там зависимость от хранимого обьема — практически линейная. Но малые файлы все равно плохо будут. Можно их кешировать в других структурах.

А можно еще чуть более подробно?
Смотрите, у нас в проекте немного модифицировано ядро. Так исторически сложилось. Под каждого клиента своя папка var (тут и получаем то самое узкое место) и log. Получаем единую кодовую базу, но со своими личными папками с кешем и логами для каждого клиента. Это работает на ура в варианте с одной рабочей машиной.

Было принято решение реализовать Autoscaling и уперлись как раз в узкое место — EFS. Предположим что у нас 500 клиентов. При обновлении приложения нам придется запустить прогрев кэша для каждого. В итоге при замере iotop скорость записи упирается в 120 Kб/c и да, это множество мелких файлов, что дает мне повод думать что EFS не выход из ситуации ибо при таком раскладе прогрев для одного происходит безумно долгий отрезок времени.

Возможно кто то сможет подсказать, каким образом все же реализовать Autoscaling? Есть не очень адекватный вариант — поднимать «шаблонную машину» куда выкатывать изменения, прогревать кеш для каждого, делать образ, обновлять Launch Configuration и обновлять запущенные инстансы в ASG, но даже тут я не уверен ибо подозреваю что когда два разных запроса одного и того же клиента будут обрабатываться на разных машинах, то один запрос возможно изменит кэш, но эти изменения на другой машине понятно что доступны не будут и вполне вероятно что работа будет не совсем адекватна.

Спасибо если кто то чуть приподнимет завесу.

Надо понимать, что лежит под всей этой механикой. Вам создается том EBS на основе которого работает сервис. Соответсвенно чем больше сумарный обьем этого EBS, тем больше его показатель IOPS. Просто зафигачте туда десятигагабайтный файл и сравните.
Насколько я помню, по умолчанию у амазона порядка 50-150 IOPS на каждые 10Гб места EBS.

EFS, надо полагать ?
Вот книгу надобно прочитать которую рекомендовали. Спасибо за ответ. Попробую.

Нет, все основано именно на EBS(block storage). Все остальные данные будут производные. Просто вам выделяется виртуальный диск. Его скорость зависит от обьема. Это все неявно. Но по сути так есть. Больше платите — больше производительность на пиках, даже если вам столько не надо.
Сколько IOPS потребляет на одну операцию EFS — не в курсе, можно померять просто императивно.

Не сочтите за невежество, но правильно ли я понял что скорость обращения к EFS зависит от объема EBS инстанса ? И чем больше инстансов с большими объемами своих блочных устройств, к которым подмонтирован EFS, тем с большей скоростью в итоге я смогу обратиться к EFS ? Я просто не очень понимаю логику которую только что придумал :) Вероятно я что то не так понял.

вот же таблички есть. docs.aws.amazon.com/...​atest/ug/performance.html . Нет, блочные девайсы инстансов не участвуют. Если вы используете EFS, участвует только текущий том EFS. под каждым EFS есть(неявно) хранилище. Вот чем больеш у вас общий вес файлов в EFS, тем больше IOPS.

Все просто. Есть вот а амазона 200 дисков на 2тб каждый. Чем больше вы дисков займете, тем меньше вам будет мешать деятельность других пользующих диски.

Да, я понял, просто сразу не правильно интерпретировал слова :) Спасибо.

Тем не менее, увы, не заработало как надо. Т,е. при копировании одного файла, я вижу более чем приемлемую скорость, а вот при прогреве кэша больше чем 120 KiB не поднимается. Я предполагаю что дело в количестве мелких файлов генерируемых прогревом, однако конечно я не ожидал что это будет такой уж проблемой для EFS. Спасибо за помощь, будем искать другие варианты. Возможно поднимем NFS сами, попробуем как будет работать с ним. Проблема ли это NFS в целом или EFS в частности.

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

Задача была сделать приложение масштабируемое горизонтально и в нашем случае при обновлении нужно прогревать кэш для каждого пользователя. Если их 1000, нужно запустить 1000 прогревов кэша (не спрашивайте почему это так :) ).

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

Сначала выбор пал на EFS, пока мы не столкнулись с тем что при прогреве создается 6000 файлов и для EFS это оказалось катастрофой в плане производительности.

Дальше было принято решение поднимать GlusterFs, чтоб работать с кэшем локально. Тоже потерпели неудачу, т.к. обнаружили что вторая машина, которая учавствует в реплике не очень адекватно себя ведет. Вернее ведет она скорее всего себя так как должна вести, тем не менее нам это не подходит.

Поставили NFS и добились в общем то того чего хотели. Сейчас тестируем создание кешей в несколько потоков. Остается открытым вопрос о отказоустойчивости ибо NFS сервер размещается в одной зоне, тогда как (и если) она вдруг перестанет отвечать, машины находящиеся в autoscaling group в другой зоне перестанут видеть файлы. Надобно будет поднимать кластер из NFS и размещать в разных зонах. Вот тут я совсем плаваю ибо никогда этого не делал. Возможно у кого то есть в этом опыт и даст ценные советы по развертыванию отказоустойчивого NFS кластера на AWS хотя бы на две зоны.

Такая история.

Автору спасибо за статью. Очень интересно.

Возможно у кого то есть в этом опыт и даст ценные советы по развертыванию отказоустойчивого NFS кластера на AWS хотя бы на две зоны.

EFS это и есть отказоустойчивый NFS кластер на AWS.

Вы пробовали по совету ТС увеличить размер ФС до поинта когда пропускная способность становится достаточной для вашего кейса?

EFS это и есть отказоустойчивый NFS кластер на AWS.

Да, я понимаю конечно и он работает так впрочем как и ожидается.

Вы пробовали по совету ТС увеличить размер ФС до поинта когда пропускная способность становится достаточной для вашего кейса?

Да, конечно, более того
Newly created file systems begin with an initial credit balance of 2.1 TiB, which enables them to add data at the 100 MiB/s burst rate until they are large enough to run at 100 MiB/s continuously (that is, 2 TiB).

И одиночный файл ну или несколько файлов работают с хорошей скоростью записи и чтения.

У меня же создаются для одного пользователя около 6000 файлов.
В варианте который я в итоге стал использовать (а именно делать операции с кешем на самой машине, где живет демон NFS) прогрев кеша для одного пользователя занимает 10 секунд, в варианте же прогрева на подмонтированном диске с использованием NFS это происходит 10 минут. И, как я понял, с этим ничего не поделать.

Не совсем ясно что за задачу вы решаете и почему выбрали решение основанное на файловой системе.

Если это веб-приложение, я бы не делал single-tier (держать данные на той же машине, что и веб-сервер). Предпочел бы 2 отдельных компонента, один для хранения данных, другой для веб-серверов.

Предпочел бы поменьше играться с кешем. Использовал бы кеш, чтоб снизить латентность, но источник данных, который лежит под кешем, должен быть способен на 100% обслужить весь production traffic если кеш по какой-то причине сброшен.

Я бы пилил свой NFS кластер только если другого выхода нет. В AWS хвататет хорошо масштабируемых систем хранения данных. (S3, DynamoDB, но есть определенные нюансы). Вероятно, приложение прийдется модифицировать, чтоб оно могли с ними работать. Но я считаю, суммарно будет выигрыш за счет того, что вам не нужно заниматься настройкой NFS кластера и постоянной поддержкой его в работоспособном состоянии (заменять отказавшие EC2 инстансы, восстанавливать после аварий в датацентрах, разбираться с рандомными повреждениями данных и т.п.).

Спасибо за ответ. Я могу расширить описание проблемы.
Не спрашивайте почему именно так, как есть, считайте что так сложилось исторически и с этим ничего не поделать, а как то заставить это работать нужно...

Речь не идет о хранении «полезных» данных на машине с веб сервером, данные будут хранится на S3, но сами файлы Symfony именно на серверах...

Итак, было некое приложение на Symfony. Одно приложение — одна база данных, один пользователь, один vhost в Nginx ну и в конце концов одна команда bin/console cache:clear .

Потом стало несколько приложений, несколько пользователей, и в общем всего по несколько.

Потом настала очередь геморроя при обновлении приложения как минимум.

Понятно что идеальное решение вопроса — одно приложение, одна база данных — разные пользователи. Но вот тут появляется то самое «исторически сложившееся» и перестроить приложение на подобную схему попросту было нельзя, но решать вопрос как то нужно.

Была поставлена задача заставить работать приложение с одной (назовем ее единой) кодовой базой.

Единственный вариант который стал рабочим — модификация ядра и вынос папок var/cache для каждого клиента в отдельную папку. Соответственно 100 пользователей — 100 папок. 1000 пользователей 1000 папок. По крайней мере на этом этапе, пока не будет новой версии приложения.

Вся эта радость должна работать через балансировщик ну и так же должен работать autoscaling.

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

Тут и получаем задачу — все сервера должны иметь доступ к одному и тому же коду. Кажущийся выход — EFS, но на создание множества файлов это не работает, а мне нужно создавать эти файлы. Обновить 1000 пользователей — создать около 6000000 (6 млн.) файлов.

Вот и было принято решение поднимать NFS самому, но с файлами работать на той же машине где и NFS демон как с EBS, что дает мне все те же 6000 файлов за 10 секунд, а на EFS (читай NFS) это растягивается на 10 минут.

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

Не рассматривали вариант хранение кеша не в файлах, а в redis’е, например. Выделить отдельный инстанс, посчитать сколько памяти нужно. Всем ключам одного пользователя давать префикс user:id:..., для удобства сброса кеша по юзеру. Доступность с любого backend’а. Если код работы с кешем достаточно изолирован, то переделка не должна занять много времени, это должно было быть быстрее чем эксперименты и настройка распределённых файловых систем.

Это кэш Symfony приложения, я не представляю возможным перенести его куда либо. Пользовательский кэш у нас и так живет в Redis. Но, кстати говоря, надобно будет в эту сторону копнуть, вдруг Symfony разрешает указывать где хранить свой кэш. Спасибо.

p.s. По сути он из себя представляет множество PHP файлов, которые создаются в процессе парсинга всего проекта, но не ключ-значение.

Не специалист в симфони, но почти уверен, что в настройках DI-контейнера можно указать свой класс, который должен реализовывать нужный интерфейс кеш-адаптера и всё.

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

Не рассматривали вариант хранение кеша не в файлах, а в redis’е, например.

А вот интересная штука — существует redisfs , в свою очередь в ядре мы можем указать путь к папкам куда угодно и откуда угодно, вот попробуем скрестить ужа с ежом. Это будет по крайней мере интересно.

Попробовали несколько реализаций redisfs, в общем работает, но по сути вариант, увы, не рабочий.

Посмотрите еще в сторону cephfs,
docs.ceph.com/docs/master/cephfs
С ним можно и на 4 зоны сделать сторейдж, только нужно хорошую сетевую пропускную способность ~10Gbit/sec (линки в авс это позволяют).

Спасибо. Посмотрим обязательно. Но мы тут намедни включили мозги и в общем то решили очевидную вещь — все переменные вынесли благодаря dotenv компоненту в отдельные env файлы, чутка изменили фронт контроллеры плюс bin/console и в общем говоря получили то чего хотели. Одна кодовая база — один кэш. Единственное — оставили каждому свои логи. Вообще говоря Symfony радует.

А вообще говоря все что на FUSE опирается, как я понял, работает более менее одинаково — плохо с большим количеством мелких файлов.

EFS добавила provisioned throughput, теперь файловую систему не нужно искуственно раздувать.

aws.amazon.com/...​s-provisioned-throughput

Расскажите и вы по подробнее — а OpCache в таком случае не спасает? А если предварительно прогревать кеши прогоном тестов? Да если тесты ещё хоть задевают каждый классс/файл?

Нам необходимо кешировать еще и контент, который мы отдаем, потому одним OpCache нам не обойтись

Минус миграции с железа в облако может быть только один — это дорого. С нашими масштабами эти затраты оправданы.

у вас нету оценки сколько приблизительно разница в цене в 2-3-10?
Понимаю что все индивидуально — но может есть хоть набросок

С ростом географии сервисов по всему миру мы были вынуждены покупать сервера в Бразилии, Штатах, Германии

Почему не использвать тот же CloudFlare не только под статику — а и сам сайт.
Регионов у них много покрыто, наличие сервера в Германии или США не сильно будет сказыватся конечному клиенту.

Да и переключать сайт на новую ноду/ип балансировшика итд чуть проше

p.s. как то у вас сайты дублируют сами себя (или криво настроены)
wikr.com
fabbiosa.com
хотя судя по источникам трафика упор на трафик с соц сетей и поисковый не важен наверное

От 2 до 10 раз, в зависимости от структуры. Оправдано, если есть задачи требующие пиковой нагрузки вида 30% времени и меньше требуется больше серверов.

Добрый день

Вы правы, такое сравнение очень индивидуально. А для себя мы его, к сожалению, не проводили.

CloudFlare — хороший вариант, но в связи с определенными особенностями, нам нужны физические точки присутствия в каждой из вышеперечисленных стран.


Дублирующиеся сайты — это алиасы, так и должно быть. И да, вы правы, трафик из соц сетей для нас является приоритетным

А kubernetes под управлением rancher вроде как должен решить проблему с автоматическим масштабированием при росте нагрузок. healthchecker пингует контейнеры (инстансы wp), если нет ответа ( уже загружен) — поднимает новый инстанс. EFS драйвер там точно есть, чтобы примонтировать хранилище к контейнерам да и комбинировать можно железки, AWS и еще около 10 облачных аналогов. Можно выбирать по цене. Только вот не знаю с коробки контейнеры будут подниматься вместе с созданием новых инстансов по API, но приблизительное время около 5-10 минут (я пробовал на практике брать инстансы AWS прямо с ранчера по API уходило гдето столько времени) + время на поднятие докер-контейнера. А сколько уникальных сайтов на WP у вас есть? Просто нужда EFS при использовании докер сборок отпадает, так как код пулим в контейнер и возможно только конфиги нужны будут для общего доступа между разными контейренами в разных регионах... Ну как то так, если интересно, могжем вместе подумать над этим, давно хотел на кейсе попробовать подумать над архитектуркой и даже потестить силу RANCHER?

Забыл упомянуть Cloudflare и Route53 тоже есть в инфраструктуре Rancher, так что в теории DNS тоже обновляеться по API, правда не знаю, полностью ли можно автоматизировать или надо будет пару кнопок нажать в UI.

Підписатись на коментарі