Материал предоставлен https://it.rfei.ru

Объекты измерений

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

Рассмотрим, например, простое веб-приложение с использованием базы данных, путь которого к всемирному господству еще только начинается. Чтобы обойтись минимальными затратами, мы разместим веб-сервер и СУБД на одном аппаратном сервере. Таким образом, все активные части приложения используют одни и те же аппаратные ресурсы (см. рис.).

Архитектура простого односерверного веб-приложения

Предположим, вы уже прочитали главу «Сбор данных: как измеряются мощности», и настроили сбор статистики как системного, так и прикладного уровня. Программы sat или rrdtool помогут вам собрать системную статистику и даже некоторые данные прикладного уровня — скажем, количество запросов веб-ресурсов или обращений к базе данных в секунду.

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

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

Разделение веб-сервера и базы данных

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

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

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

Сервер базы данных

Как увеличение количества запросов к базе данных в секунду будет влиять на:

  • использование диска;
  • ожидание ввода/вывода (процент времени, в течение которого база данных ожидает завершения сетевых или дисковых операций );
  • использование оперативной памяти;
  • использование процессора?

Веб-сервер

Как увеличение количества запросов к веб-серверу в секунду будет влиять на:

  • использование диска;
  • ожидание ввода/вывода;
  • использование оперативной памяти;
  • использование процессора?

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

Архитектурные решенияТочки масштабирования