АРХИТЕКТУРА И ЕЕ ВЛИЯНИЕ НА МОЩНОСТИ

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

АРХИТЕКТУРА И ЕЕ ВЛИЯНИЕ НА МОЩНОСТИ

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

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

Предоставление веб-служб через открытые API открывает совершенно новый класс проблем: с данными вашего приложения начинают работать другие приложения, каждое из которых обладает своими закономерностями интенсивности и роста нагрузки. Кроме того, перед пользователями открывается удобный путь для злоупотреблений, что вносит дополнительную неопределенность в расчет мощностей. Потребуется мониторинг использования API с выявлением закономерностей, граничных сценариев использования и недобросовестных разработчиков приложений, намеренных получить доступ ко всему дереву базы данных. Необходимо реализовать средства контроля, обеспечивающие соблюдение правил или условий обслуживания (TOS, Terms of Service), которые должны сопровождать любые веб-службы с открытым API.

В первый год работы Flickr количество загрузок фотографии на сайт возросло с 60 до 660 в минуту. От потребления 200 гигабайт дискового пространства в день разработчики дошли до 880, а от предоставления 3000 изображений в секунду — до 8000. И это только за первый год!

Планирование мощностей очень быстро выходит на первый план. Но все не так плохо; все, что потребуется, — это уделить немного внимания выбору правильных показателей, а далее, будет рассказано, как это делается. Разделим этот процесс на следующие сегменты:

  1. Определение целей.
  2. Сбор метрик и определение ограничений.
  3. Идентификация трендов и формирование прогнозов на основании этих метрик и ограничений.
  4. Развертывание и управление мощностями.