Сравнение производительности железного сервера и облака Amazon

Сегодня разработчики не представляют себе высоконагруженную систему без базы данных. Этот способ хранения информации становится культовым. Мы привыкли работать с базой данных каждый день, но все же есть тёмные пятна. Одно из них – производительность. Написано множество статей о настройке, оптимизации базы данных и т.д. Они полезны, если у вас уже есть база данных (БД) и её производительности недостаточно. Но эти статьи не помогут, если вам нужно запустить базу данных в облачных сервисах, таких как AWS, Azure, Rackspace и т.д.

Уверен, эти вопросы некоторым знакомы, потому что меня много об этом спрашивали:

• Должен ли я использовать AWS или обычный железный сервер?
• Какой тип сервера выбрать на Amazon?
• Использовать для базы данных Amazon RDS или EC2?
• Выбрать у Amazon выделенные или инстансы по требованию?
• Сколько транзакций может обрабатывать сервер каждого типа?

Цель статьи – решить эти вопросы. Конечно, на них нет прямого ответа, он будет начинаться со слов «зависит от ...». Но я надеюсь, мой анализ все же поможет вам принять правильное решение.

Среда тестирования

В левом углу ринга удивительный выделенный железный сервер HP DL380 G9 со следующими спецификациями:

CPU: 16 cores (Dual Socket Octo Core Intel Xeon E5–2630v3 2.4GHz, #Processors: 2, #Cores per Proc: 8)
RAM: 128 GB
DISKS: 500 GB RAID 5 SSD

А в правом углу ринга два сервиса Amazon: EC2 и RDS. Чтобы добиться таких же характеристик, как на железном сервере, я использую два инстанса базы данных: DB1 (Memory Optimized) и DB2 (Compute optimized). Спецификации следующие:

DB1:

r3.4xlarge (memory optimized)
16 cores
122 GB RAM
320 GB SSD Instance Storage

DB2:

c3.8xlarge
32 cores
60 GB RAM
750 GB io1 EBS 7500 IOPS

Я также протестирую инстансы с разными типами аренды: выделенные и по запросу, плюс EBS-оптимизацию для инстанса, в который она не включена по умолчанию (например, r3.4xlarge).

Обратите внимание:

• Я не тюнинговал RDS или EC2 сервисы, использовал только стандартные конфигурации
• Результаты могут варьироваться в зависимости от зон доступности (AWS) и регионов
• В отличие от железных серверов, в Amazon есть некоторые накладные расходы на HVM-виртуализацию

Условия тестирования

• Операционная система для EC2 и железного сервера: Ubuntu 14.04 LTS x64
• Типы инстансов EC2: r3.4xlarge и c3.8xlarge
• Типы инстансов RDS: db.r3.4xlarge и db.m4.10xlarge (инстанс db.c3.8xlarge недоступен на RDS, поэтому я заменил его инстансом уровнем выше)
• Объёмы: 320 ГБ SSD для DB1 и 750 GB IO1 7500 IOPS для DB2
• Движок MariaDB: 10.0.17
• SysBench версия: 0.4.2
• SysBench test: OLTP complex test
• Команда для запуска SysBench:
  

  sysbench --db-driver=mysql --num-threads=$THREADS --max-requests=0 --test=oltp --mysql-table-engine=innodb --oltp-table-size=2000000 --max-time=60 --mysql-engine-trx=yes --mysql-user=$USER --mysql-password=$PASSWORD --mysql-host=$HOST run
  

  
  
• Максимальное количество подключений (конфигурационный файл my.cnf): 300
• Потоки: от 1 до 256
• Хост для запуска sysbench: localhost для EC2, для RDS – в той же зоне доступности
• Результаты: количество транзакций в секунду по итогам SysBench-теста
• SysBench-тесты проводятся изолированно от других тестов

«Лучшие практики» AWS

Прежде чем перейти к тестированию, хочу показать вам рекомендации Amazon. В 2015 году компания выпустила подробный Whitepaper по запуску реляционных баз данных на EC2 и RDS. Полную документацию вы найдёте по ссылке.

Вот краткая выдержка из документа:

Рекомендуем сначала рассмотреть Amazon RDS. Это лучший выбор, если:

• Вы сосредоточены на задачах высокого уровня, таких как настройка производительности, оптимизация схемы. Вы ждёте, что Amazon предоставит базу данных, будет управлять резервным копированием и восстановлением данных, патчами безопасности, обновлять версии SQL Server (СУРБД) и управлять хранилищем.
  
  
• Вы ищете высокодоступное решение для базы данных и хотите использовать синхронную репликацию Multi-AZ по нажатию одной кнопки без нужды вручную настраивать и поддерживать зеркалирование базы данных, отказоустойчивую кластеризацию или группы доступности AlwaysOn.
  
  
• Вы не хотите управлять резервным копированием и, главное, восстановлением базы данных к определённой точке во времени – предпочитаете, чтобы AWS автоматизировал этот процесс.

Лучше запустить SQL Server на EC2, если:

• Вам нужен полный контроль над инстансами базы данных, включая доступ к операционной системе и программному стеку.
• Вы хотите, чтобы ваши собственные администраторы управляли базой данных, включая резервное копирование, репликацию и кластеризацию.
• Размер и производительность базы данных превышают текущие максимумы или другие ограничения RDS Amazon.
• Вы хотите использовать возможности или опции SQL Server, которые не поддерживает Amazon RDS.
• Вы хотите настроить решение для аварийного восстановления при работе с SQL Server на AWS, как источника.
• Необходимо использовать версию SQL Server, неподдерживаемую Amazon RDS (например, версию 2014-ого года, которая не поддерживается на момент написания статьи).

Результаты

Как я уже говорил, у нас есть два бойца на ринге, так что в результате мы получим железный сервер против AWS. Поскольку мы используем пару сервисов Amazon, будет несколько тестов:

• EC2 и RDS на базе DB1 по сравнению с железным сервером
• EC2 и RDS на базе DB2 по сравнению с железным сервером

Результаты очень интересные, попробуем проанализировать:

• Значения для обоих EC2 серверов очень похожи, растут линейно до 16 потоков, а потом останавливаются и остаются почти на том же уровне даже после увеличения количества потоков.
  EBS-оптимизация немного увеличивает количество транзакций в секунду для большего количества потоков.
  
  
• Выделенные инстансы практически не влияют на производительность. Результаты для выделенных и инстансов по требованию очень похожи – разница буквально 2-3%. А значит выделенные инстансы не ускоряют работу БД, но обеспечивают безопасность данных. Так как изолированы от инстансов других пользователей на уровне аппаратного обеспечения хоста.
  
  
• Инстансы «Compute optimized» показывают производительность немного ниже, чем инстансы «Memory Optimized» на обоих тестах: для EC2 и RDS.
  
  
• RDS с меньшим количеством потоков ведёт себя несколько хуже, чем EC2 или железный сервер, этот разрыв сохраняется до 16 потоков. Начиная с 16 потоков производительность RDS стремительно растёт с большим отрывом от EC2. На 256 потоках значение для RDS втрое больше.
  
  
• Железный сервер показывает хорошие результаты для меньшего количества потоков и проигрывает RDS, начиная со 128 потоков.
  
  
• Железный сервер показывает свой лучший результат на 32 потоках, при более высоких показателях значение уменьшается.

Вывод

Как вы видите из графиков выше, инстансы EC2 недостаточно хорошо работают для высоконагруженных систем с огромным количеством соединений. Поэтому на вопрос «Использовать для базы данных Amazon RDS или EC2?» я должен ответить: «Зависит от ...». Если вы работаете с высоконагруженной базой данных с огромным количеством соединений, то определённо должны выбрать RDS. По сравнению с железными серверами он показывает неплохие результаты, несмотря на разницу при меньшем количестве потоков. Но если вы используете кластерную систему с парой подчинённых узлов и количеством потоков меньше 16, выберите EC2 – этот сервис немного лучше работает при меньшем количестве потоков.
На вопрос: «Должен ли я использовать AWS или железный сервер для моей базы данных» отвечу также: «Зависит от ...», только помните что:

	Железный сервер Физический выделенный сервер	Облако IaaS Виртуальные машины в публичном облаке
П л ю с ы	хорош для интенсивных рабочих нагрузок полный доступ к серверу, никаких «шумных соседей» стабильная производительность контейнерам не нужна виртуализация	подходит для разных нагрузок виртуальные машины разворачиваются быстрее лучше инструменты управления для бэкапов, тестирования дешевле разнообразие размеров VM позволяет выбрать правильный размер для конкретных работ
М и н у с ы	дороже не такой гибкий, дольше разворачивается не такие крутые инструменты управления (не будет образов всей машины для резервирования) слишком много ресурсов для большинства нагрузок	нестабильная производительность, возможна проблема «шумного соседа» проблемы безопасности при совместном использовании ресурсов

По заявлению Amazon выделенные инстансы главным образом обеспечивают безопасность данных. Результаты тестирования по разным регионам плавающие – отличаются буквально на 2-3%. В основном это зависит от нагрузки на регион и, как следствие, расхождения графиков. Я бы не стал рассматривать выделенные инстансы как способ увеличить быстродействие БД.

И да, до сих пор сложно ответить на вопрос: «Сервер какого типа я должен выбрать на Amazon?». Но я советую запускать базу данных для высоконагруженных систем на RDS. Если все же решите использовать EC2, то инстансы Memory Optimized с EBS-оптимизацией – лучший выбор.