AWS Batch statt Lambda für bestimmte Workloads verwenden
AWS Batch führt große Jobs auf EC2-Instanzen mit Docker-Images aus. Das Tool ist eine Alternative für Workloads, die für AWS Lambda nicht gut geeignet sind.
Große oder komplexe Workloads stellen für Entwickler eine Herausforderung dar. Sie müssen oft viel Zeit in die Verwaltung von Ressourcen investieren, wenn die Anwendungsleistung nachlässt. Mit AWS Batch können IT-Entwickler eine große Anzahl von Batch-Computing-Aufträgen innerhalb der AWS-Cloud ausführen.
AWS Batch führt große Jobs auf EC2-Instanzen (Elastic Compute Cloud) mit Docker-Images aus. Das Tool ist eine Alternative zu Workloads, die für AWS Lambda nicht besonders gut geeignet sind. Entwickler, die mit Amazon EC2 Container Service (ECS) und Amazon Simple Queue Service (SQS) vertraut sind, sollten mit dem ähnlich designten AWS Batch keine Schwierigkeiten haben.
ECS erlaubt keine automatische Bereitstellung von Instanzen, die auf der benötigten Kapazität basieren. Wenn vorhandene ECS-Instanzen die maximale Kapazität erreicht haben, lässt der Service keine zusätzlichen Tasks zu. AWS Batch löst dieses Problem mit einer Konfiguration, die dem Auto Scaling in einer ECS-ähnlichen Umgebung ähnelt.
Im Grunde ist AWS Batch nur ein weiteres Tool zur Verwaltung von Aufgaben, die auf AWS ausgeführt werden sollen. IT-Teams müssen dabei für die zugrunde liegenden Ressourcen bezahlen, die der Dienst verwendet. Entwickler können AWS Batch so konfigurieren, dass ein Mindestmaß an Kapazität erhalten bleibt. Man sollte also vorsichtig sein und ungenutzte Computerumgebungen aufräumen – oder zumindest die Mindestkapazität für Umgebungen, die nicht mehr verwendet werden, entfernen.
ECS ermöglicht es Entwicklern, lange oder ständig laufende Aufgaben mit Unterstützung durch Automated Scaling auszuführen. AWS Batch ist allerdings nicht gut geeignet, um Benutzeranfragen zu bearbeiten oder Aufgaben auszuführen, die nie abgeschlossen werden. Es sollte auch nicht für Aufgaben verwendet werden, die schnell erledigt werden müssen. In diesem Fall ist es besser, diese auf AWS Lambda auszuführen.
AWS Batch ist in drei Teile gegliedert: Compute-Umgebungen, Queues und Jobdefinitionen.
Compute-Umgebungen
Eine Compute-Umgebung definiert, wie EC2-Instanzen für die Verarbeitung von Jobs bereitgestellt werden. AWS Batch sollte man verwenden, um Spot Instances automatisch bereitzustellen. Damit wird man den Anforderungen des Workloads gerecht und kann Geld sparen.
AWS Batch führt große Jobs auf EC2-Instanzen mit Docker-Images aus. Das Tool ist eine Alternative zu Workloads, die für AWS Lambda nicht besonders gut geeignet sind.
IT-Teams können Compute-Umgebungen so konfigurieren, dass eine minimale Kapazität für die schnelle Verarbeitung von AWS Batch Jobs erhalten bleibt. Alternativ lassen sich AWS Batch Jobs so einrichten, dass die Kapazität nur bei Bedarf erhöht wird. Eine Compute-Umgebung richtet einen ECS-Cluster und eine Auto-Scaling-Gruppe ein. Diese übernehmen die automatische Skalierung, verwalten die Redundanz und ermöglichen Fehlertoleranz.
Queues
Entwickler senden AWS Batch Jobs an Warteschlangen, die Anfragen zur Verarbeitung von Aufträgen enthalten und diese an Prozesse in der Compute-Umgebung weiterleiten. Solche Queues, die mit einer oder mehreren Compute-Umgebungen verbunden sind, ermöglichen es Entwicklern, bestimmte Aufgaben zu priorisieren.
Am besten richtet man mehrere Compute-Umgebungen ein, damit bestimmte Tasks mit On-Demand Instances schneller ausgeführt werden können, während die Burst-Kapazität gezielt auf Spot Instances ausgerichtet ist.
Unser Unternehmen verarbeitet mit Queues zum Beispiel Pressemitteilungen und Blogeinträge. Pressemitteilungen haben hohe Priorität und sind zeitkritisch, Blogartikel nicht. Deshalb haben wir eine Warteschlange mit hoher Priorität für Pressemitteilungen und eine Warteschlange mit Standardpriorität für Blogartikel eingerichtet. Beide Queues werden sowohl in einer On-Demand-Instanzumgebung als auch in einer Spot-Instanzumgebung verarbeitet. Die On-Demand-Instanzumgebung verfügt über genügend Kapazität, um alle Pressemitteilungen zu verarbeiten – mit einigen zusätzlichen Kapazitäten für einen plötzlichen Anstieg.
Während der normalen Nutzung verfügt die On-Demand-Instanzumgebung für die Verarbeitung der Blogartikel über eine gewisse Restkapazität. Steigt die Zahl der Pressemitteilungen sprunghaft an, kann die zusätzliche Kapazität für Pressemitteilungen genutzt werden. Blogeinträge werden dann in die Spot-Instanzumgebung verschoben, die möglicherweise nicht genügend Kapazität hat, um sofort mit allem Schritt zu halten. Wenn die Pressemitteilungen weniger werden, können Blogartikel die zusätzliche Kapazität in der On-Demand-Instanzumgebung wieder in Anspruch nehmen.
Jobdefinitionen
Eine Jobdefinition ist eine bestimmte Art von Anforderung, die Informationen über den Docker-Container enthält. Dazu gehören Konfigurationsdetails und Befehle, die ausgeführt werden müssen. Jobdefinitionen sind das AWS Batch-Äquivalent zu ECS-Tasks. Jede Definition besteht aus einem Befehl und einem Input für den Befehl, damit dieser auf einem bestimmten Docker-Image ausgeführt werden kann. Entwickler übermitteln die Jobdefinitionen an Warteschlangen, die dann in Compute-Umgebungen ausgeführt werden.
Jobdefinitionen können jedes Standard-Docker-Image von Docker Hub ausführen – oder benutzerdefinierte Docker-Images von Amazon EC2 Container Registry. Beim Absetzen eines einzelnen Jobs können Entwickler auch jede der Befehls- oder Konfigurationsvariablen ausschalten.
Einreichen von Batch-Jobs aus SDKs
Während das Absetzen von Jobs über die AWS Management Console ein möglicher Startpunkt ist, müssen die meisten Anwendungen periodisch und programmatisch Jobs absetzen. Die AWS SDKs bieten für jede Sprache verschiedene Methoden, um Jobs zu übermitteln. Entwickler können jede Einstellung in der Jobdefinition überschreiben, wenn sie einen neuen Job einreichen. Jede Absetzung eines Jobs führt eine oder mehrere Aufgabeninstanzen aus – werden Aufträge eingereicht, erhöht sich die benötigte Gesamtkapazität, um die zusätzliche Arbeitslast zu bewältigen.
Im Gegensatz zu ECS bleibt der Job in der Warteschlange und wartet auf mehr Kapazität, falls keine Kapazität mehr vorhanden ist. Zusätzlich skaliert die Compute-Umgebung automatisch auf die maximale Kapazität und hält sich an andere Einschränkungen, wie zum Beispiel die Spot-Instance-Preise.
Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!
