Выбор провайдера облачных сервисов

Рынок сервисов, предоставляемых по облачной модели, серьезно вырос: пользователи публичных облаков могут легко получить сотни виртуальных машин, заплатив только за то, чем действительно пользуются, без каких бы то ни было предварительных затрат. Такая гибкость заставляет все больше и больше организаций, в том числе государственных предприятий, школ, коммерческих компаний и провайдеров контента, переносить свои приложения в облака. Как следствие, все больше компаний начинают предлагать облачные сервисы: Amazon Web Services (AWS), AppEngine Google, Windows Azuret, Cloud Servers и Rackspace Cloud Sites. Несмотря на то что увеличение числа провайдеров стимулирует здоровую конкуренцию, выбрать наилучшее облако для конкретного приложения становится все сложнее.

Представьте, что вам нужно перенести сервис электронной почты в облако. Определить, какой из провайдеров предлагает необходимые для этого возможности, не составляет труда: большинство из них реализуют сходный набор функций. Однако сказать, какое из облаков позволит добиться наилучшей производительности при обработке электронной почты, довольно сложно, поскольку, как правило, не проводится детального, всеобъемлющего сравнительного анализа производительности решений разных провайдеров облака. Спецификации производительности, приводимые самими провайдерами, обычно весьма туманны (например, "каждый сервер облака получает четыре виртуальных центральных процессора"), а многочисленные отраслевые отчеты и публикации в блогах, посвященные данной теме [ 1-3 ], по большей части узкоспециализированы и не охватывают все аспекты работы облака. Многие из этих публикаций в первую очередь касаются скорости вычислений виртуальных машин и игнорируют другие аспекты, такие как производительность при доступе к системам хранения и самих сервисов.

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

Сервисы облака

Для того чтобы поддерживать разнообразные приложения, провайдеры облака, как правило, имеют в своем арсенале целый спектр сервисов вычисления, хранения и работы в сети. Например, AWS предлагает вычислительный сервис Elastic Compute Cloud (EC2), сервис хранения SimpleDB, Simple Storage Service (S3) и Simple Queue Service (SQS), а также сервис использования внутренних сетей Amazon, который подключается к другим сервисам. Сейчас ведущие провайдеры облака предлагают четыре вида сервисов.

Гибкие вычислительные кластеры

Вычислительный кластер включает в себя набор экземпляров виртуальных машин, на которых выполняется код пользовательского приложения. Каждый виртуальный экземпляр может быть обычной виртуальной машиной (у провайдера инфраструктуры как сервиса, такой как AWS и Cloud Servers) или изолированной средой (у провайдера платформы как сервиса, такой как AppEngine). Кластеры достаточно гибкие в том смысле, что число экземпляров может меняться динамически, в зависимости от нагрузки приложения. Например, в облачном Web-приложении число экземпляров интерфейсных серверов может увеличиваться с возрастанием объема входящих запросов, поэтому нагрузка на каждом экземпляре сервера не превысит предельно допустимого уровня.

Сервисы постоянного хранения

Эти сервисы сохраняют данные приложения и состояния, которые планируется использовать в дальнейшем. К таким сервисам могут получать доступ все машины в кластере. Они отличаются от ресурсов хранения в каждой виртуальной машине, которые являются временными и к которым не могут обращаться напрямую другие экземпляры. Они также отличаются от сервисов блокового хранения, которые предлагают некоторые провайдеры (например, Elastic Block Storage от Amazon). К ним не могут обращаться одновременно несколько машин, и они в основном служат для резервного копирования.

Существует несколько общих типов сервисов хранения. Табличное хранение (SimpleDB, Google DataStore и Table Storage в Azure) аналогично традиционной базе данных. Хранение больших бинарных объектов (S3, Cloud Files компании Rackspace и Azure Blob Storage) позволяет, например, сохранять фотографии и видео. Хранение очередей (SQS и Azure Queue Storage) – это особый вид сервиса хранения, который реализует глобальную очередь сообщений, поддерживающую синхронизацию между различными уровнями виртуальных экземпляров. Сервисы постоянного хранения обычно реализуются как сервисы категории RESTful [ 5 ] ( Representational State Transfer — "передача репрезентативных состояний"). Такие сервисы поддерживают высокую готовность и прекрасно масштабируются по сравнению с их аналогами, реализованными вне облака.

Сети внутри облака

