Требования к серверу SMS-шлюза: подбор от 1 до 200 сообщ./с

«Какой сервер мне нужен?» Этот вопрос первым задаёт почти каждый покупатель, и ответ на него скромнее, чем опасается большинство, и конкретнее, чем говорит большинство поставщиков. SMS-шлюз не кодирует видео. Его работа состоит в постановке в очередь, маршрутизации, биллинге и учёте, и растёт именно учёт. В этом руководстве приведены требования к серверу SMS-шлюза для каждого уровня трафика с реальными цифрами, объяснено, почему выделенные vCPU важнее количества ядер, и показано, как отчёты о доставке и архивы заполняют диск за год. В конце вы найдёте короткий список провайдеров и план резервного копирования, который должен быть у вас до запуска первого клиента.

Требования к серверу SMS-шлюза по уровням трафика

Сервер определяет число сообщений в секунду на пике, а не число сообщений в месяц. Клиент, который отправляет 1 000 000 сообщений, распределённых по месяцу, в среднем даёт 0,4 сообщ./с; тот же клиент, запустив в девять утра промоакцию на 200 000 номеров, требует 100 сообщ./с в течение получаса. Шлюз должен принять этот всплеск, передать его операторам так быстро, как они принимают трафик, а затем принять возвращающиеся отчёты о доставке, которые на пике приходят с той же скоростью, с какой шла отправка.

Таблица ниже повторяет подбор сервера, который мы публикуем на странице платформы, и соответствует тому, на чём работают наши собственные установки. Объёмы указаны за месяц, скорости указаны как устойчивые.

Устойчивый трафик	Объём в месяц	Сервер	Примечания
~1 сообщ./с	До ~1 000 000 SMS	4 vCPU, 8 ГБ RAM, SSD на 100 ГБ, всё на одном сервере	Здесь большинство реселлеров проводят свой первый год
~10 сообщ./с	От ~1 000 000 до 10 000 000	8 vCPU, от 16 до 32 ГБ RAM, SSD от 250 до 500 ГБ	Поисковый индекс и базу данных желательно разместить на отдельных дисках
~50 сообщ./с и выше	10 000 000 и более	16+ vCPU, от 32 до 64 ГБ RAM, быстрые NVMe, компоненты разнесены по узлам	Очередь, база данных, поиск и уровень SMPP получают каждый свои ресурсы

Две вещи в этой таблице обычно удивляют. Во-первых, насколько мал первый уровень: полноценная мультитенантная платформа с веб-консолью, SMPP-сервером, очередью, базой данных и поисковым индексом умещается на сервере с 4 vCPU, потому что при 1 сообщ./с ни один из компонентов не работает под нагрузкой. Во-вторых, переход на третий уровень связан не с процессором, а с вводом-выводом (I/O). При 50 сообщ./с база данных записывает строку сообщения, обновляет её, когда оператор подтверждает приём, обновляет ещё раз, когда приходит отчёт о доставке, и индексирует её для поиска. Три записи на сообщение при 50 сообщ./с дают 150 операций записи в секунду непрерывно, плюс чтение со всех открытых клиентских дашбордов. Это проблема диска, и именно поэтому NVMe и разнесённые узлы появляются в третьей строке, а не раньше.

Всплески трафика: начинаете с малого, но нужен запас

Есть распространённый промежуточный случай, который таблица не отражает. Вы начинаете с нуля, поэтому месячный объём у вас крошечный, но ваш первый клиент, сеть школ или интернет-магазин, отправляет всё одним утренним всплеском и ожидает доставки в течение нескольких минут. Вам нужен запас от 100 до 200 сообщ./с, пока устойчивый трафик ещё ниже 1 сообщ./с.

Решение: выделенный сервер на 4-8 vCPU с 32 ГБ RAM. У провайдеров из списка ниже он стоит от 50 до 100 $ в месяц. Он справляется со всплеском, потому что ядра принадлежат только вам, а объёма RAM хватает, чтобы держать очередь и рабочий набор данных в памяти, и служит вам до тех пор, пока устойчивый трафик, отчёты о доставке и формирование отчётности не начнут конкурировать за один и тот же диск. Именно тогда пора переходить на следующий уровень, и обычно это происходит после десятого клиента, а не после первого.

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

Выделенные или общие vCPU

Прайс-листы хостинг-провайдеров размывают важную границу. Сервер с общими ядрами «4 vCPU» даёт вам четыре доли процессорного времени на ядрах, которыми одновременно пользуются другие клиенты провайдера; выделенный сервер «4 vCPU» даёт четыре ядра, которые принадлежат только вам. Для сайта разница незаметна. Для SMS-шлюза это разница между промоакцией, доставленной за десять минут, и промоакцией, доставленной за сорок.

