SMS-шлюз на собственном сервере: что для этого нужно на самом деле

SMS-шлюз на собственном сервере относится к тем вещам, которые снаружи выглядят просто, а своё настоящее устройство показывают в неделю запуска. Отправить одно сообщение легко. Настоящая работа в другом: надёжно отправлять миллионы, правильно тарифицировать каждое, подтверждать доставку и обходиться при этом без сбоев ночью. В этом руководстве архитектура разобрана простыми словами, приведены честные цифры по оборудованию, отмечена граница, где заканчивается бесплатное ПО, и описана эксплуатация, за которую вы отвечаете с того момента, как трафик становится реальным. Задача руководства в том, чтобы помочь вам принять осознанное решение: разрабатывать, покупать или ещё какое-то время продолжать арендовать.

Что такое SMS-шлюз на собственном сервере

Если заглянуть за дашборды, шлюз устроен как небольшой конвейер из четырёх участков. Трафик приходит, встаёт в очередь, отправляется и учитывается. Понимание этих четырёх участков составляет большую часть дела.

Приём (ingress) определяет, как сообщения поступают в систему. Бизнес-клиенты отправляют их через HTTP API, потому что это удобно, через веб-панель для разовых рассылок или через SMPP-подключение (bind), когда сами являются другой платформой с большим объёмом. SMPP представляет собой родной протокол телеком-отрасли: постоянное TCP-соединение, которое проходит аутентификацию один раз, после чего сообщения идут по нему потоком в виде двоичных пакетов. Хорошо настроенный SMPP-клиент может отправлять десятки тысяч сообщений в секунду, и именно поэтому серьёзные отправители выбирают его, а не HTTP.

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

Транспортный шлюз (bearer) и есть та часть, которая действительно общается с операторами. В большинстве стеков на собственном сервере эту роль играет Kannel: его BearerBox держит постоянные SMPP-подключения к каждому SMSC (центру сообщений оператора), поддерживает их активными, переподключается при обрывах и распределяет трафик между сессиями. Вспомогательный процесс читает очередь ожидающих сообщений и передаёт их транспортному шлюзу; другой обрабатывает отчёты о доставке и входящие сообщения, которые приходят обратно. Этому уровню не одно десятилетие, он исключительно надёжен, и опираться на него не стыдно.

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

Подбор сервера: что на самом деле нужно для 1, 10 и 50 сообщений в секунду

Первая ошибка при подборе сервера состоит в том, чтобы мыслить месячными объёмами. SMS-трафик идёт всплесками: распродажа у ритейлера или ночное формирование выписок в банке прогоняет месячный объём за час. Сервер нагружают устойчивая пиковая пропускная способность, объём возвращающихся отчётов о доставке (часто событий столько же, сколько отправленных сообщений) и нагрузка на отчёты и поиск, которую создают ваши клиенты. Рассчитывайте на пик, а не на среднее значение.

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

Устойчивая пропускная способность	Примерный объём в месяц	Стартовая конфигурация (один узел)	Что обычно подводит первым
~1 сообщ./с	До ~1 000 000	4 vCPU, 8 ГБ RAM, SSD на 100 ГБ, все компоненты вместе	Диск заполняется логами и DLR
~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, компоненты разнесены по узлам	Пределы одного узла: пора переходить на Active-Active

Два практических замечания. Во-первых, пропускная способность к любому отдельному оператору обычно ограничена числом SMPP-сессий, которое разрешает оператор, а не вашим оборудованием; если маршрут работает медленно, а сервер простаивает, вам, скорее всего, нужно больше сессий (до максимума, который допускает оператор), а не более мощный сервер. Во-вторых, как только платформа становится критичной для бизнеса, прекратите наращивать один сервер и переходите на топологию высокой доступности с компонентами на выделенных узлах. Задокументированные базовые показатели, снятые с вашей собственной установки, ценнее любой типовой таблицы, потому что «норма» определяется относительно вашего оборудования и вашего трафика.

Что даёт открытое ПО и где оно заканчивается