Такие сети связывают экземпляры виртуальных машин друг с другом и с сервисами хранения. Предполагается, что все облака используют в центрах обработки данных сети с большой полосой пропускания и низкой задержкой. Это объясняется тем, что высокая сетевая производительность критически важна для работы многих распределенных приложений, таких как многоуровневые Web-сервисы и задания MapReduce.

Глобальные сети

В отличие от сетей внутри облака, связывающих компоненты приложения, глобальные сети связывают облачные центры обработки данных, где размещаются приложения, с оконечными хостами в Интернет. Для потребительских приложений, таких как Web-сайты, производительность глобальной сети может серьезно влиять на время ответа. Все провайдеры облака используют множество центров обработки данных, расположенных в разных географических регионах, и запрос пользователя может быть выполнен ближайшим к нему центром, чтобы уменьшить задержку глобальной сети.

Все вместе

Перечисленные четыре типа сервисов — самые распространенные и составляют основу в создании онлайн-платформы общего назначения. Серверы обычного облачного приложения, такого как сайт социальной сети, могут работать на кластере, эффективно используя масштабирование для поддержки работы в случае резкого увеличения числа обращений. Данные пользователей могут храниться в различных сервисах хранения, и получить доступ к ним можно по сети внутри облака. Контент сайта может доставляться пользователям с небольшой задержкой через глобальную сеть. Другие важные сервисы облака, такие как сервисы MapReduce (Hadoop) и сервисы резервного копирования, не столь распространены — они не нужны большинству приложений облака.

Сравнительный анализ облаков

Для того чтобы сравнить облака по этим четырем сервисам, выберем параметры их оценки.

Во-первых, параметры оценки должны быть напрямую связаны с производительностью приложений, должны быть понятны и напрямую отражать различные аспекты производительности. Например, параметры хранения должны отражать эффективность ввода/вывода для приложений, интенсивно использующих системы хранения. Во-вторых, параметры должны быть применимы к самым разным провайдерам, вне зависимости от того, как они реализуют сервисы. Например, одни провайдеры используют виртуальные машины Xen, а другие предпочитают Hyper-V или иные внутренние технологии виртуализации. Эти параметры должны быть абстрагированы от деталей реализации и отражать влияние на производительность сервисов от начала до конца.

Исходя из этих соображений были выбраны 10 параметров, которые вместе исчерпывающе описывают производительность облака (см. табл. 1). Некоторые из этих параметров стандартные и уже широко применяются вне контекста облака:

• время выполнения эталонных тестов на производительность для измерения эффективности работы виртуальной машины;
• задержка и пропускная способность при работе сервисов хранения;
• задержка и пропускная способность сети.

Кроме того, для оценки уникальных облаков могут быть выбраны нетрадиционные параметры.

Производительность или стоимость

Многие сервисы облака не бесплатны — клиенты должны платить за потребляемые ресурсы, и пользователи, для которых стоимость имеет важное значение, могут отказаться от услуг провайдера облака, предлагающего лучшую производительность, но по высоким ценам. Сделать свой выбор пользователям помогут два параметра определения рентабельности платных сервисов облака: стоимость выполнения эталонного теста для оценки рентабельности экземпляра виртуальной машины; рентабельность различных сервисов хранения на основе стоимости каждой операции хранения.

Таблица 1. Параметры производительность облака.

Скорость масштабирования

Уникальная особенность облака – высокомасштабируемый вычислительный кластер. Скорость масштабирования может оказаться критической и для производительности, и для стоимости приложений, работающих с меняющейся нагрузкой. При увеличении нагрузки скорость масштабирования должна быть такой, чтобы качество сервиса не снижалось. Даже когда рабочая нагрузка низкая, потребителю все равно приходится иметь несколько запасных копий на случай ее резкого роста, поэтому чем быстрее может масштабироваться кластер, тем меньше резервных экземпляров нужно потребителям, что снижает затраты.

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

Согласованность хранения

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

Задержка в глобальной сети

Производительность глобальной сети определяется минимальной задержкой от некоторой средней точки до центров обработки данных провайдера. Предположим, что провайдер имеет ЦОД в США и в Европе. Для средней точки в США сетевая задержка при получении сервиса для потребителя из этой страны обычно меньше. Задержка для средней точки соответствует реальной задержке при использовании достаточно хорошего алгоритма балансировки нагрузки, всегда направляющего запрос в ближайший центр обработки данных. В данном исследовании эта задержка измерялась от нескольких географически разнесенных средних точек в PlanetLab .

Измерение параметров

