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

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

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

6. Эксперименты и результаты

В этом разделе представлены результаты производительности (WIPS) и стоимости ($) прогона тестового набора TPC-W с использованием восьми вариантов "облачных" служб, описанных в разд. 4. Кроме того, в этом разделе показаны время и стоимость массовой загрузки тестовой базы данных для каждого варианта.

Табл. 2. Пропускная способность, Cost/WIPS, предсказуемость стоимости

6.1 Общая картина

В табл. 2 кратко излагаются общие результаты этого исследования. Более развернутый анализ приводится в последующих подразделах. В первом столбце приводятся данные о наивысшей пропускной способности (WIPS), которой удалось достичь в каждом варианте. Во втором и третьем столбцах перечисляются значения показателя Cost/WIPS для слабых рабочих нагрузок (EB=1, второй столбец) и для высоких рабочих нагрузок (EB=max, третий столбец). В четвертом столбце приводится среднее значение и отклонение стоимости для всего диапазона рабочих нагрузок, от EB=1 до EB=max. Здесь под EB=max понимается максимальное число EB, с которым сумел справиться данный вариант "облачной" службы, т.е. число EB, при котором была достигнута максимальная пропускная способность. Во всех столбцах наивысшие значения показателей выделены полужирным шрифтом и курсивом.

Если взглянуть на первый столбец (пропускная способность), то становится ясно, что только S3 и Azure смогли справиться с высокой рабочей нагрузкой в 9000 EB. Для всех других вариантов при росте числа EB узким местом становится сервер баз данных. Мы полагаем, что вариант S3 с архитектурой распределенного управления способен масштабироваться за пределами 9000 EB. Это единственная архитектура без потенциальных узких мест. Поскольку служба Azure основана на архитектуре репликации (подраздел 3.3), она исчерпывает свои возможности масштабирования, когда мастер-сервер баз данных становится перегруженным. Однако, как кажется, Microsoft использует для поддержки уровня баз данных SQL Azure высокопроизводительные машины, так что при наличии 9000 EB предел возможностей этой службы достигнут не был.

Если обратиться к результатам "Cost/WIPS", то можно заметить, что для всех служб, кроме Google AE, меньшее значение этого показателя достигается при высоких рабочих нагрузках. В идеале "Cost/WIPS" должно было бы быть константой, не зависящей от рабочей нагрузки. Если для некоторой службы значение "Cost/WIPS" оказывается более высоким при низкой рабочей нагрузке, чем при высокой рабочей нагрузке, то это означает, что с этой службой связаны фиксированные расходы, которые требуется оплачивать независимо от уровня использования службы. Например, во всех вариантах Amazon требуется платить хотя бы за одну виртуальную машину EC2, чтобы иметь возможность отвечать на запросы клиентов, даже если нет вообще никакой нагрузки. Кроме того, в некоторых вариантах Amazon приходится платить за машины на уровне базы данных. Подобно этому, чтобы поддерживать Web-приложение в режиме онлайн, в варианте Azure приходится помесячно платить за SQL Azure и, по крайней мере, за одну машину с сервером Web и приложений. Единственный вариант, в котором отсутствуют какие-либо фиксированные расходы и не приходится ничего платить в отсутствие какой-либо нагрузки, обеспечивает Google AppEngine. Очевидно, что такие фиксированные расходы не вяжутся с парадигмой платы по мере использования, приверженность которой обещалась в области cloud computing.

Четвертый столбец табл. 2 показывает среднее значение и среднее квадратичное отклонение показателя Cost/WIPS на всем диапазоне значений числа EB, с которым смогла справиться соответствующая служба. У всех служб, кроме Google, имеется высокое отклонение, означающее, что стоимость службы сильно зависит от нагрузки и потому становится непредсказуемой (если только нагрузка системы не является постоянной).

Рис. 7. Сравнение архитектур

6.2 Горизонтальное масштабирование (scale-out)

На рис. 7 показана производительность в WIPS, достигнутая каждым из вариантов, как функция от числа EB. Для упрощения понимания на рис. 7 не показаны результаты для Google AppEngine без кэширования и для MySQL/R. Служба Google AppEngine без кэширования продемонстрировала почти такую же производительность, что и Google AppEngine с кэшированием, во всех случаях немного худшую, но различия были незначительными, и кривая на графике получилась почти такой же. Служба MySQL/R показала почти такую же производительность, что и MySQL; снова во всех случаях производительность MySQL/R была немного хуже, чем MySQL/R, но кривые на графике почти не отличаются. При наличии рабочих нагрузок с большим числом запросов на обновление данных (таких как рабочая нагрузка "оформления заказов" в TPC-W) мастер-сервер становится узким местом, и горизонтальное масштабирование только читающих транзакций за счет увеличения числа серверов-сателлитов не приводит к какому-либо выигрышу в производительности.

