Много сил тратится на дебаты «монолиты против микросервисов», но реальная проблема, стоящая за этими спорами, заключается в том, стоит ли распределенная архитектура времени разработчика и накладных расходов. Размышляя о реальных эксплуатационных аспектах наших систем, мы можем получить некоторое представление о том, действительно ли нам нужны распределенные системы для большинства задач.
Мы все хорошо знакомы с виртуализацией и абстракциями между нашим программным обеспечением и серверами, на которых оно запущено. В наши дни в моде «бессерверные» вычисления, и даже «голое железо» (bare metal) — это класс виртуальных машин. Однако все программного обеспечения работает на сервере. Поскольку сейчас мы живем в мире виртуализации, большинство этих серверов намного больше и намного дешевле, чем мы на самом деле думаем.
Познакомьтесь со своим сервером
Это изображение сервера с процессорами AMD, используемого Microsoft Azure. Слева большое металлическое приспособление (с медными трубками) является радиатором, а металлические коробки, к которым прикреплены медные трубки, являются теплообменниками на процессорах. Процессоры представляют собой серверные процессоры AMD третьего поколения, каждый из которых имеет следующие характеристики:
- 64 ядра
- 128 потоков
- ~ 2-2,5 ГГц
- Ядра, способные выполнять 4-6 инструкций за такт
- 256 МБ кэш-памяти L3
Всего этот сервер имеет 128 ядер с 256 одновременными потоками. Со всеми ядрами, работающими вместе, этот сервер способен достигать 4 терафлопов максимальной вычислительной производительности с двойной точностью. В начале 2000 года этот сервер был бы на вершине списка 500 лучших суперкомпьютеров. Только в 2007 году этот сервер покинул бы список Топ-500. Каждое ядро ЦП значительно мощнее, чем одно ядро 10-летней давности, и может похвастаться гораздо более широким конвейером вычислений.
Над и под каждым процессором находится память: 16 слотов оперативной памяти DDR4-3200 на сокет. Самые экономичные модули DIMM на сегодняшний день составляют 64 ГБ. В “бюджетном” варианте этот сервер может содержать 1 ТБ памяти. Оснащенный специализированными модулями DIMM большой емкости (которые, как правило, медленнее, чем модули DIMM меньшего размера), этот сервер поддерживает до 8 ТБ памяти. При DDR4-3200 и 16 каналах памяти этот сервер, скорее всего, будет иметь пропускную способность около 200 Гбит/с для всех своих ядер.
Что касается ввода-вывода, каждый ЦП предлагает 64 линии PCIe 4-го поколения. Имея в общей сложности 128 линий PCIe, этот сервер может поддерживать 30 твердотельных накопителей NVMe плюс сетевая карта. Типичные конфигурации, которые вы можете купить, будут предлагать слоты примерно для 16 твердотельных накопителей или дисков. Последнее, на что я хотел обратить внимание на этой картинке, — это сетевая карта в правом верхнем углу. Этот сервер, вероятно, оснащен сетевым подключением 50-100 Гбит/с.
Возможности одного сервера
Один сервер сегодня способен на:
- Раздачу видеофайлов на скорости 800 Гбит/с
- 1 миллион операций ввода-вывода в секунду в базе данных NoSQL
- 70 000 операций ввода-вывода в секунду в PostgreSQL
- 500к запросов в секунду к nginx
- Компиляцию ядра Linux за 20 секунд
- Рендеринг видео 4k с x264 при 75 FPS
Среди прочего. В наши дни существует множество общедоступных тестов, и если вы знаете, как ведет себя ваш продукт, вы, вероятно, сможете найти подходящий тест.
Стоимость одного сервера
У крупного хостинг-провайдера OVHCloud вы можете арендовать сервер HGR-HCI-6 с характеристиками, аналогичными указанным выше, со 128 физическими ядрами (256 потоков), 512 ГБ памяти и пропускной способностью 50 Гбит/с за $1,318 в месяц.
В бюджетном варианте Hetzner вы можете арендовать сервер меньшего размера с 32 физическими ядрами и 128 ГБ ОЗУ примерно за 140 евро в месяц. Это меньший сервер, чем у OVHCloud (1/4 размера), но он дает вам некоторое представление о разбросе цен между хостинг-провайдерами.
В AWS одним из крупнейших серверов, которые вы можете арендовать, является сервер m6a.metal. Он предлагает пропускную способность сети 50 Гбит/с, 192 виртуальных ЦП (96 физических ядер) и 768 ГБ памяти и стоит $8.2944 в час в восточном регионе. Это получается до 6,055 долларов в месяц. Облачная наценка это реально!
Аналогичный сервер со 128 физическими ядрами и 512 ГБ памяти (а также с соответствующими сетевыми картами, твердотельными накопителями и контрактами на поддержку) можно приобрести на веб-сайте Dell примерно за 40,000 долларов. Однако, если вы собираетесь потратить так много на сервер, вам, вероятно, следует поговорить с продавцом, чтобы убедиться, что вы получаете лучшее предложение, какое только можете. Вам также нужно будет заплатить за размещение этого сервера и подключение его к сети.
Для сравнения, покупка сервера это около 8 месяцев до безубыточности по сравнению с использованием облачных серверов и 30 месяцев до безубыточности по сравнению с арендой. Конечно, покупка серверов имеет много недостатков, как и аренда, поэтому в будущем мы немного поговорим об «облачной надбавке» и о том, готовы ли вы за него платить (спойлер: ответ «да», но не так много, как облачные компании хотят, чтобы вы платили).
Думая об облаке
«Облачная эра» всерьез началась примерно в 2010 году. В то время самым современным процессором был 8-ядерный процессор Intel Nehalem. Hyperthreading только начинался, так что 8-ядерный процессор предлагал колоссальные 16 потоков. Вскоре появилось аппаратное ускорение для шифрования AES, а ширина векторов составляла 128 бит. У самых больших процессоров было 24 МБ кэш-памяти, а ваш сервер мог вместить колоссальные 256 ГБ памяти DDR3-1066. Если вы хотели хранить данные, Seagate только что начал предлагать жесткий диск емкостью 3 ТБ. Каждое ядро предлагало 4 FLOP за цикл, а это означает, что ваш 8-ядерный сервер, работающий на частоте 2.5 ГГц, предлагал невероятно быстрые 80 GFLOP.
На этой волне возник бум распределенных вычислений: если вы хотели делать что-либо, связанное с извлечением данных, вам требовалось много дисков, чтобы получить желаемую пропускную способность хранилища. Если вы хотели выполнять большие вычисления, вам обычно требовалось много процессоров. Это означало, что вам нужно было координировать работу большого количества ЦП, чтобы выполнить большую часть задач.
С тех пор размер серверов значительно увеличился, а твердотельные накопители увеличили доступные операции ввода-вывода в секунду как минимум в 100 раз, но размер основных виртуальных машин и контейнеров не сильно увеличился, а мы по-прежнему используем виртуализированные диски, которые обеспечивают производительность, больше похожую на жесткие диски, чем на твердотельные накопители (хотя этот разрыв сокращается).
Одного сервера (плюс резервная копия) обычно достаточно
Если вы занимаетесь чем-то, кроме потокового видео, и у вас менее 10,000 запросов в секунду, одного сервера, как правило, будет достаточно для большинства веб-сервисов. Для действительно простых сервисов один сервер может работать с миллионами запросов в секунду или около того. Очень немногие веб-сервисы получают столько трафика — если у вас такой проект, вы об этом знаете. Даже если вы обслуживаете видео, разумно использовать только один сервер для плоскости управления. Бенчмарк может помочь вам определить, где вы находитесь. В качестве альтернативы вы можете использовать общие тесты аналогичных приложений или таблицы общих показателей производительности, чтобы оценить, насколько большая машина вам может понадобиться.
Высокий лучше, чем широкий
Когда вам нужен кластер компьютеров, если одного сервера недостаточно, использование меньшего количества больших серверов часто будет лучше, чем использование большого парка небольших машин. Накладные расходы на координацию кластера не равны нулю, и эти накладные расходы часто составляют O(n) на каждый сервер. Чтобы уменьшить эти накладные расходы, вы, как правило, предпочитаете использовать несколько больших серверов, а не множество небольших серверов. В случае таких вещей, как бессерверные вычисления, когда вы выделяете крошечные недолговечные контейнеры, эти накладные расходы составляют большую часть стоимости использования. С другой стороны, координация кластера из одного компьютера тривиальна.
Большие серверы и доступность
Большим недостатком использования одного большого сервера является его доступность. Вашему серверу нужно время простоя, и он ломается. Обычно достаточно запустить основной и резервный серверы, разместив их в разных центрах обработки данных. Конфигурация 2×2 должна успокоить настоящих параноиков: два сервера в основном центре обработки данных (или облачном провайдере) и два сервера в резервном центре обработки данных обеспечат вам значительную избыточность. Если вам нужно третье резервное развертывание, вы часто можете сделать его меньше, чем основное и дополнительное.
Тем не менее, вам, возможно, все же придется беспокоиться о коррелированных сбоях оборудования. Известно, что жесткие диски (а теперь и твердотельные накопители) иногда имеют коррелированные сбои: если вы видите сбой одного диска, у вас гораздо больше шансов увидеть второй сбой до восстановления, если ваши диски из одной производственной партии. Такие сервисы, как Backblaze, решают эту проблему, используя множество различных моделей дисков от разных производителей. На Hacker news недавно узнали об этом на горьком опыте, когда основной и резервный сервер вышли из строя одновременно.
Если вы пользуетесь услугами хостинг-провайдера, который арендует готовые серверы, целесообразно арендовать два разных типа серверов в каждом из ваших основных и резервных центров обработки данных. Это позволит избежать почти всех режимов отказа, характерных для современных систем.
Используйте облако, но не будьте слишком облачны
Сочетание доступности и простоты использования — одна из главных причин, почему мне (и большинству других инженеров) нравятся облачные компьютеры. Да, вы платите значительную надбавку за аренду машин, но у вашего облачного провайдера так много опыта в создании серверов, что вы даже не видите большинства сбоев, а в случае других сбоев вы можете очень быстро вернуться к работе, арендовав новую машину в их почти безграничном пуле вычислительных ресурсов. Их работа заключается в том, чтобы у вас не было простоев, и хотя они не всегда делают это идеально, у них это неплохо получается.
Хостинг-провайдеры, которые готовы сдать вам сервер в аренду, являются более дешевой альтернативой облачным провайдерам, но эти провайдеры иногда могут иметь низкое качество, а некоторые из них не понимают таких вещей, как подготовка сети и связанные с этим сбои оборудования. Кроме того, переход с одного арендованного сервера на более крупный раздражает гораздо больше, чем изменение размера облачной виртуальной машины. Облачные серверы имеют надбавку к цене по понятной причине.
Однако когда вы имеете дело с облаками, ваши продавцы обычно подталкивают вас к «облачной» архитектуре. Это такие вещи, как микросервисы в автоматически масштабируемых группах виртуальных машин с легионами балансировщиков нагрузки между ними, а также продукты, улучшающие привязку к поставщику, такие как бессерверные вычисления и управляемые базы данных высокой доступности. Есть веская причина, по которой продавцы облачных вычислений продвигают «облачную архитектуру» — для них это лучше!
Принято считать, что облачная архитектура хороша тем, что позволяет легко масштабироваться. Есть веские причины использовать cloud-native архитектуру, но обслуживание большого количества людей не входит в их число — большинство продуктов могут обслуживать миллионы людей одновременно с одним сервером и никогда не дадут вам неожиданный пятизначный счет.
Почему я должен платить за пиковую нагрузку?
Одним из распространенных критических замечаний по поводу подхода «один большой сервер» является то, что теперь вы должны платить за железо для пиковой нагрузки вместо того, чтобы просто платить за то, что вы используете. Таким образом, бессерверные вычисления или парки виртуальных машин с микросервисами более тесно увязывают ваши расходы с вашей прибылью.
К сожалению, поскольку все ваши сервисы работают на серверах (нравится вам это или нет), кто-то в этой цепочке поставок взимает с вас плату в зависимости от пиковой нагрузки. Часть «облачной премии» для балансировщиков нагрузки, бессерверных вычислений и небольших виртуальных машин зависит от того, сколько дополнительных мощностей необходимо создать вашему облачному провайдеру, чтобы справляться уже со своей пиковой нагрузкой. Вы все равно платите за чью-то пиковую нагрузку!
Это означает, что если ваша рабочая нагрузка является исключительно скачкообразной — например, симуляция, которую нужно запустить один раз, а затем отключить навсегда, — вам следует использовать «облачные» решения, но если ваша рабочая нагрузка не такая скачкообразная, у вас часто будет более дешевая система (и ее проще построить), если вы выберете несколько больших серверов. Если использование вашего облачного провайдера более неустойчиво, чем ваше, вы будете платить эту надбавку без какой-либо выгоды.
Эта надбавка распространяется и на виртуальные машины, а не только на облачные сервисы. Однако, если вы используете облачную виртуальную машину круглосуточно и без выходных, вы можете не платить «надбавку за пиковую нагрузку», используя годовые контракты или договорившись с продавцом, если вы достаточно велики.
Как правило, чем больше ваша рабочая нагрузка, тем более облачной должна быть ваша архитектура.
Сколько стоит быть облачным?
Быть облачным дорого. Как правило, я ожидаю надбавки к цене в 5-30 раз в зависимости от того, что вы покупаете у облачной компании, и в зависимости от базового уровня. Не 5-30%, а умножение от 5х до 30х.
Вот цена AWS lambda: $0.20 за 1 млн запросов + $0.0000166667 за ГБ-секунду ОЗУ. Я использую здесь цены на процессор x86, чтобы сохранить паритет с экземпляром m6a.metal, который мы видели выше. Большие серверы ARM и бессерверные вычисления ARM дешевле.
Предполагая, что ваш сервер стоит $8.2944 в час и способен выполнять 1 тыс. запросов в секунду с 768 ГБ ОЗУ:
- 1 тыс. запросов в секунду — это 60 тыс. запросов в минуту или 3.6 млн запросов в час.
- Каждый запрос здесь получает 0.768 ГБ-секунд ОЗУ.
- Замена этого сервера будет стоить около 46 долларов в час при использовании бессерверных вычислений.
Ценовая надбавка за бессерверные вычисления по сравнению с экземпляром составляет 5.5x. Если вы можете поддерживать загрузку этого сервера более 20%, использование сервера будет дешевле, чем использование бессерверных вычислений. И это еще до любой формы скидок, который вы можете применить к своему серверу — если вы можете арендовать эти большие серверы на спотовом рынке или если вы сравните цену, которую вы можете получить с годовым контрактом, надбавка к цене будет еще выше.
Если вы сравните стоимость аренды OVHCloud для того же сервера, надбавка к цене при покупке ваших вычислений через AWS lambda будет в 25х раз выше.
Если вы планируете арендовать сервер у недорогого хостинг-провайдера или использовать AWS lambda, вам следует отдать предпочтение хостинг-провайдеру, если вы можете поддерживать работу сервера на 5% мощности!
Кроме того, обратите внимание, что фактическое число запросов в секунду не имеет значения: если сервер стоимостью $8.2944 в час способен выполнять 100 тыс. запросов в секунду, запрос будет использовать в 100 раз меньше времени памяти, а это означает, что вы получите тот же 5.5-кратный (или 25-кратный) прирост. Конечно, вы должны масштабировать размер сервера в соответствии с вашим приложением.
Распространенные возражения против одного большого сервера
Если вы предлагаете использовать подход с одним большим сервером, вы часто будете сталкиваться с противодействием со стороны людей, которые более комфортно чувствуют себя в облаке, предпочитают быть модными или имеют обоснованные опасения. Думайте об этом по своему усмотрению, но большинство людей сильно недооценивают, сколько на самом деле стоит «облачная архитектура» по сравнению с собственными серверами. Вот некоторые распространенные возражения.
Но если я использую облачную архитектуру, мне не нужно нанимать системных администраторов
Нет, нужно. Просто теперь они называются «Cloud Ops» и находятся под другим руководством. Кроме того, их способность читать загадочную документацию, поступающую от облачных компаний, и следить за соответствующими потоками обновлений и устареваний делает их в 5 раз дороже, чем системных администраторов.
Но если я использую облачную архитектуру, мне не нужно делать обновления безопасности
Нет, нужно. Возможно, вам придется делать меньше, но те, которые вам не нужно делать, легко автоматизировать. Вы по-прежнему будете разделять боль аудита используемых вами библиотек и проверки безопасности всех ваших конфигураций.
Но если я использую облачную архитектуру, мне не нужно беспокоиться о том, что она выйдет из строя
Архитектуры «высокой доступности», которые вы получаете от использования облачных структур и микросервисов, почти компенсируют хрупкость, которую они добавляют из-за сложности. На этом этапе, если вы используете два разных облачных региона или двух облачных провайдеров, вы обычно можете предположить, что этого достаточно, чтобы избежать отключения вашего сервиса. Однако в прошлом у облачных провайдеров часто случались глобальные сбои, и нет оснований предполагать, что облачные центры обработки данных будут отключаться реже, чем ваши отдельные серверы.
Помните, что мы пытаемся предотвратить коррелированные сбои. Облачные центры обработки данных имеют множество частей, которые могут выйти из строя коррелированным образом. Хостинг-провайдеры имеют гораздо меньше этих частей. Точно так же сложные облачные службы, такие как управляемые базы данных, имеют больше режимов отказа, чем простые (VM).
Но я могу развиваться быстрее, если буду использовать облачную архитектуру
Тогда сделайте это, и просто следите за счетами и думайте, когда стоит переключиться. Это, пожалуй, самый сильный аргумент в пользу использования облачных конструкций. Однако, если вы не будете думать об этом по мере роста, вы, скорее всего, в конечном итоге сожжете много денег на своей облачной архитектуре тогда, когда давным-давно пора переключиться на что-то более скучное.
Моя рабочая нагрузка действительно взрывная
Переносите все в облако. Это отличная причина для использования таких вещей, как бессерверные вычисления. Одним из больших преимуществ конструкций облачной архитектуры является то, что они действительно хорошо масштабируются. Если ваша рабочая нагрузка проходит через длительные периоды бездействия, перемежающиеся большими непредсказуемыми всплесками активности, облачная архитектура, вероятно, подойдет вам очень хорошо.
Что насчет CDN?
Невозможно получить преимущества CDN, как в уменьшении задержки, так и в экономии пропускной способности, с одним большим сервером. Это также относится и к другим системам, которые необходимо распределять, например, к резервным копиям. К счастью, CDN и резервные копии являются конкурентными рынками и относительно дешевы. Это то, что нужно покупать, а не строить.
Заметка о микросервисах и монолитах
Мысль об «одном большом сервере» естественным образом совпадает с мыслью о монолитной архитектуре. Однако вам не нужно использовать монолит для использования одного сервера. Вы можете запускать множество контейнеров на одном большом сервере с одним микросервисом на каждый контейнер. Однако микросервисные архитектуры обычно добавляют системе много накладных расходов, что дает сомнительную выгоду, когда вы работаете на одном большом сервере.
Выводы
Когда вы сталкиваетесь с трудностями роста и приближаетесь к ограничениям своих текущих серверов, на сегодняшний день общепринятым мнением является использование сегментации и горизонтального масштабирования или использование облачной архитектуры, которая дает вам горизонтальное масштабирование «бесплатно». Часто проще и эффективнее масштабировать вертикально. Использование одного большого сервера сравнительно дешево, сводит ваши накладные расходы к минимуму и на самом деле имеет довольно хорошую историю доступности, если вы будете осторожны, чтобы предотвратить коррелированные аппаратные сбои. Это не гламурно и не поможет вашему резюме, но один большой сервер сослужит вам хорошую службу.