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

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

С веб-приложениями дело обстоит иначе: пользователи не видят, что их проблема решается, и чувствуют себя не комфортно. Опыт работы в Flickr показал, что пользователи намного снисходительнее относятся к проблемам, если вы держите их в курсе дел. У нас имеются форумы, на которых пользователи могут сообщать об ошибках и дефектах, а также блог (размещенный вне нашего вычислительного центра и потому не подверженный сбоям), в котором мы сообщаем о текущих событиях, если сайт недоступен.

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

Кэширование используется во многих компонентах back-end-инфраструктур. Кэширование объектов, часто запрашиваемых клиентами (или другими уровнями back-end-серверов), может иметь заметный положительный эффект для производительности и масштабируемости, но оно также требует внимательной реализации и повышает затраты на управление.

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

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

Когда на Flickr возникали проблемы, администраторы включали кэширование в системе полнотекстового поиска; это давало некоторое время для выявления и исправления проблем.

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

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

Конечно, преобразование страницы в статический код HTML нарушает работу многих функций, свойственных современным динамическим веб-сайтам, но у статических страниц есть свои преимущества:

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

Также следует учитывать и недостатки выдачи статических HTML-страниц под критической нагрузкой:

• Вам понадобится инфраструктура, которая будет просто и быстро генерировать эти страницы (как начальную версию, так и обновленные). В идеале на веб-странице должна размещаться команда или кнопка, которая заменяет исходную динамическую страницу статическим HTML-аналогом или отменяет замену. На разработку такой инфраструктуры потребуется время и ресурсы.
• Вам придется следить за тем, что где хранится, чтобы изменения контента отражались в страницах. Генерирование статического контента должно быть синхронизировано с источником контента (как правило, базой данных). Изменения, внесенные в базу данных, должны быть отражены во всех статических страницах, в которые включается данный контент.

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

Здесь перечислены лишь некоторые меры, которые спасут ваши серверы, «погребенные» под лавиной трафика.

Отключение «тяжеловесных» функций

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

Веб-серверы Flickr, например, выполняют географический поиск по IP-адресу клиента, чтобы определить наиболее вероятные языковые предпочтения. Автоматический выбор языка делает сайт более удобным для пользователя, но, с другой стороны, это еще одна функция, которая должна выполняться приложением. Когда компания только запустила локализованную семиязычную версию Flickr, эта функция была включена при запуске. В механизме поиска мгновенно возникла перегрузка, поэтому сотрудники просто отключили поиск на то время, пока разбирались в причинах происходящего. Как выяснилось, проблема заключалась в искусственном ограничении частоты запросов на географическом сервере, который был настроен слишком консервативно. Администраторы повысили порог до приемлемого уровня, после чего снова включили функцию поиска. Если бы инженеры не предусмотрели возможности быстрого включения/отключения этой функции (если бы она была жестко закодирована в приложении), на поиски причин, отключение и исправление потребовалось бы куда больше времени. Все это время сайт находился бы в состоянии пониженной функциональности, а то и вовсе не работал бы.

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

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

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

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

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

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

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

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

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

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

Не технические причины:

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

Технические причины:

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

Независимо от того, как организация собирается использовать облачную инфраструктуру, сам факт такого использования оказывает значительное влияние на планирование мощностей. WordPress.com хранение данных обходится дороже, чем до перехода на облачный сервис, но их это устраивает. SmugMug.com платит за Amazon S3 меньше, чем пришлось бы платить за организацию собственного хранилища. В сфере облачных инфраструктур не существует единых рекомендаций «на все случаи жизни»; каждое решение зависит от приложения и организации (впрочем, это относится и ко многим другим технологиям).

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

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

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

SmugMug.com веб-сайт для размещения фотографий, в некоторых отношениях похожий на Flickr. Он поддерживает собственные вебсерверы и базы данных, но широко использует облачную инфраструктуру Amazon как для хранения данных (S3), так и для вычислений (ЕС2).

