1&1 Mail & Media GmbH In 6 Monaten zum georedundanten Kubernetes Hardware Cluster
Technologien
Kundennutzen
- effizientere Ressourcennutzung
- agile Entwicklung
- schnelle Umsetzung
Eine moderne Plattform für Microservices in einer historisch gewachsenen Infrastruktur aufzubauen ist weder in der Theorie noch in der Praxis ein leichtes Unterfangen. Dass ein solches Vorhaben aber nicht nur gelingen kann, sondern dem Geschäftsbereich sogar eine Art Vorbildfunktion beschert, zeigt das gemeinsame Projekt von 1&1 Mail & Media GmbH und inovex. Hier wurde eine 1&1-Bereichsinfrastruktur innerhalb weniger Monate auf modernen Kubernetes-Clustern bereitgestellt.
Wir möchten eine moderne Container-Plattform für den Portalbereich aufbauen, mit der wir perspektivisch unsere bestehende Virtualisierungsinfrastruktur ablösen können.
Simone Hoefer
Head of Portal Platform Services, 1&1 Mail & Media GmbHDer Geschäftsbereich Portal der 1&1 Mail & Media GmbH ist für die Infrastruktur der Webmail-Dienste der Endkund:innen des Unternehmens verantwortlich. Diese umfassen rund 38 Millionen E-Mail-Accounts, die in drei georedundanten Rechenzentren liegen.
Die Infrastruktur basierte bisher auf einem unternehmensweiten VMWare Cluster, der durch die zentrale IT bereitgestellt und verwaltet wurde, und auf dedizierter Hardware (Bare Metal), die von den Sysadmin-Teams des Geschäftsbereichs betrieben wird. Da die Virtual Machine Packages (VM-Packages) – unabhängig vom tatsächlichen Bedarf – nur mit festen Ressourcen-Größen (CPU, Arbeitsspeicher, Storage, …) ausgeliefert werden konnten, war punktuelle Skalierung nicht – beziehungsweise nur mit Verschwendung der übrigen, nicht gebrauchten Ressourcen – möglich. Zudem konnten virtuelle Maschinen nur halbautomatisch bereitgestellt werden, was eine automatische Skalierung unmöglich machte und weitere Arbeitszeit in Anspruch nahm.
Die Zielsetzung war also klar: Die neue Infrastruktur sollte automatisierbar sein, um eine schnelle Skalierung gewährleisten zu können und flexibel genug, um nur die wirklich gebrauchten Ressourcen skalieren zu können. So sollte die bisher für die Bereitstellung von Ressourcen verantwortliche IT entlastet und der direkte Zugriff der Entwickler:innen ermöglicht werden.
Mit diesen Anforderungen vor Augen wurde im Mai 2017 bei einem einwöchigen gemeinsamen Workshop von 1&1 und inovex eine moderne Lösungsarchitektur skizziert. Nachdem mögliche Alternativen diskutiert und auf der Basis der Anforderungen bewertet worden waren, fiel die Wahl auf Container und Kubernetes als Orchestrierungs-Tool. In diesem Kontext hatte inovex schon in der Vergangenheit Projekte gemeistert – entsprechend groß waren technisches Vorwissen und Erfahrungswerte. Auch der Stellenwert der neuen Infrastruktur im Unternehmenskontext und mögliche Anknüpfungspunkte an diese wurden frühzeitig identifiziert.
Um einen möglichst reibungslosen Einstieg zu gewährleisten, sollten Stateless Backend Microservices als Startpunkt dienen und Anwendungen mit Storage-Anbindungen erst im zweiten Schritt angegangen werden, da Stateful Microservices weitere technologische Herausforderungen mit sich bringen – divide and conquer.
Neben der Lösungsarchitektur wurden vorab schon grundlegende technische Rahmenbedingungen geklärt, etwa die Kompatibilität der 1&1-Hardware mit dem zu verwendenden CoreOS/Container Linux und die Abhängigkeit von anderen internen technischen Teams und Zulieferern. In vier weiteren Wochen wurde also folgende Lösungsskizze erarbeitet:
Wie bei Microservices-Plattformen üblich, wurde das Projekt agil mit einem cross-funktionalen Team aus inovex- und 1&1-Mitgliedern aus verschiedenen Teams und Bereichen besetzt. Ziel war die Entwicklung eines Proof of Concept, der 6 Monate später produktiv genutzt werden kann – im ersten Schritt noch parallel zu den bestehenden VMs, um die Container-Infrastruktur gefahrlos testen und potenzielle Lastspitzen abfangen zu können. Nicht nur die Architektur war für diese Herangehensweise ausschlaggebend, auch im Unternehmenskontext bot sich Scrum als agiles Framework an: die iterative Entwicklung erzwingt den regelmäßigen Abgleich von Zielsetzung und Fortschritt und kleine Erfolge in Form von abgeschlossenen Sprints halfen, das Management davon zu überzeugen, dass das Projekt auf dem richtigen Weg ist.
Schon hier kam dem Projekt eine Vorreiterrolle zu: Die transparente Entwicklung, offene Reviews und Dailies sowie die Frage nach aktivem Feedback durch Mitarbeiter:innen trugen dazu bei, die neue Architektur zu etablieren. Mitarbeiter:innen, die den Betrieb der Infrastruktur zukünftig verwalten sollten, wurden so optimal in den Aufbau der neuen Infrastruktur integriert.
Insbesondere der Umgang mit Containern, die man im Gegensatz zu virtuellen Maschinen dank ihrer schnellen Verfügbarkeit und Reproduzierbarkeit im Problemfall eher ersetzt als repariert, musste erst gelernt werden (Pet-vs.-Cattle-Prinzip). Im Sinne der eingangs erwähnten Automatisierung kamen außerdem Deployment Pipelines mit GoCD zum Einsatz, für die nach und nach Templates geschrieben wurden, um projektneuen Entwickler:innen die Arbeit zu erleichtern und ihnen eine Auseinandersetzung mit den Details der Deployments zu ersparen.
Die Modellierung durch Infrastructure as Code macht es möglich, automatisch neue Cluster mit sofort einsetzbaren Umgebungen aufsetzen zu können, sodass weder eine manuelle Provisionierung noch ein Einrichten des Betriebssystems notwendig ist – Abteilungen können sich so komplett auf die Entwicklung ihrer jeweiligen Anwendungen konzentrieren.
Bewusst eingesetzte Methoden wie Pair Programming und regelmäßige Code Reviews haben sich ebenso positiv auf das Vertrautwerden mit den neuen Technologien ausgewirkt wie die räumliche Nähe der Entwickler:innen, die schnelles Nachfragen erleichterte.
Um weitere Berührungsängste zu vermeiden, wurde zunächst nur ein kleiner Teil der Live-Umgebung von der neuen Kubernetes-Infrastruktur gestemmt, während der Rest noch in der Bestandsumgebung lief (Blue-Green Deployment). Generell wurden virtuelle Maschinen nicht direkt abgeschaltet, sondern liefen parallel und standen in der Einarbeitungsphase so weiterhin als Fallback bereit. Nicht zuletzt dienten interne Tech- und Support-Channels für Rückfragen dazu, das Vertrauen in das Vorhaben aufrecht zu erhalten.
Eine kleine Anekdote am Rande: Testweise wurden die Fallback-Systeme abgeschaltet, ohne dass es im Betrieb aufgefallen ist – die neue Microservice-Architektur hatte ihre Feuerprobe bestanden.
Trotz des knappen Zeitrahmens wurde der Proof of Concept wie geplant im 3. Quartal 2017 – 6 Monate nach Kick-off – fertig, sodass im 4. Quartal der Übergang in die nächste Phase stattfinden konnte: Ab Dezember sollte das Projekt allein von 1&1-Mitarbeiter:innen betrieben werden, weshalb 2 Monate für die Übergabe der Ownership anberaumt wurden. In dieser Zeit musste gewährleistet werden, dass das Betriebsteam autonom Updates, Diagnose, Logging und Alerts durchführen kann.
Kostet Automatisierung Arbeitsplätze?
Bei Automatisierungsprojekten schwingt häufig die Angst mit, dass Arbeitsplätze wegfallen, wenn Pipelines Schritte übernehmen, die bisher von Mitarbeiter:innen durchgeführt werden mussten. Dieses gemeinsame Projekt von 1&1 und inovex ist ein Beispiel dafür, dass dem nicht so ist: Automatisierung ersetzt in der Regel sich wiederholende und dadurch schnell lästig werdende Aufgaben und verringert dadurch die Entwicklungszeit, erhöht aber gleichzeitig die Komplexität des Systems und führt neue Abhängigkeiten ein. So fordert sie mehr Kooperation zwischen Software-Entwicklung und Betrieb und begünstigt die Etablierung einer DevOps-Kultur.
In kleinen schnellen Schritten wurde nach und nach eine Microservice-Architektur mit Kubernetes etabliert, die eine automatisierte Bereitstellung von Ressourcen ermöglicht. Der agile Ansatz half dabei nicht nur bei der technologischen Entwicklung, sondern gestaltete das Projekt transparenter und führte die Mitarbeiter:innen nach und nach an die neuen Technologien heran. Inzwischen ist dadurch eine interne Community entstanden, die das Projekt pflegt und vorantreibt.
Nach erfolgreicher Übergabe wird das Projekt weiterentwickelt und umfasst derzeit über 800 Server, georedundant verteilt auf Cluster an 3 Standorten, die von einem sieben- bis achtköpfigen Team weiterentwickelt werden und so die Infrastruktur für 80 Administrator:innen und über 300 Entwickler:innen bereitstellen. Durch die flexiblere Verwaltung konnte außerdem die Effizienz der verwendeten Ressourcen erhöht werden, im Referenzfall (Monitoring des Spam-Scanners) etwa um 20 Prozent. Zwar kam es seit Beginn der Beta-Phase vereinzelt zu Ausfällen – teils eines ganzen Clusters –, diese hatten dank des System-Designs allerdings keinerlei Auswirkungen auf die Nutzer:innen. Nach Abschluss der Beta-Phase blieb das System komplett ohne Ausfälle.
Unternehmensintern blieb dieser Erfolg nicht unbemerkt: Heute laufen mehr als 100 Dienste auf der neuen Infrastruktur, die kontinuierlich weiter skaliert wird.
Wie können wir Sie unterstützen?