Рис. 7 показывает, что единственными масштабируемыми вариантами являются S3 и Azure. Как отмечалось в предыдущем подразделе, S3 – это единственный вариант, основанный на архитектуре без узких мест. Azure хорошо масштабируется за счет использования мощных машин для поддержки серверов баз данных. Оба эти варианта идеально масштабируются вплоть до 9000 EB и достигают максимальной пропускной способности при наличии 9000 EB. Для сравнения, идеальная пропускная способность некоторой абсолютно совершенной системы показана на рис. 7 точечной линией. У всех других вариантов имеется предел масштабируемости, и они не справляются с нагрузкой при возрастании числа EB выше этого предела. Базовые варианты, основанные на MySQL и RDS, достигают своего предела при числе EB около 3500; для SimpleDB предел наступает при примерно 3000 EB; для Google AE с кэшированием пределом является несколько сотен EB.

Рис. 8. RDS: WIPS(EB)

Рис. 9. SimpleDB: WIPS(EB)

Рис. 10. AE/C: WIPS(EB)

Поведение архитектурных вариантов в ситуациях перегрузки поразительным образом различается. На рис. 8-10 более детально показано поведение AWS RDS, SimpleDB и Google AppEngine по отношению к производительности. Как и на рис. 7, на этих рисунках показаны идеальное поведение (точечная линия) и наблюдаемое (WIPS) поведение (зеленая линия). Кроме того, желтая линия показывает число поступающих запросов. Напомним (см. разд. 5), что в тестовом наборе TPC-W специфицируется, что клиент (т.е. эмулируемый браузер) ожидает ответа до направления своего следующего запроса. Поэтому, если система не справляется с нагрузкой и больше не производит ответов, то число поступающих запросов становится меньше, чем в идеальной системе. Очевидно, что линия WIPS должна находится ниже линии поступающих запросов. На рис. 8-10 демонстрируются следующие эффекты, возникающие в ситуациях перегрузки разных вариантов:

