MySQL Encryption Performance Пересмотрено

Это сообщение  написано Эрни Сухрада из блога MySQL Performance.

Это вторая часть в серии из двух частей о влиянии на производительность шифрования данных в полете с MySQL. В первой части я уделил особое внимание влиянию использования встроенной поддержки MySQL SSL с некоторыми довольно неожиданными результатами. Конечно, ожидалось, что пропускная способность запросов будет ниже с SSL, чем без, но я был довольно удивлен величиной снижения производительности во время установки соединения. Эти результаты естественно подтолкнули к дальнейшему исследованию; в частности, я хотел сравнить различия в производительности между встроенными средствами шифрования SSL MySQL и внешними технологиями шифрования, такими как туннелирование SSH. Я также буду использовать этот пост, чтобы ответить на пару вопросов, заданных в комментариях к моей оригинальной статье. Итак, без лишних слов …

Тестовая среда

Различные тесты, обсуждаемые в этом посте, включали в себя четыре разных машины:

• Машина A: экземпляр m1.xlarge EC2 (4 vCPU / 15 ГБ ОЗУ / Amazon Linux) в США-Запад-2 / Орегон
• Машина B: m1.xlarge EC2 экземпляр (4 vCPU / 15 ГБ ОЗУ / Amazon Linux) в ЕС-Запад / Ирландия
• Машина C: Intel Core i7-2600K 3,4 ГГц (8 ядер HT / 32 ГБ ОЗУ / CentOS 6.4)
• Машина D: Intel Core i3-550 3,2 ГГц (4 ядра HT / 16 ГБ ОЗУ / CentOS 6.4)

Некоторые тесты были проведены с сообществом MySQL 5.6.13, а другие — с Percona Server 5.6.13.

Технология внешнего шифрования

В этом тесте я рассмотрел один из самых распространенных способов установления связи между сайтами при отсутствии «истинной» VPN — старого доброго туннеля SSH. У меня нет готового доступа к достаточному оборудованию для настройки VPN с аппаратным ускорением, но этого достаточно, чтобы проиллюстрировать это. Напомним, что набор шифров SSL по умолчанию, используемый MySQL / SSL, является DHE-RSA-AES256-SHA; если мы немного распакуем это, это говорит нам о том, что мы используем обмен ключами Диффи-Хеллмана с SHA1 в качестве нашей функции хеширования, RSA для аутентификации и шифрования с помощью 256-битного AES (в режиме CBC, согласно документации OpenSSL). Хотя, возможно, это не сразу очевидно, этот же набор шифров довольно легко эмулировать с помощью OpenSSH. Протокол SSH версии 2 по умолчанию использует DHE / RSA / SHA1, поэтому все, что нам нужно сделать, это явно указать шифр AES256-CBC при настройке нашего туннеля,и мы должны, по сути, сравнивать зашифрованные яблоки с зашифрованными яблоками. Ради любопытства мы также попробуем наш SSH-туннель с AES256 в режиме CTR, который теоретически должен быть немного быстрее из-за его способности шифровать блоки параллельно, но, как оказалось, по крайней мере для этого теста, разница маргинальный.

Для этого теста использовались машины C (сервер) и D (клиент), которые находятся в одной и той же VLAN гигабитного канала Ethernet, и используемый тестовый сценарий был аналогичен описанному в части 1, в которой мы пытаемся создать 100 соединения как можно быстрее. Каждая конфигурация теста выполнялась 10 раз, при этом средние значения и стандартные отклонения для каждого теста перечислены в таблице ниже, а числа приведены в соединениях в секунду. Также обратите внимание, что для этого конкретного теста все используемые ключи имеют размер 4096 бит и тесты выполнялись только для Percona Server 5.6.13.

Или для тех из вас, кто любит графику, я думаю, что график говорит сам за себя.

Очевидно, что неиспользование шифрования по-прежнему является самой быстрой игрой в городе, но пропускная способность соединения через SSH-туннель не снижает производительность до уровня, близкого к тому, который используется встроенной функцией MySQL SSL. Переход с 1000 до 22 сП потенциально бесполезен, но я бы рискнул предположить, что 470-480 с / с в одном потоке все равно обеспечат исправные результаты для большинства людей.

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

