Requisiti del server per un gateway SMS: da 1 a 200 msg/s

“Di quale server ho bisogno?” è la prima domanda che pone quasi ogni acquirente, e la risposta è più piccola di quanto molti temano e più precisa di quanto dicano molti fornitori. Un gateway SMS non è un codificatore video. Il suo lavoro è mettere in coda, instradare, fatturare e tenere la contabilità, ed è la contabilità a crescere. Questa guida Le presenta i requisiti del server per un gateway SMS a ogni fascia di traffico, con numeri reali, spiega perché le vCPU dedicate contano più del numero di core, mostra che cosa fanno al Suo disco in un anno le ricevute di consegna e gli archivi, e si chiude con una rosa di provider e il piano di backup da avere pronto prima che il primo cliente vada in produzione.

Requisiti del server per un gateway SMS, fascia per fascia

Il numero che decide il Suo server sono i messaggi al secondo nel momento di picco, non i messaggi al mese. Un cliente che invia 1.000.000 di messaggi distribuiti su un mese ha una media di 0,4 msg/s; lo stesso cliente che lancia una promozione verso 200.000 numeri alle nove del mattino ha bisogno di 100 msg/s per mezz’ora. Il gateway deve assorbire quella raffica, passarla agli operatori alla velocità con cui la accettano e poi raccogliere le ricevute di consegna che tornano indietro, che nel picco arrivano allo stesso ritmo degli invii.

La tabella qui sotto è il dimensionamento che pubblichiamo nella pagina della piattaforma, e corrisponde a ciò su cui girano le nostre stesse installazioni. I volumi sono mensili, i ritmi sono sostenuti.

Traffico sostenuto	Volume mensile	Server	Note
~1 msg/s	Fino a ~1.000.000 SMS	4 vCPU, 8 GB di RAM, SSD da 100 GB, tutto su una sola macchina	La maggior parte dei rivenditori resta qui per il primo anno
~10 msg/s	Da ~1.000.000 a 10.000.000	8 vCPU, da 16 a 32 GB di RAM, SSD da 250 a 500 GB	Indice di ricerca e database idealmente su dischi propri
~50 msg/s e oltre	10.000.000 e oltre	16+ vCPU, da 32 a 64 GB di RAM, NVMe veloce, componenti distribuiti su più nodi	Coda, database, ricerca e livello SMPP hanno ciascuno il proprio spazio

Due aspetti di questa tabella sorprendono. Primo, quanto è piccola la prima fascia: una piattaforma multi-tenant completa, con console web, server SMPP, coda, database e indice di ricerca, sta su una macchina da 4 vCPU, perché a 1 msg/s nessuno di questi componenti è sotto pressione. Secondo, il salto alla terza fascia non riguarda la CPU. Riguarda l’I/O: a 50 msg/s il database scrive la riga del messaggio, la aggiorna quando l’operatore conferma la ricezione, la aggiorna di nuovo quando arriva la ricevuta e la indicizza per la ricerca. Tre scritture per messaggio a 50 msg/s fanno 150 scritture al secondo, in modo sostenuto, più le letture di ogni dashboard cliente aperta. È un problema di disco, ed è per questo che NVMe e nodi separati compaiono nella terza riga e non prima.

La questione delle raffiche: partire in piccolo, ma con margine

C’è un caso intermedio frequente che la tabella non coglie: Lei parte da zero, quindi il Suo volume mensile è minimo, ma il Suo primo cliente è una catena di scuole o un negozio online che invia tutto in un’unica raffica al mattino e si aspetta che i messaggi arrivino nel giro di pochi minuti. Le servono da 100 a 200 msg/s di margine mentre il Suo ritmo sostenuto è ancora sotto 1 msg/s.

La risposta è un server dedicato da 4 a 8 vCPU con 32 GB di RAM. Costa da 50 a 100 USD al mese presso i provider elencati più avanti, regge la raffica perché i core sono Suoi e la RAM tiene in memoria la coda e i dati di lavoro, e La accompagna finché volume sostenuto, ricevute di consegna e reportistica non iniziano a contendersi lo stesso disco. Quello è il momento di salire di fascia, e di solito arriva dopo il decimo cliente, non dopo il primo.

L’errore da principianti più costoso in questo settore è acquistare la terza fascia il primo giorno perché un foglio di calcolo prevedeva 50 clienti. Acquisti la prima fascia pronta per le raffiche, tenga d’occhio il disco e la coda delle ricevute, e passi alla fascia successiva quando lo indicano i grafici.

vCPU dedicate o condivise

I listini dei servizi di hosting rendono sfumata una distinzione importante. Un’istanza condivisa da “4 vCPU” Le dà quattro porzioni di tempo su core usati anche da altri tenant; un’istanza dedicata da “4 vCPU” Le dà quattro core che sono Suoi. Per un sito web la differenza è invisibile. Per un gateway SMS è la differenza tra una promozione che arriva in dieci minuti e una che arriva in quaranta.

