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

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

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

4. Облачные службы

В этом разделе описываются альтернативные службы, предлагаемые тремя крупными игроками в области "облачных" вычислений – компаниями Amazon (AWS, Amazon Web Services), Google и Microsoft. Поскольку какие-либо стандарты пока еще отсутствуют, эти службы различаются во многих аспектах: бизнес-моделями, программными компонентами, используемыми на всех уровнях, и моделями программирования. Сводка различий и ключевых характеристик приведена в табл. 1. Для экспериментов, описываемых в разд. 6, наиболее уместна строка Архитектура (Architecture), и поэтому эта строка в табл. 1 выделена. Другой важной категорией является Конфигурация аппаратных средств (HW configuration). Для использования нескольких служб требуется указание нужного числа виртуальных машин, а также того, какие виды серверов должны быть установлены на этих машинах. Только в Google AppEngine аппаратные ресурсы на всех уровнях выделяются автоматически в зависимости от рабочей нагрузки. В SimpleDB и Azure ресурсы автоматически предоставляются и настраиваются на уровнях "сервера баз данных" и "системы хранения", но на уровне серверов Web и приложений требуется ручное конфигурирование аппаратных ресурсов. Компания Amazon обеспечивает службу AutoScaling, которую можно использовать для автоматического увеличения и уменьшения числа машин EC2 на уровне серверов Web и приложений. Однако мы не использовали эту службу при проведении экспериментов, чтобы иметь возможность управлять ими и сосредоточиться на масштабируемости на уровне баз данных.

4.1 Amazon (AWS)

Amazon является поставщиком инфраструктуры как сервиса (infrastructure as a service, IaaS). Другими словами, Amazon обеспечивает набор базовых служб для использования компьютерной инфраструктуры (ресурсов процессоров, хранения данных и сети), установки некоторой платформы (например, сервер Web и приложений Tomcat и сервер баз данных MySQL) и запуска приложения на этой платформе. Тем самым, Amazon обеспечивает отличную основу для реализации различных архитектурных вариантов. Основными службами Amazon, которые использовались в экспериментах, описываемых в этой статье, являются EC2 (для получения ресурсов процессоров), EBS (для получения сервиса хранения, который можно монтировать подобно диску) и S3 (для получения области хранения, которую можно использовать для хранения данных "ключ-значение"). Поскольку эти службы могли бы запросто обеспечиваться другими поставщиками "облачных" служб, все архитектурные варианты, реализуемые поверх инфраструктуры Amazon, объявляются в табл. 1 гибкими (flexible). В последние два года компания Amazon стала обеспечивать более развитые службы, такие как RDS и SimpleDB. Эти службы доступны только в "облачной" среде Amazon. Все службы Amazon подробно описаны в [1], включая цены на использование каждого сервиса. В следующих пунктах этого подраздела описывается, как мы реализовали пять разных архитектурных вариантов с использованием служб Amazon (AWS).

4.1.1 AWS MySQL

Первый вариант изучался в соответствии с классической архитектурой рис. 1. Этот вариант можно считать базовым для всех экспериментов, потому что он следует классической (не допускающей использование "облачной" среды) модели развертывания корпоративного Web-приложения. В своей реализации мы использовали переменное число машин EC2 для запуска серверов Web и приложений и выполнения логики приложения (тестового набора TPC-W). Мы изменяли число машин EC2 в зависимости от рабочей нагрузки. В качестве комбинированного сервера Web и приложений использовался Tomcat версии 6.0.18. На уровне сервера баз данных мы использовали MySQL версии 5.0.51 с InnoDB, работающий в среде Ubuntu 8.04. Сервер MySQL работал на отдельной машине EC2. В качестве системы хранения мы использовали EBS для хранения и базы данных, и журналов. EBS гарантирует персистентность (данные EBS реплицируются). Теоретически, базу данных можно было бы сохранять и на локальных дисках машин EC2, на которых работает сервер MySQL. Однако этот подход привел бы к утрате всех данных в случае отказа машины EC2. Поэтому возможность такого варианта в экспериментах не предусматривалась. Что же касается производительности, то на рис. 6 приводятся результаты сравнения производительности EBS при выполнении операций чтения и записи с соответствующими показателями локально подключенного диска. Как можно видеть, пропускная способность обоих вариантов примерно одна и та же.

Рис. 6. Производительность EBS при выполнении операций чтения/записи

4.1.2 AWS MySQL/R

Для исследования архитектуры с репликацией (рис. 3) мы использовали MySQL Replication версии 5.0.51 на некотором наборе машин EC2. В этом варианте мы использовали для хранения базы данных (более дешевые) локальные диски машин EC2, поскольку долговечность данных обеспечивалась архитектурой репликации. EBS использовалось только для журналов эталонной копии. Эти журналы требовались для перехода к использованию резервного оборудования после отказа мастер-сервера.

