Каковы проблемы масштабируемости с pub/sub серверами?

Я изучаю настройку службы публикации/подписки с помощью веб-сокетов. Из того, что я могу сказать, узкие места масштабируемости будут в основном связаны с памятью, которая влияет на то, сколько сокетов может быть открыто одновременно, поэтому я считаю разумным отделить это от других серверов, на которых работают такие службы, как API. Это правильно? Я полагаю, что память стоит дороже, чем вычислительная мощность, когда речь идет о хостинге, поэтому есть ли какие-либо рекомендации по оптимизации этого типа сервера для масштабируемости и стоимости?

Цель состоит в том, чтобы предоставить пользователю этого веб-приложения обновления в режиме реального времени, поскольку системы в полевых условиях проверяют новые данные без необходимости периодически опрашивать серверную часть. Но мы не хотим удваивать затраты на сервер, иначе оно того не стоит. Мы используем AWS EC2 с балансировкой нагрузки и автоматическим масштабированием для наших текущих серверов API.

Фактическое использование памяти одним сокетом не так уж много.

Что съедает память, так это состояние, связанное с тем, какой клиент в каких обновлениях заинтересован, и какой клиент уже получил конкретное обновление.

В примитивной реализации (т. е. с использованием сетевого стека ОС) последнее состояние сохраняется в виде исходящих буферов, поэтому, если обновление отправляется 10 000 клиентам, данные копируются 10 000 раз, причем каждая копия добавляется к исходящая очередь, где она дополняется необходимыми заголовками (которые содержат состояние каждого соединения), а затем для аппаратного обеспечения создается дескриптор, предписывающий отправить пакет, представляющий собой конкатенацию заголовков и полезной нагрузки.

Копия полезной нагрузки для каждого клиента хранится в памяти до тех пор, пока она не будет подтверждена клиентом, и отсюда возникают требования к памяти. Эта память не может быть выгружена, поэтому она создает нагрузку на память и кэш-память других приложений.

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

Варианты, которые у вас есть

1. запустить службу публикации/подписки на том же сервере, что и приложение
2. запустить службу публикации/подписки на выделенном сервере с сетевой ОС
3. запустить службу публикации/подписки на выделенном сервере с настраиваемой сетью
4. запустить службу публикации/подписки на нескольких выделенных серверах

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

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

тл;др: не нужно преждевременно оптимизировать. Разделите службу, чтобы первым шагом масштабирования было простое изменение конфигурации, и начните оптимизацию, как только это произойдет.