Причина в характере нагрузки. Веб-трафик ровный и прощает задержки: медленная секунда то тут, то там остаётся незамеченной. SMS-трафик идёт всплесками и хранит состояние (stateful). Во время всплеска уровень SMPP должен непрерывно загружать bind с операторами и вовремя отвечать на их контрольные сигналы (heartbeat), очередь должна разгружаться, а отчёты о доставке нужно сопоставлять с сообщениями, пока те ещё «горячие» в базе данных. Если в этот момент общее ядро занято соседом, bind подвисает, окно оператора заполняется, оператор ограничивает ваш трафик (throttling), а отчёты о доставке скапливаются позади отправок. Ничего не ломается, но всё, что вы обещали клиенту о скорости и отчётности, теперь запаздывает.

Практическое правило: общие vCPU для демонстрации и тестового сервера (staging), выделенные vCPU для всего, за что платит клиент. Разница в цене на первом уровне составляет от 20 до 40 $ в месяц, а это меньше, чем один час вашего времени, потраченный на объяснение клиенту, почему вчерашний отчёт до сих пор обновляется.

RAM: что на самом деле хранится в памяти

С памятью рассуждать проще. Постоянно в ней должны находиться три вещи: очередь (каждое сообщение, которое принято, но ещё не передано оператору, плюс каждый отчёт о доставке, ещё не сопоставленный с сообщением), рабочий набор базы данных (сообщения за последние несколько дней, тарифные сетки, клиентские аккаунты) и кэш поискового индекса. На первом уровне все три вместе умещаются в 8 ГБ, и ещё остаётся место для операционной системы и веб-консоли. На втором уровне рабочий набор растёт вместе с историей, и от 16 до 32 ГБ позволяют базе данных не обращаться к диску при формировании отчётов, которые клиенты открывают каждое утро.

На практике память заканчивается не из-за очереди, а из-за отчётности. Клиент, который запрашивает «все сообщения в эту страну за прошлый квартал» у базы данных, вынужденной читать их с диска, превращает двухсекундный запрос в двухминутный и замедляет работу всех остальных, пока запрос выполняется. Добавить RAM дешевле всего. Архивировать старые сообщения в документное хранилище, как это делает разнесённая архитектура третьего уровня, надёжнее в долгосрочной перспективе.

Диск: основной рост дают отчёты о доставке и архивы

Именно на диске происходит реальный рост, и именно его никто не рассчитывает. Каждое отправленное сообщение порождает как минимум три записи: само сообщение, отчёт о доставке от оператора и запись биллинга, по которой списана оплата с клиента. Добавьте индексы, которые ускоряют поиск и отчётность, и практическая цифра для планирования составит около 1 КБ на сообщение со всем перечисленным, до сжатия.

На первом уровне 1 000 000 сообщений в месяц дают примерно 1 ГБ прироста в месяц. SSD на 100 ГБ вмещает такой прирост за несколько лет. На втором уровне 10 000 000 сообщений в месяц дают 10 ГБ в месяц, или 120 ГБ в год, а поисковый индекс добавляет сверху ещё от 30 до 50%. Поэтому во второй строке указано от 250 до 500 ГБ, и поэтому поисковый индекс и базу данных «желательно» размещать на отдельных дисках: на общем диске они конкурируют за одну и ту же пропускную способность записи.

Два архитектурных решения не дают этому стать проблемой. Первое: уровень архива. Основная база данных хранит недавний период (скажем, 90 дней), а более старые сообщения переносятся в документное хранилище, где по ним по-прежнему можно искать, но они больше не замедляют транзакционные таблицы. Второе: политика хранения, которую вы определяете осознанно. Многие операторы хранят отчёты о доставке от 12 до 24 месяцев на случай споров и удаляют тексты сообщений раньше, а на некоторых рынках срок хранения регулируется, поэтому уточните правила для стран, куда вы отправляете трафик. Платформа со встроенным уровнем архива (так устроен стек Smppcube: MongoDB в роли архива рядом с MySQL в роли основной базы данных) превращает оба решения в настройку, а не в отдельный проект.

Сеть и порты

Пропускная способность канала ограничением не является: сообщение занимает несколько сотен байт. Важен стабильный публичный IP-адрес, потому что операторы обычно вносят IP-адрес вашего SMPP bind в белый список и не любят его менять. Также нужен открытый входящий порт 2775 (или выбранный вами порт), если ваши собственные клиенты будут подключаться к вашему SMPP-серверу. Кроме того, нужны HTTPS для консоли и HTTP API и исходящий доступ к SMPP- и HTTP-эндпоинтам операторов. Если вы работаете в DMZ или в изоляции от интернета (air-gap), шлюзу нужны только каналы к операторам и сеть консоли. Это одна из причин, по которым собственный сервер работает в регулируемых средах, где SaaS-панель даже не могут согласовать.

