Fallstudie: Forensik und Anpassung kombiniert

Fallstudie: Forensik und Anpassung auf derselben Pipeline

Hinweis zum Umfang

Diese Fallstudie betrifft eine einzelne Pipeline bei einem Kunden, einen großen monolithischen Compliance-Build, wie er in regulierten Unternehmensumgebungen typisch ist. Die Kennzahlen unten beziehen sich auf diese eine Pipeline, nicht auf einen Durchschnitt des Pools.

Ergebnisse in dieser Größenordnung sind nicht typisch. Die meisten Pipelines starten nicht bei 67 Stunden. Ich nehme den Fall auf, weil er zeigt, wie sich die beiden Optimierungsschritte kombinieren, wenn sie nacheinander auf denselben Build angewendet werden.

Ausgangslage

Der Workload stammte ursprünglich von einem Unternehmen und wurde in die Cloud-Infrastruktur eines anderen Unternehmens migriert. Die beiden Organisationen hatten unterschiedliche Netzwerktopologien, unterschiedliche Namenskonventionen und unterschiedliche Betriebsgrundlagen.

Auf der On-Premise-Hardware des ursprünglichen Unternehmens lief der Compliance-kritische Build in 35 bis 42 Stunden durch. Nach der Übergabe in die Azure-Umgebung des aufnehmenden Unternehmens benötigte derselbe Build 67 Stunden. Die Regression war über mehrere Läufe reproduzierbar.

Die Pipeline hieß „nightly", passte aber nicht mehr in eine Nacht und musste auf jeden zweiten Tag verschoben werden, um überlappende Läufe zu vermeiden.

Schritt eins: Forensik

Ich instrumentierte die längste Pipeline-Phase und korrelierte die Laufzeiten mit Netzwerk-, Namensauflösungs- und Infrastrukturmetriken. Die Build-Agents selbst waren gesund.

Die zusätzliche Dauer ließ sich auf Operationen zurückführen, die wiederholt ausgehende Lookups gegen Endpunkte durchführten. Diese Endpunkte waren bei der Migration zwischen den Unternehmen nicht sauber neu eingebunden worden.

Ursache war eine DNS-Konfiguration, die im Ziel-Unternehmen, jedoch nicht im ursprünglichen Unternehmen vorhanden war. Jeder Lookup führte zu einem Timeout- und Retry-Zyklus, multipliziert mit der Anzahl der Lookups pro Build-Phase. Die Verzögerung summierte sich über einen langen monolithischen Build massiv auf.

Nach der DNS-Korrektur fiel die Pipeline-Laufzeit von 67 Stunden auf 29 Stunden, bereits schneller als die ursprüngliche On-Premise-Baseline beim Ausgangsunternehmen.

Schritt zwei: Anpassung

Mit dem nun gesunden Build profilierte ich die Ressourcennutzung über die verbleibenden 29 Stunden. Der Workload war stark singlethreaded und durch die Taktfrequenz begrenzt, nicht durch die Anzahl der Kerne. Die bereitgestellte Hardware war bei den Kernen überdimensioniert und bei der Frequenz unterdimensioniert.

Ich wechselte das Hardware-Profil zu einem mit weniger Kernen und höherer Taktfrequenz, passend zur Form des Workloads. Dasselbe Vorgehen wie in der separaten Anpassungs-Fallstudie, erneut angewendet auf die nun gesunde Pipeline.

Die Pipeline-Laufzeit fiel von 29 Stunden auf 16 Stunden.

Ergebnis

• Ende zu Ende: 67 Stunden auf 16 Stunden, 76 % schneller insgesamt
• Forensik allein: 67 Stunden auf 29 Stunden, 57 % schneller
• Anpassung darauf: 29 Stunden auf 16 Stunden, weitere 45 % schneller
• Verglichen mit der Pre-Migrations-Baseline On-Premise von 35 bis 42 Stunden: mehr als 50 % schneller als vor dem Cloud-Umzug
• Cloud-Kosten pro Lauf entsprechend reduziert durch die kürzere Laufzeit und einen niedrigeren Stundensatz der Hardware nach der Umstellung
• Umfang: eine Pipeline, ein Kunde, zwei nacheinander durchgeführte Optimierungsschritte
• Zeitrahmen: zuerst Ursachenanalyse, anschließend Hardware-Anpassung auf dem nun gesunden Build