Wie Sie die Latenz von AWS Lambda mit benutzerdefinierten Laufzeiten reduzieren

Wenn Sie AWS Lambda-Funktionen verwenden, möchten Sie in der Regel so schnell wie möglich eine Antwort an den Client zurückgeben. Stellen Sie sich jedoch eine Situation vor, in der Sie die Antwort für den Client berechnen und nach dem Senden der Antwort an den Client noch einige Aktionen durchführen möchten (z.B. einige Metriken schreiben). Da AWS Lambda-Standardfunktionen keine Aktionen nach der Rückgabe der Antwort zulassen, kommt es für den Client zu einer zusätzlichen Latenzzeit aufgrund der anderen Aktionen, die zuerst abgeschlossen werden müssen. In diesem Blog wird erklärt, wie Sie mit benutzerdefinierten AWS Lambda-Laufzeiten die zusätzliche Latenz verringern und trotzdem die zusätzliche Verarbeitung durchführen können.

Der Pseudocode unten zeigt eine einfache Standard-Lambda-Funktion. Nach der Rückgabe der Antwort durch die Funktion handler() ist keine weitere Verarbeitung möglich.

handler(event, context):
  response = process(event)
  // You have to do your additional processing here...
  return response
  // ... since it is not possible here

Durch die Verwendung von benutzerdefinierten AWS Lambda-Laufzeiten erhalten Sie mehr Kontrolle über den Ausführungskontext der Lambdas. Mit benutzerdefinierten Laufzeiten können Sie das sogenannte Lambda Skript steuern. Dies ist im Grunde eine Endlosschleife, die:

• Ruft eine nächste eingehende Anfrage über die AWS Lambda Runtime API ab
• Ruft den eigentlichen Lambda-Funktionscode auf, um die Antwort zu erhalten
• Senden Sie die Antwort über die AWS Lambda Runtime API an den Client zurück.

Bei Standard-Lambdas haben Sie keinen Zugriff auf dieses bootstrap Skript und die AWS Lambda Runtime API. AWS stellt das Bootstrap-Skript bereit, das es in dieser Situation für Sie bereitstellt/verwendet.

In Pseudocode sehen bootstrap und der Lambda-Funktionscode wie folgt aus (siehe dieses Beispiel, um ein Beispiel mit Bash-Skripten zu sehen):

bootstrap script:
while true:
  get evenData and requestID from Lambda Runtime API next invocation endpoint
  response = invoke lambda handler with evenData
  post response to Lambda Runtime API response endpoint using requestID
Lambda code:
handler(eventData):
  response = process(evenData)
  // Again, you have to do your additional processing here...
  return response
  // ... since it is not possible here

Wie Sie in diesem Setup sehen können, gibt es nach der Rückgabe der Antwort durch den Lambda-Handler keine weitere Verarbeitung, die durchgeführt werden kann. Durch die Verwendung von AWS Lambda Custom Runtimes haben wir jedoch die Kontrolle über das bootstrap Skript, was uns mehr Möglichkeiten eröffnet. Der Trick, um eine zusätzliche Verarbeitung zu ermöglichen, besteht darin, das Senden der Antwort an den Lambda-API-Antwortendpunkt vom Bootstrap-Skript auf den Lambda-Funktionshandler selbst zu verlagern.

Der Lambda-Funktionshandler kann jetzt:

• Senden Sie zunächst die Antwort an die Antwort-API der Lambda Runtime
• Führen Sie dann die zusätzliche Verarbeitung durch
• Und schließlich geben Sie die Kontrolle an das Skript bootstrap zurück, das dann die Details des nächsten Lambda-Aufrufs abruft.

In Pseudocode ausgedrückt würde dies lauten:

bootstrap script:
while true:
  get evenData and requestID from Lambda Runtime API next invocation endpoint
  responseEndpointUrl = create url with requestID and Lambda Runtime API response endpoint
  invoke lambda handler with evenData and responseEndpointUrl
Lambda code:
handler(eventData, responseEndpointUrl):
  response = process(evenData)
  post response to responseEndpointUrl
  // Now we dan do the additional processing...
  Do the addition processing
  // ... before returing control to the bootstrap script
  return

Auf diese Weise erhält der Client die Antwort so schnell wie möglich, während es noch möglich ist, weitere Verarbeitungen vorzunehmen, nachdem die Antwort gesendet wurde.

Wir haben diese Lösung erfolgreich in unserem Serverless Scientist-Projekt eingesetzt. Weitere Einzelheiten finden Sie im Bootstrap-Skript, in der Funktion lambda_handler() und in der Einrichtung des Scientist Lambdas in der Datei serverless.yml. Wir haben das Serverless Framework verwendet und die Lambdas in Python implementiert, aber diese Lösung kann natürlich auch mit anderen Sprachen und Frameworks umgesetzt werden.

Ich bin neugierig, was Sie von dieser Lösung halten. Können Sie sie auch anwenden? Kann sie verbessert werden? Lassen Sie es uns in den Kommentaren wissen.