SMS-Gateway-Serveranforderungen: Dimensionierung 1 bis 200 msg/s

„Welchen Server brauche ich?“ ist die erste Frage, die fast jeder Käufer stellt, und die Antwort fällt kleiner aus, als die meisten befürchten, und konkreter, als die meisten Hersteller angeben. Ein SMS-Gateway ist kein Video-Encoder. Seine Arbeit besteht aus Warteschlangen, Routing, Abrechnung und Buchführung, und was wächst, ist die Buchführung. Dieser Leitfaden nennt Ihnen die Serveranforderungen eines SMS-Gateways für jede Traffic-Stufe mit echten Zahlen, erklärt, warum dedizierte vCPU wichtiger ist als die Zahl der Kerne, zeigt, was Zustellberichte und Archive im Lauf eines Jahres mit Ihrer Platte machen, und schließt mit einer Anbieter-Auswahl und dem Backup-Plan, den Sie haben sollten, bevor der erste Kunde live geht.

SMS-Gateway-Serveranforderungen nach Traffic-Stufe

Die Zahl, die über Ihren Server entscheidet, sind Nachrichten pro Sekunde in der Spitze, nicht Nachrichten pro Monat. Ein Kunde, der 1.000.000 Nachrichten über einen Monat verteilt sendet, kommt im Schnitt auf 0,4 msg/s; derselbe Kunde, der um neun Uhr morgens eine Werbeaktion an 200.000 Nummern schickt, will eine halbe Stunde lang 100 msg/s. Das Gateway muss diesen Schub aufnehmen, ihn so schnell an die Netzbetreiber übergeben, wie sie ihn annehmen, und anschließend die zurückkommenden Zustellberichte auffangen, die in der Spitze in derselben Rate eintreffen, in der gesendet wurde.

Die Tabelle unten ist die Dimensionierung, die wir auf der Plattform-Seite veröffentlichen, und sie entspricht dem, worauf unsere eigenen Installationen laufen. Die Volumina sind monatlich, die Raten dauerhaft.

Dauerhafte Rate	Monatsvolumen	Server	Hinweise
~1 msg/s	bis ~1.000.000 SMS	4 vCPU, 8 GB RAM, 100 GB SSD, alles auf einer Maschine	Die meisten Reseller bleiben in ihrem ersten Jahr hier
~10 msg/s	~1.000.000 bis 10.000.000	8 vCPU, 16 bis 32 GB RAM, 250 bis 500 GB SSD	Suchindex und Datenbank idealerweise auf eigenen Platten
~50 msg/s und mehr	10.000.000 und mehr	16+ vCPU, 32 bis 64 GB RAM, schnelles NVMe, Komponenten auf mehrere Knoten verteilt	Warteschlange, Datenbank, Suche und SMPP-Schicht bekommen jeweils eigenen Raum

Zwei Dinge an dieser Tabelle überraschen. Erstens, wie klein die erste Stufe ist: Eine vollständige mandantenfähige Plattform mit Webkonsole, SMPP-Server, Warteschlange, Datenbank und Suchindex passt auf eine Maschine mit 4 vCPU, weil bei 1 msg/s keine dieser Komponenten unter Druck steht. Zweitens geht es beim Sprung in die dritte Stufe nicht um CPU. Es geht um I/O: Bei 50 msg/s schreibt die Datenbank einen Datensatz pro Nachricht, aktualisiert ihn, wenn der Netzbetreiber bestätigt, aktualisiert ihn erneut, wenn der Zustellbericht eintrifft, und indexiert ihn für die Suche. Drei Schreibvorgänge pro Nachricht bei 50 msg/s sind 150 Schreibvorgänge pro Sekunde, dauerhaft, plus die Lesezugriffe jedes offenen Kunden-Dashboards. Das ist ein Plattenproblem, und deshalb erscheinen NVMe und verteilte Knoten in der dritten Zeile und nicht früher.

Die Frage der Lastspitzen: klein anfangen, Reserve brauchen

Es gibt einen häufigen Fall dazwischen, den die Tabelle nicht erfasst: Sie beginnen bei null, Ihr Monatsvolumen ist also winzig, aber Ihr erster Kunde ist eine Schulkette oder ein Onlineshop, der alles in einem einzigen morgendlichen Schub sendet und erwartet, dass es innerhalb von Minuten ankommt. Sie brauchen 100 bis 200 msg/s Reserve, während Ihre dauerhafte Rate noch unter 1 msg/s liegt.