На момент написания статьи SmugMug.com использует свыше 600 Тбайт пространства в Amazon S3. Передача хранения данных в облако Amazon позволила сконцентрироваться на разработке новых функций. Сначала сервис S3 использовался в качестве резервного хранилища для сайта. Постепенно уверенность в производительности и надежности сервиса окрепла, и на S3 было переведено все первичное хранение данных, хотя у Amazon Web Services тогда еще не существовало соглашения об уровне обслуживания для этого сервиса (сейчас оно есть). Решение о перемещении хранения данных было принято легко, потому что руководство SmugMug увидело экономические преимущества и не хотело расширять персонал для организации внутреннего хранения данных.

Фотографии, отправленные в SmugMug, помещаются в очередь для отправки в ЕС2, где они преобразуются к нескольким размерам для использования на сайте и других операций по обработке. То же самое происходит с отправленными видеороликами. Обработанные материалы сохраняются непосредственно в S3. Конечно, описание получается чрезмерно упрощенным, но в процессе SmugMug использует достаточно интересную схему управления облаком.

Циклы обратной связи

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

Некоторые из этих метрик:

• Текущее количество заданий, ожидающих обработки.
• Приоритеты заданий, ожидающих обработки.
• Типы заданий (фотографии, видеоролики и т. д.).
• Сложность заданий (HD-видео или фотография 1 мегапиксел)
• Критичность заданий, ожидающих обработки, по времени.
• Текущая нагрузка на экземпляры ЕС2.
• Среднее время выполнения задания.
• Исторические метрики нагрузки и производительности обработки заданий.
• Продолжительность запуска нового вычислительного экземпляра.

Учитывая все эти метрики, система SmugMug масштабируется с повышением или сокращением текущего количества используемых экземпляров ЕС2. Таким образом повышается эффективность обработки с использованием облачной инфраструктуры.

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

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

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

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

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

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

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

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

WordPress.com обеспечивает хостинг свыше 2 миллионов блогов (на момент написания статьи) и получает свыше 30 миллионов просмотров страниц за день. Серверы компании установлены в трех вычислительных центрах, между которыми налажена репликация данных. Одно время это обстоятельство усложняло отправку мультимедийных материалов (видео аудио, фотографии) для пользователей, потому что у фирмы возникали проблемы с развертыванием нового дискового пространства. Фирма выбрала сервис Amazon Simple Storage Service (S3) для решения проблем резервного копирования/восстановления данных.

По мере накопления опыта использования сервиса в WordPress постепенно начали использовать S3 для основного хранения данных. Выбор в пользу облачною хранения объяснялся не экономическими причинами, на момент написания статьи затраты на S3 в 3-4 раза превышали затраты на приобретение собственной системы хранения данных и управление ею. В WordPress стремились к простоте развертывания и управления. Избавившись от проблем с использованием дискового пространства, они смогли сосредоточиться на других частях инфраструктуры и функциональности сайта. В сущности, WordPress планирует использовать S3 как «склад данных» почти бесконечной емкости.

Amazon Web Services (AWS) взимает плату за чтение и запись данных в своем облаке S3, поэтому WordPress кэширует контент, получаемый от S3, на своих собственных серверах.

Благодаря кэшированию часто запрашиваемых объектов (или объектов, которые оцениваются как «достаточно популярные» для кэширования) WordPress использует S3 с максимально возможной эффективностью. Кэширование помогает избежать лишних затрат на передачу данных, а также ускоряет предоставление контента с собственных серверов.

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

Означает ли это, что WordPress больше не занимается планированием мощностей? Вовсе нет. Остались системы кэширования (а также базы данных и веб-серверы), которые тоже должны масштабироваться, но это считается приемлемым, поскольку самым «больным местом» было хранение данных. WordPress с радостью переработала архитектуру хранения данных, чтобы больше не беспокоиться о ней.

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

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

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

Отсутствие приемлемых соглашений об уровне обслуживания

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

Юридические аспекты

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

Затраты

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

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