Il motivo è la forma del carico. Il traffico web è regolare e tollerante; un secondo lento qua e là non si nota. Il traffico SMS è a raffiche e con stato: durante una raffica il livello SMPP deve tenere alimentati i bind con gli operatori e rispondere in tempo ai loro heartbeat, la coda deve svuotarsi e le ricevute devono essere abbinate ai messaggi finché questi sono ancora in memoria nel database. Se in quel momento un core condiviso è occupato da un vicino, il bind si blocca, la finestra dell’operatore si riempie, l’operatore La rallenta con il throttling e le Sue ricevute si accumulano dietro gli invii. Nulla si rompe, ma tutto ciò che ha promesso al cliente su velocità e reportistica ora è in ritardo.

Regola pratica: vCPU condivise per la demo e per il server di staging, vCPU dedicate per tutto ciò che un cliente paga. Nella prima fascia la differenza di prezzo va da 20 a 40 USD al mese, meno di un’ora del Suo tempo passata a spiegare a un cliente perché il report di ieri si sta ancora aggiornando.

RAM: che cosa resta davvero in memoria

Il fabbisogno di memoria è più facile da valutare. Tre cose devono restare residenti: la coda (ogni messaggio accettato ma non ancora passato a un operatore, più ogni ricevuta non ancora abbinata), i dati di lavoro del database (i messaggi degli ultimi giorni, i listini, gli account cliente) e la cache dell’indice di ricerca. Nella prima fascia tutte e tre insieme stanno in 8 GB, con spazio per il sistema operativo e la console web. Nella seconda fascia i dati di lavoro crescono con il Suo storico, e da 16 a 32 GB evitano che il database debba leggere dal disco per i report che i clienti aprono ogni mattina.

Nella pratica la RAM non si esaurisce per colpa della coda, ma della reportistica. Un cliente che chiede “tutti i messaggi verso questo Paese nell’ultimo trimestre” a un database costretto a leggerli dal disco trasforma una query di due secondi in una di due minuti, e rallenta tutti gli altri mentre è in esecuzione. Aggiungere RAM è la soluzione più economica; archiviare i messaggi vecchi in un database documentale, che è ciò che fa la struttura separata della terza fascia, è quella duratura.

Disco: la crescita viene da ricevute di consegna e archivi

Il disco è il punto in cui avviene la vera crescita, ed è la parte che nessuno dimensiona. Ogni messaggio inviato produce almeno tre record: il messaggio stesso, la sua ricevuta di consegna dall’operatore e la voce di fatturazione che lo ha addebitato al cliente. Aggiunga gli indici che rendono veloci ricerca e reportistica, e una cifra di pianificazione pratica è di circa 1 KB per messaggio, tutto compreso, prima della compressione.

Nella prima fascia, 1.000.000 di messaggi al mese significano circa 1 GB di crescita al mese. Un SSD da 100 GB ne contiene anni. Nella seconda fascia, 10.000.000 di messaggi al mese significano 10 GB al mese, 120 GB all’anno, e un indice di ricerca aggiunge dal 30 al 50 per cento: ecco perché la seconda riga indica da 250 a 500 GB, e perché l’indice di ricerca e il database stanno “idealmente” su dischi propri, dato che quando ne condividono uno si contendono la stessa banda di scrittura.

Due scelte di progetto evitano che tutto questo diventi un problema. Primo, un livello di archivio: il database principale conserva la finestra recente (per esempio 90 giorni) e i messaggi più vecchi passano a un database documentale, dove restano ricercabili ma non rallentano più le tabelle transazionali. Secondo, una politica di conservazione decisa davvero: molti operatori conservano le ricevute di consegna per un periodo da 12 a 24 mesi in vista di eventuali contestazioni e cancellano prima il testo dei messaggi, e alcuni mercati regolano il periodo di conservazione, quindi verifichi la regola per i Paesi verso cui invia. Una piattaforma con un livello di archivio integrato, come è disegnato lo stack di Smppcube, con MongoDB come archivio accanto a MySQL come sistema di riferimento, trasforma entrambe le scelte in un’impostazione anziché in un progetto.

Rete e porte

La banda non è il vincolo: un messaggio pesa qualche centinaio di byte. Ciò che conta è un IP pubblico stabile, perché di solito gli operatori inseriscono in allowlist l’IP del Suo bind SMPP e non amano doverlo aggiornare, e la porta 2775 aperta in ingresso (o la porta che sceglie Lei) se i Suoi clienti si collegheranno in bind al Suo server SMPP. Oltre a questo servono HTTPS per la console e per l’API HTTP, e l’accesso in uscita verso gli endpoint SMPP e HTTP degli operatori. Se opera in una DMZ o isolato dalla rete, il gateway ha bisogno solo dei collegamenti con gli operatori e della rete della console, ed è uno dei motivi per cui il self-hosting funziona in ambienti regolamentati dove un pannello SaaS non può nemmeno essere approvato.