В MySQL Replication используется протокол ROWA/эталонная копия, описанный в подразделе 3.3, для синхронизации всех запросов на обновление, а запросы от приложений на чтение могут обрабатываться любым сервером-сателлитом. Репликация не является прозрачной. Поэтому в каждом сервере приложений поддерживаются подключения к мастер-серверу и к одному серверу-сателлиту. Запросы обновляющих транзакций обрабатываются мастер-сервером, в то время как запросы только читающих транзакций направляются серверам-сателлитам, ассоциированным с сервером приложений. Как и при использовании AWS MySQL Tomcat использовался как интегрированный сервер Web и приложений, и число машин для этого уровня изменялось в зависимости от рабочей нагрузки.

Мы также экспериментировали с MySQL Cluster версий 5.0.51 и 7.0.8a. Использование MySQL Cluster сулило горизонтальное масштабирование при наращивании числа серверов [17]. К сожалению, обе эти версии MySQL Cluster показали в наших экспериментах производительность, худшую, чем у одиночной системы MySQL (AWS MySQL), и поэтому мы не представляем полученные результаты в этой статье. Мы не можем объяснить, почему нам не удалось воспроизвести результаты [17] в "облачной" среде Amazon.

4.1.3 AWS RDS

В конце 2009 г. компания Amazon выпустила RDS – службу реляционных баз данных (relational database service). По существу, RDS реализует такую же платформу, что и описанный выше подход AWS MySQL. Поэтому мы полагаем, что эти подходы обеспечивают примерно одинаковую производительность с близкими затратами. Различием является то, что RDS заранее комплектуется таким образом, что пользователям не приходится беспокоиться о развертывании, внесении исправлений и обновлений в программное обеспечение, а также о резервном копировании данных. RDS доступна в пяти разных "размерах", начиная от небольших серверов и заканчивая учетверенными сверхбольшими серверами баз данных. Очевидно, что для поддержки слабых рабочих нагрузок достаточно небольшого сервера, а крупные серверы нужны при наличии тяжелых рабочих нагрузок, содержащих много запросов на чтение и обновление. Соответственно, цены использования RDS меняются от $0,11 в час для небольшого сервера до $3,11 в час для учетверенного сверхбольшого сервера. За счет этого RDS поддерживает вертикальное масштабирование (scale-up) на уровне баз данных. Однако, поскольку RDS основывается на классической архитектуре, она не может обеспечить горизонтальное масштабирование (scale-out) за счет увеличения числа серверов баз данных.

4.1.4 AWS SimpleDB

Как упоминалось в начале этого подраздела, у Amazon также имеется собственная служба баз данных – SimpleDB. SimpleDB поддерживает простой интерфейс, позволяющий пользователям вставлять, модифицировать и удалять записи. Кроме того, эта служба позволяет выбирать записи на основе значений их ключей или диапазонов значений первичных и вторичных ключей. Подробности реализации SimpleDB не опубликованы. Из личных бесед с техническими специалистами Amazon нам удалось узнать, что архитектура SimpleDB лучше всего характеризуется как комбинация разделения (рис. 2) и репликации (рис. 3). Однако, в отличие от MySQL Replication, SimpleDB не синхронизует обращения по чтению и записи к разным копиям одних и тех же данных, так что эта служба поддерживает только низкий уровень согласованности, называемый согласованностью в конечном счете (eventual consistency) [29]. К марту 2010 г. в SimpleDB в качестве наивысшего уровня согласованности также поддерживалось "согласованное чтение". К сожалению, мы не могли учесть наличие этого релиза в своих эккспериментах, потому что он появился слишком поздно.

На уровне приложения вариант AWS SimpleDB реализуется с использованием той же конфигурации, что и другие варианты AWS, т.е. Tomcat с переменным числом машин EC2. Поскольку в SimpleDB не поддерживается SQL, операции SQL, подобные соединению и агрегации, необходимо реализовывать на уровне приложения. Для этого мы реализовали (Java-) библиотеку с этими операциями SQL и вручную оптимизированными SQL-запросами (т.е. с выбранными порядками и методами выполнения соединений). Очевидно, что для применения этого подхода потребовалась пересылка всех требуемых данных из SimpleDB в серверы приложений, что привело к ухудшению производительности по сравнению с подходом пересылки запросов, выполняемых полнофункциональными SQL-ориентированными системами баз данных.

4.1.5 AWS S3

