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

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

Одно из преимуществ открытых API заключается в том, что они позволяют повысить эффективность вашего приложения. Если внешние разработчики захотят получить доступ к данным, а вы не предоставите методы API для этой цели, вероятно, им придется извлекать данные из страниц сайта, а это крайне неэффективно по многим причинам. Скажем, даже если их интересует только конкретное значение на странице, им все равно придется запрашивать всю страницу со всем содержимым: разметкой CSS, JavaScript и другими компонентами, которые необходимы для отображения страницы в клиентском браузере, но не представляют интереса для разработчика. Но, хотя API повышают эффективность приложения, при отсутствии должного контроля они также открывают ваш веб-сервис для потенциальных злоупотреблений, так как у других приложений появляется возможность запрашивать конкретные фрагменты данных. Наличие методов сбора и сохранения данных об использовании открытых API на уровне пользователей или запросов может считаться обязательным требованием к отслеживанию мощностей на таких сайтах. Задача обычно решается посредством использования уникальных ключей API или других уникальных удостоверений. При каждом обращении к API ключ идентифицирует приложение и разработчика, ответственного за его создание.

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

В Flickr автоматически объявляются недействительными любые ключи, которые используются для злоупотреблений API в соответствии с положениями, описанными в условиях обслуживания. Для каждого ключа API накапливается почасовая статистика о количестве вызовов и подробностях каждого вызова. Рисунок дает общее представление о метриках вызовов API.

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

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

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

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

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

• Изоляция каждого работающего приложения и измерение его потребления ресурсов.
• Обеспечение постоянного потребления ресурсов некоторыми приложениями.

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

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

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

• отправка фотографии (в основном дисковый ввод/вывод и сетевые ресурсы);
• обработка графики (процессор);
• генерирование страниц сайта (память и процессор)

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

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

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

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

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

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

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

Как видно из рисунка, по крайней мере в эти конкретные выходные обработка каждых 30 фотографий в минуту повышала загрузку процессора на лишние 25 процентов.

Мы получили чрезвычайно грубую оценку, которая базируется на малом и статистически незначительном наборе данных. Рассматривайте ее всего лишь как пример изоляции использования ресурсов в многофункциональной системе. Более корректное подтверждение соотношения 25:30 потребовало бы анализа большего объема трафика и интенсивности отправки, с последующим повторным сравнением данных. Но этот процесс предоставляет в наше распоряжение отправную точку, на которой могут базироваться оценки потолков.

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

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

Для начала взгляните на графики, представленные на рисунке, которые показывают как частота запросов влияет на системные ресурсы.

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

Рисунок подтверждает наши предположения: количество операций, ожидающих завершения дискового ввода/вывода, почти идеально коррелирует с интенсивностью запросов. Мы знаем, что сервер Squid использует диск интенсивнее, чем любой другой ресурс (например, процессор или память). Из этого мы делаем вывод, что определяющей ресурсной метрикой является ожидание дискового ввода/вывода, как и в случае с потолком базы данных. Воспользовавшись RRDTool для получения метрик ожидания дискового ввода/вывода и интенсивности запросов, мы можем построить график по этим данным в Excel, как показано на рисунке.

Теперь мы ясно видим, что две метрики связаны друг с другом (по тому как они одновременно возрастают) и как ожидание дискового ввода/вывода влияет на производительность Squid.

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

Мы видим, что время обслуживания попаданий не претерпевает сколько-нибудь существенных изменений за период наблюдении (оно колеблется около 100 миллисекунд). Следует учесть, что метрика «времени обслуживания » Squid учитывает время до момента получения клиентом последнего байта ответа, а оно может изменяться в зависимости от удаленности клиента от сервера. Из диаграммы следует, что, хотя ожидание дискового ввода/вывода возросло, оно не отразилось на времени отклика сервера Squid, по крайней мере при той нагрузке, которую он испытывал. Нам хотелось бы, чтобы время обслуживания находилось в разумном диапазоне, чтобы пользователю не приходилось подолгу ждать фотографий, поэтому мы установили для этого конкретного сервера максимальное время обслуживания равным 180 миллисекундам. Но что произойдет, если объем трафика поднимет время обслуживания выше порогового значения?

