![[Перевод] Один большой сервер на хозяйстве](https://habrastorage.org/webt/1l/wu/xi/1lwuxidwheogffbesojdkvgmwb4.jpeg "[Перевод] Один большой сервер на хозяйстве")
Много копий сломано в спорах за монолиты и микросервисы. Но реальная дилемма состоит в том, стоит ли разработчику тратить время на распределённую архитектуру?
Все хорошо знают, что такое виртуализация. Это слой абстракции между нашим ПО и всеми серверами, на которых оно работает. Сегодня бессерверные вычисления везде. И даже «выделенный сервер» стал типом виртуальной машины. Однако любой софт работает на настоящем железе. А в эпоху виртуализации это железо стало гораздо мощнее и дешевле, чем вы думаете, говорит автор этой статьи.
На КДПВ — фотография сервера на процессорах AMD в дата-центре Microsoft Azure. Большое металлическое крепление слева (с медными трубками) — радиатор. От него идут медные трубки к теплообменникам на каждом CPU. Это серверные процессоры AMD третьего поколения, у каждого следующие характеристики:
- 64 ядра
- 128 потоков
- тактовая частота ~2–2,5 ГГц
- ядра выполняют 4–6 инструкций за такт
- 256 МБ кэша L3
В сумме на этом сервере 128 ядер с 256-ю параллельными потоками. При совместной работе всех ядер сервер выдаёт пиковую производительность вычислений двойной точности в 4 TFLOPS. В начале 2000 года он занял бы первое место в списке мощнейших суперкомпьютеров мира Top500 и держался бы в рейтинге до 2007 года. Каждое ядро значительно мощнее, чем любой одноядерный процессор десятилетней давности, и у него гораздо более широкий вычислительный конвейер.
Сверху и снизу от каждого процессора установлена память: по 8 слотов оперативной памяти DDR4-3200 на сокет. Максимальный объём «экономически эффективных» модулей DIMM сегодня составляет 64 ГБ. При «экономическом» наполнении сервер вместит 16*64 ГБ=1 ТБ памяти. Если же наполнить его специализированными модулями DIMM большой ёмкости (которые обычно медленнее), то сервер вместит до 8 ТБ. В стандарте DDR4-3200 с 16 каналами памяти этот сервер, вероятно, обеспечит пропускную способность памяти ~200 Гбит/с для всех своих ядер.
Что касается ввода-вывода, то каждый CPU предлагает 64 полосы PCIe gen 4. При общем количестве 128 линий PCIe сервер способен поддержать 30 твердотельных накопителей NVMe плюс сетевую карту. Типичные конфигурации в продаже предлагают слоты примерно для 16 SSD или дисков. Последняя важная деталь на этой фотографии — сетевая карта в правом верхнем углу. Скорее всего, этот сервер подключён к сети на скорости 50–100 Гбит/с.
Возможности такого сервера
Вот на что способен один такой сервер:
- Раздача видеофайлов на скорости 400 Гбит/с (поправка: уже 800 Гбит/с)
- 1 миллион IOPS на базе NoSQL
- 70 тыс. IOPS в PostgreSQL
- Полмиллиона запросов в секунду на nginx
- Компиляция ядра Linux за 20 секунд
- Рендеринг 4k видео кодеком x264 на 75 FPS
Это кроме всего прочего. В наши дни есть куча публичных бенчмарков, так что можно заранее прикинуть производительность своей службы, если найти похожий бенчмарк.
Стоимость такого сервера
У крупного хостера вроде OVHCloud можно арендовать сервер HGR-HCI-6 со 128 ядрами (256 потоков), 512 ГБ памяти и пропускной способностью 50 Гбит/с за $1318 в месяц.
У популярного бюджетного хостера Hetzner можно взять сервер с 32 ядрами и 128 ГБ оперативной памяти примерно за €140 в месяц. Это гораздо меньший сервер (четверть размера), но он даёт некоторое представление о разбросе цен между хостинг-провайдерами.
В AWS один из самых больших инстансов/серверов в аренду будет m6a.metal. Это 50 Гбит/с пропускной способности сети, 192 vCPU (96 физических ядер) и 768 ГБ памяти. Его стоимость $8,2944/час в Восточном регионе США. Это примерно $6055 в месяц. Наценка за облако имеет место быть!
Аналогичный сервер со 128 физическими ядрами и 512 ГБ памяти (а также соответствующими сетевыми картами, SSD и контрактами на поддержку) можно купить на сайте Dell примерно за $40 000. Но понятно, что на таком уровне цен можно пообщаться с продавцом и выбить скидку. Также придётся заплатить за размещение сервера и подключение к сети.
Если посчитать, то собственный сервер окупается за 8 месяцев по сравнению с облачными сервисами и за 30 месяцев по сравнению с арендой. Конечно, у каждого варианта свои плюсы и минусы. Однако содержание своего сервера — весьма хлопотное дело, как и аренда. Вопрос в том, насколько оправдана «наценка за облако» и окупится ли она (спойлер: «да, но не такая большая, как хотят облачные компании»).
Размышления об облаке
«Облачная эпоха» началась примерно в 2010 году. Самыми современными тогда были «Зионы» на архитектуре Nehalem с недавним изобретением — гиперпоточностью (у самой мощной серверной серии Xeon 6500/7500 (Beckton) было 8 ядер и 16 потоков).
Аппаратное ускорение шифрования AES ещё не появилось, а процессор оперировал векторными инструкциями размером всего 128 бит. Самые большие процессоры оснащались 24 МБ кэша, так что на сервер можно было поставить максимум 256 ГБ памяти DDR3-1066. Для хранения данных компания Seagate выпустила самый мощный жёсткий диск на 3 ТБ. Каждое ядро выдавало 4 FLOPS за цикл, то есть 8-ядерный сервер на частоте 2,5 ГГц обеспечивал максимум 80 GFLOPS.
Бум распределённых вычислений стартовал из рациональной мысли — чтобы кратно увеличить пропускную способность хранилища, нужно параллельно включить в работу множество накопителей. Та же схема действует в отношении многопоточных вычислений на большом количестве CPU.
С тех пор размер серверов значительно увеличился, а SSD ускорили операции ввода-вывода в сто раз, но размер стандартных VM и контейнеров практически не изменился. Мы по-прежнему используем виртуализированные диски, которые больше похожи на HDD, чем на SSD (хотя определённый прогресс есть).
Обычно хватает одного сервера (плюс бэкап)
Если мы не занимаемся обработкой потокового видео, а система обрабатывает менее 10 тыс. запросов в секунду, то одного сервера вполне достаточно для большинства приложений. В действительно простых приложениях он вообще обеспечит до миллиона QPS. Очень немногие веб-сервисы получают такой большой трафик. Если у вас есть такая служба, вы знаете, какая это редкость. Даже при обработке видеопотоков вполне разумно установить один управляющий сервер, чтобы оценить общий масштаб нагрузки. Для примерной оценки можно использовать таблицы с бенчмарками типичных задач.
Лучше ввысь, чем вширь
Если одного сервера недостаточно и нам нужен серверный кластер, то несколько больших серверов зачастую лучше, чем много маленьких. Координация кластера требует ненулевых накладных расходов, и этот оверхед зачастую рассчитывается как O(n) от количества серверов. Чтобы уменьшить накладные расходы, лучше использовать несколько больших серверов, чем много маленьких.
Если у нас бессерверные вычисления с крошечными короткоживущими контейнерами, то накладные расходы составляют большую часть стоимости использования. С другой стороны, координация кластера из одного компьютера — тривиальная задача.
Большие серверы и даунтайм
Главный недостаток одного большого сервера — нехватка должной избыточности и надёжности. Сервер может уходить в даун, может ломаться. Обычно рекомендуют ставить основной и резервный сервер в разных дата-центрах. Конфигурация 2×2 должна успокоить истинных параноиков: два сервера в основном ЦОДе (или у облачного провайдера) и два сервера в резервном. Если хочется поднять третий узел, его можно сделать меньше двух основных.
Но всегда есть риск одновременных аппаратных сбоев. Известно, что HDD и SSD нередко выходят из строя одновременно, особенно если они из одной партии. Недавно администраторы Hacker News убедились в этом на собственном опыте, когда основной и резервный серверы вышли из строя одновременно. Опытные сисадмины таких сервисов, как Backblaze, закупают много разных моделей накопителей от разных производителей, не допуская гомогенной среды.
Если ваш хостер предоставляет в аренду готовые серверы, разумно арендовать разные типы серверов и в основном ЦОДе, и в резервной локации. Это защитит от разных видов скоррелированных сбоев.
Используем облако, но без фанатизма
Сочетание высокой надёжности и простоты в использовании — одна из главных причин, почему инженерам нравятся облачные сервисы. Да, вы платите значительную премию за аренду, но у провайдера такой большой опыт поддержки серверов, что большинство проблем даунтайма вас вообще не затронет, а в случае редкого сбоя можно быстро восстановить работоспособность, арендовав новую машину из их почти безграничного вычислительного пула. Такова их работа — следить, чтобы у вас не было простоев. Пусть и не всегда идеально, но они неплохо справляются со своим делом, это нужно признать.
Аренда сервера у хостинг-провайдера — более дешёвая альтернатива облачным сервисам, но качество их услуг не всегда на высоте. Бывает, что они не обеспечивают защиту от корреляции аппаратных сбоев или не умеют автоматически настраивать сеть (provisioning). Кроме того, переехать с одного выделенного сервера на другой (более крупный) гораздо труднее, чем просто изменить размер инстанса VM. Облачные службы неспроста берут премию к цене.
Но проблема в том, что облачные маркетологи настойчиво пытаются продать нам «нативную облачную архитектуру». Это такие вещи, как микросервисы в группах виртуальных машин с автоматическим масштабированием и легионами балансировщиков нагрузки. А также разные специфические продукты, с помощью которых нас привязывают к вендору. Это могут быть бессерверные вычисления и управляемые БД высокой доступности. Есть веская причина, по которой продавцы облачных решений продвигают свою «облачную архитектуру» — это выгодно им!
Принято считать, что облачная архитектура — это хорошо, она позволяет легко масштабироваться. Действительно, есть веские причины для использования облачной архитектуры. Но работа под высокой нагрузкой» не является такой причиной. В большинстве случаев для обслуживания миллиона одновременных посетителей достаточно единственного сервера. И никто не выставит вам пятизначный счёт.
Зачем платить за пиковую нагрузку?
Один из распространённых аргументов против одного сервера-монолита состоит в том, что основную часть времени он простаивает, раскручиваясь на полную мощность только в моменты пиковой нагрузки. Поскольку мы изначально резервируем избыточные мощности, то как бы постоянно оплачиваем эту гипотетическую пиковую нагрузку вместо того, чтобы платить по мере использования, в то время как бессерверные вычисления и VM с микросервисами точнее соответствуют нашим расходам и прибыли.
Но поскольку все сервисы работают на серверах (хотите вы этого или нет), кто-то в этой цепочке всё равно выставляет тариф в зависимости от своей пиковой нагрузки. Часть «облачной премии» за балансировщики нагрузки, бессерверные вычисления и небольшие VM основана на том, сколько дополнительных мощностей необходимо создать вашему облачному провайдеру, чтобы справиться с пиковой нагрузкой. Мы в любом случае платим за чью-то пиковую нагрузку!
Это означает, что если нагрузка крайне неравномерная — например, нужно прогнать симуляцию один раз, а после этого мы никогда её не запустим — тогда да, лучше обратиться к облачным решениям. Но если изменения нагрузки более регулярные, то зачастую несколько больших серверов обойдутся дешевле (и проще в настройке). Если нагрузка у облачного провайдера более скачкообразная, чем у вас, вы платите ему облачную премию ни за что. То есть за наш счёт он решает свои проблемы.
Эта премия относится не только к облачным сервисам, но и к VM. Хотя если использовать облачную виртуальную машину в режиме 24/7, то можно избежать «премии за пиковую нагрузку» через годичные контракты или персональные скидки, если вы достаточно крупный клиент.
В целом, чем больше пиков в нагрузке, тем более облачной должна быть архитектура.
Облако выливается в копеечку
Облачная архитектура — это дорого. Как правило, можно ожидать увеличения расходов в 5–30 раз в зависимости от того, какие услуги вы заказываете у облачной компании и от базового уровня. Не 5–30%, а от пяти до тридцати раз.
Вот цены на лямбду AWS: $0,20 за миллион запросов плюс $0,0000166667 за ГБ-секунду оперативной памяти. Здесь цены для x86, чтобы сравнить с вышеупомянутым инстансом m6a.metal. Большие ARM-серверы, как и бессерверные вычисления ARM, стоят дешевле.
Предположим, что сервер стоит $8,2944 в час и обрабатывает 1000 QPS с 768 ГБ оперативной памяти:
- 1000 QPS — это 60 тыс. запросов в минуту или 3,6 млн запросов в час
- Каждый запрос получает 0,768 ГБ-секунд оперативной памяти (амортизировано)
- Такой объём облачных вычислений обойдётся примерно в $46/час
Премия за бессерверные вычисления по сравнению с серверным инстансом составляет 5,5 раз. Если вы сможете поддерживать загрузку сервера на уровне более 20%, то он дешевле, чем использование бессерверных вычислений. И это мы ещё не начали экономить. А ведь если арендовать серверы на спотовом рынке или по годичному контракту, то будет ещё дешевле.
По сравнению с арендой того же сервера у хостинг-провайдера вычисления AWS Lambda выходят примерно в 25 раз дороже.
Таким образом, хостинг-провайдер получается выгоднее облачного сервиса, если мы можем поддерживать работу сервера на 5% мощности!
Также обратите внимание, что фактическое число QPS не имеет значения: если сервер стоимостью $8,2944 в час способен обработать 100 тыс. QPS, то запрос использует в 100 раз меньше памяти, то есть мы получаем ту же 5,5-кратную (или 25-кратную) премию. Конечно, следует масштабировать размер сервера в соответствии с приложением.
Типичные возражения против сервера
Некоторые выступают против архитектуры с одним большим сервером. У них могут быть законные опасения насчёт этой архитектуры. Или они просто считают облачную архитектуру более модной, или им с ней удобнее работать. В любом случае, большинство людей сильно недооценивают, в какую цену на самом деле выливается «облачная архитектура» по сравнению с базовыми вычислениями.
Для облака мне не нужно нанимать сисадминов!
Да, это так. Просто они теперь называются Cloud Ops и находятся под руководством другого менеджера. Они должны разбираться в заумной документации от облачных компаний и следить за всеми потоками обновлений и закрытий служб, поэтому зарабатывают в пять раз больше сисадминов.
В облаке не нужно накатывать обновления безопасности!
Да, это так. Возможно, придётся меньше их накатывать, хотя большинство рутинных операций легко автоматизировать. Но вам придётся инспектировать используемые библиотеки и отвечать за безопасность всех своих конфигураций.
В облаке не нужно беспокоиться о даунтайме!
Тут интересный момент. Архитектура с микросервисами за счёт дублирования почти компенсирует ту хрупкость, которую вносит из-за своей сложности. Сегодня если использовать двух облачных провайдеров или два разных региона, то это достаточно надёжная защита от сбоев. Но в прошлом у облачных провайдеров часто случались глобальные сбои. И нет причин полагать, что облачные ЦОДы будут падать реже, чем ваши отдельные серверы.
Помните, что мы пытаемся предотвратить корреляционные сбои. В облачных дата-центрах много элементов, которые могут выходить из строя скоррелированно. У хостеров таких элементов гораздо меньше. Аналогично, в сложных облачных сервисах типа управляемых БД больше режимов отказа, чем в простых сервисах (виртуальные машины).
С облачной архитектурой у меня ускорится разработка!
Пожалуй, это самый сильный аргумент в пользу использования облачных сервисов. В таком случае просто используйте облако и следите за счетами, чтобы успеть переключиться обратно в случае необходимости. Если не следить за балансом, можно очень быстро влететь на большие деньги.
Наша рабочая нагрузка сильно скачет!
Вот тогда добро пожаловать в облако. Значительные всплески активности — отличная причина использовать бессерверные вычисления и другие облачные технологии. Одно из главных преимуществ облачных архитектурных конструкций заключается в том, что они очень хорошо масштабируются. Если длительные периоды простоя сменяются мощными непредсказуемыми всплесками, то облачная архитектура подходит как нельзя лучше.
Что насчёт CDN?
Один большой сервер никогда не обеспечит вам преимущества CDN, как по уменьшению пинга, так и в экономии трафика. Это справедливо и для других распределённых систем, например, резервного копирования. К счастью, на рынках CDN и резервного копирования высокая конкуренция и они относительно дёшевы. Такие штуки лучше покупать, а не строить самому.
Заметка о микросервисах и монолитах
Мысли об «одном большом сервере» естественным образом ассоциируются с монолитными архитектурами. Но это не связанные вещи. На одном большом сервере можно запустить и кучу контейнеров, по одному микросервису на контейнер. Однако микросервисные архитектуры в целом добавляют много накладных расходов в систему на одном сервере, а выгода сомнительна.
Выводы
Когда вы растёте и приближаетесь к пределу возможностей текущих серверов, традиционная мудрость современных специалистов — перейти на шардинг, горизонтальное масштабирование или облачную архитектуру, где горизонтальное масштабирование вс⌘троено изначально. Но зачастую проще и эффективнее провести вертикальное масштабирование.
Один большой сервер обходится относительно дёшево. Накладные расходы сводятся к минимуму, а надёжность на самом деле вполне достойная, если обеспечить резервирование и предотвратить корреляционные аппаратные сбои. Это не очень гламурно и не украсит ваше резюме, но один большой сервер достойно вам послужит.