Мир открытого ПО для SMS действительно хорош, и, делая вид, что это не так, вы только теряете деньги. Kannel и Jasmin обеспечат терминацию SMPP, будут держать подключения к операторам и передавать огромные объёмы по цене сервера. Если вам нужен просто канал между одной системой и одним оператором, они часто оказываются правильным ответом, и переплачивать не стоит.

Заканчиваются они на бизнес-уровне, и этот пробел шире, чем кажется. Из коробки у вас вообще нет графической панели администратора, поэтому каждый маршрут, тариф и пользователь задаётся в конфигурационном файле. Нет мультитенантных клиентских аккаунтов, а значит, нет изоляции, балансов и тарифов по клиентам. Нет биллинга, выставления счетов и контроля баланса. Нет клиентских порталов white-label, понятных отчётов о доставке, которые просят клиенты, механизма обработки отписок (opt-out) и того, кому можно позвонить, когда подключение падает в полночь. Всё это не критика инструментов: они созданы как транспортный шлюз, а не как продукт. Это лишь значит, что превратить транспортный шлюз в бизнес означает запустить программный проект, и оценить его стоимость нужно честно, прежде чем начинать. Реальной цене «бесплатного» посвящено отдельное сравнение.

Эксплуатация, о которой никто не предупреждает

Запуск означает начало работы, а не её конец. Четыре эксплуатационные реалии определят, станет ваш шлюз бизнесом или постоянной головной болью.

Отчёты о доставке (DLR) подтверждают, что сообщение дошло, и без них не обойтись. Оператор возвращает отчёт со статусом «доставлено», «ошибка» или «срок истёк», и ваша платформа должна сопоставить его с исходным сообщением, обновить отчёт клиента и принять решение по списанию. При временной ошибке (телефон выключен, перегрузка сети) сообщение ещё может быть доставлено в пределах срока действия, и деньги за него не следует возвращать преждевременно; при окончательной ошибке (неверный номер, блокировка) сообщение не будет доставлено никогда, и деньги нужно вернуть. Ошибившись в этой классификации, вы либо теряете деньги на возвратах, которых не следовало делать, либо раздражаете клиентов, списывая оплату за сообщения, которые так и не дошли.

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

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

Резервное копирование легко отложить, и об этом вы пожалеете больше всего. Вашей основной базе данных, списку клиентов, балансам и персистентности очереди нужна резервная копия, которую вы действительно проверили восстановлением, а не просто поставили в расписание. Проверьте её один раз до появления клиентов, потому что день, когда она понадобится, будет худшим днём, чтобы узнать, что она никогда не работала.

Разработать или купить: честный ответ

Вот развилка, без рекламных обещаний. Если у вас есть время инженеров, вам нравится владеть стеком, а сам канал передачи сообщений и есть ваш продукт, разработка на основе открытого ПО вполне законна и дёшева с точки зрения лицензий. Эту экономию вы потратите на месяцы разработки биллинга, мультитенантности, порталов и отчётности и на их бессрочное сопровождение, но для некоторых команд именно такой обмен и будет правильным.

Если же вы хотите продавать сообщения клиентам уже в этом квартале, покупка платформы, которая полностью принадлежит вам, обычно выгоднее по расчёту. Платформа с разовой лицензией, такая как Smppcube, поставляет весь бизнес-уровень, то есть мультитенантные аккаунты, биллинг, порталы и отчётность, поверх того же проверенного транспортного шлюза и работает на вашем собственном сервере, поэтому вы сохраняете изоляцию от интернета (air-gap) или размещение в DMZ, ради которых собственный сервер часто и выбирают. Вы платите за лицензию и взамен получаете от шести до двенадцати месяцев, которые не тратите на разработку ПО, не отличающего вас от конкурентов.

Честная проверка проста: является ли написание ПО для шлюза вашим бизнесом или отвлекает от него? Ответьте на этот вопрос первым, и архитектура, подбор сервера и эксплуатация, описанные выше, станут чек-листом, а не неожиданностью. Начните со своей цифры пиковой пропускной способности и ясного понимания, кому вы продаёте, и остальное решение сложится само.