Предпраздничный период - особое время испытаний для всех жизненно-важных «органов» интернет-магазина - колл-центр разрывается от звонков, логистика не может справиться с потоком доставки, а сайт с трудом справляется с всплесками посетителей.

О работе сайта в предновогодний период, о специфике проблем, с которыми можно встретиться, и о том как можно попытаться с ними бороться мы и поразмышляем сегодня.

Специфика сезонных нагрузок

Чем рост посещаемости в высокий сезон отличается от обычного роста нагрузки? 

Прежде всего, это:

• резкие всплески посещаемости;

• несоизмеримая с оборудованием нагрузка на сервер

• а также критические и срочные требования к способности масштабироваться

Самое главное и важное то, что нагрузка в высокий период чаще всего растет неестественно. Причиной может стать рекламная кампания, специальное предложение, или промо в социальных сетях - в кратчайший промежуток времени нагрузка на сайте вырастает не на несколько процентов, а многократно, в 2, в 3 и более раз.

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

Ежедневная нагрузка остается на прежнем уровне, но в определенный час, буквально за считанные минуты  происходит резкий всплеск посещаемости. Чаще всего сервер к этому не готов.  Если мы будем не готовы к такой нагрузке, и не сможем среагировать и быть готовыми принять такую нагрузку за очень короткое время - мы просто потеряем всех посетителей. При этом важно понять – что посетителей скорее всего мы привлекли за деньги, и они совершенно нелояльны нашему проекту. Как минимум – мы просто потеряем те средства, которые вложили в продвижение, а как максимум – получим негативный PR среди этой аудитории. 

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

И вот здесь мы приходим к тому, что постоянно слышим об облачных хостингах – может быть, можно использовать облака и платить только за те ресурсы, которые мы будем использовать? Сможем неограниченно масштабироваться? Не будем думать об обслуживании серверов?

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

• PaaS - платформа, предоставляемая как сервис;

• IaaS - инфраструктура, предоставляемая как сервис. 

Платформа как сервис

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

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

PaaS был бы главным и единственным решением всех наших проблем, если бы не одно серьезное препятствие - есть жесткие ограничения на то, как, каким образом должен работать код со всеми элементами платформы.

Это можно сравнить с оркестром, где один инструмент должен играть в ограничениях тональности и ритма остального оркестра. 

Все PaaS-решения замкнуты на производителя - у каждой платформы свой язык взаимодействия. Создав приложения для одной из платформ,  будет сложно «переехать» на другую. При переносе уже существующего проекта, его текущий код может оказаться неприспособленным к платформе, на которую мы хотим перейти - нужно будет полностью его переписывать. Мы будем привязаны к единственному вендору.

Существуют различные PaaS-решения - прежде всего Google AppEngine, Heroku, Engine Yard. За прошедший год работа подобных сервисов однозначно поменялась, и для многих небольших сайтов - за PaaS будущее, но сейчас мы бы пока не рекомендовали их использовать.

Инфраструктура как сервис

Облачные хостинги, работающие по принципу «Инфраструкутура как сервис»  - это набор сервисов, предоставляющих домтуп непосредственно к аппаратной инфраструктуре, а не к платформе и ПО. Такие службы выглядят, как хостинги с виртуальными серверами. Вы можете купить обычный сервер с понятными для администратора терминами - такими как оперативная память, процессор и так далее. Но, в отличие от классического хостинга, вы можете очень быстро поменять имеющуюся  конфигурацию. Нагрузка пришла больше? Значит немедленно масштабируемся и принимаем ее.

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

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

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

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

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

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

Для примера рассмотрим аварии на Amazon:

• 21 апреля 2011 – недоступность 53 часа, US датацентр

• 7 августа 2011 года – недоступность 36 часов, EU датацентр

• 29 июня 2012 года – недоступность 7 часов, US датацентр

В Azure авария случилась буквально несколько дней назад. И если в Amazon мы видели, как падает один из доступных датацентров (и сам Amazon рекомендует создавать проект в нескольких), то в случае с Azure произошло глобальное падание – упал весь хостинг.

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

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

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

Гибридные облака

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

В случае запланированной акции о который вы знаете, резком незапланированном скачке посещаемости или просто падении сервера вы масштабируете сервер в облаке, переключаетесь на него и живете на нем столько времени, сколько вам нужно чтобы выдержать нагрузку.

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

Посмотрим на это с технической точки зрения. При использовании Nginx/Apache/MySQL/Linux решений это может быть сделано с помощью Master-Slave или Master-Master репликации базы данных, а синхронизация файлов реализуется, например, с помощью сервиса lsyncd. Переключение между площадками может быть организовано с помощью проксирования со старого сервера и простой смены адресов в DNS-записях (при использовании низкого значения TTL).

Как же это выглядит схематично?

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

Исходные данные: 

Рядовая конфигурация:

CPU E5-2680 v2, 8 ядер
16 гигабайт оперативной памяти
80 гигабайт HDD

Пиковая конфигурация:

CPU E5-2680 v2, 32 ядра
60 гигабайт оперативной памяти
80 гигабайт HDD

общая длительность пиков: 48 часов

Облака в Amazon:

Рядовая конфигурация: 

с3.2xalrge, EBS 80Gb - $117.43 в месяц
(1 yr Medium Reserved предоплата $1072)

Пиковая конфигурация:

с3.8xlarge - $1.912 в час

Резервная конфигурация:

m3.medium, EBS 80Gb - $28.37 в месяц
(1 yr Medium Reserved предоплата $181)

Хостинг в FastVPS:

Рядовая конфигурация: 

FPS-1 4x2 GHz CPU Cores 16GB RAM - $44 в месяц

Пиковая конфигурация:

HP-SSD-64-DUALCPU 64GB RAM - $464 в месяц

Целиком «железное» решение значительно экономичней в штатном режиме, но если мы решаем готовиться к нагрузкам увеличением сервера -  мы платим за те два месяца, что мы ждем пиков.

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

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

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

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

В заключение хотелось бы отметить, что рынок облачного хостинга двигается семимильными шагами. Если еще несколько лет назад большинство функций, которых все ждали, ограничивалось лишь описанием на бумаге. Сейчас мы видим появление огромного количества сервисов, которые действительно упрощают жизнь и позволяют делать то, что раньше получить было бы очень сложно. Amazon Glacier позволяет практически неограниченно хранить резервные копии. Сервисы по обработке данных – очень дешево создавать такие решения, которые ранее требовали бы очень сложной архитектуры и ее внедрения.  «Платформы» стали концентрироваться на конкретных решениях, и возможно уже в скором будущем мы увидим новые, еще более эффективные решения, как для простых, так и сложных интернет-магазинов. Надо лишь держать руку на пульсе.

Оригинал: http://prograbli.ru/techno_experience/Cloud_protecting_the_site_from_seasonal_loads/