Die Antwort ist ein dedizierter Server mit 4 bis 8 vCPU und 32 GB RAM. Er kostet bei den unten genannten Anbietern 50 bis 100 USD im Monat, er bewältigt die Spitze, weil die Kerne Ihnen gehören und der RAM die Warteschlange und das Working Set im Speicher hält, und er trägt Sie so lange, bis dauerhaftes Volumen, Zustellberichte und Reporting anfangen, um dieselbe Platte zu konkurrieren. Das ist der Moment, eine Stufe höher zu gehen, und er kommt meist nach dem zehnten Kunden, nicht nach dem ersten.

Der teuerste Anfängerfehler in diesem Geschäft ist, am ersten Tag die dritte Stufe zu kaufen, weil eine Tabellenkalkulation Ihnen 50 Kunden vorhergesagt hat. Kaufen Sie die für Lastspitzen gerüstete erste Stufe, beobachten Sie die Platte und die Warteschlange der Zustellberichte, und wechseln Sie, wenn die Diagramme es Ihnen sagen.

Dedizierte oder geteilte vCPU

Die Preislisten der Hosting-Anbieter verwischen eine wichtige Grenze. Eine geteilte Instanz mit „4 vCPU“ gibt Ihnen vier Zeitscheiben von Kernen, die auch andere Kunden nutzen; eine dedizierte Instanz mit „4 vCPU“ gibt Ihnen vier Kerne, die Ihnen gehören. Bei einer Website ist der Unterschied unsichtbar. Bei einem SMS-Gateway ist es der Unterschied, ob eine Werbeaktion in zehn Minuten ankommt oder in vierzig.

Der Grund ist die Form der Last. Web-Traffic ist gleichmäßig und nachsichtig; eine langsame Sekunde hier und da fällt nicht auf. SMS-Traffic kommt in Schüben und ist zustandsbehaftet: Während einer Spitze muss die SMPP-Schicht ihre Carrier-Binds versorgen und deren Heartbeats rechtzeitig beantworten, die Warteschlange muss abfließen, und Zustellberichte müssen ihren Nachrichten zugeordnet werden, solange diese in der Datenbank noch frisch im Speicher liegen. Nutzt in diesem Moment ein Nachbar den geteilten Kern, stockt der Bind, das Fenster des Netzbetreibers füllt sich, der Netzbetreiber drosselt Sie, und Ihre Zustellberichte stauen sich hinter den Sendungen. Nichts geht kaputt, aber alles, was Sie dem Kunden über Geschwindigkeit und Reporting versprochen haben, kommt jetzt zu spät.

Faustregel: geteilte vCPU für die Demo und den Staging-Server, dedizierte vCPU für alles, wofür ein Kunde bezahlt. Der Preisunterschied liegt in der ersten Stufe bei 20 bis 40 USD im Monat, also unter einer Stunde Ihrer Zeit, in der Sie einem Kunden erklären, warum der Bericht von gestern immer noch aktualisiert wird.

RAM: was tatsächlich im Speicher liegt

Der Speicherbedarf lässt sich leichter abschätzen. Drei Dinge wollen resident bleiben: die Warteschlange (jede angenommene, aber noch nicht an einen Netzbetreiber übergebene Nachricht, dazu jeder noch nicht zugeordnete Zustellbericht), das Working Set der Datenbank (die Nachrichten der letzten Tage, die Preislisten, die Kundenkonten) und der Cache des Suchindex. In der ersten Stufe passen alle drei zusammen in 8 GB, mit Platz für das Betriebssystem und die Webkonsole. In der zweiten Stufe wächst das Working Set mit Ihrer Historie, und 16 bis 32 GB verhindern, dass die Datenbank für die Berichte, die Kunden jeden Morgen öffnen, auf die Platte zugreifen muss.

Wo der RAM in der Praxis ausgeht, ist nicht die Warteschlange, sondern das Reporting. Ein Kunde, der „alle Nachrichten in dieses Land im letzten Quartal“ anfordert, macht auf einer Datenbank, die das von der Platte lesen muss, aus einer Abfrage von zwei Sekunden eine von zwei Minuten und bremst alle anderen, solange sie läuft. Mehr RAM ist die günstigste Lösung; ältere Nachrichten in eine Dokumentendatenbank zu archivieren, wie es das verteilte Design der dritten Stufe tut, ist die dauerhafte.

