Сравнение производительности железного сервера и облака 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 или железный сервер для моей базы данных» отвечу также: «Зависит от ...», только помните что:

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

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

Автор: FirstVDS / FirstDEDIC

Источник