Анализ альтернативных архитектур управления транзакциями в "облачной" среде

Дональд Коссман, Тим Краска и Саймон Лоузинг
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

5. Экспериментальная среда

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

5.1 Тестовый набор TPC-W

Поскольку нас интересовала сквозная производительность корпоративных Web-приложений, включающих обработку транзакций, мы использовали тестовый набор TPC-W [28]. В других тестовых наборах для OLTP (таких как TPC-C и TPC-E) упор делается на влиянии на общую производительности системы баз данных, и не имитируется какая-либо сложная логика приложения. Хотя организация TPC не рекомендует использовать TPC-W, этот тестовый набор остается популярым и в индустрии, и в академических организациях.

Тестовый набор TPC-W моделирует онлайновый книжный магазин с использованием смеси из пятнадцати видов запросов: поиск продуктов, выдача информации о продуктах, оформление заказа на покупку и т.д. Кроме того, в TPC-W специфицируются три вида рабочих нагрузок: (a) просмотр товаров (browsing), (b) подбор товаров (shopping), (c) оформление заказов (ordering). Для каждого вида рабочей нагрузки устанавливается вероятность появления в ней каждого вида запроса. Во всех экспериментах, описываемых в этой статье использовалась смесь "оформление заказов", поскольку в ней содержится больше всего запросов на обновление данных (примерно треть от общего числа запросов). Наконец, рабочий набор TPC-W позволяет изучать различные рабочие нагрузки с учетом темпа поступления запросов. Для этой цели в рабочем наборе TPC-W используются эмулируемые пользовательские браузеры (emulated browser, EB). Каждый EB имтирует действия одного пользователя, который выдает запрос (в соответствии с вероятностями, установленными для используемой смеси), ожидает ответа и по истечении специфицированного времени выдает следующий запрос. Мы изменяли параметр EB от 1 (≈ 500 запросов в час) до 9000 (≈ 1250 запросов в секунду). В смеси "оформление заказов" запросу уровня TPC-W соответствовало в среднем 6,6 HTTP-запросов, поскольку Web-страницы TPC-W содержат несколько встроенных компонентов (например, изображений).

В тестовом наборе TPC-W имеются два показателя. Первый показатель – это показатель пропускной способности, т.е. число допустимых запросов TPC-W, поступающих за одну секунду. Для этого показателя обычно (и в данной статье) используется аббревиатура WIPS (от Web Interactions Per Second). Важно, что учитываются только допустимые запросы, время обработки которых соответствует установленным требованиям. В зависимости от вида запроса допустимое время ответа изменяется от 3 до 20 секунд. Результаты выполнения тестового набора принимаются во внимание, если 90% всех запросов каждой категории являются допустимыми, и система обеспечивает полный ответ на каждый из этих запросов в пределах допустимого времени. Нельзя, например, игнорировать все запросы на обновление данных и добиваться высокого значения WIPS за счет выполнения только запросов на чтение.

Вторым показателем, определяемым в TPC-W, является Cost/WIPS. Этот показатель связывает производительность (т.е. WIPS) с совокупной стоимостью владения (total cost of ownership) компьютерной системы. Чтобы обеспечить возможность измерения этого показателя, в тестовом наборе TPC-W приводятся точные правила вычисления стоимости системы. Для данного исследования эти правила пришлось ослабить, потому что они не применимы ни к каким исследуемым "облачным" службам. Во всех наших экспериментах стоимость определялась размером счета, который мы должны были оплатить.

Кроме упрощения правил вычисления показателя Cost/WIPS, мы ввели в тестовый набор TPC-W следующие изменения:

• База данных тестового набора: В тестовом наборе TPC-W указывается, что размер тестовой базы данных возрастает линейно в зависимости от числа EB. Поскольку нас особо интересовали масштабируемость служб по отношению к транзакционной рабочей нагрузки и эластичность этих служб при изменении рабочей нагрузки, мы выполняли все свои эксперименты с использованием фиксированной тестовой базы данных, соответствующей стандартной базе данных TPC-W для 100 EB. Эта база данных содержала информацию о 10000 единицах товаров, и ее исходные данные составляли 315 мегабайт, что обычно приводило к размерам баз данных около 1 гигабайта при добавлении индексов (подраздел 6.5).
• Согласованность: В тестовом наборе TPC-W требуется обеспечение строгой согласованности данных с применением ACID-транзакций. Как показано в табл. 1, в нескольких вариантах этот уровень согласованности не поддерживается.
• Запрос бестселлера (Bestseller Query): Одну из разновидностей запросов TPC-W, так называемый запрос бестселлера, было невозможно реализовать с использованием S3, SimpleDB и Google AE. Реализация такого запроса на уровне приложения невозможна, поскольку для его выполнения пришлось бы просканировать почти всю базу данных целиком. Чтобы избежать влияния этого вида запроса на все результаты, мы заменили его запросом, который случайным образом выбирает некоторый набор продуктов, и который можно эффективно реализовать на всех платформах.
• HTTP: В тестовом наборе TPC-W требуется, чтобы для обеспечения безопасных коммуникаций клиента и сервера использовался протокол HTTPS. Для упрощения мы использовали протокол HTTP (без шифрования).