• RDS (рис. 8): Пропускная способность RDS прекращает расти после возрастания числа EB до 3500 и остается после этого неизменной. Другими словами, обеспечиваются ответы на все запросы, но на все большее число запросов ответы не поступают за время, специфицированное в тестовом наборе TPC-W. Напомним, что вариант MySQL с технической точки зрения является тем же, что и RDS, и поэтому обладает таким же поведением (для краткости не показанным на рисунках).
• SimpleDB (рис. 9): Рис. 7 показывает, что максимальная пропускная способность достигается при наличии 3000 EB и составляет более 200 WIPS. В действительности, служба SimpleDB в наших экспериментах стала перегруженной уже при 1000 EB и пропускной способности в 128 WIPS. В этом состоянии SimpleDB перестала справляться с запросами записи в горячие точки (hot spot). В тестовом наборе TPC-W часто обновляются объекты позиция заказа (item), и соответствующие запросы на обновление перестали обрабатываться. В соответствии с правилами тестового набора TPC-W недопустимой является ситуация, в которой система не может обработать более 10% запросов любой категории (разд. 5). В результате в табл. 2 в качестве показателя пиковой производительности зафиксировано 128 WIPS. В ситуации перегрузки SimpleDB просто отказывается обрабатывать запросы и возвращает код ошибки. Поскольку это происходит без какой-либо задержки, число поступающих запросов возрастает линейно при росте числа EB.
• Google AE/C (рис. 10): Подобно SimpleDB, Google AE (с кэшированием и без кэширования) в ситуации перегрузки прекращает обрабатывать запросы. На рис. 10 этому эффекту сответствует линейный рост числа поступающих запросов. В отличие от SimpleDB, Google AE поступает "по справедливости" и отказывается обрабатывать запросы всех категорий. Другими словами, в ситуации перегрузки система перестает обрабатывать и запросы на чтение, и запросы на запись. В экспериментах с горизонтальным масштабированием служба Google AppEngine показала наихудшую производительность по сравнению со всеми другими вариантами. Это явление можно объяснить тем, что Google фокусируется на поддержке минимальных рабочих нагрузок за минимально возможную цену (см. следующий подраздел).

  Табл. 3. Cost/WIPS (в долларах), изменяется число EB

  

  6.3 Стоимость

  6.3.1 Cost/WIPS

  В табл. 3 приводятся значения показателя Cost/WIPS для альтернативных вариантов при изменении числа EB. Как обсуждалось в подразделе 6.1, при низких рабочих нагрузках (менее 100 EB) самым дешевым является Google AE, а при средних и высоких рабочих нагрузках – Azure. Стоимость трех вариантов MySQL (MySQL, MySQL/R и RDS) при средних рабочих нагрузках (EB=100 и EB=3000) (почти) такая же, как у Azure, но они не справляются c высокими рабочими нагрузками (подраздел 6.2).

  Табл. 6. Время и стоимость массовой загрузки; размер базы данных и стоимость хранения

  

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

  Azure и варианты MySQL побеждают при средних и высоких рабочих нагрузках, поскольку при таких рабочих нагрузках фиксированные расходы амортизируются. Для SQL-сервера Azure помесячная плата составляет $100, если размер базы данных не превышает 100 гигабайт, независимо от числа запросов, которые придется обработать серверу. При использовании MySQL и MySQL/R необходимо арендовать виртуальные машины EC2, чтобы поддерживать базы данных в режиме онлайн. Аналогично, при использовании RDS требуется вносить фиксированную почасовую плату, так что стоимость в расчете на WIPS уменьшается при возрастании рабочей нагрузки. Следует заметить, что при использовании "облачных" служб Google сетевой трафик обходится дешевле, чем при использовании служб Amazon и Microsoft.

  Этот анализ стоимости в значительной мере является артефактом бизнес-моделей, используемых компаниями Amazon, Google и Microsoft. Очевидно, что все поставщики в любой момент времени могут изменить свою политику ценообразования, и Amazon в прошлом часто уже это делала. Однако анализ стоимости показывает, в расчете на какой вид рабочей нагрузки оптимизируется та или иная служба. Google, очевидным образом, нацелена на бюджетный рынок, а Microsoft, похоже, ориентируется на корпоративных заказчиков. Кроме того, мы полагаем, что стоимость в действительности является хорошим показателем эффективности приложений.

  Табл. 4. Общая стоимость за день (в долларах), изменяется число EB

  

  6.3.2 Cтоимость за день

  В табл. 4 показана общая стоимость за день использования альтернативных подходов при изменяющейся нагрузке (числе EB). (Знак "-" показывает, что данный вариант не смог справиться с данной нагрузкой.) Эти результаты согласуются с наблюдениями предыдущего пункта: Google выигрывает при наличии низких рабочих нагрузок; Azure выигрывает при наличии средних или высоких рабочих нагрузок. Все остальные варианты занимают промежуточные позиции. Три варианта MySQL близки по стоимости к Azure в дипазоне рабочих нагрузок, с которыми они справляются. Еще раз заметим, что в Azure и трех вариантах MySQL применяются примерно одни и те же архитектурные принципы (классическая архитектура плюс репликация с использованием эталонной копии). В этом эксперименте особняком стоит SimpleDB. При используемой в настоящее время схеме ценообразования SimpleDB является исключительно дорогостоящей службой. Высокая стоимость SimpleDB особенно досадна при большом числе EB, поскольку пользователям приходится платить даже в той ситуации, когда SimpleDB не обрабатывает много запросов и не справляется с рабочей нагрузкой.

  Как показывает табл. 4, общая стоимость использования S3 линейно возрастает при росте рабочей нагрузки. Это именно то поведение, которого следовало бы ожидать от модели "платы по мере использования". Для S3 высокая стоимость соответствует высокой пропускной способности, так что высокая стоимость S3 при наличии высоких рабочих нагрузок является допустимой. Это наблюдение подтвержается хорошими значениями показателя Cost/WIPS для S3 при наличии высоких рабочих нагрузок (табл. 3). Тем не менее, для большинства рабочих нагрузок S3 является более дорогостоящей, чем другие варианты (за исключением SimpleDB). Это явление можно объяснить моделями ценообразования Amazon для EBS и S3. Например, операция записи в S3 обходится в сотни раз дороже, чем операция записи в EBS (а эта служба используется в вариантах MySQL). Amazon может оправдать эти различия тем, что S3 поддерживает параллельное выполнение операций обновления с обеспечением соласованности в конечном счете, а EBS поддерживает только последовательное выполнение операций записи (и чтения).

  

  Рис. 11. Факторы стоимости при 250 EB (в долларах)

  6.3.3 Анализ стоимости

  На рис. 11 показаны дневная стоимость сетевого трафика, ресурсов процессоров и хранения данных. Стоимость сетевого трафика показана красным цветом. Стоимость сетевого трафика является полностью изменичивой, зависящей от рабочей нагрузки. На рис. 11 фиксированная часть стоимости ресурсов процессоров показана оранжевым цветом, а переменная часть – желтым цветом. Фиксированная часть стоимости ресурсов процессоров – это стоимость резервирования машин. Переменная часть этой стоимости определяется дополнительными расходами при реальном использовании ресурсов процессоров. Например, стоимость виртуальных машин EC2 зависит от интенсивности их использования. У стоимости хранения данных также имеются фиксированный и переменный компоненты. Фиксированной частью стоимости хранения данных является месячная стоимость хранения базы данных. Переменная часть этой стоимости определяется затратами на выполнение каждого запроса чтения данных из базы данных и записи данных. Как будет показано в подразделе 6.5, фиксированная часть стоимости хранения данных для наших экспериментов не существенна, и поэтому на рис. 11 синим цветом показано одно значение показателя стоимости хранения данных как суммы фиксированной и переменных частей. На рис. 11 для каждого варианта при EB=250 показано разбиение общей стоимости по видам ресурсов (сеть, процессоры, хранение данных). Как и ранее, для краткости опущены результаты для MySQL/R и Google AE без кэширования (они аналогичны результатам для MySQL и Google AE с кэшированием соответственно).

  Как видно на рис. 11, в общей стоимости для варианта MySQL при EB=250 доминирует стоимость сетевого трафика. Еще одним существенным фактором является стоимость резервирования виртуальных машин EC2 для серверов Web и приложений, а также серверов баз данных. Все остальные факторы стоимости являются незначительными. Для SimpleDB в общей стоимости доминирует (переменная) стоимость процессорных ресурсов, требуемых для выполнения запросов на чтение и запись данных. Как отмечалось в предыдущем пункте, SimpleDB является дорогостоящей службой. Все остальные факторы стоимости для SimpleDB не сильно отличаются от факторов стоимости других вариантов. У варианта S3 значительную часть общей стоимости составляет стоимость хранения данных, поскольку (как отмечалось в предыдущем пункте) стоимость чтения и записи данных в S3 значительно больше соответствующей стоимости EBC. Все остальные факторы стоимости S3 сопоставимы с соответствующими факторами стоимости других вариантов, реализованных в "облачной" среде Amazon.

  Легко видеть, что Google AE является единственным вариантом без фиксированных затрат на резервирование процессорных ресурсов. Стоимость этих ресурсов является полностью переменной, но даже при наличии средней рабочей нагрузки в 250 EB, она значительна. Тем не менее, отсутствие какой-либо фиксированной стоимости (имеется только несущественная фиксированная часть стоимости хранения базы данных в облачной среде Google) делает службы Google привлекательными для небольших приложений.

  Еще раз заметим, что, по-видимому, Azure ориентируется на сектор рынка, в котором Microsoft не будет конкурировать с Google. Microsoft назначает фиксированную цену на резервирование машин для серверов приложений и баз данных. Однако после соответствующей оплаты при реальном использовании этих машин никакие дополнительные переменные расходы не возникают.

  

  Рис. 12. MySQL: факторы стоимости при изменении числа EB

  

  Рис. 13. RDS: факторы стоимости при изменении числа EB

  

  Рис. 14. SimpleDB: факторы стоимости при изменении числа EB

  

  Рис. 15. S3: факторы стоимости при изменении числа EB

  

  Рис. 16. AE/C: факторы стоимости при изменении числа EB

  

  Рис. 17. Azure: факторы стоимости при изменении числа EB

  Рис. 12-17 подтверждают эти результаты. На этих рисунках визуализируется процентное соотношение факторов стоимости для каждого варианта в зависимости от рабочей нагрузки. Рис. 12 и 13 для MySQL в RDS закрашены, в основном, красным цветом, поскольку в общей стоимости этих вариантов доминирует стоимость сетевого трафика, почти независимо от рабочей нагрузки. Только при небольших рабочих нагрузках (EB<100) существенной становится стоимость резервирования машин (оранжевая часть рисунков). На обоих рисунках интересный эффект представляют зигзаги. Каждый такой шаг (при EB>1500) показывает, что на уровне серверов Web и приложений добавилась еще одна виртуальная машина EC2, чтобы система могла справиться с возросшей рабочей нагрузкой.

  Рис. 14 подверждает, что в общей стоимости варианта SimpleDB доминирует стоимость выполнения запросов и операций обновления данных службой SimpleDB. Соответственно, рис. 15 показывает, что при наличии высоких рабочих нагрузок (EB>1000) в стоимости архитектуры распределенного управления, реализованной поверх S3, доминирует стоимость использования службы AWS S3. При наличии небольших рабочих нагрузок доминируют фиксированная стоимость резервирования машин EC2 и стоимость сетевого трафика.

  Рис. 16 подтверждает, что в общей стоимости варианта Google AE доминирует (переменная) стоимость процессорных ресурсов. Только при наличии очень низких рабочих нагрузок (EB<10) в стоимости этого варианта доминирует стоимость хранения данных (синяя часть рисунка), но при таких рабочих нагрузках общая стоимость является пренебрежимо малой (несколько центов). В отличие от этого, рис. 17 в основном закрашен красным, что подтвреждает доминирование в общей стоимости варианта Azure стоимости сетевого трафика – как и для вариантов MySQL. На рис. 17 имеются такие же зигзаги, как и на рис. 12 и 13, возникающие при добавлении нового сервера приложений при очередном возрастании рабочей нагрузки на 1500 EB.

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

  Табл. 5. Вертикальное масштабирование RDS: пропускная способность, Cost/WIPS, предсказуемость стоимости

  

  6.4 Вертикальное масштабирование (scale-up)

  Одной из целей cloud computing является горизонтальное масштабирование (scale-out), т.е. обеспечение повышения пропускной способности за счет увеличения числа машин. Тем не менее, некоторые поставщики "облачных" служб поддерживают и возможности вертикального масштабирования (scale-up). Для классической архитектуры и архитектур с разделением и репликацией данных, описанных в разд. 3, такие возможности вертикального масштабирования являются важными, поскольку сервер баз данных может стать узким местом, и его вертикальное масштабирование является единственным путем к достижению высокой пропускной способности. Опция вертикального масштабирования обеспечивается в Amazon RDS. В табл. 5 показаны общие результаты в отношении пропускной способности, Cost/WIPS и предсказуемости стоимости. Можно видеть, что (как и следовало ожидать) более крупная машина способна выдержать более высокую рабочую нагрузку. Однако даже самая крупная машина RDS не способна справиться с рабочей нагрузкой в 9000 EB и обеспечить пропускную способность выше 1000 WIPS. Очевидно, что при вертикальном масштабировании повышается фиксированная часть стоимости системы (наблюдается высокое значение показателя Cost/WIPS при низких рабочих нагрузках) и, соответственно, снижается уровень предсказуемости стоимости (т.е. возрастает отклонение).

  Табл. 6. Время и стоимость массовой загрузки; размер базы данных и стоимость хранения

  

  6.5 Массовая загрузка

  Для полноты в табл. 6 для всех альтернативных вариантов показано время и стоимость массовой загрузки, а также размер базы данных и месячная стоимость ее хранения. Как и раньше, выигрышные результаты выделены полужирным шрифтом и курсивом. Во всех случаях для массовой загрузки базы данных использовались наилучшие доступные средства. В случае MySQL данные заносились через JDBC-подключение. В случае SimpleDB мы использовали операцию пакетной вставки (batch-put), которая сохраняет сразу 25 записей. Для S3 отсутствует какая-либо особая поддержка массовой загрузки, так что данные загружались с использованием стандартного протокола, описанного в [3]. В случае Google AE для применения средства Google для пакетного импорта данных мы использовали скрипт на языке Python. В случае Azure использовался SQL Azure Migration Wizard. В целом, в этой категории явным образом победила система MySQL. Для MySQL/R стоимость и время загрузки в точности в три раза превышали эти показатели для MySQL, поскольку для MySQL/R мы использовали коэффициент репликации, равный трем.

  Если говорить о размере базы данных и стоимости месячного хранения (два последних столбца табл. 6), то, как видно, победила служба Azure. Однако в целом стоимость хранения данных является незначительной и не является важным фактором общей стоимости (подраздел 6.3). Следует заметить, что для всех вариантов, кроме MySQL, стоимость месячного хранения возрастает линейно при росте размера базы данных. В варианте MySQL для хранения баз данных используется EBS (п. 4.1.1), а функция стоимости EBS является более сложной. Для EBS разумно обеспечивать избыточные ресурсы, поскольку если устройство ESB становится полностью заполненным, то необходимо обеспечить новое устройство ESB большей емкости, и данные должны копироваться со старого устройства ESB на новое устройство. Очевидно, что копирование данных – это очень дорогостоящая процедура, так что во избежание подобных случаев лучше сразу позаботиться о резерве внешней памяти.

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