Comments 19
Хороший пост.
Хочу поделиться наблюдением о том, как использование облаков и CDN в обозримом будущем повлияет на мозги разработчиков сайтов. Которые привыкли динамически генерить страницу (по шаблону) в ответ на запрос, а потом подгружать на неё элементы дизайна. В то время как для эффективности сегодня надо наоборот максимально быстро отдать статический каркас страницы из CDN, а затем асинхронно подрузить на неё динамику от апачей.
Насколько я знаю, никто из российской топовой тройки CMS так пока не делает. А у вас как?
Хочу поделиться наблюдением о том, как использование облаков и CDN в обозримом будущем повлияет на мозги разработчиков сайтов. Которые привыкли динамически генерить страницу (по шаблону) в ответ на запрос, а потом подгружать на неё элементы дизайна. В то время как для эффективности сегодня надо наоборот максимально быстро отдать статический каркас страницы из CDN, а затем асинхронно подрузить на неё динамику от апачей.
Насколько я знаю, никто из российской топовой тройки CMS так пока не делает. А у вас как?
Спасибо. Так будет еще быстрее — отдавать все что можно как статику через CDN, а динамику дергать параллельно используя nginx как сборщик кусков от серверов приложений за ним (обратный прокси) с SSI.
Не думаю, что предложенный вами способ генерации страниц в обозримом будущем будет массово использоваться, все-таки традиционная схема — сгенерированный каркас и контент плюс статика в CDN лучше подходит для большинства сколь-либо сложных веб-проектов.
Хотя как нишевое решение для кого-то, конечно, подойдет.
Хотя как нишевое решение для кого-то, конечно, подойдет.
Думаю обращений к сайтам, особенно с мобильных устройств станет все больше и разработчики будут вынуждены заюзать по максимуму ресурсы облаков, CDN — иначе не справятся с нагрузкой.
Безусловно, CDN — очень полезна, но все же классическое взаимодействие с ней (для отдачи статики в динамически сгенерированный шаблон) выглядит более очевидным, и имеет понятные плюсы.
С CDN нет так страшно машины держать в США, где все новое появляется быстрее и впервые :-) Пускай там PHP работает, чисто бизнес-логика — а весь контент как по трубам отдается с ближайших серверов CDN к клиенту. Я тестил ради любопытства скорость загрузки ресурсов на серверах в Бразилили из США через CDN — скорость песня, латенси несколько ms :-)
Я с вами полностью согласен.
У меня есть весьма в итоге успешный опыт перевода highload проекта 24/7 на CDN от этих известных ребят — level3.com.
Я лишь хочу сказать, что схема предложенная dgstudio, которую вы поддержали, вряд ли получит массовое распространение.
А вот традиционный вариант со статикой на CDN, как я уже говорил, очень хорош, при этом месторасположение серверов приложений действительно в такой конфигурации не играет решающей роли.
У меня есть весьма в итоге успешный опыт перевода highload проекта 24/7 на CDN от этих известных ребят — level3.com.
Я лишь хочу сказать, что схема предложенная dgstudio, которую вы поддержали, вряд ли получит массовое распространение.
А вот традиционный вариант со статикой на CDN, как я уже говорил, очень хорош, при этом месторасположение серверов приложений действительно в такой конфигурации не играет решающей роли.
level3 это крутые ребята :-) Мы столкнулись с тем, что CDN Амазона не имеет точек раздачи в России. Для отечественных проектов решили раздавать через CDNVideo. Еще хвалят Ngenix. Интересно, когда гиганты выйдут на наш рынок и откроют точки раздачи трафика в России, те же level3 ;-)
Ну то, что их нет в России, не так уж и страшно. В моем случае это была онлайн-игра, где статика обновлялась раз в неделю, да и то небольшая ее часть. Поэтому основной задачей CDN было быстро отдать новые файлы пользователям.
Кстати, для сайтов можно реализовать механизм, запускающийся после полной загрузки запрошенной страницы, загружающий статику, которая не используется на данной странице, но может пригодиться впоследствии, чтобы браузер спокойно, пока пользователь изучает уже загруженный контент, клал ее в кэш. Отображать, конечно, ее не нужно.
Кстати, для сайтов можно реализовать механизм, запускающийся после полной загрузки запрошенной страницы, загружающий статику, которая не используется на данной странице, но может пригодиться впоследствии, чтобы браузер спокойно, пока пользователь изучает уже загруженный контент, клал ее в кэш. Отображать, конечно, ее не нужно.
Мы часто делаем приложения, которые имеют возможности кэширования страниц целиком (например, это может указываться в конкретном Action контроллера). Далее NGINX раздаёт такие страницы статически для пользователей, не вошедших в систему. Метод подсмотрен в плагине W3TC для Wordpress.
Также кэшируются на диске и/или в памяти кусочки страниц, из которых легко и быстро собрать страницу.
Также кэшируются на диске и/или в памяти кусочки страниц, из которых легко и быстро собрать страницу.
А теперь начните раздавать этот закэшированных контент через CDN — нгинкс будет загружен значительно меньше, клиенты начнут закачивать статику с латенси в 2-7 мс, а не 50-150 как часто бывает. Рулить устареванием файлов в CDN — через «file?123453». На форумах веб-сервисов Амазона часто встретишь как уже сами клиенты требуют чтобы разработчики убирали максимум статики и файлов в облако и CDN.
Знать бы хоть одну CMS, которая бы из коробки готова была к такому разделению. Просто потому, что CMS — понятие массового рынка, и рассчитываются на «массовые» хостинги. А там CDN, SSI, множества бекэндов, балансировщиков и прочего не то чтобы нет — даже если и есть, массовый покупатель этого не использует, ибо не понимает и боится. А так — купил аккаунт на LAMP-сервере, установил Wordpress, обвешал плагинами — работает себе. Только такой «чересчур динамический» сайт нормально «разбить» под технологичный хостинг — проще повеситься…
Т.е. здесь речь надо вести о AWS-заточенной CMS, а это все же товар уникальный, поскольку этот хостинг выбирают уже те, кто понимает, что хочет, и требования такого заказчика устроит не CMS, а сайт на основе CMF.
Пока же массовые CMS имеют модули для работы с CloudFlare (честно сказать, который «и так», без модулей, работает), где хоть что-то делается «как бы автоматом». Как бы, поскольку такой кеш подходит не всем, но многим тексто-ориентированным сайтам подходит вполне.
Т.е. здесь речь надо вести о AWS-заточенной CMS, а это все же товар уникальный, поскольку этот хостинг выбирают уже те, кто понимает, что хочет, и требования такого заказчика устроит не CMS, а сайт на основе CMF.
Пока же массовые CMS имеют модули для работы с CloudFlare (честно сказать, который «и так», без модулей, работает), где хоть что-то делается «как бы автоматом». Как бы, поскольку такой кеш подходит не всем, но многим тексто-ориентированным сайтам подходит вполне.
Наш продукт поддерживает несколько облачных технологий «из коробки». Мы хорошо понимаем что это так востребовано и идем навстречу:
1) CDN — не меняя код вы включаете замену ссылок на ресурсы и клиенты начинают загружать картинки, стили и скрипты с ближйший серверов CDN. Я думаю это как раз то, что будет востребовано большинством типовых проектов — сайт становится рядом с клиентом :-)
2) Облачные хранилища файлов — вы можете переместить свои файлы через админку в облако: s3, google и другие. Удобно если файлов у вас много, они тяжелые. А раздавать их конечно нужно… через CDN.
3) Облачный бэкап — можно переносить свои бэкапы в облако, они шифруются.
4) Поддержка технологий кластеризции — (мастер-мастер репликация, мастер-слейв и др.) можно развернуться практически из коробоки как кластер в облаке, многие наши партнеры запускают решения в Амазоне, других, отечественных облаках.
1) CDN — не меняя код вы включаете замену ссылок на ресурсы и клиенты начинают загружать картинки, стили и скрипты с ближйший серверов CDN. Я думаю это как раз то, что будет востребовано большинством типовых проектов — сайт становится рядом с клиентом :-)
2) Облачные хранилища файлов — вы можете переместить свои файлы через админку в облако: s3, google и другие. Удобно если файлов у вас много, они тяжелые. А раздавать их конечно нужно… через CDN.
3) Облачный бэкап — можно переносить свои бэкапы в облако, они шифруются.
4) Поддержка технологий кластеризции — (мастер-мастер репликация, мастер-слейв и др.) можно развернуться практически из коробоки как кластер в облаке, многие наши партнеры запускают решения в Амазоне, других, отечественных облаках.
Темы кеша вообще и кеша в битриксе в частности — поле благодатное )
Хорошо, что вы есть. Плохо, что даже партнеры, делая сайты, не всегда думают о производительности (девиз — «а вы возьмите сервер помощнее»), а потом страницы с 300 запросами в БД при любом кешировании отнюдь не «мгновенны» оказываются.
Все руки не дойдут ваше новое ядро пощупать, так что ничего не скажу.
Anybody else? )
Хорошо, что вы есть. Плохо, что даже партнеры, делая сайты, не всегда думают о производительности (девиз — «а вы возьмите сервер помощнее»), а потом страницы с 300 запросами в БД при любом кешировании отнюдь не «мгновенны» оказываются.
Все руки не дойдут ваше новое ядро пощупать, так что ничего не скажу.
Anybody else? )
Немного не в тему экономии, но — как вы обновляете билды приложения на машинках, которые разворачиваются из AMI? Обновляете образ или с помощью какой-то стартовой автоконфигурации?
Скоро предстоит подобную штуку делать, и мы пока не понимаем, что будет лучше. (Если что, у нас Windows+IIS).
Скоро предстоит подобную штуку делать, и мы пока не понимаем, что будет лучше. (Если что, у нас Windows+IIS).
Спасибо за интересный вопрос. :-) Как мы обновляем кластер, например, на Битрикс24:
— Имеется скрипт на «великом своей могучестью» языке bash.
— Имеется эталонная EC2 машинка, на которую выгружается стабильная версия релиза.
— Скрипт через АПИ Амазона снимает снепшот с эталона — который сохраняется в виде образа виртуалки — AMI. Если рейд — нужно весь рейд фризить, например с fsfreeze на момент создания AMI.
— Скрипт создает LaunchConfiguration, в которой проставляет ссылку на новое AMI.
— Затем обновляет свойство AutoScaling группы — указывая новый LaunchConfig.
— Переключаем оригины CDN с кластера/балансера на эталонную машину. Догадайтесь зачем :-)
— По одной машинки тушим и ждем пока на их смену запустятся с нового AMI.
— Возвращаем оригины CDN обратно на балансировщик.
— Процесс обновления занимает минут 40 — из-за небыстрого переключения CDN туда обратно.
На самом деле процедура совершенно простая, прозрачная. После начала использования SpotInstances мы так обновляем 2 кластера сразу.
— Имеется скрипт на «великом своей могучестью» языке bash.
— Имеется эталонная EC2 машинка, на которую выгружается стабильная версия релиза.
— Скрипт через АПИ Амазона снимает снепшот с эталона — который сохраняется в виде образа виртуалки — AMI. Если рейд — нужно весь рейд фризить, например с fsfreeze на момент создания AMI.
— Скрипт создает LaunchConfiguration, в которой проставляет ссылку на новое AMI.
— Затем обновляет свойство AutoScaling группы — указывая новый LaunchConfig.
— Переключаем оригины CDN с кластера/балансера на эталонную машину. Догадайтесь зачем :-)
— По одной машинки тушим и ждем пока на их смену запустятся с нового AMI.
— Возвращаем оригины CDN обратно на балансировщик.
— Процесс обновления занимает минут 40 — из-за небыстрого переключения CDN туда обратно.
На самом деле процедура совершенно простая, прозрачная. После начала использования SpotInstances мы так обновляем 2 кластера сразу.
Правильно ли я понимаю, что для Spot Instance можно задать максимальную цену, например в $20-$50, изредка платить эту цену за час и не бояться, что однажды инстанс будет неожиданно выключен?
Sign up to leave a comment.
Как сэкономить деньги в Amazon Web Services — выбор эффективной архитектуры