5.2 Методология, показатели и реализация

Целью этой оценки производительности являлось изучение масштабируемости (с учетом пропускной способности) и стоимости альтернативных "облачных" служб при наличии различных рабочих нагрузок. Для этого мы реализовали и пропустили тестовый набор TPC-W с использованием этих альтернативных служб (описанных в разд. 4), а также измерили WIPS и стоимость при изменении числа EB (числа имитируемых параллельно работающих пользователей). Как отмечалось в предыдущем подразделе, мы изменяли нагрузку от одного EB (слабая рабочая нагрузка) до 9000 EB (тяжелая рабочая нагрузка). Мы не оценивали другие обещанные возможности "облачных" вычислений, такие как доступность, время выхода на рынок и гибкость, потому что эти показатели трудно измерить. Таким образом, измерялись следующие показатели:

• WIPS(EB): Пропускная способность допустимых запросов в одну секунду в зависимости от числа эмулируемых браузеров (EB). Чем выше, тем лучше. (Как объяснялось в предыдущем подразделе, "допустимым запросом" считается запрос, время выполнения которого соответствует установленным требованиям.)
• Cost/WIPS(EB): Стоимость в соответствии с пропускной способность снова в зависимости от числа EB. Чем меньше, тем лучше.
• CostPerDay/WIPS(EB): (Прогнозируемая) общая стоимость выполнения тестового набора с некоторым числом EB в течение 24 часов. Чем меньше, тем лучше.
• s(Cost/WIPS): Среднеквадратичное отклонение Cost/WIPS для разных значений числа EB (от EB=1 до EB=max, где max – это число EB, при котором была бы достигнута наивысшая пропускная способность). Этот показатель является мерой предсказуемости стоимости службы. В идеале показатель Cost/WIPS не должен зависеть от нагрузки и потому должен являться предсказуемым. Так что, чем меньше значение s, тем лучше.

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

В зависимости от используемого варианта службы мы применяли одну из двух экспериментальных установок для определения стоимости и WIPS при заданном числе EB. Для вариантов SimpleDB, S3 и Google AppEngine (с кэшированием и без кэширования) мы измеряли WIPS для ряда значений числа EB (EB=1, 250, 500, 1000, 2000, 3000, 4000 и 9000, если это оказывалось возможным) в течение 10 минут. Для этих вариантов мы не могли выполнить измерения для всего спектра значений числа EB из-за ограниченного бюджета. Для трех вариантов, основанных на MySQL (MySQL, MySQL/R и RDS), и варианта Azure мы проводили измерения для всех значений числа EB в диапазоне от EB=1 до EB=9000. Для этого мы начинали работу при EB=1 и затем увеличивали рабочую нагрузку, добавляя по одному EB через каждые 0,4 секунды. Во всех случаях перед каждым экспериментальным прогоном тестового набора мы выполняли "разогревающий" (warm-up) двухминутный прогон; стоимость и пропускная способность этой двухминутной разогревающей фазы не учитываются в результатах, представленных в этой статье.

Для обеспечения стабильности результатов мы выполняли ряд дополнительных экспериментов и измерений. Для MySQL,MySQL/R, RDS и Azure все эксперименты повторялись по семь раз, и в результаты включались средние значения WIPS и стоимости, полученные при каждых семи прогонах. Из-за бюджетных ограничений для вариантов SimpleDB, S3, Google AE (с кэшированием и без кэшироввания) все эксперименты повторялись только по три раза. Кроме того, мы прогоняли несколько частных вариантов тестового набора (при фиксированном числе EB) в течение более долгого времени (до тридцати минут), чтобы оценить, смогут ли службы настроить свою конфигурацию к имеющейся рабочей нагрузке. Однако нам не удалось выявить таких эффектов. Только при использовании Microsoft Azure мы наблюдали небольшую разрывность. В наших первых экспериментах служба Azure быстро становилась недоступной при EB=2000 и EB=5500. Мы полагаем, что в эти моменты времени службы Azure перемещали базу данных TPC-W на более крупные машины, чтобы можно было справиться с возрастающей рабочей нагрузкой. Этот эффект наблюдался только при выполнении самого первого эксперимента с использованием Azure. Как кажется, Azure при уменьшении рабочей нагрузки не возвращает базу данных на менее мощные машины, так что все последующие эксперименты с использованием Azure (предположительно) выполнялись на крупной машине баз данных. Однако в целом все результаты были на удивление стабильными, и мы получили только один резко выделяющийся частный результат в одном из экспериментов с MySQL. Хорошо известно, что качество услуг, обеспечиваемое поставщиками "облачных" служб, является изменчивым, но долговременное детальное изучение этих отклонений не являлось целью описываемой работы.

