Der Übergang von SSH zu REST-basierter Jobeinreichung verändert das Verhalten der Datenpipeline auf architektonischer Ebene. Es geht um Manageability, Fehlertoleranz und Ressourcenmanagement.
Das Problem zeigt sich nicht sofort — bis das System an seine Grenzen stößt. In dem betrachteten Fall wurden über 700 Jobs über SSH zu EMR-Clustern ausgeführt. Dies umfasste alles, von Spark und MapReduce bis hin zu beliebigen CLI-Befehlen. Dieser Ansatz schien einfach: sich mit dem Master-Knoten zu verbinden und den Befehl auszuführen. Doch mit der Zunahme der Pipelines verwandelte sich SSH in eine Quelle der Instabilität. Die Verbindung war zustandsbehaftet: Bei einem Ausfall des Clients (z. B. Pod in Kubernetes) konnte der Job weiterlaufen, hängen bleiben oder „Zombie“-Prozesse hinterlassen. Gleichzeitig wuchs die Risikozone: direkter Zugang zu Produktionsclustern, Schlüssel, komplexes Zugriffsmodell. Irgendwann wurde dies zum Blocker für die weitere Evolution der Infrastruktur.
Die Lösung lag nicht in der „Verbesserung von SSH“, sondern in der Abkehr davon. Das Team wechselte zur REST-basierten Jobeinreichung über API. Die zentrale Idee war, das Management des Lebenszyklus des Jobs auf die Serverseite zu verlagern. Anstatt die Verbindung aufrechtzuerhalten, sendet der Client eine HTTP-Anfrage, und das System verfolgt selbstständig die Ausführung. Dies reduziert die Kopplung der Komponenten und macht das Verhalten vorhersehbar. Für den Hadoop-Stack (Spark, Hive, MapReduce) gab es bereits APIs: Livy und HiveServer2. Die Hauptschwierigkeit lag woanders — über 300 Aufgaben bestanden aus beliebigen Shell-Befehlen ohne REST-Schnittstelle. Hier wurde YARN Distributed Shell verwendet. Dies ermöglichte das Ausführen beliebiger Shell-Skripte innerhalb des YARN-Containers mit Ressourcenmanagement und standardisiertem Lebenszyklus. Der Kompromiss ist offensichtlich: Es wird eine Abstraktionsschicht hinzugefügt, aber im Gegenzug entsteht ein einheitliches Ausführungsmodell.
Architektonisch wurde ein Zwischenservice — ein REST-Gateway zur Ausführung von Jobs — zum Schlüsselfaktor. Es nimmt Anfragen vom Orchestrator (Airflow) entgegen, kümmert sich um die Authentifizierung, sendet Aufgaben an die Rechenmaschinen (EMR/YARN, Trino, Snowflake) und verfolgt den Status. Dies beseitigt die Notwendigkeit des direkten Zugriffs auf die Cluster. Jetzt hält Airflow keine SSH-Sitzungen mehr, sondern arbeitet über die API. Selbst wenn der Orchestrator neu gestartet wird, läuft der Job weiter, und der Status kann über dieselbe API abgerufen werden. Dieses Muster wird in der Branche seit langem als Möglichkeit diskutiert, die Kopplung zu reduzieren und die Robustheit verteilter Systeme zu erhöhen.
Die Implementierung stellte sich als nicht trivial heraus. Die Migration betraf Hunderte von Jobs und mehrere Regionen mit unterschiedlicher Netzwerktopologie. Einer der unerwarteten Effekte war das Auftreten versteckter Probleme. Zum Beispiel begannen nach dem Wechsel zu YARN Aufgaben aufgrund von Einschränkungen des virtuellen Speichers (vmem) zu fallen. Früher umging SSH diese Einschränkungen, indem es Befehle direkt auf dem Master-Knoten ausführte. Nach der Migration wurden die Ressourcen tatsächlich kontrolliert. Es musste vmem-Checks deaktiviert werden, gemäß den Empfehlungen von AWS, da sie zu Fehlalarmen führen können. Eine zweite Klasse von Problemen waren Netzwerkabhängigkeiten. Einige Jobs hingen von einer bestimmten Routing-Konfiguration ab (z. B. Zugang zu Key-Management-Diensten), was nicht explizit beschrieben war. Bei der Übertragung in andere Cluster brach dies. Dies zeigte einen wichtigen Punkt: SSH maskiert infrastrukturelle Abhängigkeiten, während ein strikteres Ausführungsmodell diese aufdeckt.
Die Ergebnisse zeigten sich auf mehreren Ebenen. Die Sicherheit wurde einfacher: SSH-Zugang zu Produktionsclustern fiel weg, die Authentifizierung wechselte zu Service-to-Service-Token, und es gab ein Audit über API-Logs. Das Ressourcenmanagement wurde vorhersehbar: Alle Aufgaben werden in YARN-Containern ausgeführt, ohne Konkurrenz um den Master-Knoten. Die Zuverlässigkeit stieg durch den serverseitigen Lebenszyklus — Jobs überstehen Clientausfälle und werden korrekt abgeschlossen. Die Beobachtbarkeit änderte sich ebenfalls: Anstelle einer manuellen Verbindung zu Knoten sind strukturierte Logs, Status und Metriken über die API verfügbar.
Dabei ist es wichtig zu beachten: Konkrete numerische Metriken der Verbesserungen werden nicht angegeben. Aber aus der Beschreibung wird deutlich, dass die Änderungen die Schlüsselfunktionen des Systems — Fehlertoleranz (reliability), Beobachtbarkeit (observability) und Ressourcenmanagement (resource management) — betroffen haben. Dies ist eine evolutionäre Verbesserung der Architektur und nicht nur ein Wechsel der Schnittstelle.
Die Hauptschlussfolgerung ist — der Übergang von SSH zu REST-basierter Jobeinreichung verändert nicht nur die Art und Weise, wie Aufgaben gestartet werden, sondern auch das Systemmodell selbst. SSH ist zu Beginn bequem, skaliert jedoch schlecht und verbirgt Probleme. Der REST-Ansatz, insbesondere in Verbindung mit Ressourcenmanagern wie YARN, macht das System transparenter. Und das bedeutet — besser verwaltbar.