Из соображений удобства сбора данных и обеспечения быстрого отклика на изменяющиеся условия, архитектура должна быть спроектирована таким образом, чтобы ее можно было легко делить на части, выполняющие отдельные задачи. В идеальном случае каждый компонент back-end-подсистемы должен выполнять одну задачу, а при необходимости быть способным к выполнению нескольких задач. В то же время эффективность выполнения каждой задачи должна легко измеряться.
Рассмотрим, например, простое веб-приложение с использованием базы данных, путь которого к всемирному господству еще только начинается. Чтобы обойтись минимальными затратами, мы разместим веб-сервер и СУБД на одном аппаратном сервере. Таким образом, все активные части приложения используют одни и те же аппаратные ресурсы (см. рис.).
Предположим, вы уже прочитали главу «Сбор данных: как измеряются мощности», и настроили сбор статистики как системного, так и прикладного уровня. Программы sat
или rrdtool
помогут вам собрать системную статистику и даже некоторые данные прикладного уровня — скажем, количество запросов веб-ресурсов или обращений к базе данных в секунду.
Недостаток конфигурации, представленной на рисунке, заключается в том, что вы не можете легко установить соответствие системной статистики тому или иному фрагменту архитектуры. Следовательно, вам не удастся ответить на основные вопросы, которые с большой вероятностью возникнут в ходе анализа, например:
Тщательный анализ позволяет примерно оценить, каким демоном используются те или иные ресурсы. В лучшем случае разные демоны не конкурируют друг с другом за ресурсы. Например, веб-сервер может загружать процессор и обходиться небольшими объемами памяти, а база данных может активно работать с памятью без значительных затрат процессорного времени. Но даже в таком идеальном сценарии при возрастании нагрузки конкуренция за ресурсы потребует разделения архитектуры по аппаратным компонентам (см. рис. «Разделение веб-сервера и базы данных»). И на этой стадии желательно знать, какие ресурсы процессора, кэша, дискового пространства, пропускной способности шины и т. д. реально необходимы каждому демону.
Такое разбиение упрощает определение требований к мощностям, так как ресурсы каждого сервера связываются с определенным архитектурным компонентом. Кроме того, оно означает, что статистические данные, собранные по каждому серверу и его ресурсам, лучше изолируются друг от друга. К нужным выводам можно прийти и в однокомпонентной конфигурации, но с большими сложностями и меньшей точностью. Конечно, разделение труда улучшает производительность, например, трафик взаимодействия с клиентом отделяется от трафика базы данных. Но пока давайте ненадолго забудем о производительности.
В процессе сбора статистики системного и прикладного уровня можно найти количественное выражение для каждой единицы мощностей в контексте условий обслуживания. Новая архитектура позволяет получить ответы на некоторые вопросы, на которые нельзя было ответить прежде, например:
Как увеличение количества запросов к базе данных в секунду будет влиять на:
Как увеличение количества запросов к веб-серверу в секунду будет влиять на:
Возможность получения ответов на эти вопросы играет ключевую роль для определения того, как (и когда) следует добавлять новые мощности в каждый компонент.
Архитектурные решения | Точки масштабирования |