Эксперименты с использованием AWS RDS и Microsoft Azure выполнялись в феврале 2010 г. Эксперименты с использованием других вариантов "облачных" служб выполнялись в октябре 2009 г. (В октябре 2009 г. Azure и RDS еще не были широко доступны.) Очевидно, что все поставщики "облачных" служб внесут в них изменения, которые повлияют на полученные нами результаты, точно так же, как развитие аппаратуры и технологии влияет на результаты любых исследований производительности. Тем не менее, мы полагаем, что результаты этого исследования позволяют лучше понять основные свойства альтернативных архитектур платформ "облачных" вычислений (разд. 3).

Во всех экспериментах эмулируемые браузеры тестового набора TPC-W выполнялись на машинах EC2 в облачной среде Amazon. Поэтому в экспериментах с использованием Google AppEngine и Azure клиентские машины находились не в тех центрах данных, в которых располагались серверные машины, обрабатывающие запросы. Чтобы не допустить несправедливости мы обеспечили, чтобы для всех вариантов с использованием служб Amazon клиентские машины EC2 и серверные машины EC2 тоже располагались в разных центрах данных. Это делалось путем явного выбора центра данных при запуске виртуальных машин (instance) EC2 для клиентов и серверов.

Для выполнения серверов Web и приложений в "облачной" среде Amazon мы использовали средние (medium) машины EC2 HIGH-CPU. Соответственно, мы использовали для тех же целей средние машины и в "облачной" среде Azure. Средние машины EC2 и Azure обладают примерно одинаковой производительностью и стоимостью, так что результаты являются прямо сопоставимыми. Кроме того, в "облачных" средах Amazon и Azure мы вручную подбирали число машин для выполнения серверов Web и приложений. С помощью отдельных экспериментов (не описываемых в данной статье) мы обнаружили, что один средний сервер может справиться с нагрузкой 1500 EB. Соответственно, мы обеспечивали один сервер Web и приложений на каждые 1500 EB, увеличивая число машин до шести для поддержки максимальной рабочей нагрузки 9000 EB. В варианте S3 интегрированный сервер Web, приложений и баз данных справлялся только с 900 EB, так что для поддержки этого варианта использовалось до десяти машин EC2. Мы заранее выделяли машины EC2 и Azure, чтобы обеспечить их доступность в случае потребности (при возрастании нагрузки). В экспериментах с использованием Google AppEngine у нас отсутствовала возможность влияния на выбор вида и числа машин, использовавшихся на уровне серверов Web и приложений, поскольку серверы автоматически обеспечивались Google AppEngine (табл. 1).

Для выполнения серверов баз данных в вариантах AWS MySQL и AWS MySQL/R мы также использовали средние машины EC2. В случаях, когда не оговаривается противное, в варианте AWS RDS мы использовали крупную (large) машину, поскольку характеристики производительности крупной машины RDS схожи с характеристиками средней машины EC2. Во всех вариантах машины баз данных было невозможно конфигурировать.

Как отмечалось в разд. 2, мы не выполняли какие-либо "пиковые" эксперименты, предлагавшиеся в [2]. Целью "пиковых" экспериментов является оценка того, насколько быстро поставщик служб адаптируется к быстрым изменениям в рабочей нагрузке. Как отмечалось выше, мы не смогли заметить каких-либо существенных настроек, выполняемых службами самостоятельно (с примечательным исключением при первом экспериментальном прогоне тестового набора в среде Azure), и поэтому мы полагаем, что наши результаты представляют стационарное поведение систем. Однако более детальный анализ "пиковой" производительности и адаптируемости является важной темой будущих исследований.

Во всех экспериментах изображения, используемые в составе тестового набора TPC-W (например, фотографии продуктов) хранились вне базы данных в отдельной файловой системе. В "облачной" среде Amazon для экономии все изображения сохранялись в локальной файловой системе EC2. В среде Azure изображения сохранялись в составе Web-проекта.

Назад Содержание Вперёд