Una rosa di provider, con i prezzi

Va bene qualsiasi provider che venda vCPU dedicate, storage SSD o NVMe e un IP statico, e che Le permetta di aprire una porta. Questi sono quelli che vediamo più spesso. Un server dedicato da 4 a 8 vCPU e 32 GB, che copre la prima fascia pronta per le raffiche e la CPU e la RAM della seconda fascia, costa di norma da 50 a 100 USD al mese presso uno qualsiasi dei primi quattro; la terza fascia, con NVMe e nodi separati, è ovunque oggetto di un preventivo su misura.

Provider	Adatto a	Perché viene citato
Hetzner	Europa	Piani con vCPU dedicate e bare metal a prezzi bassi
Netcup	Europa	Core dedicati a basso costo; noi stessi siamo su Netcup
DigitalOcean	Regioni in tutto il mondo	Console semplice, prezzi prevedibili, snapshot facili
OVHcloud	Europa, Nord America	Bare metal disponibile quando le macchine virtuali non bastano più
Alibaba Cloud	Arabia Saudita e Golfo	Un data center all’interno del Regno per la residenza dei dati
Il Suo hardware	Installazioni isolate dalla rete o regolamentate	Solo i costi di colocation; al gateway non serve nulla dall’esterno, tranne i collegamenti con gli operatori

La nota “noi stessi siamo su Netcup” è lì perché gli acquirenti lo chiedono; descrive ciò che funziona nelle prime due fasce, non è un invito a ignorare gli altri. Controlli i listini aggiornati prima di decidere. Se i Suoi clienti si trovano in un solo Paese, un provider con una regione lì accorcia il percorso di andata e ritorno verso gli operatori e, soprattutto, tiene i dati dove il regolatore si aspetta che siano.

Il conto completo, con onestà

Il dimensionamento del server ha senso solo accanto al resto del conto, ed è qui che il modello self-hosted si guadagna il suo nome. Tre voci, e solo una è nostra:

1. La licenza, una sola volta: 6,400 USD per la piattaforma, ogni canale, ogni funzione e il primo anno di supporto. È la pagina dei prezzi riassunta in un solo numero.
2. Il server, ogni mese: da 50 a 100 USD nelle prime due fasce, pagati al provider che sceglie, sul Suo account, e può spostarlo quando vuole.
3. Il Suo traffico verso gli operatori, alle tariffe che negozia con il Suo SMSC o aggregatore. Noi non ci mettiamo mai in mezzo.

Confronti tutto questo con un pannello in affitto, dove il canone della piattaforma cresce con il Suo traffico e il server è invisibile perché appartiene a loro: la voce del server è l’unica che non può ridurre crescendo, e qui è la voce più piccola della pagina.

Backup, monitoraggio e le parti noiose

Un server non è un piano. Prima che il primo cliente vada in produzione, tre cose dovrebbero esistere ed essere state provate:

• Un backup notturno che Lei ha ripristinato almeno una volta. Il dump del database più la directory di configurazione, copiati fuori dalla macchina (lo snapshot del provider è comodo, ma uno snapshot sullo stesso account del server non è un backup contro il blocco dell’account). Provi il ripristino sulla macchina di staging: un backup che nessuno ha mai ripristinato è solo una speranza.
• Avvisi su disco e coda. Bastano due soglie: disco oltre l’80 per cento e ricevute in coda da più di 15 minuti. La prima Le dice di archiviare o di crescere; la seconda Le segnala che un bind con un operatore non è in salute prima che lo faccia un cliente.
• Un server di staging. Il VPS condiviso più economico che riesce a trovare, con la stessa versione, dove si provano per primi gli aggiornamenti e i nuovi listini. Costa quanto un caffè al mese; il suo valore è ogni aggiornamento che non dovrà annullare sulla macchina di produzione mentre i clienti stanno inviando.

Quando non Le serve nulla di tutto questo

Se invia qualche migliaio di messaggi al mese da una sola applicazione e non ha clienti propri, non Le serve affatto un server per il gateway: un’API HTTP di un qualsiasi fornitore, chiamata dalla Sua applicazione, è la dimensione giusta. Il dimensionamento di questa guida è pensato per chi vende messaggistica ad altri: rivenditori, aggregatori, operatori, o un’azienda che gestisce la messaggistica per molti team interni. A quel punto il server è la parte meno costosa dell’attività, e sapere in quale fascia si trova, e che cosa La porterà alla successiva, è gran parte di ciò che “requisiti” ha sempre voluto dire.