Klingen "Burns Cliff", "Columbia Hills", "Endeavour" und "Bonneville Crater" wie von dieser Welt? Sie haben Recht! Es handelt sich um einige der geografischen Strukturen, die Mars Exploration Rover (MER) der NASA besucht haben. Seit mehreren Jahren senden die Rover wahre Schätze an aufsehenerregenden Daten zurück, darunter auch hochlauflösende Bilder vom roten Planeten. Mittlerweile ist Amazon Simple Workflow Service (Amazon SWF) an einigen der wichtigen Rechentechnologien hinter diesen Missionen beteiligt. Amazon SWF ermöglicht NASA-Wissenschaftlern die zuverlässige Steuerung missionskritischer Abläufe und eine effiziente Verarbeitung des wachsenden Wissens, das wir über unser Universum erlangen.
Marsrover Curiosity
Das Jet Propulsion Laboratory (JPL) der NASA nutzt Amazon SWF als wichtigen Baustein für verschiedene Missionen, u. a. für den Marsrover Curiosity und für das Carbon in the Arctic Reservoir Vulnerability Experiment (CARVE). Diese Missionen generieren laufend große Datenvolumen, die effizient und zuverlässig verarbeitet, analysiert und gespeichert werden müssen. Die Datenverarbeitungs-Pipelines für taktische Operationen und wissenschaftliche Analysen umfassen eine Vielzahl nacheinander ausgeführter Schritte und bieten weitreichende Möglichkeiten zur Parallelverarbeitung auf mehreren Computern. Zu den Beispielen zählen die Erzeugung von 3D-Daten anhand von Bildpaaren, das Aneinanderfügen von mehreren Gigapixel großen Panoramen, damit Wissenschaftler in das Terrain des Mars eintauchen können, und die Unterteilung dieser Gigapixel-Bilder in Kacheln, damit Daten bedarfsorientiert geladen werden können. Es gibt eine globale Community von Bedienern und Wissenschaftlern, die auf solche Daten bauen. Für diese Community gelten häufig enge Zeitrahmen für taktische Operationen, mitunter nur einige Stunden. Zum Erfüllen dieser Anforderungen legen JPL-Ingenieure eine Zielvorgabe für die Verarbeitung und Verbreitung von Mars-Bildern binnen Minuten fest.
JPL speichert und verarbeitet Daten schon geraume Zeit in AWS. Viele dieser Aufgaben erfolgen im Polyphony-Framework, der Referenzimplementierung der Cloud-orientierten Architektur von JPL. Diese Architektur bietet Unterstützung für die Bereitstellung, Speicherung, Überwachung und Abstimmung von Datenverarbeitungsaufträgen in der Cloud. Die bestehende Polyphony-Palette für Datenverarbeitung und -analyse umfasst Amazon EC2 für Rechenkapazität, Amazon S3 für Datenspeicherung und -verteilung sowie Implementierungen von Amazon SQS und MapReduce wie z. B. Hadoop für die Aufgabenverteilung und -ausführung. Doch ein wichtiges Element hat bislang gefehlt: ein Abstimmungsservice zur Erledigung von Aufgaben für große, komplexe Workflows.
Wenngleich Warteschlangen einen effektiven Ansatz zur Verteilung massenparalleler Aufträge darstellen, gelangten die Ingenieure schnell an Grenzen. Da in Warteschlangen keine Reihenfolge und Abhängigkeiten ausgedrückt werden können, eigneten sie sich nicht für komplexe Workflows. Die JPL-Ingenieure mussten bei Verwenden von Warteschlangen auch mit der Duplizierung von Nachrichten zurechtkommen. Beim Aneinanderfügen von Bildern resultierte beispielsweise eine duplizierte Aufgabe zum Anfügen eines Bilds in einem aufwendigen überflüssigen Verarbeitungsschritt. Dessen Ergebnis war das Verursachen einer weiteren aufwendigen Verarbeitung, während sich die Pipeline vergeblich in Richtung Fertigstellung bewegt. JPL verfügt außerdem über zahlreiche Anwendungsfälle, die über die reine Datenverarbeitung hinaus gehen und Mechanismen zum Steuern des Kontrollflusses erfordern. Während die Ingenieure ihre datengesteuerten Kontrollflüsse problemlos mithilfe von MapReduce implementieren konnten, hatten sie Schwierigkeiten, jeden Schritt in der Pipeline innerhalb der Semantik des Frameworks auszudrücken. Mit zunehmender Komplexität der Datenverarbeitung hatten sie insbesondere Schwierigkeiten, Abhängigkeiten zwischen Verarbeitungsschritten abzubilden und mit Fehlern bei verteilten Berechnungen zurechtzukommen.
JPL-Ingenieure erkannten die Notwendigkeit eines Abstimmungsservice mit den folgenden Merkmalen:
- Hochverfügbarkeit: Zur Unterstützung missionskritischer Operationen
- Skalierbarkeit: Zur Vereinfachung der Parallelausführung in Hunderten von Amazon EC2-Instances
- Einheitlichkeit: Eine geplante Aufgabe muss mit sehr hoher Wahrscheinlichkeit einmal ausgeführt werden
- Ausdrückbarkeit: Zum einfachen Ausdrücken komplexer Workflows zur Beschleunigung der Entwicklung
- Flexibilität: Die Ausführung von Workflows darf nicht auf Amazon EC2 begrenzt sein und Aufgaben müssen routingfähig sein
- Leistungsstärke: Aufgaben müssen mit minimaler Latenz geplant werden
JPL-Ingenieure griffen auf Amazon SWF zurück und integrierten den Service in die Polyphony-Pipelines, die für taktische Operationen für die Datenverarbeitung von Mars-Bilder zuständig sind. Sie verschafften sich dadurch eine unvergleichliche Kontrolle und Transparenz in Bezug auf die verteilte Ausführung ihrer Pipelines. Noch wichtiger war, dass sie komplexe Workflows kurz und bündig ausdrücken konnten, ohne gezwungen zu sein, das Problem in einem bestimmten Paradigma auszudrücken.
Zur Unterstützung des Fast Motion Field Test für den Rover Curiosity, der auch als Mars Science Laboratory bezeichnet wird, mussten JPL-Ingenieure Bilder verarbeiten, 3D-Bilder generieren und Panoramen erzeugen. Für die Erstellung von 3D-Bildern ist ein Paar aus Bildern erforderlich, die gleichzeitig aufgenommen wurden. Dabei werden Bereichsdaten generiert, die einem Bediener die Entfernung und Richtung des Rovers anhand der Pixel in den Bildern mitteilen. Das linke und das rechte Bild können parallel verarbeitet werden. Die 3D-Verarbeitung kann allerdings erst beginnen, nachdem jedes Bild verarbeitet wurde. Dieser klassische Workflow aus Teilen und Zusammenfügen kann in einem warteschlangenbasierten System nur schwierig ausgedrückt werden, während für sein Ausdrücken mit SWF nur einige einfache Java-Codezeilen samt AWS Flow Framework-Anmerkungen nötig sind.
Das Generieren von Panoramen wird ebenfalls als Workflow implementiert. Aus taktischen Gründen werden Panoramen an jedem Standort generiert, an dem Rover parkt und Bilder aufnimmt. Deshalb wird das Panorama immer dann, wenn ein neues Bild von einem bestimmten Standort ankommt, durch die neu verfügbaren Informationen erweitert. Aufgrund der enormen Größe der Panoramen und der Anforderung, sie schnellstmöglich zu erstellen, muss die Aufgabe aufgeteilt und auf zahlreichen Computern abgestimmt werden. Der von den Ingenieuren verwendete Algorithmus teilt das Panorama in mehrere große Zeilen. Die erste Aufgabe im Workflow ist das Generieren der einzelnen Zeilen basierend auf den am Standort verfügbaren Bildern. Nach ihrer Generierung werden die Zeilen in mehrere Auflösungen skaliert und zur Nutzung durch Remote-Clients in Kacheln unterteilt. Mithilfe des umfassenden Funktionsangebots von Amazon SWF haben JPL-Ingenieure diesen Anwendungsfluss als Amazon SWF-Workflow ausgedrückt.
Ein Opportunity Pancam-Mosaik der Gesamtgröße 11280 × 4280 Pixel mit 77 Farbbildern. Kacheln mit sechs Detailstufen sind erforderlich, um dieses Bild mit einer frei wählbaren Größe an den Betrachter zu übermitteln. Die gelben Rasterlinien geben die für jedes Bild erforderlichen Kacheln an. Die Panoramen für das Instrument Mastcam des Mars Science Laboratory bestehen aus 1296 Bildern mit einer Auflösung von knapp 2 Gigapixel! Unten sehen Sie das entsprechende Panoramabild.
Durch die in der Cloud verfügbare Orchestrierung bietet Amazon SWF JPL die Möglichkeit zur Ressourcennutzung innerhalb und außerhalb seiner Umgebung und zur nahtlosen Verteilung von Anwendungsausführungen in der öffentlichen Cloud. So können die Anwendungen dynamisch skaliert werden und in einer wirklich verteilten Weise ausgeführt werden.
Viele Datenverarbeitungs-Pipelines von JPL sind als automatisierte Arbeitsprozesse zum Hochladen von durch Firewalls geschützten Daten sowie als Arbeitsprozesse zur parallelen Datenverarbeitung sowie zum Herunterladen von Ergebnissen strukturiert. Die Arbeitsprozesse zum Hoch- und Herunterladen werden auf lokalen Servern ausgeführt. Die Arbeitsprozesse zur Datenverarbeitung können sowohl auf lokalen Servern als auch Amazon EC2-Knoten ausgeführt werden. Mithilfe der Routingfunktionen in Amazon SWF haben JPL-Entwickler Arbeitsprozesse dynamisch in die Pipeline integriert und nutzen dabei Arbeitsprozesse wie die Standortbindung von Daten aus. Diese Verarbeitungsanwendung zeichnet sich außerdem durch hohe Verfügbarkeit aus, da beim Ausfall lokaler Arbeitsprozesse die Verarbeitung Cloud-basierter Arbeitsprozesse fortgesetzt wird. Da Amazon SWF keine Einschränkung hinsichtlich des Standorts der Arbeitsprozessknoten auferlegt, führt JPL Aufträge in mehreren Regionen und auch in seinen lokalen Rechenzentren aus, um für missionskritische Systeme die höchstmögliche Verfügbarkeit zu bieten. Sobald Amazon SWF in mehreren Regionen verfügbar ist, plant JPL ein regionsübergreifendes automatisches Failover zu SWF.
Die Nutzung von Amazon SWF durch JPL ist nicht auf Datenverarbeitungsanwendungen begrenzt. Mithilfe der Planungsfunktionen in Amazon SWF haben JPL-Ingenieure ein verteiltes Cron-Auftragssystem entwickelt, das missionskritische Operationen zeitgerecht und zuverlässig ausgeführt hat. Zusätzlich zur Verfügbarkeit hat sich JPL eine beispiellose, zentralisierte Transparenz für diese verteilten Aufträge mithilfe der Anzeigefunktionen von Amazon SWF verschafft, die über die AWS Management Console zur Verfügung stehen. JPL hat sogar eine Anwendung entwickelt, mit der wichtige Daten im MER in Amazon S3 gesichert werden. Mittels verteilter Cron-Aufträge aktualisiert JPL die Sicherungen und prüft außerdem die Integrität der Daten entsprechend dem für das Projekt gewünschten Zeitplan. Alle Schritte dieser Anwendung einschließlich Verschlüsselung, Hochladen in S3, Zufallsauswahl der zu prüfenden Daten und die tatsächliche Prüfung durch einen Vergleich mit standortinternen Daten mit S3 werden zuverlässig mithilfe von Amazon SWF aufeinander abgestimmt. Darüber hinaus haben mehrere JPL-Teams ihre vorhandenen Anwendungen für die Nutzung der Abstimmungsfunktionen der Cloud rasch migriert, indem auf die Programmierunterstützung zurückgegriffen wurde, die über das AWS Flow Framework zur Verfügung steht.
JPL nutzt weiterhin Hadoop für einfache Datenverarbeitungs-Pipelines und Amazon SWF ist nun erste Wahl für die Implementierung von Anwendungen mit komplexen Abhängigkeiten zwischen den Verarbeitungsschritten. Entwickler nutzen nun auch häufig die Diagnose- und Analysefunktionen der AWS Management Console, um Anwendungen während der Entwicklung zu debuggen und verteilte Ausführungen nachzuverfolgen. Mit Amazon SWF können geschäftskritische Anwendungen, deren Entwicklung, Tests und Bereitstellung bisher Monate dauerte, innerhalb weniger Tage fertiggestellt werden.