Blog

Vermeiden Sie kostspielige Schleifen in AWS Step-Funktionen

Joris Conijn

Aktualisiert Oktober 15, 2025
4 Minuten

Wir alle haben in unserer Laufbahn mit AWS StepFunctions herumgespielt. Es ist ein fantastisches Orchestrierungstool! Aber es gibt einige Szenarien, in denen Ihnen Ihre Cloud-Rechnung um die Ohren fliegen kann! In diesem Blog erkläre ich Ihnen, wie Sie in eine solche Situation geraten können und - was vielleicht noch wichtiger ist - wie Sie sie vermeiden können!

Schleife

Beispiel einer StepFunction-Schleife

Wenn Sie sich dieses Muster ansehen, denken Sie vielleicht, okay, wir warten 5 Sekunden und verwenden Lambda, um etwas abzufragen. Wenn die Antwort wahr ist, sind wir fertig. Wenn nicht, warten wir erneut und überprüfen den Status noch einmal. Das Problem bei diesem Muster ist, dass die Antwort möglicherweise nie wahr ist, was zu einer Endlosschleife führt, die Kosten verursacht. In StepFunctions gibt es keine Endlosschleifen. Wenn Sie sich in einer solchen "Endlosschleife" befinden, wird AWS die Ausführung beenden, sobald Sie 25.000 Ereignisse überschritten haben. Selbst wenn Sie sie implementieren, wird sie irgendwann von AWS gestoppt. Aber jede Schleife hat 3 Übergänge, und Sie müssen für diese Transaktionen bezahlen. Sie sind ziemlich billig, aber das Problem liegt in dieser Schleife, insbesondere wenn dieses Muster Teil einer Map-Verteilung ist, die Ihnen 10.000 parallele Ausführungen ermöglicht.

Angenommen, Ihre StepFunction wird auf der Grundlage eines S3-Ereignisauslösers aufgerufen. Wir laden 100 Dateien in unseren S3-Bucket hoch. Dadurch werden 100 Ausführungen ausgelöst, was zu 3.000.000 Zustandsübergängen alle 5 Sekunden führt, bis die 25.000 Ereignisse überschritten werden.

Sie sehen bereits, dass dies Ihre AWS-Rechnung in die Höhe treiben wird.

Das Rückrufmuster

StepFunction Rückrufmuster

Sie können dieses Problem lösen, indem Sie ein Callback-Muster implementieren. Es ist ganz einfach: Sie legen eine Nachricht in einer SQS-Warteschlange ab. Sie können dann einen beliebigen Verbraucher verwenden, um die anstehende Aufgabe zu erledigen. Wenn die Aufgabe erledigt ist, benachrichtigt der Verbraucher die Ausführung der Schrittfunktion und gibt das Ergebnis zurück.

Dies ist ein bekanntes Muster, aber wir entwerfen unsere Systeme für den Fall eines Fehlers! Das Tolle an einer SQS-Warteschlange ist ihr Wiederholungsmechanismus.

Rückrufmuster mit einer Warteschlange für tote Buchstaben

Jetzt können wir es wie folgt gestalten:

  1. Die StepFunction platziert die Aufgabe in der SQS-Warteschlange.
  2. Der Prozessor empfängt einen Stapel von Nachrichten
  3. Die Funktion verarbeitet jede Nachricht, und zwar für jede:
    1. Senden Sie einen Heartbeat an die Ausführung der StepFunction. Dadurch wird verhindert, dass die StepFunction eine Zeitüberschreitung erfährt.
    2. Wenn die Nachricht ungültig ist, können wir die Ausführung der StepFunction direkt abbrechen.
  4. Je nach Ergebnis, wird die Funktion:
    1. Wenn ein Fehler auftritt, wird die Nachricht in der Warteschlange gehalten.
      • Dadurch wird der Wiederholungsmechanismus auf der Grundlage der Sichtbarkeitseinstellungen in der Warteschlange ausgelöst.
    2. Wenn die Nachricht erfolgreich verarbeitet wurde, werden wir:
      • Senden Sie einen Erfolg an die StepFunction-Ausführung.
      • Entfernen Sie die Nachricht aus der Warteschlange.
  5. Wenn die Nachricht die maximale Anzahl von Wiederholungsversuchen erreicht hat, wird sie an die Warteschlange für tote Briefe weitergeleitet.
  6. Der Dead Letter Queue Processor erhält die Nachricht.
  7. Die Ausführung der StepFunction wird mit einem zusätzlichen Kontext fehlschlagen.
  8. Entfernen Sie die Nachricht aus der Warteschlange für tote Briefe.

Warum ist dies ein gutes Design? Weil es Fehlschläge einkalkuliert! Wir haben die eigentliche Verarbeitung hier ausgeklammert. Die Lambda-Verarbeitung kann jedoch aus vielen Gründen fehlschlagen:

  • Er kann die Grenzen von AWS Service erreichen.
  • Es könnte von einem anderen externen System abhängen, das nicht verfügbar ist.
  • Sie skalieren so schnell, dass die serverlosen Komponenten die Last noch nicht bewältigen können.

Mit der SQS-Warteschlange und dem Wiederholungsmechanismus haben Sie bessere Chancen auf Erfolg. Wenn die Wiederholungsversuche erschöpft sind, markiert die Dead-Letter-Warteschlange den Fehler in der Schrittfunktion selbst. Auf diese Weise haben Sie alle Ausführungsinformationen an einem einzigen Ort, den Sie analysieren können.

Fazit

Vermeiden Sie die Erstellung von Schleifen in Ihren StepFunctions. Verwenden Sie stattdessen das Callback-Muster! Entwerfen Sie Ihre Abläufe so, dass sie robust sind und rechnen Sie mit Fehlern!

Foto von Steve Johnson

Verfasst von

Joris Conijn

Joris is the AWS Practise CTO of the Xebia Cloud service line and has been working with the AWS cloud since 2009 and focussing on building event-driven architectures. While working with the cloud from (almost) the start, he has seen most of the services being launched. Joris strongly believes in automation and infrastructure as code and is open to learning new things and experimenting with them because that is the way to learn and grow.

Contact

Let’s discuss how we can support your journey.