So optimierte die führende Videoplattform movingimage ihre Kubernetes-Container

Als führende Enterprise-Videoplattform in Europa haben wir bei movingimage ein übergeordnetes Ziel: Wir wollen von Grund auf verändern, wie Unternehmen Video einsetzen. Unsere Engineering-Teams arbeiten im Zuge unser laufenden Innovation täglich daran, unsere Plattform weiter zu optimieren. Dabei haben bei uns Stabilität, Zuverlässigkeit und Performance grundsätzlich Vorrang. Allerdings mussten wir feststellen, dass wir zur Überdimensionierung von Kubernetes-Containern in Microsoft Azure neigten. 

Mit der Zeit fragten wir uns, ob wir wirklich alle zugeteilten Ressourcen brauchten – und ob wir andererseits Stabilitätsprobleme verursachten, indem wir bestimmte Container in unserer Produktionsumgebung unterdimensionierten. Wir hatten weder alle Antworten noch eine zuverlässige Möglichkeit, die Ressourcennutzung und die Anforderungen innerhalb von Containern zu erfassen.

Unser System für Video-Content-Management muss hochverfügbar sein und beste Leistung liefern. Wir waren allerdings mit Problemen konfrontiert, deren Diagnose und Behebung zu lange dauerte. Obwohl wir einige Open-Source-Tools für das Infrastruktur-Monitoring nutzten, halfen sie uns kaum nachzuvollziehen, wie unsere Software genau lief. Wenn wir über den Open-Source-Stack ein Problem aufdeckten, fehlten uns die nötigen Telemetriedaten und Analysemöglichkeiten, um es innerhalb der Software präzise zu verorten. Somit blieb dem Engineering-Team oft nichts anderes übrig, als die Anwendungslogs manuell durchzugehen, was nicht nur mühselig, sondern auch zeitaufwändig war. 

Von übergroßen VMs zu überdimensionierten Containern 

Als wir firmenweit auf Microsoft Azure umstellten, migrierten die Teams unsere Anwendungen im Lift-and-Shift-Verfahren. Einige der virtuellen Maschinen (VMs) in unserer On-Premises-Umgebung waren viel zu groß, sodass die Teams bei der Anwendungsmigration ähnlich überdimensionierte Container in Microsoft Azure anlegten. Im Laufe der Zeit stieg die Neigung zur Überprovisionierung zugleich mit der Zahl der Container. So hatten wir zum Beispiel für eine Node.js-Anwendung fünf Cores bereitgestellt. Das heißt, wir verschwendeten im Schnitt vier Cores pro Container, da Node.js auf einem einzelnen Thread läuft. 

Gleichzeitig war uns bewusst, dass andere Container wahrscheinlich zu klein angelegt waren, was potenziell Schwierigkeiten im Hinblick auf Stabilität und Performance verursachen konnten. Daher suchten wir nicht unbedingt nach einer Möglichkeit, alles so klein wie möglich zu halten, sondern wollten jeden Container in der richtigen Größe anlegen, und zwar auf Grundlage von Einblicken in die tatsächliche Ressourcennutzung.

Anlegen eines Container-Dashboards

Als ich als Team Lead für DevSecOps zu movingimage kam, galt eine meiner ersten Fragen der Möglichkeit, eine Observability-Plattform bereitzustellen. Bald erhielt ich die Genehmigung, New Relic in unserer Umgebung zu erproben. Plötzlich hatten wir Transparenz bis auf Code-Ebene und Anwendungsmetriken, anhand derer wir datengestützte Entscheidungen treffen konnten. So konnten wir umgehend auf Probleme reagieren, die unsere Kund:innen betrafen, oder sie sogar im Vorfeld erkennen und beheben, noch bevor sie sich in der Praxis bemerkbar machten.

Ich hatte zuvor schon Custom-Dashboards von New Relic eingesetzt, um von der bloßen Cloudoptimierung zu Metriken in einzelnen Kubernetes-Containern überzugehen.  Also erstellte ich auch hier ein neues Dashboard. Mithilfe der New Relic Query Language (NRQL) kann ich nun die Verbrauchsmetriken für unsere drei movingimage-Umgebungen (Produktion, Qualitätssicherung (QS) und Entwicklung) visualisieren – und außerdem die etwa 150 Container in jeder Umgebung.

Als Videounternehmen erklären wir neue Dinge gerne über unser bevorzugtes Medium. Deswegen habe ich ein Video für meine Kollegen gemacht und darin erklärt, wie das Dashboard funktioniert und wie sie die Daten am besten interpretieren und nutzen können. Ich habe ausgeführt, welche Metriken New Relic verfolgt, was diese bedeuten und welche Folgen die Umsetzung von Optimierungen anhand der Einblicke aus dem Dashboard hat. Als unser CEO und unser CTO das Video sahen, wollten sie die Optimierungen gleich durchführen. Sie erkannten sofort, welche erheblichen Einsparungen damit möglich waren.

Zunächst testete das Engineering-Team unsere Optimierungshypothesen. Anschließend gaben wir den einzelnen Dev-Teams Empfehlungen für die Anpassung der Größenstruktur der Umgebungen, für die sie jeweils zuständig waren.             

50 % weniger Ressourcen- und Kostenaufwand 

Vor Beginn unserer Initiative zur Container-Optimierung hatten wir 40 bis 50 Knoten in der Microsoft-Azure-Produktionsumgebung am Laufen. Heute sind es durchschnittlich gerade einmal 20 Knoten, in einem Rahmen von 15 bis 30 Knoten im Produktionsbereich. Indem wir die Größe der einzelnen Containerumgebungen optimiert haben, konnten wir die Zahl der Knoten – und dementsprechend die Compute-Kosten – halbieren. Das Beste war, dass unsere Kunden den Unterschied feststellten. Während der Größenanpassung der Container haben wir gleichzeitig unterprovisionierte Umgebungen identifiziert und korrigiert, was positive Auswirkungen sowohl auf die Stabilität als auch auf die Performance hatte. 

Dasselbe machten wir in unserem QS-Cluster. Dort haben wir die Zahl der Knoten von 40 bis 60 auf weniger als 20 an einem normalen Tag reduziert. Das schlug sich in einer um etwa 60 % reduzierten Zuweisung von Cloud-Compute-Ressourcen und einer entsprechenden Kostensenkung nieder. 

In Verbindung mit unserer beschleunigten Incident Response und Fehlerbehebung entging das unseren Kunden nicht. Sie sagten ganz unmissverständlich: „Was auch immer ihr im letzten Jahr gemacht habt, die Verbesserung ist enorm.“ Plötzlich sprachen Kunden positiv über unsere Entwicklung. Ein Teil dieser Entwicklung ist, dass wir jetzt unternehmensweit stärker datengesteuert sind. New Relic ist und war eine beeindruckende Ressource, die uns hilft, einen echten Mehrwert zu realisieren.