Сегодня разработчики не представляют себе высоконагруженную систему без базы данных. Этот способ хранения информации становится культовым. Мы привыкли работать с базой данных каждый день, но все же есть тёмные пятна. Одно из них – производительность. Написано множество статей о настройке, оптимизации базы данных и т.д. Они полезны, если у вас уже есть база данных (БД) и её производительности недостаточно. Но эти статьи не помогут, если вам нужно запустить базу данных в облачных сервисах, таких как 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 по сравнению с железным сервером

image

image

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

  • Значения для обоих 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-оптимизацией – лучший выбор.
Поделиться с друзьями
-->

Комментарии (10)


  1. crezd
    25.04.2017 14:38
    +3

    Железный сервер минусы: дороже


    Как раз таки все(в том числе и мы), переезжают с RDS на выделенный сервер из за дороговизны RDS(поищите эту тему в гугле). Экономия такая — 3000$/мес RDS, 550$/мес выделенные сервера. Единственное что, пришлось потратить время на разворачивание кластера, настройки бекапов, но это одноразовое вложение.


    1. Amet13
      25.04.2017 22:04

      одноразовое вложение

      А поддерживать этот кластер? Проверять бекапы, производить восстановление?
      Если для этого изначально есть админы (которому нужно платить деньги за все это), то зачем нужно было использовать RDS?


      1. rPman
        25.04.2017 23:36
        +2

        вы осознаете ценовую разницу? 3000$/мес vs 550$/мес

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


        1. Amet13
          26.04.2017 09:02
          +1

          Конечно осознаю, но утверждать, что имеет место быть только одноразовое вложение неверно.
          И 550$+зарплата админа != 550$+одноразовое вложение.


  1. le1ic
    25.04.2017 21:29

    Наверное, для БД имело смысл протестировать High I/O Instances EC2


  1. alexoron
    25.04.2017 23:01
    +4

    Облако хорошо для старта компании.
    Когда у компании появится «жирок» тогда можно задумываться о своем физическом сервере(ах).

    Хороший пример Weta Digital, которая зарождалась в еще далеких 90-х годах и создавшая самые крутые спецэффекты для более чем 50 голливудских блокбастеров, сейчас владеет СВОЕЙ самой огромной рендер-фермой, которая тоже была задействована для создания Аватара. Для рендеринга сцен фильма Weta использовала серверную ферму площадью 930 м2 с использованием 4 тыс. серверов компании Hewlett-Packard, имевших в общей сложности 35 000 процессорных ядер под управлением операционной системы Ubuntu.
    А ведь в те времена миллионеры!!! взяли напрокат компьютер и установили его в задней части обветшалого дома в Веллингтоне, что в Новой Зеландии.


  1. galserg
    26.04.2017 10:49

    хотелось бы понять — в каком месте железный сервер ДОРОЖЕ, чем aws.
    RDS r3.4xlarge стоит около 900 долларов в месяц если постоянная подписка, и 1600 — если это инстанс по требованию
    железный сервер с параметрами тестового на европейском хостинге я легко возьму за 400-500 евро.


  1. negodnik
    26.04.2017 13:16

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

    Раньше это был конечно страх божий, переносить ПО, базы и т.п., настраивать все окружение.


  1. myrkoxx
    04.05.2017 11:05

    В Amazon RDS есть еще Amazon Aurora — они обещают увеличения по производительности относительно стандартного MySQL почти в 5 раз:

    Amazon Aurora provides 5X the throughput of standard MySQL or twice the throughput of standard PostgreSQL running on the same hardware.


    Вы не пробовали использовать их движок? Интересно было бы увидеть и его в сравнении.


    1. FirstJohn
      04.05.2017 11:07

      Не пробовали, но поставим себе в план.