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

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

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

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

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

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

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

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

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

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

Давайте признаем: настройка — весьма увлекательное занятие, которое быстро входит в привычку. Но когда вы тратите время на настройку, тестируете результат и снова возвращаетесь к настройке, процесс может превратиться в бесконечную «дыру», которая поглощает все ваше время и усилия с минимальной отдачей (или вовсе без нее). Бывают редкие прекрасные ситуации, когда изменение простого и очевидного параметра ускоряет работу системы, вы обнаруживаете параметр конфигурации MySQL, который удваивает размер кэша, или после тестирования выясняете, что установка размера окна TCP на уровне ядра ускоряет пересылку данных. Замечательно! Но как показано на рисунке, после каждой такой драгоценной находки количество оставшихся очевидных оптимизаций стремительно уменьшается.

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

Небольшой пример пояснит, чем производительность отличается от мощностей. Допустим, в Сан-Франциско живет мясник, который готовит самую восхитительную ветчину в штате Калифорния. Лавка мясника заключает договор с магазином в Сан-Хосе о поставке товара. Ежедневно ветчина должна доставляться из Сан-Франциско в Сан-Хосе на грузовиках, причем доставка должна занимать не больше часа. Мясник должен определить, сколько грузовиков и какого типа потребуется для доставки ветчины в Сан-Хосе. Спрос на ветчину в Сан-Хосе увеличивается. Делать лучшую ветчину в штате непросто, но таким трудностям можно только позавидовать. Трех имеющихся грузовиков пока хватает, но ожидается, что в ближайшие три месяца объем перевозок может возрасти вдвое. Как решить эту проблему?

• Заставить грузовики ездить быстрее.
• Купить дополнительные грузовики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сколько запросов в секунду способен обработать сервер базы данных в конкретной аппаратной конфигурации?
• При каком предельном количестве запросов в секунду (QPS) снижение производительности начнет влиять на впечатления пользователя от работы с сайтом?

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

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

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

Например, для распределения нагрузки LAMP-приложение может использовать два сервера MySQL: основная база данных для записи оперативной информации и дополнительная — только для чтения.

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

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

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

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

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

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

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

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

1. Насколько хорошо работает существующая инфраструктура? Измерьте параметры рабочей нагрузки для каждого компонента архитектуры приложения (веб-сервера, сервера базы данных, сети и т. д.) и сравните их с требованиями к производительности, сформулированными ранее.
2. Что понадобится сделать в будущем для поддержания приемлемой производительности? Составьте прогноз на основании имеющейся информации о производительности системы в прошлом, а затем учтите затраты и необходимое время. Определите, что и когда вам понадобится.
3. Как организовать установку и управление ресурсами после получения всего необходимого? Организуйте запуск новых мощностей с использованием методов и инструментов, проверенных на практике.
4. Переведите дух и повторите. Повторяйте анализ и уточняйте план с течением времени.

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

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

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

Добро пожаловать в cyпермаркет управления веб-ресурсами.