Ein selbst gehostetes SMS-Gateway betreiben: was wirklich dazugehört
Ein selbst gehostetes SMS-Gateway gehört zu den Dingen, die von außen einfach aussehen und ihre wahre Gestalt in der Woche der Inbetriebnahme zeigen. Eine Nachricht zu senden ist leicht; Millionen zuverlässig zu senden, jede korrekt abzurechnen, die Zustellung nachzuweisen und das ohne einen Ausfall um 2 Uhr nachts, das ist die eigentliche Arbeit. Dieser Leitfaden geht die Architektur in klaren Worten durch, nennt ehrliche Hardware-Zahlen, markiert die Linie, an der kostenlose Software aufhört, und legt die Abläufe dar, die Sie in dem Moment übernehmen, in dem der Verkehr real wird. Das Ziel ist, Ihnen zu helfen, mit offenen Augen zu entscheiden, ob Sie bauen, kaufen oder noch ein wenig weiter mieten.
Was ein selbst gehostetes SMS-Gateway eigentlich ist
Unter den Dashboards ist ein Gateway ein kleines Fließband mit vier Stationen. Verkehr kommt herein, wird in die Warteschlange gestellt, wird gesendet und wird verbucht. Diese vier Stationen zu verstehen, ist der größte Teil der Schlacht.
Der Eingang ist die Art, wie Nachrichten ankommen. Geschäftskunden senden aus Bequemlichkeit über eine HTTP-API, über ein Web-Panel für einmalige Kampagnen oder über einen SMPP-Bind, wenn sie selbst eine andere Plattform mit hohem Volumen sind. SMPP ist das telekom-native Protokoll: eine dauerhafte TCP-Verbindung, einmal authentifiziert, über die die Nachrichten dann als Binärpakete strömen. Ein gut konfigurierter SMPP-Client kann Zehntausende Nachrichten pro Sekunde einreichen, und genau deshalb bevorzugen ernsthafte Versender ihn gegenüber HTTP.
Die Warteschlange ist der Stoßdämpfer. Man sendet nie direkt vom Eingang zum Betreiber, denn Betreiber nehmen in ihrem eigenen Tempo an, und Ihre eingehenden Spitzen passen nicht dazu. Stattdessen landet jede angenommene Nachricht in einer schnellen In-Memory-Warteschlange (Redis ist die übliche Wahl) und gibt sofort eine Bestätigung zurück. Das erlaubt Ihnen, einen Versand von einer Million Nachrichten in Sekunden anzunehmen, ohne eine zu verlieren, und sie dann gleichmäßig an die Betreiber zu speisen. Die Persistenz dieser Warteschlange zählt: Wenn die Maschine neu startet und die Warteschlange nur im Speicher lag, ist alles verloren, was noch nicht auf die Platte geschrieben wurde.
Der Träger ist der Teil, der wirklich mit den Betreibern spricht. In den meisten selbst gehosteten Stacks ist das Kannel, dessen BearerBox die dauerhaften SMPP-Verbindungen zu jedem SMSC (dem Nachrichtenzentrum des Betreibers) hält, sie am Leben erhält, sich bei Abbrüchen neu verbindet und den Verkehr über die Sitzungen verteilt. Ein begleitender Prozess liest die anstehende Warteschlange und übergibt die Nachrichten an den Träger; ein anderer kümmert sich um die Zustellbestätigungen und die zurückkommenden eingehenden Nachrichten. Diese Schicht ist Jahrzehnte alt und äußerst zuverlässig, und es ist keine Schande, sich auf sie zu stützen.
Abrechnung und Buchhaltung ist die Station, die alle unterschätzen. Jede Nachricht muss vor dem Versand gegen das Guthaben des richtigen Kunden verbucht, nach der genommenen Route bepreist, bei Meldung eines endgültigen Fehlers durch einen Betreiber korrekt erstattet und in einer Rechnung zusammengefasst werden, die ein Kunde lesen kann. Das ist keine Funktion, die man später anschraubt; sie ist durch alle anderen Stationen gewoben, und hier verlieren Amateur-Gateways stillschweigend Geld.
Server-Dimensionierung: was Sie bei 1, 10 und 50 Nachrichten pro Sekunde wirklich brauchen
Der erste Fehler bei der Dimensionierung ist, in Monatssummen zu denken. SMS-Verkehr kommt in Schüben: der Flash-Sale eines Händlers oder der nächtliche Kontoauszugslauf einer Bank drückt das Volumen eines Monats in einer Stunde durch. Was die Maschine belastet, ist der anhaltende Spitzendurchsatz, das Volumen der zurückkommenden Zustellbestätigungen (oft so viele Ereignisse wie gesendete Nachrichten) und die Berichts- und Suchlast, die Ihre Kunden erzeugen. Dimensionieren Sie für die Spitze, nicht für den Durchschnitt.
Die folgende Tabelle ist ein Ausgangspunkt für eine Ein-Knoten-Bereitstellung, kein Vertrag. Nachrichtengröße, Kodierung, Routenmix und wie lange Sie die Datensätze aufbewahren, verschieben alle Zahlen.
| Anhaltender Durchsatz | Ungefähres Monatsvolumen | Start-Hardware (ein Knoten) | Was zuerst nachgibt |
|---|---|---|---|
| ~1 msg/s | Bis zu ~1.000.000 | 4 vCPU, 8 GB RAM, 100-GB-SSD, alle Komponenten zusammen | Die Platte füllt sich mit Logs und DLR |
| ~10 msg/s | ~1.000.000 bis 10.000.000 | 8 vCPU, 16 bis 32 GB RAM, 250- bis 500-GB-SSD | Suche und Berichte unter Kundenlast |
| ~50 msg/s | Ab 10.000.000 | 16+ vCPU, 32 bis 64 GB RAM, schnelle NVMe, Komponenten auf mehrere Knoten verteilt | Grenzen des Einzelknotens; Zeit für Active-Active |
Zwei praktische Hinweise. Erstens: Der Durchsatz zu einem einzelnen Betreiber ist in der Regel durch die Zahl der SMPP-Sitzungen begrenzt, die der Betreiber erlaubt, nicht durch Ihre Hardware; ist eine Route langsam, während Ihre Maschine untätig ist, brauchen Sie wahrscheinlich mehr Sitzungen, bis zum Maximum des Betreibers, und keinen größeren Server. Zweitens: In dem Moment, in dem die Plattform geschäftskritisch wird, hören Sie auf, eine einzelne Maschine zu vergrößern, und wechseln Sie zu einer hochverfügbaren Topologie mit den Komponenten auf dedizierten Knoten. Eine dokumentierte Basislinie, aus Ihrer eigenen Bereitstellung erhoben, ist mehr wert als jede generische Tabelle, denn was normal ist, definiert sich relativ zu Ihrer Hardware und Ihrem Verkehr.
Was Open Source Ihnen gibt und wo es aufhört
Die Open-Source-SMS-Welt ist wirklich gut, und das Gegenteil zu behaupten kostet Sie Geld. Kannel und Jasmin terminieren SMPP, halten die Betreiber-Binds und bewegen enorme Volumina zum Preis des Servers. Wenn Sie eine direkte Leitung zwischen einem System und einem Betreiber brauchen, sind sie oft die richtige Antwort, und Sie sollten nicht zu viel kaufen.
Wo sie aufhören, ist die Geschäftsschicht, und die Lücke ist größer, als sie aussieht. Von Haus aus bekommen Sie überhaupt keine grafische Verwaltung, also ist jede Route, jeder Tarif und jeder Benutzer eine Konfigurationsdatei. Sie bekommen keine mandantenfähigen Kundenkonten, was keine Isolierung, keine Guthaben und keine Tarife pro Kunde bedeutet. Sie bekommen keine Abrechnung, keine Rechnungsstellung und keine Kreditkontrolle. Sie bekommen keine White-Label-Kundenportale, keine lesbaren Zustellberichte, nach denen Kunden fragen, keine Opt-out-Engine und niemanden, den Sie anrufen können, wenn um Mitternacht ein Bind abbricht. Nichts davon ist eine Kritik an den Werkzeugen; sie wurden gebaut, um ein Träger zu sein, kein Produkt. Es bedeutet nur, dass es ein Softwareprojekt ist, einen Träger in ein Geschäft zu verwandeln, und Sie sollten dieses Projekt ehrlich kalkulieren, bevor Sie es beginnen. Diese wahren Kosten von “kostenlos” sind das Thema eines eigenen Vergleichs.
Die Abläufe, vor denen Sie niemand warnt
Die Inbetriebnahme ist der Anfang der Arbeit, nicht das Ende. Vier betriebliche Realitäten entscheiden, ob Ihr Gateway ein Geschäft oder ein Kopfschmerz ist.
Zustellbestätigungen (DLR) sind die Art, wie Sie beweisen, dass eine Nachricht angekommen ist, und sie sind nicht optional. Ein Betreiber liefert eine Bestätigung zurück, die zugestellt, fehlgeschlagen oder abgelaufen lautet, und Ihre Plattform muss sie der ursprünglichen Nachricht zuordnen, den Bericht des Kunden aktualisieren und über die Abrechnung entscheiden. Ein vorübergehender Fehler (Gerät aus, Netzüberlastung) kann innerhalb seines Gültigkeitsfensters noch zugestellt werden und sollte nicht vorzeitig erstattet werden; ein endgültiger Fehler (ungültige Nummer, gesperrt) wird nie zugestellt und sollte erstattet werden. Diese Einordnung falsch zu treffen, ist der Weg, entweder mit Erstattungen Geld zu verlieren, die Sie nicht geben sollten, oder Kunden zu verärgern, indem Sie Nachrichten berechnen, die nie ankamen.
Wiederholungen und Gültigkeit entscheiden, was mit Nachrichten geschieht, die beim ersten Mal nicht durchgehen. Sie brauchen eine vernünftige Wiederholungsrichtlinie und eine Gültigkeitsdauer, sonst häuft eine blockierte Route stillschweigend unzugestellten Verkehr an, bis ein Kunde fragt, warum seine Kampagne nie losging.
Überwachung ist der Unterschied, ob Sie es aus einem Diagramm erfahren oder von einem verärgerten Kunden. Behalten Sie mindestens den Status der Betreiber-Binds, die Warteschlangentiefe, die Zustellrate pro Route und den freien Speicherplatz im Auge. Ein Gateway ohne Überwachung ist kein kleineres Gateway; es ist eine Zeitbombe mit guten Absichten. Eine wenig glamouröse Wahrheit, die man verinnerlichen sollte: Ein überraschender Anteil der Vorfälle vom Typ “alles ist kaputt” ist schlicht eine volle Platte, also prüfen Sie das zuerst.
Backups sind die, deren Auslassen Sie bereuen werden. Ihr Aufzeichnungssystem, Ihre Kundenliste, Ihre Guthaben und die Persistenz Ihrer Warteschlange brauchen alle ein Backup, das Sie durch Wiederherstellen tatsächlich getestet und nicht nur eingeplant haben. Testen Sie es einmal, bevor Sie Kunden haben, denn der Tag, an dem Sie es brauchen, ist der schlechteste Tag, um zu entdecken, dass es nie funktioniert hat.
Bauen oder kaufen, ehrlich
Hier ist die Weggabelung, ohne Verkaufsgespräch. Wenn Sie die Entwicklungszeit haben, es genießen, den Stack zu besitzen, und die Messaging-Leitung selbst Ihr Produkt ist, ist der Aufbau auf Open Source legitim und lizenzseitig günstig. Diese Ersparnis geben Sie in den Monaten aus, die der Aufbau der Abrechnungs-, Mandanten-, Portal- und Berichtsschichten kostet, und in deren dauerhafter Pflege, aber für manche Teams ist genau das der richtige Handel.
Wenn Ihr Ziel dagegen ist, in diesem Quartal Messaging an Kunden zu verkaufen, ist der Kauf einer Plattform in Ihrem Eigentum meist die bessere Rechnung. Eine einmalig lizenzierte Plattform wie Smppcube liefert die gesamte Geschäftsschicht, die mandantenfähigen Konten, die Abrechnung, die Portale und die Berichte, auf demselben praxiserprobten Träger und läuft auf Ihrem eigenen Server, sodass Sie die Air-Gap- oder DMZ-Haltung bewahren, für die man Self-Hosting oft überhaupt erst wählt. Gegen eine Lizenzgebühr sparen Sie sechs bis zwölf Monate, die Sie nicht mit dem Bau von Software verbringen, die nicht Ihr Alleinstellungsmerkmal ist.
Der ehrliche Test ist einfach: Ist das Schreiben von Gateway-Software Ihr Geschäft oder eine Ablenkung davon? Beantworten Sie das zuerst, und die Architektur, die Dimensionierung und die Abläufe oben werden zu einer Checkliste statt zu einer Überraschung. Beginnen Sie mit Ihrer eigenen Spitzendurchsatz-Zahl und einer klaren Vorstellung davon, an wen Sie verkaufen, und der Rest der Entscheidung ergibt sich von selbst.
FRAGEN
Was macht ein selbst gehostetes SMS-Gateway eigentlich?
Es ist die Software, die zwischen Ihren Kunden und den Mobilfunkbetreibern sitzt. Sie nimmt Nachrichten über eine API, ein Web-Panel oder einen SMPP-Bind entgegen, validiert sie und stellt sie in eine Warteschlange, leitet jede an eine Betreiberverbindung weiter, verbucht sie gegen ein Guthaben und verarbeitet die zurückkommende Zustellbestätigung. Es selbst zu betreiben bedeutet, dass es auf Ihrem eigenen Server lebt statt auf dem eines anderen Unternehmens.
Welchen Server brauche ich, um ein SMS-Gateway zu betreiben?
Für einen kleinen Betrieb unter etwa 1.000.000 Nachrichten pro Monat ist eine einzelne Maschine mit 4 vCPU, 8 GB RAM und einer 100-GB-SSD ein sinnvoller Ausgangspunkt. Der Sprung in den Bereich von 1.000.000 bis 10.000.000 verlangt 8 vCPU und 16 bis 32 GB, wobei Suche und Datenbank idealerweise auf einer eigenen Platte liegen. Darüber hinaus verteilen Sie die Komponenten auf mehrere Knoten. Spitzendurchsatz und das Volumen der Zustellbestätigungen belasten die Maschine weit mehr als die Monatssumme.
Reicht Kannel allein, um ein SMS-Gateway zu betreiben?
Kannel ist eine hervorragende, praxiserprobte SMSC-Verbindungsschicht, und die meisten ernsthaften Gateways nutzen es noch darunter. Was es Ihnen nicht bietet, ist eine grafische Oberfläche, mandantenfähige Kundenkonten, eine Abrechnung pro Kunde, White-Label-Portale, Berichte oder eine Opt-out-Engine. Das sind die Teile, die ein kommerzielles Wiederverkaufsgeschäft tatsächlich verkauft, und genau die bauen Sie obendrauf oder kaufen sie.
Sollte ich ein selbst gehostetes SMS-Gateway bauen oder eine lizenzierte Plattform kaufen?
Wenn Sie die Entwicklungszeit haben und es genießen, den Stack zu besitzen, ist der Aufbau auf Open Source machbar und lizenzseitig günstig. Wenn Ihr Ziel ist, in diesem Quartal Messaging an Kunden zu verkaufen, erspart Ihnen eine lizenzierte Plattform in Ihrem Eigentum sechs bis zwölf Monate Aufbau der Abrechnungs-, Portal- und Berichtsschicht. Der ehrliche Test ist, ob das Schreiben dieser Software Ihr Geschäft ist oder eine Ablenkung davon.