Горизонтальное масштабирование (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
