По мере того как все больше сайтов реализует характеристики модели Web 2.0, задачи управления веб-ресурсами (и особенно управление мощностями) начинают играть все более важную роль. Если сайт содержит контент, создаваемый пользователями, его эксплуатация и развитие не находятся под полным контролем создателей сайта. Заметная часть контроля находится в руках сообщества пользователей, как доказывает пример со взрывами в лондонском метро (см. предисловие). Данное обстоятельство нередко пугает людей, привыкших строить сайты с хорошо прогнозируемыми закономерностями роста. Получается, что мощности плохо прогнозируются и за ними должны следить обе заинтересованные стороны — как коммерческий, так и технологический персонал. Разработчики и администраторы социального веб-сайта должны действовать, опережая рост популярности сайта, и собрать из этой «восходящей спирали» достаточно данных для принятия обоснованных решений по планированию в будущем.
От стиля вождения зависит пожизненный пробег вашего автомобиля. Аналогичный принцип действует и в веб-архитектурах. Одной из тем, к которым мы будем неоднократно возвращаться в этом курсе, является значительное влияние архитектуры сайта на особенности взаимодействия, потребления и управления мощностями. Архитектура влияет на фактическое использование мощностей сильнее, чем любые настройки и оптимизации серверов и сети. Кроме того, архитектура играет важную роль в том, насколько легко и гибко происходит добавление и удаление мощностей.
Настройка и оптимизация программных и аппаратных средств имеет отношение к планированию мощностей, но это не одно и то же. В курсе основное внимание уделяется адаптации архитектур, упрощающей управление мощностями. Сегментация и простота деления архитектуры на компоненты поможет справиться со многими проблемами определения характеристик нагрузки, проблемами, решение которых необходимо для создания точной картины того, какие аспекты системы вам придется наращивать и когда.
Предоставление веб-служб через открытые API открывает совершенно новый класс проблем: с данными вашего приложения начинают работать другие приложения, каждое из которых обладает своими закономерностями интенсивности и роста нагрузки. Кроме того, перед пользователями открывается удобный путь для злоупотреблений, что вносит дополнительную неопределенность в расчет мощностей. Потребуется мониторинг использования API с выявлением закономерностей, граничных сценариев использования и недобросовестных разработчиков приложений, намеренных получить доступ ко всему дереву базы данных. Необходимо реализовать средства контроля, обеспечивающие соблюдение правил или условий обслуживания (TOS, Terms of Service), которые должны сопровождать любые веб-службы с открытым API (подробнее об этом в главе “Сбор данных: как измеряются мощности”).
В первый год работы в Flickr количество загрузок фотографий на сайт возросло с 60 до 660 в минуту. От потребления 200 гигабайт дискового пространства в день они дошли до 880, а от предоставления 3000 изображений в секунду — до 8000. И это только за первый год!
Планирование мощностей очень быстро выходит на первый план. Но все не так плохо; все, что потребуется, — это уделить немного внимания выбору правильных показателей, а в остальных главах этого курса будет рассказано, как это делается. Этот процесс разделен на следующие сегменты:
| Не путайте производительность с мощностями | Проверка знаний: проблемы и процессы планирования мощностей |