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.
movingimage mit Hauptsitz in Berlin ist Europas führender SaaS-Anbieter sowohl für Live- als auch für On-Demand-Unternehmensvideos. Videos sind die Leidenschaft des Unternehmens, das nicht nur Software für Unternehmensvideos anbietet, sondern sich auch als Experte für Videokommunikation behauptet. Unternehmen setzen die Cloud-Lösung von movingimage ein, um Videoinhalte aller Art zentral und effizient zu verwalten und in Top-Qualität auf allen Endgeräten zu streamen. Renommierte Traditionsunternehmen wie VW, Douglas und Commerzbank nutzen die sichere, zentralisierte Videolösung von movingimage.
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.
Ein Überblick über das Angebot von movingimage.
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.
Dieses Dashboard setzt movingimage zur Beurteilung von Infrastrukturdaten ein. Damit kann das Team erhebliche Kosteneinsparungen erzielen, denn das Dashboard gewährt Einblicke darüber, welche Container gute oder schlechte Kandidaten sind, wie groß sie sein sollten und welche potenziellen Probleme lauern könnten.
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.
- Den Workshop von Frank Dornberger bei FutureStack können Sie hier ansehen, um mehr über die Größenoptimierung von Kubernetes-Containern zu erfahren.
- Lesen Sie die umfassende Einführung in das Kubernetes-Monitoring und informieren Sie sich in unserer Dokumentation, wie Sie Ihre Kubernetes-Daten am besten nutzen.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.