Чтобы получить ответ на этот вопрос, мы снова займемся уже знакомым делом — повышением нагрузки. Медленно увеличивайте нагрузку на серверах, записывая их метрики. Поскольку мы теперь знаем, какой из аппаратных ресурсов следует за повышением трафика, известно, что нужно искать порог, при котором ожидание дискового ввода/вывода начинает влиять на время обслуживания попаданий в кэш. Повышение интенсивности запросов к нашему серверу Squid должно происходить медленно, чтобы избежать слишком резкого подъема частоты попадании. Как видно из рисунка, воспроизведение URL-адресов из Httperf или Siege или исключение серверов из пула с распределением нагрузки позволяет постепенно повышать частоту запросов на одном сервере Squid.

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

На этом рисунке мы видим искомую «красную линию» (выражаясь образно). На 40 процентах ожидания дискового ввода/вывода мы обрабатываем до 850 запросов в секунду. Если взять за основу время обслуживания, это будет максимальная производительность, которую мы можем ожидать от нашей аппаратной платформы с этой конкретной конфигурацией. Для полноты картины стоит сказать, что в эту конфигурацию входит Dell PowerEdge 2950 с шестью SAS-дисками (15 000 об./мин), 4 Гбайт ОЗУ и одним четырехъядерным процессором.

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

На этих двух графиках представлена частота попаданий в кэш и эталонный возраст LRU для конкретного кэширующего сервера Squid, который использовался для обслуживания запросов в течение 5 месяцев. Частота попаданий в кэш выражена в процентах, а эталонный возраст LRU — в днях. В течение наблюдаемого периода возраст LRU и частота попаданий снижались с небольшой, но различимой скоростью, это обстоятельство объясняется возрастанием количества фотографий, отправляемых пользователями. С ростом рабочего набора запрашиваемых фотографий кэшу приходится выполнять все большую работу по вытеснению, чтобы освободить место для новых объектов. Но даже при таком снижении эффективности похоже, что при 72-процентной частоте попаданий эталонный возраст LRU для этого сервера составляет около 3 часов. Значение более чем достойное и вполне приемлемое для нашей среды. В дальнейшем следует наблюдать за частотой попаданий и изменять размер кэша в случае необходимости.

Подведем итог. В этом примере задействованы две метрики, связанные с потолками нашей системы кэширования — ожидание дискового ввода/вывода и эффективность кэширования.

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

Потолок в 850 запросов в секунду предполагает стабильную частоту попадания в кэш, которая тоже может изменяться со временем.

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

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

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

В таблице приведена сводка основных факторов планирования кэша.

Мощности кэширования определяются двумя основными факторами: размером рабочего набора и степенью динамизма (изменчивости) данных.

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

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

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

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

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

Каждый кэширующий сервер обладает ограниченным объемом дискового пространства и памяти, используемой в качестве кэша. Рабочий набор фотографий слишком велик для размещения в кэше, поэтому кэш постепенно заполняется. Заполненному кэшу приходится постоянно принимать решения относительно того, какие объекты следует удалить из кэша, чтобы освободить место для новых объектов. Этот процесс основан на алгоритме замены, или вытеснения. Существует много разных алгоритмов вытеснения; одним из самых распространенных является алгоритм вытеснения по давности использования LRU (Least Recently Used). Принцип его работы представлен на рисунке.

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

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

Важнейшие метрики, которые должны отслеживаться при использовании любой программы кэширования:

• Частота попаданий в кэш.
• Общая частота запросов
• Средний размер объекта.
• Эталонный возраст LRU (при использовании метода LRU).

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

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

Диаграмма на рисунке показывает, как механизм кэширования Squid и Varnish обычно используется с серверами.

Как видно из рисунка, в схеме кэширования базы данных в стиле Memcached диаграмма изменяется лишь незначительно.

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

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

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

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

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

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

На основании этих метрик можно довольно уверенно сказать, что 40-процентное ожидание дискового ввода/вывода является потолком для этой базы данных. В том, что касается конфигурации оборудования, распределения и частоты запросов, характерных для этой базы данных, следует планировать нахождение в зоне ниже 40 процентного ожидания. Но что это означает в контексте реальной работы базы данных?

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

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

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

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

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

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

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

