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

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


Целью этой оценки производительности являлось изучение масштабируемости (с учетом пропускной способности) и стоимости альтернативных "облачных" служб при наличии различных рабочих нагрузок. Для этого мы реализовали и пропустили тестовый набор 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-проекта.


Содержание раздела