Общая картина
В табл. 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. Сравнение архитектур
