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

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

Общий процесс прогнозирования мощностей довольно прост:

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

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

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

Вследствие непредсказуемого характера обращении к Flickr, оборудование баз данных в настоящее время ограничивается интенсивностью дискового ввода/вывода, с которой могут справиться серверы. Каждый сервер баз данных сейчас оснащается шестью дисками RAID 10 с 16 Гбайт ОЗУ. Большая часть физической памяти выделяется в распоряжение MySQL, а остальная память используется под кэш файловой системы для оптимизации дискового ввода/вывода. В архитектуре появляется «узкое место» аппаратного уровня. У проблемы есть несколько решений, в числе которых:

• горизонтальное распределение нагрузки по разным шести-дисковым серверам (текущий план);
• замена каждого шестидискового сервера аппаратной платформой с большим количеством дисководов;
• расширение физической памяти для повышения производительности как файловой системы, так и MySQL:
• использование более быстрых технологий ввода/вывода, например, твердотельных дисков (SSD, Solid-Slate Disks).

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

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

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

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

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

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

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

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

В качестве примера еще раз проанализируем потребление дискового пространства. Прогноз строился на основании данных, собранных за 15-дневный период, с 26/7/05 по 09/8/05. Мы выяснили, что 30/8/05 (приблизительно через две недели) все дисковое пространство будет заполнено, если в системе не будут развернуты новые носители. А точнее, затраты дискового пространства должны достигнуть 20 446,81 Гбайт и затем превысить общее свободное пространство 20 480 Гбайт.

Насколько точным оказался прогноз? На рисунке показано, что произошло на самом деле.

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

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

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

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

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

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

• количество сообщений на форуме в минуту;
• количество сообщений за день на одного пользователя;
• количество загрузок видеороликов за день на одного пользователя;
• количество загрузок фотографий за день на одного пользователя.

Можно считать, что работа с приложением — это то же самое, что и «вовлечение пользователя» (термин из области маркетинга и управления продуктами).

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

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

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

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

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

На момент написания статьи сайт Flickr обслуживал пользователей из восьми разных вычислительных центров в США, а вскоре к ним также добавятся центры в Европе и Азии. Вычислительные центры в США распределены между восточным и западным побережьем; пользователи получают контент из того вычислительного центра, который территориально расположен ближе к ним. Фотографии распределяются по так называемым фотокомплексам (photo farms).

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

При запуске второй площадки обнаружилось, что центр на восточном побережье при пиковой нагрузке получает на 65-70% больше трафика, чем его западный «напарник».

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

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

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

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

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

Для примера взгляните на рисунок, на нем представлен график изменения интенсивности трафика на веб-сервере за день.

Рисунок весьма типичен для дневного распределения трафика в США. Нагрузка начинает медленно расти утром (по Восточному времени), когда пользователи начинают работать в Интернете. Затем пользователи уходят на обед, а в сети появляются пользователи с Западного побережья. Нагрузка какое-то время держится на высоком уровне, а затем начинает падать, когда пользователи уходят с работы. В конечном итоге остаются только пользователи, работающие в Интернете по ночам.

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

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

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

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

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

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

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

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

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

Первые реализации практики планирования материальных запасов по принципу «точно в срок» (just -in-time) были разработаны фирмой Toyota Motors. Фирма знала, что организация, хранение и контроль лишних автомобильных запчастей сопряжены с большими затратами, поэтому было решено сократить «резервные» запасы и точно прогнозировать, в какой момент возникнет необходимость в запасных частях. Лишние запасы приводили к лишним тратам. Вместо того, чтобы заполнять огромные склады тысячами деталей для своих машин, фирма Toyota заказывала и отправляла на склад детали только тогда, когда это было реально необходимо. Такая практика привела к колоссальному сокращению затрат и обеспечила фирме конкурентные преимущества в 1950-х годах. Сейчас практика планирования запасов по принципу «точно в срок» является частью любого современного производства.

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

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

Некоторые шаги типичного процесса закупки, на которые следует обратить особое внимание:

1. Определение потребностей. Вы знаете, с какой нагрузкой справятся ресурсы вашей системы, потому что вы определили потолки и постоянно отслеживаете параметры использования. Возьмите эти данные за основу для аппроксимации и приступайте к прогнозированию. Этот этап имеет основополагающее значение при планировании мощностей.
2. Обоснование закупки. Добавьте красок и красивых шрифтов к графикам, построенным на предыдущем этапе, — вы будете показывать их людям, которые должны утвердить закупку оборудования. Не жалейте времени на то, чтобы ваша финансовая аудитория поняла, почему вы требуете новые мощности, почему вы требуете их именно сейчас и почему позднее вы будете требовать еще больше. В своей презентации предельно ясно изложите, к чему приведет нехватка мощностей.
3. Анализ предложений поставщиков. Поставщики хотят продать вам серверы и диски, вы хотите купить серверы и диски — во Вселенной все находится в равновесии. Но почему вы отдаете предпочтение поставщику А перед поставщиком Б? Потому что поставщик А помогает преодолеть ваши страхи, связанные с заказом серверов, предлагая быструю поставку и замену, скидки на серверы при будущих заказах или скидки, связанные с временем доставки.
4. Заказ оборудования. Возможно ли отслеживание заказа в Интернете? Есть ли у вас телефон (о, ужас!) надежного человека, который может в любой момент сообщить, где находится ваше оборудование? Знает ли вычислительный центр о поступлении компьютеров, учтен ли этот факт в рабочем графике?
5. Физическая установка. Сколько времени потребуется на то, чтобы серверы добрались от погрузочной площадки до стойки и были подключены к работающему коммутатору? Потребуется ли участие персонала вычислительного центра, или вы подключите машины сами? Хватит ли крепежа? Электродрелей? Перекрестных кабелей? Сколько времени займет весь процесс?
6. Установка ОС, приложений, конфигурации. Далее, мы поговорим о сценариях развертывания, включающих в себя автоматическую установку ОС, программного обеспечения и управление конфигурацией. Тем не менее факт автоматизации еще не значит, что установка не займет вашего времени и вам не нужно знать о возникающих проблемах.
7. Тестирование. Существует ли в вашей организации группа контроля качества? Среда тестирования? Потребуется процесс, в ходе которого вы сможете проверить функциональность всех необходимых компонентов и убедиться в том, что все находится на своих местах. По этой теме написано множество книг, я просто напоминаю о том, что тестирование является необходимым шагом на пути к выводу сервера в полноценную эксплуатацию.
8. Развертывание нового оборудования. Историю можно считать законченной только после того, как сервер заработает. Запуск машины в эксплуатацию должен быть достаточно простой задачей, основанной на том же процессе, который использовался для измерения мощностей новых серверов. Возможно, получаемый сервером трафик стоит временно увеличить, дав ему повышенный приоритет в пуле с распределяемой нагрузкой. Если вы знаете, что новые мощности устраняют «узкое место» в системе, проследите за тем, как их введение повлияло на трафик.

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

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

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

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