Вы явно не работали со всей этой гадостью, раз пишете такое...Вы правы в том и только в том, что если ни монолитное приложение не умеет в поддержку многопроцессорного железа, ни сервер приложений, нужно просто всё ограничить в рамках одной нума ноды. Теоретически вы абослютно правы, но на практике это ни разу не тривиальная задача.
По факту это сейчас достижимо на сервере приложений IIS или с контейнерами LXD, или у вас там Java EE/Jakarta EE экосистема. Остальные сервера приложений сами не способны на такие привязки от слова "совсем". Для микросервисных веб-приложений, их интерпретаторов и серверов это сложная задача. И даже если хайлоада нет, то вам все равно придется назначать границы, если вы этого не сделаете то работа приложений будет не определена и не стабильна.
Для дурацких серверов приложений можно сделать привязку средствами ОС сверху, но тогда теряется вообще всякий смысл пользоваться сервером приложений для разделения физических ресурсов. Весь сервер приложений тогда окажется на одной NUMA-ноде. А если есть N приложений, которые нужно разместить по M нодам NUMA, задача опять нетривиальна. Что тогда делать? Порождать несколько экземпляров серверов приложений. И вот чтобы удобно ими управлять это всё виртуализируют.
Получается так:
- Есть веб-приложение, обрабатывающее запросы, в доме, который построил Джек.
- Есть дурацкий сервер приложений, который порождает экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек.
- Есть виртуальная машина с одним узлом NUMA, в которой запущен сервер приложений, который порождает экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек.
- Есть гипервизор, который назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек.
- Есть инфраструктура виртуализации, которая предоставляет API для управления кластерами гипервизоров, которые назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек.
- Есть сервер оркестрации, который управляет несколькими инфраструктурами виртуализации (тест и прод), которые предоставляет API для управления кластерами гипервизоров, которые назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек.
Ну как? Тошнит? Это применяется для внутренних корпоративных продуктов какой-нибудь логичтической фирмы. Ничего особенного. И вот вся эта пресловутая контейнеризация призвана, якобы, упростить архитектуру крупных корпоративных веб-проектов. Однако, на 2023-й год она не способна выкинуть виртуализацию.
> Если ваше приложение больше 256 потоков успешно грузит, и вот никак не масштабируется горизонтально вообще, то очень плохо конечно.
Есть 2 типа приложений микросервисные и остальные.
Микросервисное приложение - это стетлесс сервис, который получает запрос и отдает ответ. Они функциональны в том смысле, что на если поступило два запроса, то приложение корректно ответит на оба вне зависимости от порядка обработки запросов. Состояния вынесены в сторадж подсистему, которая отделена от микросервиса. А еще микросервисное приложени не использует маршалинг. Каждый функциональный модуль, к которому хочет обратиться такое приложение оформлен в виде другого микросервисного приложения, а не разделяемой библиотеки/класса/ассембли, которая подгружается в общую кучу этого приложения.
Сама идея использования микросервисных приложений заключается в том, что есть:
1. Оркестрация серверов приложений
2. Сервера рабочих процессов управляют экземплярами приложений
3. Приложение "простое", желательно однопоточное, без стейтов на нем, работающее в режиме вопрос-ответ и общением с источником стейтфул-данных на бекенде (база, файловый сторадж, итд)
Микросервисные приложения не управляют своими ресурсами и своей многозадачностью. Это вынесено на сервер приложений, который за это отвечает. Другие "остальные" большие приложения по "256 потоков" - это монолитные приложения. И они ничем не хуже микросервисов. Просто они сами управляют своей многопоточностью, потенциально грузят внутрь себя другие куски кода и возможно держат на себе стейты так, что запрос 2 может быть обработан только после запроса 1 и только на том же самом экземпляре мнололитного приложения.
Собственно микросервисные приложения хорошо масштабируются, но тратят больше ресурсов на сопровождающую инфраструктуру и имеют издержки на сетевое нелокальное взаимодействие. Монолитные приложения в общем случае быстры, но развитие их кодовой базы проблематично, горизонтальное масштабирование, в общем случае, - нетривиальная задача, решение которой зависит от самого приложения. Диалектика шила и мыла.
При этом вопрос виртуализации не снимает ни один подход к написанию веб-приложений. Для микросервисных приложений, которые работают на железе, нужно чтобы _сервер приложений_, который порождает экземпляры (рабочие процессы) и перенаправляет на них поток запросов умел работать с железом и ОС. Для микросервисных приложений, которые работают на железе, нужно чтобы _само приложение_, умело работать с железом и ОС. Сервера приложений устроены так, что могут запускать и микросервисные приложения и монолитные. Просто контроль за ресурсами будет в разных местах. То есть в общем случае все сводится к одному к поддержке железа и ОС. И вот если оно (монолитное приложение или сервер микросервисных приложений) дурацкое, то вам нужны виртуалки, чтобы правильно решить задачу с размещением этого всего на NUMA.
Причем в реальности для "больших" монолитных веб-приложений, например, как вы пишете про "256 потоков", ситуация усугубляется тем, что их интерпретатор должен понимать железо, быть интегрирован в ОС, или это бинарное приложение на С, что по сути даст то же самое. Отсюда и появляется требование к inetd-архитектуре IIS, который предоставляет такую интеграцию средствами ОС. Или Java EE, которая построена на этих принципах, только не в рамках стандартных библиотек ОС, а средствами JVM.
Ваши "простые" теоретические решения запускать все в рамках нуманоды понятны и правильны. Я же просто описываю практическую сторону вопроса, развернуто отвечая на вопрос причем тут виртуализация.
Я могу дать лаконичный и краткий ответ: "либо используйте виртуализацию, либо ставьте нормальную ОС с нормальной реализацией UNIX Internet Daemon (Windows с IIS)", но такой ответ местной публике не понравится. Начнутся эмоции, ответ сочтут за троллинг, потому что многие тут не видели крупных веб-проектов и не понимают реальную проблематику их написания и дальнейшего сопровождения.
Есть 3 многообещающих продукта, которые в перспективе следующих 10 лет способны потеснить гегемонию IIS на поприще высоконагруженных внутрикорпоративных порталов:
- NGINX Unit, если они начнут наконец работать с железом. Снйчас оно очередное "дурацкое".
- LXD, если у него появится инфраструктура, но судя по новости там форк на форке и запираемся в каноникал.
- Потуги Red Hat вокруг Barebone OpenShift.
