Wandel annehmen in einem schnelllebigen Startup
Mindestens einmal im Jahr gehe ich mit meiner Familie segeln. Nichts Spektakuläres – ein Segelboot, das wir selbst bedienen können, um Natur und gemeinsame Zeit zu genießen. Erstaunlicherweise spielt dabei der Wind eine zentrale Rolle – Richtung und Stärke. Und das Verrückte daran: Er dreht ständig!
So wie der Wind ändert sich auch das Leben permanent. Besonders in einem schnelllebigen Startup. Was heute gut funktioniert, passt morgen vielleicht schon nicht mehr. Zu erkennen, wann es Zeit ist, den Kurs zu wechseln, nachzujustieren oder ein System komplett zu überholen, ist entscheidend. Als Engineers neigen wir dazu, uns in unsere Entscheidungen und die Systeme, die wir bauen, zu verlieben. Doch am Alten festzuhalten, kann zur Belastung werden.
Bei Attribute™ verlieben wir uns in Menschen, nicht in das, was wir bauen. Als es also so weit war, unseren Data-Processing-Stack zu hinterfragen, war das keine Überraschung. Anfangs trafen wir unter den gegebenen Rahmenbedingungen die besten Infrastrukturentscheidungen. Doch mit dem Wachstum wurden genau diese Entscheidungen zu Grenzen – und zwangen uns zum Umdenken.
Die frühe Entscheidung: Serverless Dataproc für Spark
Als wir mit dem Aufbau unserer Datenverarbeitungs-Infrastruktur begannen, entschieden wir uns für Serverless Dataproc, um unsere Spark-Jobs auszuführen. Damals war das genau die richtige Wahl. Als schlankes Team mit begrenzter Engineering-Kapazität konnten wir es uns schlicht nicht leisten, einen selbst verwalteten Spark-Cluster aufzubauen und zu betreiben. Serverless Dataproc erlaubte es uns, uns auf die Wertschöpfung zu konzentrieren, ohne uns um den operativen Overhead kümmern zu müssen. Wir konnten unsere Spark-Jobs schreiben, unkompliziert deployen und den Rest Google Cloud überlassen.
Die Wachstumsschmerzen: Kosten und fehlende Kontrolle
Mit unserem Geschäft wuchsen auch die Anforderungen an die Datenverarbeitung. Mehr Daten hießen mehr Jobs, häufigere Ausführungen und irgendwann: explodierende Kosten.
Dazu kamen operative Engpässe. Der Black-Box-Charakter von Dataproc gab uns kaum Einblick in die Details der Job-Ausführung – Performance-Optimierung und effizientes Debugging wurden dadurch mühsam.
An diesem Punkt überwogen die Nachteile die Vorteile. Uns war klar: Wir mussten die Kontrolle zurückholen.
Das "Warum" hinter der Migration
Ich habe eine einfache Regel für jedes Engineering-Projekt: Am Anfang muss ein starkes "Warum" stehen. Ohne triftigen Grund sollten wir unsere wertvollste Ressource – Zeit – nicht darauf verwenden. (Kleiner Hinweis: Eine neue Technologie auszuprobieren, nur weil sie "cool" ist, reicht nie als Grund.)
Für unsere Dataproc-Migration war das "Warum" eindeutig:
- Kosteneffizienz: Serverless Dataproc war schlicht zu teuer geworden.
- Operative Transparenz: Wir brauchten mehr Kontrolle und Einblick in unsere Spark-Jobs.
- Skalierbarkeit und Flexibilität: Wir wollten unsere Infrastruktur an sich verändernde Anforderungen fein justieren können.
Mit diesen Gründen im Rücken starteten wir ein fokussiertes Projekt: die Migration unserer Spark-workloads von Dataproc auf eine selbst verwaltete, Kubernetes-basierte Lösung.
Die Migration: Spark auf Kubernetes umziehen
Wir entschieden uns, unsere Spark-Jobs mit Spark-on-Kubernetes zu deployen – so laufen Spark-Anwendungen als native Kubernetes-workloads. Hier ein grober Überblick über unseren Ansatz:
Infrastruktur-Setup:
- Wir haben einen Kubernetes-Cluster auf Google Kubernetes Engine (GKE) mit aktiviertem Autoscaling bereitgestellt, um schwankende workloads abzufangen.
- Für unsere Spark-Jobs haben wir einen eigenen Namespace eingerichtet – so bleiben sie klar von anderen Services getrennt.
- Spot-Instanzen kommen zum Einsatz, um die Kosten weiter zu drücken.
Job-Ausführung mit SparkApplication CRD:
Wir nutzen den Spark Operator, um Spark-workloads als Kubernetes-native Ressourcen zu verwalten.
Damit lassen sich Spark-Jobs deklarativ über Kubernetes Custom Resources (CRs) definieren – deutlich einfacher in Verwaltung und Skalierung.
Observability und Monitoring:
Für das Echtzeit-Monitoring der Job-Ausführung haben wir Victoria Metrics und Grafana angebunden.
Das Ergebnis: Mehr Kontrolle, geringere Kosten, besseres Monitoring
Die Migration brachte deutliche Verbesserungen:
- Kostensenkung: Durch den Wegfall des Managed-Overheads von Dataproc und eine gezielte Optimierung der Ressourcennutzung haben wir unsere Spark-Verarbeitungskosten um mehr als 70 % gesenkt.
- Mehr Transparenz: Wir haben tiefere Einblicke in die Job-Ausführung gewonnen – gut für Debugging und Optimierung. Zugleich ist die Ownership im Engineering-Team gewachsen: Ohne Black Box sind wir gezwungen, sauberere Engineering-Arbeit zu leisten.
- Skalierbarkeit: Der Betrieb auf Kubernetes erlaubt uns, workloads dynamisch zu skalieren – ohne die Grenzen eines Anbieters. Die bessere Spark-Performance und kürzere Laufzeiten haben zudem unsere Effizienz in der Feature-Entwicklung erhöht und damit den Produktnutzen gesteigert.
Fazit
Engineering heißt, Probleme so effizient wie möglich zu lösen. Serverless Dataproc war für uns am Anfang die richtige Entscheidung – und der Wechsel zu Kubernetes war die richtige Entscheidung, als wir gewachsen sind.
Die wichtigste Lektion? Bleiben Sie anpassungsfähig. Verlieben Sie sich nicht in Ihre Entscheidungen, sondern nehmen Sie den Wandel an – er kommt sowieso, ob Sie wollen oder nicht.
Ich bin gespannt, wann uns die aktuelle Spark-Infrastruktur die erste Reibung beschert…