Platte: Zustellberichte und Archive sind das Wachstum

Auf der Platte findet das eigentliche Wachstum statt, und genau diesen Teil dimensioniert niemand. Jede gesendete Nachricht erzeugt mindestens drei Datensätze: die Nachricht selbst, ihren Zustellbericht vom Netzbetreiber und den Abrechnungseintrag, der den Kunden belastet hat. Rechnen Sie die Indizes hinzu, die Suche und Reporting schnell machen, und eine praktische Planungsgröße liegt bei etwa 1 KB pro Nachricht insgesamt, vor der Komprimierung.

In der ersten Stufe sind 1.000.000 Nachrichten im Monat etwa 1 GB Wachstum im Monat. Eine SSD mit 100 GB fasst davon Jahre. In der zweiten Stufe sind 10.000.000 Nachrichten im Monat 10 GB im Monat, 120 GB im Jahr, und ein Suchindex obendrauf fügt 30 bis 50 Prozent hinzu. Deshalb steht in der zweiten Zeile 250 bis 500 GB, und deshalb liegen Suchindex und Datenbank „idealerweise“ auf eigenen Platten: Teilen sie sich eine, konkurrieren sie um dieselbe Schreibbandbreite.

Zwei Designentscheidungen verhindern, dass daraus ein Problem wird. Erstens eine Archivebene: Die Hauptdatenbank hält das jüngste Zeitfenster (etwa 90 Tage), und ältere Nachrichten wandern in eine Dokumentendatenbank, wo sie weiter durchsuchbar sind, die Transaktionstabellen aber nicht mehr bremsen. Zweitens eine Aufbewahrungsrichtlinie, die Sie tatsächlich festlegen: Viele Betreiber bewahren Zustellberichte 12 bis 24 Monate für Streitfälle auf und löschen Nachrichteninhalte früher, und manche Märkte regeln die Aufbewahrungsfrist, prüfen Sie also die Regel für die Länder, in die Sie senden. Eine Plattform mit eingebauter Archivschicht, so wie der Smppcube-Stack gezeichnet ist, mit MongoDB als Archiv neben MySQL als führendem System, macht aus beiden Entscheidungen eine Einstellung statt eines Projekts.

Netzwerk und Ports

Die Bandbreite ist nicht der Engpass; eine Nachricht umfasst ein paar hundert Bytes. Worauf es ankommt, ist eine stabile öffentliche IP, weil Netzbetreiber die IP Ihres SMPP-Binds meist auf eine Allowlist setzen und sie nur ungern ändern, und ein offener eingehender Port 2775 (oder der Port Ihrer Wahl), wenn Ihre eigenen Kunden sich an Ihren SMPP-Server binden sollen. Dahinter HTTPS für die Konsole und die HTTP-API sowie ausgehender Zugriff auf die SMPP- und HTTP-Endpunkte der Netzbetreiber. Wenn Sie in einer DMZ oder netzgetrennt arbeiten, braucht das Gateway nur die Carrier-Verbindungen und das Konsolennetz, und das ist einer der Gründe, warum Self-Hosting in regulierten Umgebungen funktioniert, in denen ein SaaS-Panel nicht einmal genehmigt werden kann.

Eine Anbieter-Auswahl mit Preisen

Jeder Anbieter, der dedizierte vCPU, SSD- oder NVMe-Speicher und eine statische IP verkauft und Sie einen Port öffnen lässt, ist geeignet. Das sind die, die wir am häufigsten sehen. Ein dedizierter Server mit 4 bis 8 vCPU und 32 GB, der die für Lastspitzen gerüstete erste Stufe sowie CPU und RAM der zweiten Stufe abdeckt, kostet bei jedem der ersten vier typischerweise 50 bis 100 USD im Monat; die dritte Stufe mit NVMe und verteilten Knoten ist überall ein individuelles Angebot.

Anbieter	Geeignet für	Warum er genannt wird
Hetzner	Europa	Angebote mit dedizierter vCPU und Bare Metal zu niedrigen Preisen
Netcup	Europa	Dedizierte Kerne zu geringen Kosten; wir selbst laufen auf Netcup
DigitalOcean	Weltweite Regionen	Einfache Konsole, planbare Preise, unkomplizierte Snapshots
OVHcloud	Europa, Nordamerika	Bare Metal verfügbar, wenn virtuelle Maschinen nicht mehr reichen
Alibaba Cloud	Saudi-Arabien und die Golfregion	Ein Rechenzentrum im Königreich für die Datenresidenz
Ihre eigene Hardware	Netzgetrennt oder reguliert	Nur Colocation-Gebühren; das Gateway braucht von außen nichts außer den Carrier-Verbindungen