Авторами исследования разработан набор инструментов для измерения параметров предоставления сервисов от четырех ведущих провайдеров: AWS, AppEngine, Azure и Cloud Servers. Кроме того, некоторые сторонние компании могут использовать этот инструментарий для того, чтобы предложить сервисы сравнения производительности облаков в режиме реального времени. Пользователям необходимо только подписаться на такие сервисы и загрузить данные сравнительного анализа за определенный период времени и для конкретного провайдера.

От производительности облака к производительности приложения

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

Прямая проекция производительности

Пользователи могут напрямую применять результаты сравнения по одному или нескольким параметрам, чтобы предположить, какой будет производительность приложения при работе с разными провайдерами облака. Например, для приложения интенсивной обработки документов можно использовать параметр "время исполнения эталонного теста", чтобы определить, в каком облаке приложение будет работать наиболее эффективно. Аналогично для приложения, активно использующего системы хранения, такого как сайт электронной коммерции, можно использовать параметры "задержка сервиса хранения" и "пропускная способность сервиса хранения", чтобы определить провайдера с наиболее подходящим сервисом [ 4 ].

Прогнозирование производительности на основе трассировки

Предыдущий подход прост, но может оказаться ограниченным, поскольку в некоторых случаях неясно, как объединять результаты по нескольким значимым параметрам. Например, сложное приложение, такое как обработка видео, может предусматривать и интенсивные вычисления, и интенсивное использование систем хранения. Объединение результатов сравнения, касающихся вычислений и хранения, — задача нетривиальная.

Один из способов ее решения – сбор данных о локальном выполнении приложения и объединение локальной трассировки с результатами измерений и прогнозирование общей производительности при работе в сети. Трассировка исполнения показывает, как локально выполняется приложение и какие ресурсы оно использует. На рисунке представлен пример трассировки исполнения запроса в стандартном трехзвенном Web-приложении. Эта трассировка показывает, как разные компоненты (Web-сервер, сервер приложений, сеть и внутренняя база данных) обрабатывают запрос. Она также позволяет узнать степень использования ресурсов каждым из компонентов (время центрального процессора, объем данных, передаваемый по сети, интенсивность запросов к базе данных).

Затем можно использовать результаты измерения для прогнозирования времени, требуемого каждому компоненту облака. Для серверного компонента можно умножить время центрального процессора, потребляемое локально, на разницу в скорости между локальным экземпляром и экземпляром в облаке. Что касается времени, потраченного на запросы к базе данных, то можно напрямую использовать параметр "операционная задержка" сервисов хранения. После чего можно сложить все прогнозируемые периоды времени. Полученное значение позволит оценить реальное время исполнения данного приложения в облаке.

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

Трассировка выполнения запроса в стандартном трехзвенном Web-приложении. Красным показано время центрального процессора, которое требуется каждому компоненту сервера для обработки запроса. Синим — объем данных, передаваемых по сети (как по глобальной сети, так и внутри облака). Эта трассировка также включает в себя запрос, переданный внутренней базе данных

***

В сфере выбора провайдера облачных сервисов предстоит еще много сделать; например, каждый сервис облака заслуживает того, чтобы был проведен полный, методичный анализ его производительности для понимания способов оптимизации существующих приложений для работы в облаках. Более того, производительность может стать не единственным критерием выбора провайдера — управляемость, готовность и избыточность данных также волнуют пользователей. Объединение всех этих факторов в полную и простую в использовании платформу для выбора провайдера остается пока нерешенной задачей.

Литература

1. Comparing Amazon EC2 Performance with Other Cloud/VPS Hosting Options... and Real Hardware , blog, 14 Apr. 2009.

2. Rackspace Cloud Servers versus Amazon EC2: Performance Analysis , blog.

3. J.S. Ward, A Performance Comparison of Clouds: AmazonEC2 and Ubuntu Enterprise Cloud , presented at 2009 Scottish Informatics and Computer Science Alliance Demofest, 2009.

4. A. Li et al., CloudCmp: Comparing Public Cloud Providers . Proc. 10th Ann. Conf. Internet Measurement, ACM Press, 2010.

5. R.T. Fielding, R.N. Taylor, Principled Design of the Modern Web Architecture. ACM Trans. Internet Technology, vol. 2, no. 2, 2002.

Энг Ли (angl@cs.duke.edu) – аспирант Университета Дюка; Сяовей Янг (xwy@cs.duke.edu) – адъюнкт-профессор Университета Дюка; Срикант Кандула, Минг Чжанг ({ srikanth , mzh }@microsoft.com) — научные сотрудники группы Networking Research Group Microsoft Research.