Переходим в облако (часть 4)

Эта статья впервые появилась в выпуск 222 журнала .net — самого продаваемого в мире журнала для веб-дизайнеров и разработчиков.

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

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

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

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

Куда движется облако?

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

Но для этого есть толчок. Все большее число людей, от менеджеров веб-сайтов до дизайнеров, сотрудников ИТ-поддержки и разработчиков, задают своему начальнику вопрос: так как же нам использовать это облако?

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

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

Но этот толчок все еще есть. Если вы работаете в мире веб-разработки более пары лет, вы узнаете этот этап. Помните вопросы, поступающие от менеджеров: «Ну и как же нам тогда использовать CMS?» и «Какие у вас планы на HTML5?» Вопрос об облаках сейчас циркулирует все больше и больше.

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

Для чего это? Что это вам дает?

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

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

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

А как насчет всех серверов разработки, которые сидят без дела всю ночь? Кончай их. Мы написали инструмент, который переводит все наши серверы разработки в спящий режим после 19:00, если на них кто-то не работает. Инструменты управления облаком, такие как Scalr, позволяют планировать включение и выключение сервера.

Развертывание простого приложения Facebook можно выполнить за считанные минуты, а его размер можно будет изменить по мере того, как ваше приложение получит больше пользователей. Просто запустите экземпляр EC2 и измените его размер в соответствии с трафиком. Или, если это немного сложнее, используйте другую часть облака «платформа как услуга» (PaaS).

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

Шаги

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

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

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

Если вы можете немного настроить приложение, начните с таких инструментов, как New Relic, xhprof для PHP или любого подобного инструмента профилирования. Если вам нужно масштабироваться, узкие места не всегда приводят к сбою приложения: иногда они могут стоить вам очень дорого. Этот шаг сэкономит вам целое состояние.

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

Сократить время работы вашего приложения можно любым способом: от переписывания медленных методов до полной замены целых разделов страницы — как часто на странице есть что-то, на что никогда не нажимали? Какая трата вычислительных циклов.

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

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

Облачные сервисы должен всегда быть «вверху». Должны, но могут и не быть. Если вы хотите 100% бесперебойную работу, вам необходимо гарантировать это, вложив немного денег.

Насколько «вверх» вы этого хотите?

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

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

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

Самый простой способ спроектировать это — нарисовать диаграмму планируемой архитектуры, указать на все и спросить: «Что произойдет, если это потерпит неудачу?». Укажите на каждый экземпляр, укажите на каждую службу, чтобы у вас был план.

Вот пример: что произойдет, если корзину S3 удалить? Ответ: нам нужно это обнаружить и восстановить все активы откуда-то еще.

Что произойдет, если балансировщик нагрузки выйдет из строя? Ответ: либо иметь два, либо обнаружить его и создать новый.

Итак, мы переходим к следующему этапу — доработке вашего приложения, чтобы оно лучше работало в облаке.

Обман в облаке

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

Первое знакомство большинства людей с облачным хостингом предполагает размещение их ресурсов на статических серверах, таких как S3 или Akami. Это значительно снижает нагрузку на ваш веб-сервер, устраняя затраты на доставку полностью статических ресурсов, таких как изображения, JavaScript, CSS и тому подобное, с вашего большого модного сервера.

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

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

Второй чит, который вы можете сделать, — это база данных. Сторонние службы баз данных, такие как Xeround, data.com и Amazon RDS, предоставляют вам управляемую базу данных с гарантированным временем безотказной работы и масштабируемостью. Администрирование базы данных — это весело, но не для всех, поэтому, если это не ваша задача, воспользуйтесь сервисом, который сделает это лучше.

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

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

Меньше, другая форма

Большие серверы не всегда лучше. Иногда меньше значит гораздо красивее, и при хостинге выгоднее иметь больше маленьких серверов, чем меньше больших.

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

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

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

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

Это работает наоборот. Если вы импортируете данные из Flickr, YouTube, Facebook, Twitter или любого из миллиардов мест, откуда вы можете получать данные, не запускайте это на веб-серверах, потому что у них достаточно дел. И вот что может изменить ситуацию: это часто означает, что в результате вы сможете меньше тратить на серверы. Значительно меньше.

Постройте его, сбейте его

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

Чтобы навести порядок в доме, вам понадобится полностью готовое приложение, которое можно запустить одной строкой:

git clone [email protected]: great-app.git && ./build.sh

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

Кто главный?

Да, да, но вы не хотите сидеть всю ночь, проверяя серверы и запуская новые, если старые выходят из строя. Вы выбираете инструмент, который сделает это за вас. Такие инструменты, как RightScale, Scalr, Enstratus и Kaavo, позволяют проектировать облако с помощью графического пользовательского интерфейса, настраивать правила масштабирования и автоматизировать поведение облака.

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

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

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

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

Здесь действует правило: не забывайте об управлении.

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

• Это делает сайт быстрее, и это приносит нам больше дохода.
• Это более устойчиво
• Он масштабируется быстрее

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

Хостинг — это не просто большая коробка с дисками и кремнием. Хостинг теперь является программным обеспечением, и всегда выгодно работать над последней и лучшей версией.

Почему стоит выбрать ОВХ?

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

Чтобы гарантировать эти результаты, OVH не пришлось подвергать риску свою инфраструктуру — фактически все физические ресурсы удваиваются, будь то серверы, места хранения или сетевое оборудование. Это также не повлияло на цены, которые являются одними из самых низких на рынке. Посещать ovh.co.uk или позвоните по телефону 020 7357 6616 для получения подробной информации.