Архитектурные решения

Архитектура определяет основную схему объединения всех компонентов bаск-end-подсистемы как аппаратных, так и программных. Она играет важнейшую роль в возможности планирования и управления мощностями. Проектирование архитектуры может быть весьма нетривиальным делом, к счастью, есть пара отличных книг, которые нам в этом помогут: «Building Scalable Web Sites» Кэла Хендерсона (Cal Henderson) и «Scalable Internet Architectures» Teo Шлосснейгла.

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

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

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

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

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

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

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

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

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

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

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

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

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

Веб-сервер

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

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

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

Точки масштабирования

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

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

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

Каждый сервер в нашем примере располагает конечным объемом следующих аппаратных ресурсов:

• Пропускная способность диска.
• Дисковое пространство.
• Процессор.
• Оперативная память.
• Сетевые ресурсы.

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

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