Погоня за данными для этого теста возникла из вопроса, оставленного в комментариях к моему оригинальному сообщению; в частности, как штраф за соединение SSL влияет на увеличение задержки в сети. Из приведенных выше результатов видно, что при использовании канала с малой задержкой использование SSL резко влияет на производительность, но что, если мы создадим это соединение по каналу WAN? Может случиться так, что если мы уже платим штраф за задержку из-за простого времени приема-передачи, возможно, использование шифрования в миксе не повредит так сильно, даже если мы сделаем это с помощью встроенной поддержки MySQL SSL. Таким образом, для этого теста я развернул два разных экземпляра Amazon EC2 (машины A и B, описанные выше). В качестве клиента использовался компьютер C, расположенный в Северной Калифорнии, и этот тест проводился как с Community MySQL, так и с Percona Server, а также с размерами ключей от 0 до 4096 бит.Используемый набор шифров SSL использовался по умолчанию, и сценарий тестирования был таким же, как и раньше: запустите 10 испытаний, создайте 100 подключений так быстро, как мы можем, и сообщайте о результатах подключений в секунду. Однако для этого теста необработанные числа несколько вторичны; мы просто хотим посмотреть, как сетевая задержка влияет на производительность SSL-соединения.

Сначала от C до B (от Северной Калифорнии до Ирландии):

--- ec2-54-220-212-210.eu-west-1.compute.amazonaws.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49228ms
rtt min/avg/max/mdev = 167.851/170.126/177.433/2.289 ms

И затем, от C до A (от Северной Калифорнии до Орегона):

--- ec2-54-212-134-221.us-west-2.compute.amazonaws.com ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49108ms
rtt min/avg/max/mdev = 42.543/44.648/59.994/3.194 ms

Как и ожидалось, очевидно, что исходные значения для трансконтинентального теста намного ниже, чем при подключении к серверам, которые, по крайней мере, географически расположены всего в нескольких сотнях миль, но, как оказалось, за исключением того, как ведет себя Community MySQL, о котором я расскажу через минуту, процентное снижение производительности на самом деле не сильно меняется. В таблице ниже сравниваются соединения от C до B с соединениями от C до A.

Несколько комментариев по вышеизложенному. Во-первых, при 1024-битном шифровании SSL это не имеет большого значения, если вы находитесь на расстоянии 40 мс или 170 мс. Во-вторых, при уменьшении задержки производительность пропускной способности соединения теряется из-за издержек шифрования SSL. Это имеет смысл, особенно если учесть, что в базовых случаях (два сервера в одной локальной сети или соединения через сокет TCP с одним и тем же сервером) в пропускной способности соединения преобладает использование (или нет) SSL. Тем не менее, единственное во всем этом, что для меня не имеет смысла, это то, насколько плохо MySQL сообщества использует 4096-битное шифрование по сравнению с Percona Server. Что такого особенного в 4096-битном шифровании, которое повышает производительность Community MySQL, но, похоже, не так сильно влияет на Percona Server? У меня нет ни хорошего ответа на это, ни даже хорошей гипотезы;если бы этого не произошло в обоих тестах, я бы, вероятно, претендовал на PEBCAT, но сейчас я просто не уверен. Так что, если кто-нибудь еще попробует этот тест, мне было бы интересно узнать, получите ли вы те же результаты.

Расставание Мысли

Независимо от аномалии с MySQL 5.6.13 и 4096-битным SSL, я думаю, что основной вывод из этого поста и его предшественника довольно ясен: если вам нужно сквозное шифрование трафика MySQL и вы используете репликацию или рабочая нагрузка пула соединений, встроенная поддержка MySQL SSL, вероятно, будет вам полезна, но если ваше приложение относится к типу, который требует частой настройки и разрыва большого количества соединений, вы можете захотеть посмотреть на разгрузку это шифрование работает в другом месте, даже если «в другом месте» просто означает запуск его через туннель SSH.