Легкий тест производительности облачных платформ AWS, Google Cloud и Microsoft Azure

Когда говорят «облачная виртуальная машина», как правило, имеют в виду AWS. И когда все эти вопросы стали для меня актуальными, из любопытства решил провести небольшой эксперимент по оценке цены/скорости систем других крупных облачных конкурентов.



Самое интересное, что по мере разматывания клубка во всей этой облачной истории внезапно всплыл один подвох, который перетасовал всю колоду. И у меня до сих пор нет ответа на вопрос, а как вообще можно вот так вот торговать мощностями, как делают это два упомянутых в заголовке гранда?
Кому интересно — добро пожаловать под кат.

Признаюсь, что богатого реального опыта работы с 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.: Уже после заливки материала на Хабр увидел вот эту статью. Ну, значит, все действительно так и есть.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 41
  • +4
    Слышал, что у гугла цены ниже только на бумаге, а в жизни тоже с сюрпризом, как и ядра. Azure кроме всего прочего идеален для разведения телеграм-ботов — бесплатно и хттпс искаропки. И публикация прямо из студии, красота.
    • 0
      AWS тоже любит подводные камни и скрытые счета. За трафик, быстрые диски и т.п.
      • –1
        Azure кроме всего прочего идеален для разведения телеграм-ботов — бесплатно и хттпс искаропки.


        Для того чтобы что-то запускать условно бесплатно лучше всего вам подойдет PaaS. Все же если пишете бота или простой бекенд request/response узнайте про AppEngine, например c Go runtime cloud.google.com/appengine/pricing и да вы получите https://*.appspot.com бесплатно.
        Или если IaaS все же — AWS Free Tier instance micro, но читайте условия.
      • 0
        С Google, кстати, есть еще одна «засада». Уже после тестов, разбирая скриншоты, стало ясно, что инстансы от Azure и AWS у меня были расположены в Европе, а Google — в Штатах. Т.е. при поднятии сервера я не обратил внимание на регион. А тонкость тут в том, что изменить местоположение дата-центра при поднятии сервера нельзя. Делается это в общих настройках консоли всех виртуальных машин, что не совсем очевидно.

        На вашем же скриншоте:



        Второй пункт — зона.

        • +1
          Да тут вообще какое-то странное сравнение.
          Тем не менее, думается, что еще два ядра от изменения географии дата-центра вряд ли появятся.

          Автор сам пишет про виртуальные ядра, сам недоумевает. И таки да, от географии зависит железо.
          Ну а цена на Azure формально самая высокая (~$356). Однако она не сильно отличается от AWS. А если учесть, что при регистрации в Azure мы получаем бонусные $200, так и вовсе становится средней.

          А про 300$ у гугла — вообще ни слова.
          • 0
            Из таблицы по вашей ссылке видно, что разница есть, но минимальная. И она не дает ответа на вопрос, гипертрединговые ядра там раздают или реальные
          • 0
            В данном месте можно было выбрать только между тремя дата-центрами, расположенными в Штатах. Чтобы сменить регион, надо было лезть в пункт «настройки». Его видно в меню слева. И тогда там появились бы дата-центры соответствующего региона.
          • 0
            Вообще все эти облака от лукавого, тоже что и VPS только на уровень ниже.
            Т.о. получив чего-то там виртуального вы будете платить реальное. И платите вы не за реальное быстродействие, кое может для вас менятся в разы с течением времени, а за мифические 2 core and m4.xlarge.
            Т.о. облака стоило также сравнить по степени загрузки. Может оказаться что Azure не так популярен, соотвественно и простаивающих мощностей там побольше.

            Самый идеальный вариант, это выделенный сервер. По быстродействию он ни с чем не сравнится. И стоит гораздо дешевле (если конечно не простаивает).

            Во время тестирования столкнулся с тем что AWS тачка с 32 ядрами + 64 Гбайтами памяти была в разы медленнее чем моя домашняя тачка с 4 процами и 8 Гб памяти. После этого в облака я перестал верить.
            • +1
              Облака в первую очередь — это не только инстансы, но набор сервисов которые предоставляет поставщик услуг.
              Для начала посмотрите список сервисов которые предлагает тот же AWS/GCP/Azure
              • +3

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

                • +1
                  SLA в три, четыри девятки

                  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%.
              • +2
                Уже после заливки материала на Хабр увидел вот эту статью. Ну, значит, все действительно так и есть.

                Ведь парень с подписью Azure MVP никогда не будет предвзят, верно?)


                Ну и как уже написали в той статье — тестировать разные инстансы, которые, скорее всего, для разных целей, довольно странно.

                • 0

                  Кажется, тестировали одинаковые инстансы, просто в разных регионах. Но производительность от этого не сильно изменится.

                  • +1
                    Я лично ориентировался на вычислительные нагрузки и брал то, что наиболее соответствовало им. У AWS это EC2, у остальных универсальные «standard». Да, с инстансами там везде можно долго играться (вариантов много и без поллитра с ними не разберешься), но подсовывать гипертрединговые ядра в самых популярных нигде не упоминая про это — это как то совсем некрасиво
                    • 0
                      Ну извините, денег мне Майкрософт не платит за эти статьи :) А врать как-то…
                      • 0

                        Нито не говорит про вранье. Но смещение акцентов из-за предвзятости и из-за того, что вы лучше знаете Azure, а значит отталкиваетесь от него и сравниваете то, насколько каждое облако Azure. И разумеется, в этом случае Azure выигрывает)


                        Возможно, я тоже предвзят и вижу лычку и из-за нее наговариваю на вас)

                        • 0
                          Я писал в статье что я специально никаких «приемчиков» не использовал, а просто создавал виртуальные машины с портала используя далее-далее-далее (только выбирал размер и ссд). Если в АВС или Гоогле можно как-то оптимальнее создать ВМ я этого не знаю, но это не должно быть важно, ибо я сравнивал «значения по умолчанию»
                    • +1
                      Спасибо за статью!!! Буду юзать Azure… для меня выходит выгоднее аналогов)
                      • +1
                        А какова архитектура системы например у Azure?
                        Имеется мощный сервер на нем гипервизор а в нем виртуалка с выбранным железом?
                        Просто
                        Ну а цена на Azure формально самая высокая (~$356)

                        как то высоковато. Если это не выделенный сервер.
                        Просто смотрю этого хостера ua-hosting.company (не реклама просто для примера)
                        у него выделенные серваки есть за 300$ в месяц.
                        Можете объяснить чем отличается хостинг виртуалки на Azure и ua-hosting.company
                        просто не понятно почему такая разница в цене? Или это кардинально разные сервисы?

                        • 0
                          Всё зависит от задач. Если вам просто один инстанс. То лучше выделенный сервер. Если отказоустойчивая архитектура — то AWS/Axure и так далее будут проще. Например, подключаете RDS на амазоне — и у вас есть отказоустойчивая база данных. S3 — для хранилища файлов с версионингом.

                          Самые дешёвые сервера на hetzner.de, ovh.ie (хотя на ovh — когда мы попробовали взять 10 серверов — некоторые из них периодически вываливались из сети, глючили и т.п.). Сервер на hetzner за 50 долларов уделает AWS инстанс за 500.
                          • 0
                            Да не стоит оно того никак.
                            При такой цене проще взять десяток серверов и нанять админа, чем иметь 3 виртуалки.
                            И будет и отказоустойчивый, и облако и что еще там надо.
                            • 0

                              Админа будет откровенно маловато. Вам нужен будет целый отдел админов.


                              Потому что отказоустойчивая реляционная база данных — это крупная проблема.
                              Отказоустойчивое хранилище с версионностью — еще одна проблема, я пока даже не видел аналогов.


                              Технологии, при помощи которых делаются приватные облака, тоже довольно сложные и прочее.


                              Так что тут еще вопрос, что дешевле получится в итоге.

                              • 0
                                Если вам надо подобные штуки — у амазона они стоят тоже ой как не мало.
                                Там команда админов начинает стоить резко меньше)
                              • 0
                                Судя по всему, у вас практически нет представлений о том, что такое облако, отказоустойчивость, маштабирование, etc которые предоставляет AWS/GCP/Azure
                          • 0
                            что за зион такой на 4.7 ггц?
                            • 0
                              Глаз режет, это верно.
                            • +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 как пляж в Крыму — дорого и грязно.
                              • 0

                                Тесты дисковой подсистемы несколько некорректны. Фокус в том, что у AWS системный диск — это всегда EBS, т.е. сетевой диск. И на него бывают разные ограничения (можно разные квоты поставить), он бывает старый, а бывает и новый SSD-based… Нет, старые машины ещё доступны и иногда в них действительно есть смысл.
                                Начал писать и прям дежавю словил — три года назад точно также расписывал разницу между сетевыми дисками в aws/azure.

                                • –2
                                  Автор статейки видимо не в курсе или умолчал за Спотовые инстансы Amazon EC2.
                                  Применяя спотовые инстансы, вы можете сократить свои эксплуатационные расходы на 50–90% по сравнению с использованием инстансов по требованию.

                                  Небольшая ремарка: чтобы вашу spot-цену не перебили выбирайте зону с наименьшими скачками цены.

                                  А теперь покажите мне в азурах и гуглах что-то напоминающее спотовые цены :)

                                  UPD: Невозможно так просто взять и сравнивать машины, все они могут имень разное оборудование или одинаковое очень тяжело подогнать.
                                • +1

                                  Для меня не понятно с каких пор эталоном тестирования дисковой подсистемы стала утилита CrystalDiskMark? При том что ей разве только обычные USB-флешки тестировать можно. Документация по утилите совершенно скудная.


                                  Режим прямого ввода/вывода, с обходом кэширования на уровне OS не включается. Нет возможности создать большой тестовый файл (в несколько раз больше ОЗУ), что бы нивелировать эту проблему. Т.е. не понятно, что протестировали. То ли ОЗУ компьютера, то ли погоду за окном.


                                  Идем дальше. Вы когда-нибудь видели сервер (или HDD) работающий только в режиме записи или только в режиме чтения и при этом в один поток I/O? Или считаете, что эти операции никак на друг друга не влияют и все приложения пишут и читают в один поток? Так какой смысл тестировать дисковую подсистему в условиях, в которых она никогда работать не будет даже в теории? Не лучше ли создавать смешанный поток I/O с известным соотношением чтение/запись, что намного ближе к реальной работе сервера и его дисковой подсистемы? А вот это как раз CrystalDiskMark делать не умеет.


                                  Ну и совсем уж простое. Объясните мне (аргументированно с отсылкой к документации) какие значения показывает CrystalDiskMark в результате? Средние полученные в процессе теста? Или максимальный пик, полученный в какую то долю секунды в процессе теста? И на какие стабильные, в течении длительного времени, значения по количеству операций ввода/вывода (IOPS) я могу рассчитывать например при использовании MSSQL на протестированных вами облачных VM?


                                  P.s. Я не против облаков :), все туда идет неизбежно. Но если уж что-то тестируете, то постарайтесь хотя бы немного в тему погрузиться.


                                  P.s. P.s. В приведенной вами аналогичной статье все тот же CrystalDiskMark, так что вы не одиноки.

                                  • 0
                                    Не отвечу по методологии исследования в статье, но по конкретному вопросу попробую. В случае с конкретными сервисами и продуктами типа MSSQL, MySQL и т.д. есть буллет-листы с пояснениями, как добиться больше попугаев по производительности. MSSQL на виртуалках, MySQL на линуксе и т.д. По исследованию в статье могу предположить, что оно м.б. актуально для нестандартных нагрузок, дабы оценить, что получите, в среднем.

                                    Поясните, что имели в виду про кэширование — для ВМ и дисков данных есть рычаг для того, чтобы ковырять кэширование.

                                    • +1

                                      Вы вырвали одну фразу из контекста и попытались найти ответ на нее. :)
                                      Про тюнинг DB это все понятно. Главный вопрос был:


                                      Почему CrystalDiskMark стал считается утилитой для тестирования дисковой подсистемы серверов?


                                      Если целью использования теста CrystalDiskMark в данном случае было потестировать дисковую подсистему облачной VM, то фокус однозначно не удался.


                                      Если мы хотим понять, что в принципе может дисковая подсистема, то нужно использовать тесты, которые умеют выполнять Direct I/O избегая попадания данных в кеш OS (как пример fio). Либо умеют создавать тестовый файл, превышающий своим размером в несколько раз ОЗУ тестируемой системы, опять же что бы система не смогла закэшировать данные и отдавать их просто из ОЗУ, не обращаясь к дисковой подсистеме (пример: IOMETER или тот же fio). Ни того ни другого CrystalDiskMark не умеет и уж темболее не умеет создавать смешанную нагрузку с одновременным чтением и записью данных.


                                      Кроме того, что бы реально нагрузить дисковую подсистему и посмотреть максимум того, что она может, не достаточно использовать всего один поток ввода/вывода. Он упрется либо в возможности самого теста по генерации нагрузки, либо в ограничения OS для одного потока I/O. Нормальные тесты умеют работать с несколькими (в т.ч. десятками и сотнями) потоков I/O.

                                      • 0
                                        Все так. Я использовал конкретную фразу, поскольку для меня все подобные тесты должны приводить к одному — к решению о том, хватит ли попугаев для моего сервиса или нет. Если это MSSQL, то для него уже эту задачу частично решили разными способами. Если что-то кастомное, то исследование в статье можно использовать как отправную точку, а дальше уже ковырять в сторону того, что вы написали.
                                        Было бы классно увидеть что-то по этой теме. У вас есть материалы/методики?
                                  • 0

                                    Я бы с удовольствием посмотрел бы на результаты тестирования вашим предложенным методом. Мне кажется, другим было бы тоже интересно.

                                    • 0

                                      Если дадите доступ к своим облачным машинам, то можно и потестировать. У меня пока нет задач, которые потребовали бы разбираться с облаками.

                                  • 0
                                    Жесть какая-то.
                                    У меня выделенный сервер примерно в 2 раза мощнее стоит 50 евро.
                                    Xeon e3-1270v5 32Gb Ram 2x500Gb SSD — 250мбит канала.
                                    • 0
                                      Судя по скриншоту, автор гонял GCP на Haswell, хотя мог взять Skylake — на два поколения новей.
                                      И до Local SSD, видимо, маны тоже не дочитал https://cloud.google.com/compute/docs/disks/local-ssd
                                      • 0

                                        Может быть тест делали до того как они стали доступны? Вроде они совсем стали доступны, чуть ли не в июне. Кстати цена на них вроде бы должна быть больше чем на haswell, интересно было бы глянуть покроет ли рост производительности, увеличенную цену.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.