В качестве четвертого архитектурного варианта мы реализовали средства выполнения тестового набора прямо поверх S3. Этот вариант соответствует архитектуре распределенного управления, представленной на рис. 4. В S3 обеспечивается только низкоуровневый интерфейс put/get, так что все высокоуровневые службы типа обработки SQL-запросов и индексации на основе B-деревьев было необходимо реализовать как часть приложения. Мы включили эти средства в состав библиотеки, поддерживающей основные средства управления базами данных для поддержки выполнения тестового набора TPC-W. Для повышения производительности эта библиотека сохраняла несколько кортежей в одном объекте S3. Кроме того, в этой библиотеке был реализован протокол, синхронизующий паралельный доступ к одним и тем же объектам S3 от нескольких серверов приложений. Для этой цели мы использовали базовый протокол, предложенный в [3]. Этот протокол простым образом реализуется поверх S3. Как и в варианте AWS SimpleDB, протокол поддерживает только согласованность в конечном счете. Более высокие уровни согласованности можно реализовать с использованием других протоколов из [3], но в своем исследовании мы этим не занимались, чтобы не отклоняться от основной цели работы. Для улучшения производительности в серверах приложений выполнялось кэширование объектов S3. В частности, объекты S3, представляющие страницы индекса в виде B-дерева, сохранялись в кэше серверов приложений даже за пределами границ транзакций. Базовый протокол, описанный в [3], применим и для обеспечения корректности при кэшировании страниц данных и индексов.

В [3] для реализации основного протокола поддержки долговечности транзакций и согласованности данных в конечном счете использовалась служба поддержки персистентных очередей Amazon SQS (Simple Queue Service). В описываемом исследовании мы использовали этот подход и реализовали базовый протокол на основе собственной реализации очередей. Наши очереди поддерживались на переменном числе машин EC2 и EBS, чтобы обеспечить сохранность журналов очередей в случае отказов машин. В зависимости от рабочей нагрузки число машин EC2 изменялось от одной до пяти. Период TTL (time to live – время жизни) для кэширования устанавливался в 120 секунд, а интервал установки контрольных точек (определенный в [3]) – в 10 секунд. Установка контрольных точек производилась под воздействием сторожевого таймера (watchdog) [3].

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

4.2 Google

В отличие от Amazon, компания Google следует только стратегии платформа как сервис (platform as a service, PaaS). Google AppEngine – это служба, позволяющая развертывать приложения целиком, не обеспечивая при этом контроля над компьютерными ресурсами. Google AppEngine автоматически увеличивает и уменьшает объем ресурсов, потребляемых приложением, в зависимости от рабочей нагрузки. В качестве языков программирования поддерживаются Python и Java со встраиваемым SQL для обеспечения доступа к базам данных. Мы использовали Java-версию Google AppEngine с Google SDK 1.2.4 и отображение данных на основе JPA (Java Persistence API). К сожалению, в Google поддерживается только упрощенный диалект SQL, называемый GQL. Поскольку возможностей GQL нам не хватало, мы реализовали отсутствующие функциональные возможности на языке Java в составе библиотеки (точно так же, как для вариантов с AWS S3 и AWS SimpleDB). Например, в GQL не поддерживаются группировки, агрегатные функции, соединения и предикаты LIKE. Как и Amazon в случае SimpleDB, Google не публикует какие-либо подробности о своей реализации GQL и распределенной системы баз данных. Согласно [13], в Google AppEngine применяется комбинированная архитектура с разделением и репликацией (рис. 2 и 3).

Одной из приятных особенностей Google AppEngine является то, что в этой службе поддерживается MemCache. Поэтому в Google AppEngine обеспечивается удобный интерфейс, позволяющий программистам приложений помещать объекты в MemCache и выбирать их оттуда. При использовании MemCache Google AppEngine полностью следует архитектуре, изображенной на рис. 5. Мы экспериментировали с обоими вариантами (кэширующим и некэширующим).

4.3 Microsoft

Компания Microsoft недавно выпустила Azure – набор "облачных" служб, основанных на Windows, SQL Server и .Net. Для выполнения экспериентов с Azure мы реализовали тестовый набор TPC-W на языке C# со встраиваемым SQL. Теоретически в "облачной" среде Azure можно было бы использовать и другие технологии, например, Java, но ко времени выполнения наших экспериментов были недоступны требуемые для этого библиотеки доступа к службам баз данных и другим службам Azure. Подобно Amazon и Google, Microsoft пока еще не опубликовала все подробности реализации Azure. Как утверждается в [22], в Azure используется архитектура репликации (с использованием мастер-сервера и серверов-сателлитов), показанная на рис. 3. Поэтому Azure следует напрямую сравнивать с вариантом AWS MySQL/R.

Все три поставщика "облачных" служб берут плату за хранение данных, сетевой трафик и ресурсы процессоров. Для некоторых категорий ресурсов они устанавливают близкие расценки (например, для ресурсов процессоров). Однако имеются и трудно уловимые различия. Например, Azure отличается от Amazon и Google принципом оплаты использования службы баз данных SQL Azure. Вместо того, чтобы брать плату по мере использования этой службы, с пользователей взимается помесячная абонетская плата, размер которой зависит от объема базы данных при отсутствии ограничений на число подключений.

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