Самое интересное, что по мере разматывания клубка во всей этой облачной истории внезапно всплыл один подвох, который перетасовал всю колоду. И у меня до сих пор нет ответа на вопрос, а как вообще можно вот так вот торговать мощностями, как делают это два упомянутых в заголовке гранда?
Кому интересно — добро пожаловать под кат.
Признаюсь, что богатого реального опыта работы с AWS, Azure и Google Cloud у меня до сего момента не было, потому я начал с простого гугления, т.к. «лобовое» сравнение характеристик не дало должного понимания картины. К примеру, при выборе многоядерных систем тот же Гугл оперирует значениями неких виртуальных ЦП, нигде не поясняя, что это значит. В результате не совсем понятно, какова именно будет производительность запущенной системы.
В итоге я принял решение поставить простой эксперимент: запустить ряд несложных тестов производительности на инсталляциях трех топовых провайдеров облачных сервисов (ими стали AWS, Google Cloud и Microsoft Azure).
Во всех трех случаях были заведены новые аккаунты и подняты Windows Server 2016 на 4-х ядерных инстансах универсального назначения. Для AWS это EC2 m4.xlarge; для Google — n1-standard-4; для Azure — DS3_v2 Standard. Память выровнена во всех трех примерах до уровня Azure.
Тут, кстати, крылась первая «засада». Нормально зарегистрироваться с первого раза получилось только с Azure. Google по каким-то причинам отказался принимать банковскую карту, заявив о «недопустимом способе оплаты» — хотя и Amazon и Azure восприняли карту нормально. У AWS глюкнула форма регистрации — да так, что пришлось обращаться в поддержку и ждать ответа. Техподдержка у них активная. Это плюс. Дважды перезванивали, дважды писали, но вопрос в итоге «висел» более недели.
Но это мелочи, поэтому вернемся к тестам. Виртуальные машины подняты, что называется, «как есть», без какой-либо дополнительной доработки. Для проверки производительности во всех случаях запускался одинаковый набор тестов:
- GeekBench 4 (на мой взгляд, самый показательный);
- 7zip (как «контрольный выстрел»);
- CristalDiskMark.
Результаты GeekBench 4
Amazon EC2 m4.xlarge в дата-центре во Франкфурте
Google Cloud (дата-центр us-central 1-c)
Microsoft Azure
Результат, если честно, немного удивил. Т.е. мы видим весьма заметное преимущество облака от Microsoft. И причина проста — Azure предоставляет полноценные четыре вычислительных ядра с высокой тактовой частотой, тогда как и Google и Amazon дают двухядерники, а цифра «четыре» получается за счет гипертрейдинга!
С Google, кстати, есть еще одна «засада». Уже после тестов, разбирая скриншоты, стало ясно, что инстансы от Azure и AWS у меня были расположены в Европе, а Google — в Штатах. Т.е. при поднятии сервера я не обратил внимание на регион. А тонкость тут в том, что изменить местоположение дата-центра при поднятии сервера нельзя. Делается это в общих настройках консоли всех виртуальных машин, что не совсем очевидно.
Тем не менее, думается, что еще два ядра от изменения географии дата-центра вряд ли появятся. Политика раздачи ресурсов у Google одинаковая, поэтому было решено оставить все как есть и тесты не переделывать (тем более, что за инсталляции каждый раз приходится платить некоторую сумму денег).
Результаты 7Zip
Результаты работы встроенного теста архиватора — исключительно для проверки GeekBench. И тут мы видим аналогичную картину, хотя с чуть меньшим расхождением. На диаграмму вынесен общий вычислительный балл Total Rating в MIPS.
Теперь давайте посмотрим на скорость дисковой подсистемы.
Результаты CrystalDiskMark
Чтобы проверить работу дисковой подсистемы, я взял CrystalDiskMark и старенький Anvil’s Storage Utilities. Первый отработал на ура, и вот его результаты:
Azure и Amazon в целом работают достаточно шустро, а вот Google, по всей видимости, жестко ограничен рамками в 25 МБ/с. Попытка перепроверки данных в Anvil’s была успешной лишь отчасти. На сервере Amazon он показал результаты, аналогичные Crystal, а вот в «облаках» Azure и Google тестовые результаты вызвали огромное количество вопросов. Например в Google скорость линейной записи зафиксировалась на отметке в 240 МБ/с, в то время как внешний мониторинг дисковых операций на консоли управления не показывал трафика выше 20 МБ/с. А это даже ниже, чем зарегистрированные значения при запуске Crystal (два горба справа на скриншоте — работа дисковых тестов).
Ценник
Цена на Google Cloud самая низкая. Особенно с учетом 30% скидки, получаемой, если виртуалка работает большую часть месяца.
Второй по цене выходит AWS. C учетом отдельной платы за хранилище в нашем случае мы получаем ~$346, что отображено на шапке соответствующей вкладки.
Ну а цена на Azure формально самая высокая (~$356). Однако она не сильно отличается от AWS. А если учесть, что при регистрации в Azure мы получаем бонусные $200, так и вовсе становится средней.
Выводы
Главный вывод — на Azure мы получили полноценные четыре вычислительных ядра процессора Xeon E5-2673. За счет этого мы имеем чуть ли не 50% превосходство в скорости выполнения многопоточных задач над AWS. Да, это стоит чуть дороже. Однако стартовые $200 и, будем честны, совсем не 50%-е превышение цены, говорят сами за себя.
Дисковая подсистема тоже не одинакова. И если хранилища Azure и AWS «шевелятся» достаточно шустро, то у Google выставлен очень жесткий и низкий барьер на дисковые операции. И если это кому-то критично, то имейте в виду. С другой стороны, у Гугла тестировался американский дата-центр. Возможно, что если бы я взял европейский, картина могла быть другой. Но сейчас пока нет времени это проверить.
P.S.: Уже после заливки материала на Хабр увидел вот эту статью. Ну, значит, все действительно так и есть.
Комментарии (41)
farcaller
28.06.2017 13:52С Google, кстати, есть еще одна «засада». Уже после тестов, разбирая скриншоты, стало ясно, что инстансы от Azure и AWS у меня были расположены в Европе, а Google — в Штатах. Т.е. при поднятии сервера я не обратил внимание на регион. А тонкость тут в том, что изменить местоположение дата-центра при поднятии сервера нельзя. Делается это в общих настройках консоли всех виртуальных машин, что не совсем очевидно.
На вашем же скриншоте:
Второй пункт — зона.
Caravus
28.06.2017 13:56+1Да тут вообще какое-то странное сравнение.
Тем не менее, думается, что еще два ядра от изменения географии дата-центра вряд ли появятся.
Автор сам пишет про виртуальные ядра, сам недоумевает. И таки да, от географии зависит железо.
Ну а цена на Azure формально самая высокая (~$356). Однако она не сильно отличается от AWS. А если учесть, что при регистрации в Azure мы получаем бонусные $200, так и вовсе становится средней.
А про 300$ у гугла — вообще ни слова.
dracon134
28.06.2017 15:02Из таблицы по вашей ссылке видно, что разница есть, но минимальная. И она не дает ответа на вопрос, гипертрединговые ядра там раздают или реальные
dracon134
28.06.2017 15:18В данном месте можно было выбрать только между тремя дата-центрами, расположенными в Штатах. Чтобы сменить регион, надо было лезть в пункт «настройки». Его видно в меню слева. И тогда там появились бы дата-центры соответствующего региона.
begemot_sun
28.06.2017 14:39Вообще все эти облака от лукавого, тоже что и VPS только на уровень ниже.
Т.о. получив чего-то там виртуального вы будете платить реальное. И платите вы не за реальное быстродействие, кое может для вас менятся в разы с течением времени, а за мифические 2 core and m4.xlarge.
Т.о. облака стоило также сравнить по степени загрузки. Может оказаться что Azure не так популярен, соотвественно и простаивающих мощностей там побольше.
Самый идеальный вариант, это выделенный сервер. По быстродействию он ни с чем не сравнится. И стоит гораздо дешевле (если конечно не простаивает).
Во время тестирования столкнулся с тем что AWS тачка с 32 ядрами + 64 Гбайтами памяти была в разы медленнее чем моя домашняя тачка с 4 процами и 8 Гб памяти. После этого в облака я перестал верить.
script88
28.06.2017 15:28+1Облака в первую очередь — это не только инстансы, но набор сервисов которые предоставляет поставщик услуг.
Для начала посмотрите список сервисов которые предлагает тот же AWS/GCP/Azure
gaploid
28.06.2017 15:53+3Вроде в облаках смысл другой. Для бескончаемого хранилища с кучами распределенных копий и минимальной ценой. Развертывания еще трех, пяти, тысячи таких вот серверов когда это нужно на пиках и автоматической масштабируемости. SLA в три, четыри девятки, кучами разными платформенными сервисами, навроде очередей, аналитики, автоматического нагрузочного тестирования и еще тысяч таких штук, для которых нужно крутить свои конфигурации развертывать их в отказо устойчевой конфигурациях, а самое главное тратить на это человеческие ресурсы и время.
MazayZaycev
28.06.2017 19:01+1SLA в три, четыри девятки
https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_6/
•For all Virtual Machines that have two or more instances deployed in the same Availability Set, we guarantee you will have Virtual Machine Connectivity to at least one instance at least 99.95% of the time.
•For any Single Instance Virtual Machine using premium storage for all Operating System Disks and Data Disks, we guarantee you will have Virtual Machine Connectivity of at least 99.9%.
SirEdvin
28.06.2017 15:28+2Уже после заливки материала на Хабр увидел вот эту статью. Ну, значит, все действительно так и есть.
Ведь парень с подписью Azure MVP никогда не будет предвзят, верно?)
Ну и как уже написали в той статье — тестировать разные инстансы, которые, скорее всего, для разных целей, довольно странно.
gaploid
28.06.2017 15:55Кажется, тестировали одинаковые инстансы, просто в разных регионах. Но производительность от этого не сильно изменится.
dracon134
28.06.2017 16:25+1Я лично ориентировался на вычислительные нагрузки и брал то, что наиболее соответствовало им. У AWS это EC2, у остальных универсальные «standard». Да, с инстансами там везде можно долго играться (вариантов много и без поллитра с ними не разберешься), но подсовывать гипертрединговые ядра в самых популярных нигде не упоминая про это — это как то совсем некрасиво
4c74356b41
29.06.2017 11:28Ну извините, денег мне Майкрософт не платит за эти статьи :) А врать как-то…
SirEdvin
29.06.2017 11:57Нито не говорит про вранье. Но смещение акцентов из-за предвзятости и из-за того, что вы лучше знаете Azure, а значит отталкиваетесь от него и сравниваете то, насколько каждое облако Azure. И разумеется, в этом случае Azure выигрывает)
Возможно, я тоже предвзят и вижу лычку и из-за нее наговариваю на вас)
4c74356b41
29.06.2017 12:47Я писал в статье что я специально никаких «приемчиков» не использовал, а просто создавал виртуальные машины с портала используя далее-далее-далее (только выбирал размер и ссд). Если в АВС или Гоогле можно как-то оптимальнее создать ВМ я этого не знаю, но это не должно быть важно, ибо я сравнивал «значения по умолчанию»
Legion21
28.06.2017 15:59+1Спасибо за статью!!! Буду юзать Azure… для меня выходит выгоднее аналогов)
Arxitektor
28.06.2017 20:07+1А какова архитектура системы например у Azure?
Имеется мощный сервер на нем гипервизор а в нем виртуалка с выбранным железом?
ПростоНу а цена на Azure формально самая высокая (~$356)
как то высоковато. Если это не выделенный сервер.
Просто смотрю этого хостера ua-hosting.company (не реклама просто для примера)
у него выделенные серваки есть за 300$ в месяц.
Можете объяснить чем отличается хостинг виртуалки на Azure и ua-hosting.company
просто не понятно почему такая разница в цене? Или это кардинально разные сервисы?
Aleks_ja
28.06.2017 21:40Всё зависит от задач. Если вам просто один инстанс. То лучше выделенный сервер. Если отказоустойчивая архитектура — то AWS/Axure и так далее будут проще. Например, подключаете RDS на амазоне — и у вас есть отказоустойчивая база данных. S3 — для хранилища файлов с версионингом.
Самые дешёвые сервера на hetzner.de, ovh.ie (хотя на ovh — когда мы попробовали взять 10 серверов — некоторые из них периодически вываливались из сети, глючили и т.п.). Сервер на hetzner за 50 долларов уделает AWS инстанс за 500.lolhunter
29.06.2017 11:51Да не стоит оно того никак.
При такой цене проще взять десяток серверов и нанять админа, чем иметь 3 виртуалки.
И будет и отказоустойчивый, и облако и что еще там надо.SirEdvin
29.06.2017 12:03Админа будет откровенно маловато. Вам нужен будет целый отдел админов.
Потому что отказоустойчивая реляционная база данных — это крупная проблема.
Отказоустойчивое хранилище с версионностью — еще одна проблема, я пока даже не видел аналогов.
Технологии, при помощи которых делаются приватные облака, тоже довольно сложные и прочее.
Так что тут еще вопрос, что дешевле получится в итоге.
lolhunter
29.06.2017 13:01Если вам надо подобные штуки — у амазона они стоят тоже ой как не мало.
Там команда админов начинает стоить резко меньше)
script88
30.06.2017 22:15Судя по всему, у вас практически нет представлений о том, что такое облако, отказоустойчивость, маштабирование, etc которые предоставляет AWS/GCP/Azure
willyd
29.06.2017 10:18+1К примеру, при выборе многоядерных систем тот же Гугл оперирует значениями неких виртуальных ЦП, нигде не поясняя, что это значит.
В документации это описано. Не знаю, где вы смотрели.
What is a virtual CPU in Google Compute Engine?
For the n1 series of machine types, a virtual CPU is implemented as a single hardware hyper-thread on a 2.6 GHz Intel Xeon E5 (Sandy Bridge), 2.5 GHz Intel Xeon E5 v2 (Ivy Bridge), 2.3 GHz Intel Xeon E5 v3 (Haswell), 2.2 GHz Intel Xeon E5 v4 (Broadwell), or 2.0 GHz Intel (Skylake) platform...
AWS
Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.
*M3 instances may also launch on an Intel Xeon E5-2670 (Sandy Bridge) Processor running at 2.6 GHz.
** These M4 instances may launch on an Intel Xeon E5-2686 v4 (Broadwell) Processor.
Как бы тест изначально неверный, поскольку выбраны неравные конфигурации.
Нормально зарегистрироваться с первого раза получилось только с Azure. Google по каким-то причинам отказался принимать банковскую карту, заявив о «недопустимом способе оплаты» — хотя и Amazon и Azure восприняли карту нормально.
GCP не принимает prepaid-карты и одну карту можно привязать только к одному аккаунту.
Про бонус GCP, как уже писалось, вы забыли. AWS дает на год бесплатное время, правда на самом дешевом инстансе.
Ну и как-бы учитывая выбранную вами конфигурацию, и то, что обычно идет не один сервер, а — больше. Бонусы в сравнении цены можно не учитывать.
Тест поверхностный и мягко говоря некорректный. И весь Azure у вас вышел таким лазурным, как берег в Ницце, а GCP и AWS как пляж в Крыму — дорого и грязно.
justmara
29.06.2017 10:36Тесты дисковой подсистемы несколько некорректны. Фокус в том, что у AWS системный диск — это всегда EBS, т.е. сетевой диск. И на него бывают разные ограничения (можно разные квоты поставить), он бывает старый, а бывает и новый SSD-based… Нет, старые машины ещё доступны и иногда в них действительно есть смысл.
Начал писать и прям дежавю словил — три года назад точно также расписывал разницу между сетевыми дисками в aws/azure.
alexoron
29.06.2017 11:02-2Автор статейки видимо не в курсе или умолчал за Спотовые инстансы Amazon EC2.
Применяя спотовые инстансы, вы можете сократить свои эксплуатационные расходы на 50–90% по сравнению с использованием инстансов по требованию.
Небольшая ремарка: чтобы вашу spot-цену не перебили выбирайте зону с наименьшими скачками цены.
А теперь покажите мне в азурах и гуглах что-то напоминающее спотовые цены :)
UPD: Невозможно так просто взять и сравнивать машины, все они могут имень разное оборудование или одинаковое очень тяжело подогнать.
ximik13
29.06.2017 11:06+1Для меня не понятно с каких пор эталоном тестирования дисковой подсистемы стала утилита CrystalDiskMark? При том что ей разве только обычные USB-флешки тестировать можно. Документация по утилите совершенно скудная.
Режим прямого ввода/вывода, с обходом кэширования на уровне OS не включается. Нет возможности создать большой тестовый файл (в несколько раз больше ОЗУ), что бы нивелировать эту проблему. Т.е. не понятно, что протестировали. То ли ОЗУ компьютера, то ли погоду за окном.
Идем дальше. Вы когда-нибудь видели сервер (или HDD) работающий только в режиме записи или только в режиме чтения и при этом в один поток I/O? Или считаете, что эти операции никак на друг друга не влияют и все приложения пишут и читают в один поток? Так какой смысл тестировать дисковую подсистему в условиях, в которых она никогда работать не будет даже в теории? Не лучше ли создавать смешанный поток I/O с известным соотношением чтение/запись, что намного ближе к реальной работе сервера и его дисковой подсистемы? А вот это как раз CrystalDiskMark делать не умеет.
Ну и совсем уж простое. Объясните мне (аргументированно с отсылкой к документации) какие значения показывает CrystalDiskMark в результате? Средние полученные в процессе теста? Или максимальный пик, полученный в какую то долю секунды в процессе теста? И на какие стабильные, в течении длительного времени, значения по количеству операций ввода/вывода (IOPS) я могу рассчитывать например при использовании MSSQL на протестированных вами облачных VM?
P.s. Я не против облаков :), все туда идет неизбежно. Но если уж что-то тестируете, то постарайтесь хотя бы немного в тему погрузиться.
P.s. P.s. В приведенной вами аналогичной статье все тот же CrystalDiskMark, так что вы не одиноки.
ahriman
30.06.2017 12:16Не отвечу по методологии исследования в статье, но по конкретному вопросу попробую. В случае с конкретными сервисами и продуктами типа MSSQL, MySQL и т.д. есть буллет-листы с пояснениями, как добиться больше попугаев по производительности. MSSQL на виртуалках, MySQL на линуксе и т.д. По исследованию в статье могу предположить, что оно м.б. актуально для нестандартных нагрузок, дабы оценить, что получите, в среднем.
Поясните, что имели в виду про кэширование — для ВМ и дисков данных есть рычаг для того, чтобы ковырять кэширование.
ximik13
30.06.2017 13:22+1Вы вырвали одну фразу из контекста и попытались найти ответ на нее. :)
Про тюнинг DB это все понятно. Главный вопрос был:
Почему CrystalDiskMark стал считается утилитой для тестирования дисковой подсистемы серверов?
Если целью использования теста CrystalDiskMark в данном случае было потестировать дисковую подсистему облачной VM, то фокус однозначно не удался.
Если мы хотим понять, что в принципе может дисковая подсистема, то нужно использовать тесты, которые умеют выполнять Direct I/O избегая попадания данных в кеш OS (как пример fio). Либо умеют создавать тестовый файл, превышающий своим размером в несколько раз ОЗУ тестируемой системы, опять же что бы система не смогла закэшировать данные и отдавать их просто из ОЗУ, не обращаясь к дисковой подсистеме (пример: IOMETER или тот же fio). Ни того ни другого CrystalDiskMark не умеет и уж темболее не умеет создавать смешанную нагрузку с одновременным чтением и записью данных.
Кроме того, что бы реально нагрузить дисковую подсистему и посмотреть максимум того, что она может, не достаточно использовать всего один поток ввода/вывода. Он упрется либо в возможности самого теста по генерации нагрузки, либо в ограничения OS для одного потока I/O. Нормальные тесты умеют работать с несколькими (в т.ч. десятками и сотнями) потоков I/O.
ahriman
30.06.2017 13:28Все так. Я использовал конкретную фразу, поскольку для меня все подобные тесты должны приводить к одному — к решению о том, хватит ли попугаев для моего сервиса или нет. Если это MSSQL, то для него уже эту задачу частично решили разными способами. Если что-то кастомное, то исследование в статье можно использовать как отправную точку, а дальше уже ковырять в сторону того, что вы написали.
Было бы классно увидеть что-то по этой теме. У вас есть материалы/методики?ximik13
30.06.2017 13:36+1Могу дать ссылки на статьи на Habr-е с чего начать.
https://habrahabr.ru/post/154235/
https://geektimes.ru/post/78632/
https://habrahabr.ru/post/245859/
https://habrahabr.ru/post/168711/
Дальше все зависит от ваших задач и стенда. Ну и ничто не заменит личный опыт.
Что касается тестирования непосредственно баз данных, а не дисковой подсистемы сервера, то имеет смысл посмотреть в сторону HummerDB.
gaploid
01.07.2017 11:51Я бы с удовольствием посмотрел бы на результаты тестирования вашим предложенным методом. Мне кажется, другим было бы тоже интересно.
ximik13
03.07.2017 07:43Если дадите доступ к своим облачным машинам, то можно и потестировать. У меня пока нет задач, которые потребовали бы разбираться с облаками.
lolhunter
29.06.2017 11:49Жесть какая-то.
У меня выделенный сервер примерно в 2 раза мощнее стоит 50 евро.
Xeon e3-1270v5 32Gb Ram 2x500Gb SSD — 250мбит канала.
Nakilon
29.06.2017 19:32Судя по скриншоту, автор гонял GCP на Haswell, хотя мог взять Skylake — на два поколения новей.
И до Local SSD, видимо, маны тоже не дочитал https://cloud.google.com/compute/docs/disks/local-ssdgaploid
01.07.2017 12:00Может быть тест делали до того как они стали доступны? Вроде они совсем стали доступны, чуть ли не в июне. Кстати цена на них вроде бы должна быть больше чем на haswell, интересно было бы глянуть покроет ли рост производительности, увеличенную цену.
dmitry_dvm
Слышал, что у гугла цены ниже только на бумаге, а в жизни тоже с сюрпризом, как и ядра. Azure кроме всего прочего идеален для разведения телеграм-ботов — бесплатно и хттпс искаропки. И публикация прямо из студии, красота.
MasMaX
AWS тоже любит подводные камни и скрытые счета. За трафик, быстрые диски и т.п.
allexx
Для того чтобы что-то запускать условно бесплатно лучше всего вам подойдет PaaS. Все же если пишете бота или простой бекенд request/response узнайте про AppEngine, например c Go runtime cloud.google.com/appengine/pricing и да вы получите https://*.appspot.com бесплатно.
Или если IaaS все же — AWS Free Tier instance micro, но читайте условия.