Der Satz „wir selbst laufen auf Netcup“ steht dort, weil Käufer danach fragen; er beschreibt, was in den ersten beiden Stufen funktioniert, und ist keine Empfehlung, die anderen zu ignorieren. Prüfen Sie die aktuellen Preislisten, bevor Sie entscheiden. Wenn Ihre Kunden in einem Land sitzen, verkürzt ein Anbieter mit einer Region dort den Weg zu den Netzbetreibern und hält, was wichtiger ist, die Daten dort, wo die Aufsichtsbehörde sie erwartet.

Die ganze Rechnung, ehrlich

Die Server-Dimensionierung ergibt nur neben dem Rest der Rechnung Sinn, und hier verdient sich das selbst gehostete Modell seinen Namen. Drei Posten, und nur einer davon geht an uns:

1. Die Lizenz, einmalig: 6,400 USD für die Plattform, alle Kanäle, alle Funktionen und das erste Jahr Support. Das ist die Preisseite in einer Zahl.
2. Der Server, monatlich: 50 bis 100 USD in den ersten beiden Stufen, bezahlt an den Anbieter Ihrer Wahl, über Ihr eigenes Konto, und Sie können ihn umziehen, wann immer Sie wollen.
3. Ihr Carrier-Traffic, zu den Tarifen, die Sie mit Ihrem eigenen SMSC oder Aggregator aushandeln. Wir sitzen nie dazwischen.

Vergleichen Sie das mit einem gemieteten Panel, bei dem die Plattformgebühr mit Ihrem Traffic wächst und der Server unsichtbar ist, weil er dem Anbieter gehört: Die Serverzeile ist das Einzige, das Sie durch Wachstum nicht günstiger machen können, und hier ist sie der kleinste Posten auf der Seite.

Backups, Überwachung und die langweiligen Teile

Ein Server ist noch kein Plan. Bevor der erste Kunde live geht, sollten drei Dinge existieren und getestet sein:

• Ein nächtliches Backup, das Sie mindestens einmal wiederhergestellt haben. Datenbank-Dump plus Konfigurationsverzeichnis, von der Maschine weg kopiert (der Snapshot des Anbieters ist bequem, aber ein Snapshot im selben Konto wie der Server ist kein Backup für den Fall, dass das Konto gesperrt wird). Testen Sie die Wiederherstellung auf der Staging-Maschine; ein Backup, das nie jemand wiederhergestellt hat, ist eine Hoffnung.
• Alarme für Platte und Warteschlange. Zwei Schwellenwerte genügen: Platte über 80 Prozent und Zustellberichte in der Warteschlange, die älter als 15 Minuten sind. Der erste sagt Ihnen, dass Sie archivieren oder erweitern müssen; der zweite sagt Ihnen, dass ein Carrier-Bind nicht gesund ist, bevor es ein Kunde tut.
• Ein Staging-Server. Der günstigste geteilte VPS, den Sie finden, mit derselben Version, auf dem Updates und neue Preislisten zuerst ausprobiert werden. Er kostet so viel wie ein Kaffee im Monat; sein Wert ist jedes Update, das Sie nicht auf der Produktivmaschine zurückrollen müssen, während Kunden senden.

Wann Sie nichts davon brauchen

Wenn Sie ein paar tausend Nachrichten im Monat aus einer einzigen Anwendung senden und keine eigenen Kunden haben, brauchen Sie überhaupt keinen Gateway-Server; eine HTTP-API eines beliebigen Anbieters, aus Ihrer App aufgerufen, ist die richtige Größe. Die Dimensionierung in diesem Leitfaden richtet sich an Betreiber, die Messaging an andere verkaufen: Reseller, Aggregatoren, Netzbetreiber oder ein Unternehmen, das Messaging für viele interne Teams betreibt. An diesem Punkt ist der Server der günstigste Teil des Geschäfts, und zu wissen, in welcher Stufe Sie sind und was Sie in die nächste bringt, ist das meiste von dem, was „Anforderungen“ je bedeutet hat.