- Twilio Segment betrieb Hunderte von Microservices, wechselte aber wegen der Komplexität und des hohen Wartungsaufwands zu einem Single-Service (Monolithen)
- Anfangs wurden die einzelnen Destination-APIs getrennt, um Fehler zu isolieren und Skalierbarkeit zu erreichen. Als die Zahl der Services jedoch auf über 140 anstieg, nahm der operative Overhead stark zu
- Die Verwaltung zahlreicher Repositories und Shared Libraries wurde schwierig, und bei Tests sowie Deployments traten Probleme auf, die alle Services betrafen
- Um das zu lösen, führte das Unternehmen das Centrifuge-System und eine Monorepo-Struktur ein und baute für die Testautomatisierung den Traffic Recorder
- Dadurch verbesserten sich Entwicklungsgeschwindigkeit und Stabilität deutlich; Twilio Segment setzt den Monolithen weiterhin aus Gründen der Produktivität und operativen Effizienz ein
Einführung von Microservices und ihre Grenzen
- Twilio Segment setzte für seine Customer-Data-Infrastruktur auf eine Microservices-Architektur und entwarf die Plattform so, dass Services für einzelne Zwecke Ereignisse unabhängig verarbeiten
- Daten werden an Hunderte von serverseitigen Destinations (z. B. Google Analytics, Optimizely usw.) weitergeleitet
- Anfangs wurde eine einzelne Queue verwendet, doch bei Ausfällen bestimmter Destinations trat Head-of-Line-Blocking auf, wodurch das gesamte System verzögert wurde
- Zur Lösung richtete das Unternehmen für jede Destination separate Services und Queues ein und erreichte so Fehlerisolation sowie unabhängige Skalierung
- Mit wachsender Zahl der Services stiegen jedoch operative Komplexität und Wartungskosten stark an, was die Entwicklung verlangsamte und die Fehlerquote erhöhte
Probleme mit einzelnen Repositories und Shared Libraries
- Jede Destination verwendet ein anderes API-Format, weshalb benutzerdefinierter Transformationscode nötig war
- Anfangs wurde alles in einem einzigen Repository verwaltet, doch fehlschlagende Tests wirkten sich auf alles aus, sodass eine Aufteilung der Repositories erfolgte
- Mit der späteren Ergänzung von mehr als 50 neuen Destinations entstanden über 50 Repositories
- Für gemeinsame Funktionen wurden Shared Libraries eingeführt, doch Versionsunterschiede und der Aufwand für Deployments nahmen zu
- Da sich die Lastmuster je Service unterschieden, waren Auto-Scaling-Einstellungen schwer abzustimmen; in manchen Fällen mussten Operatoren manuell eingreifen
Umstellung auf den Monolithen und Einführung von Centrifuge
- Es fiel die Entscheidung, mehr als 140 Services in einem einzigen Service zu konsolidieren
- Um die einzelnen Queues zu ersetzen, wurde das Centrifuge-System entwickelt, das alle Events an einen einzigen Service weiterleitet
- Centrifuge entwickelte sich später zur Connections-Backend-Infrastruktur von Twilio Segment weiter
- Mit der Umstellung auf einen Single-Service-Aufbau konnten der operative Aufwand reduziert und die Reaktion auf Störungen vereinfacht werden
Monorepo und Testautomatisierung
- Der gesamte Code für die Destinations wurde in ein einziges Repository zusammengeführt, und mehr als 120 Abhängigkeiten wurden auf eine einheitliche Version gebracht
- Das vereinfachte die Versionsverwaltung und verbesserte die Wartungseffizienz
- Für die Testautomatisierung wurde der Traffic Recorder eingeführt
- Er zeichnet echte HTTP-Requests und -Responses auf und spielt sie wieder ab, wodurch die Abhängigkeit von externen Netzwerken entfällt
- Die Testdauer sank von mehreren Minuten auf den Millisekundenbereich, bei deutlich höherer Stabilität
- Die Fehlerrate bei Tests sank, und die Produktivität der Entwickler stieg deutlich
Auswirkungen und Trade-offs der monolithischen Struktur
- Nach der Konsolidierung in einen Single Service verbesserten sich Deployment-Geschwindigkeit und Entwicklungseffizienz deutlich
- Innerhalb eines Jahres stieg die Zahl der Verbesserungen an Shared Libraries von 32 auf 46
- Ein einzelner Engineer kann ein Deployment innerhalb weniger Minuten durchführen
- Auch die operative Effizienz verbesserte sich, da Lastspitzen durch große Worker-Pools aufgefangen werden können
- Es gibt jedoch auch Nachteile, darunter schwierigere Fehlerisolation, geringere Cache-Effizienz und Risiken bei Dependency-Updates
- Ein Teil dieser Nachteile wird durch einfacheren Betrieb und höhere Produktivität ausgeglichen
Fazit
- Microservices lösten anfangs Leistungsprobleme, sind aber für großflächige Skalierung und gebündelte Updates weniger geeignet
- Durch die Umstellung auf einen Monolithen wurden Betriebsstabilität und Entwicklungsgeschwindigkeit gleichermaßen verbessert
- Für eine erfolgreiche Umstellung sind ein robustes Testsystem und die Akzeptanz von Trade-offs entscheidend
- Twilio Segment setzt zwar in Teilen seiner Infrastruktur weiterhin auf Microservices, bewertet jedoch für serverseitige Destinations einen Monolithen als die geeignetere Struktur
Noch keine Kommentare.