На рисунке представлены данные о количестве параллельных подключений MySQL, а также количестве выполняемых операций INSERT, UPDATE, DELETE и SELECT в секунду за один час. За время наблюдения в каждой из метрик наблюдаются пики, но только один из них заслуживает особого внимания. На нижнем графике представлена величина задержки репликации базы данных за последний час, пиковое значение достигает 80 секунд. Видеть такую задержку репликации, конечно, не хочется. Обычно она означает, что на подчиненных машинах временно отсутствуют свежие данные, загруженные на главную машину.

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

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

В этом примере Ganglia собирает и представляет в графическом виде статистику использования дисков для нашей базы данных. Отчет составляется каждые 60 секунд по значениям некоторых полей, возвращаемых командой Linux iostat: %iowait и %ioutil.

Обратите внимание: хотя интенсивность использования диска поднималась до 100 процентов более одного раза, задержка репликации MySQL увеличилась только во время того периода, когда ожидание ввода/вывода пересекло 40-процентную отметку.

Что это означает? Даже после беглого взгляда на метрики можно сделать вывод, что задержка репликации обусловлена дисковым вводом/выводом, а не общей загрузкой диска. Также можно сказать, что проблемы с задержкой репликации появляются только тогда, когда ожидание ввода/вывода составляет 40 и более процентов. Учтите, что эти результаты относятся только к конкретной конфигурации базы данных в Flickr; это всего лишь пример, а не общее правило. А может, они указывают на какой-нибудь дефект этого конкретного сервера? Возможно. Гипотеза должна легко проверяться — для этого следует спровоцировать указанное поведение на аналогичном сервере. В нашем конкретном случае анализ графиков с других серверов показал, что данная связь имеет общий характер и наблюдается в работе Flickr постоянно: другие базы данных с идентичным оборудованием также испытывали задержку репликации, когда ожидание дискового ввода/ вывода приближалось к 40 процентам.

Практически каждый динамический веб-сайт хранит информацию в какой-либо базе данных. А это означает, что мощности базы данных тоже необходимо планировать. В мире LAMP наибольшей популярностью обладают базы данных MySQL и Postgres; впрочем, Oracle, Microsoft SQL Server и множество других баз данных используются в bаск-еnd-подсистеме многих успешных сайтов.

Кроме базовой серверной статистики также имеется ряд специфических метрик баз данных, которые тоже желательно отслеживать:

• Количество запросов в секунду (SELECT, INSERT, UPDATE и DELETE).
• Текущее количество открытых подключений.
• Задержка репликации.
• Частота попаданий в кэш.

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

Например, в прошлом в Flickr предполагалось, что базы данных, работающие на некоторой аппаратной платформе, обладают потолком в X запросов в секунду, а после прохождения этого потолка наступает неприемлемое снижение производительности. Однако позднее сотрудники с удивлением обнаружили, что некоторые запросы нормально выполняются для пользователей, у которых не более 10 000 фотографий, но резко замедляются для пользователя, имеющего более 100 000 фотографий (да, на Flickr есть пользователи, загружающие более ста тысяч фотографий!) Тогда мы переопределили потолки для сервера базы данных, обслуживающего пользователей с большим количеством фотографий. Такого рода «творческое отслеживание» мощностей и производительности практически обязательно для баз данных; оно подчеркивает, насколько важно понимать особенности реального использования баз данных вне контекста системной статистики.

На этой стадии я должен еще раз повторить замечание, относившееся к настройке производительности. Как упоминалось в книге Джереми Заводны и Дерека Боллиннгa High Performance MySQL, производительность баз данных часто сильнее зависит от схем и запросов, чем от скорости оборудования. По этой причине разработчики и администраторы баз данных направляют первоочередные усилия на оптимизацию схем и запросов, зная, что это может кардинально отразиться на производительности базы данных. В свою очередь, это обстоятельство отражается на потолках базы данных. Сегодня вы думаете, что вам нужны 10 серверов баз данных для обслуживания 20 000 запросов в секунду, а завтра выясняется, что можно обойтись всего 5, потому что вы (или ваши программисты) смогли оптимизировать наиболее частые (или высоко затратные) запросы.