Отношение «фотографии/пользователи» и ожидание дискового ввода/вывода

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

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

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

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

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

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

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

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

На этом графике, скомпилированном по нескольким базам данных, сопоставляются пиковые ожидания дискового ввода/вывода с текущим отношением «фотографии/пользователи». Глядя на график, мы можем найти точку, в которой ожидание дискового ввода/вывода начинает резко возрастать. В диапазоне 85 — 90 фотографий на пользователя наблюдается резкий скачок, когда ожидание дискового ввода/вывода поднимается выше 30 процентов. Потолок составлял 40 процентов; следовательно, мы должны были проследить за тем, чтобы количество фотографий на пользователя оставалось в диапазоне 80-100. Этим соотношением можно управлять на прикладном уровне, распределяя фотографии «тяжеловесных» пользователей по нескольким базам данных.

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

Переход на федеративную архитектуру позволяет управлять распределением пользователей (и их фотографий) по базам данных. Фактически это означает, что каждый сервер (или пара серверов по соображениям избыточности) содержит уникальный набор данных. Эта архитектура отличается от более традиционных монолитных баз данных, в которых все записи хранятся на одном сервере. Дополнительную информацию о федеративных архитектурах баз данных можно найти в книге Кола Хендерсона «Building Scalable Web Sites».

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

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

Количество загруженных фотографий и зарегистрированных пользователей

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