Короткий список провайдеров с ценами

Подойдёт любой провайдер, который продаёт выделенные vCPU, хранилище на SSD или NVMe и статический IP-адрес и позволяет открыть порт. Ниже те, которые мы встречаем чаще всего. Выделенный сервер на 4-8 vCPU и 32 ГБ, которого хватает для первого уровня с запасом на всплески и для процессора и памяти второго уровня, обычно стоит от 50 до 100 $ в месяц у любого из первых четырёх; третий уровень с NVMe и разнесёнными узлами везде рассчитывается по индивидуальному запросу.

Провайдер	Подходит для	Почему его выбирают
Hetzner	Европа	Тарифы с выделенными vCPU и выделенные серверы (bare metal) по низким ценам
Netcup	Европа	Выделенные ядра по низкой цене; мы сами работаем на Netcup
DigitalOcean	Регионы по всему миру	Простая консоль, предсказуемые цены, удобные снапшоты
OVHcloud	Европа, Северная Америка	Выделенные серверы (bare metal), когда виртуальных машин становится мало
Alibaba Cloud	Саудовская Аравия и страны Персидского залива	Дата-центр на территории Королевства для локального хранения данных
Собственное оборудование	Изоляция от интернета (air-gap) или регулируемые среды	Только плата за колокейшн; извне шлюзу не нужно ничего, кроме каналов к операторам

Строка «мы сами работаем на Netcup» появилась потому, что покупатели об этом спрашивают. Она говорит о том, что работает на первых двух уровнях, а не призывает игнорировать остальных провайдеров. Перед выбором сверьтесь с актуальными прайс-листами. Если ваши клиенты находятся в одной стране, провайдер с регионом в этой стране сокращает время обмена с операторами и, что важнее, хранит данные там, где этого ожидает регулятор.

Все расходы, честно

Подбор сервера имеет смысл только рядом с остальными расходами, и именно здесь модель на собственном сервере оправдывает своё название. Три статьи расходов, и только одна из них наша:

1. Лицензия, разовый платёж: 6 400 $ за платформу, все каналы, все возможности и первый год поддержки. Это вся страница цен в одной цифре.
2. Сервер, ежемесячно: от 50 до 100 $ на первых двух уровнях. Вы платите выбранному провайдеру в своём собственном аккаунте и можете переехать, когда захотите.
3. Ваш трафик у операторов по тарифам, которые вы сами согласуете со своим SMSC или агрегатором. Мы никогда не выступаем посредником.

Сравните это с арендованной панелью, где плата за платформу растёт вместе с вашим трафиком, а сервера не видно, потому что он принадлежит им. Статья «сервер» остаётся единственной, которую нельзя удешевить за счёт роста, и здесь она самая маленькая в списке.

Резервное копирование, мониторинг и прочая рутина

Сервер сам по себе не является планом. До запуска первого клиента должны существовать и быть проверены три вещи:

• Ночное резервное копирование, которое вы хотя бы раз проверили восстановлением. Дамп базы данных плюс каталог конфигурации, скопированные за пределы сервера (снапшот провайдера удобен, но снапшот в том же аккаунте, что и сервер, не защитит, если этот аккаунт заблокируют). Проверьте восстановление на тестовом сервере: резервная копия, которую никто не восстанавливал, остаётся лишь надеждой.
• Оповещения по диску и очереди. Достаточно двух порогов: диск заполнен более чем на 80%, и возраст очереди отчётов о доставке превышает 15 мин. Первое оповещение говорит, что пора архивировать или расширяться; второе сообщает о проблеме с bind оператора раньше, чем об этом скажет клиент.
• Тестовый сервер (staging). Самый дешёвый VPS с общими ядрами, какой вы найдёте, с той же версией платформы, на котором сначала проверяют обновления и новые тарифные сетки. Обходится он в символическую сумму в месяц, а ценность его заключается в каждом обновлении, которое не придётся откатывать на рабочем сервере, пока клиенты отправляют сообщения.

Когда всё это вам не нужно

Если вы отправляете несколько тысяч сообщений в месяц из одного приложения и у вас нет собственных клиентов, сервер для шлюза вам не нужен вовсе: HTTP API любого поставщика, вызываемый из вашего приложения, как раз подходит по масштабу. Подбор сервера в этом руководстве рассчитан на тех, кто продаёт услуги обмена сообщениями другим: реселлеров, агрегаторов, операторов или компанию, которая обеспечивает рассылки для множества внутренних команд. На этом этапе сервер оказывается самой недорогой частью бизнеса, а понимание того, на каком уровне вы находитесь и что переведёт вас на следующий, и составляет почти всё, что когда-либо означали «требования».