Event-Quellenzuordnungen und Stream-Verarbeitung

Serverlose Anwendungen mit AWS Lambda

Claudio Canales

Senior DevOps Engineer

Wo Event-Quellenzuordnungen passen

Queues und Streams werden oft in Batches gepollt.
Event-Quellenzuordnungen steuern Polling und Batching.

Position der Event-Quellenzuordnung

Was ist eine Event-Quellenzuordnung?

Eine Ressource, die eine Quelle mit deiner Funktion verbindet.
Lambda pollt die Quelle nach Records.
Lambda ruft deinen Handler mit einem Batch auf.

Ablauf der Event-Quellenzuordnung

Push vs. Poll (warum es zählt)

Push-Modell

Push-Quellen senden Events sofort.
Beispiel: ein Upload zu Amazon S3.

Poll-Modell

Poll-Quellen werden von Lambda abgefragt.
Lambda baut einen Batch und ruft deinen Handler auf.
Das ändert Latenz und Retry-Verhalten.

Push- vs. Poll-Modelle

Queue vs. Stream

Queue (Amazon SQS)

Verwaltete Nachrichten-Warteschlange, wie ein Posteingang.

Stream (DynamoDB Streams)

Änderungsprotokoll einer DynamoDB-Tabelle.
Beides kommt als Records, aber mit unterschiedlicher Bedeutung.

Vergleich: Queue vs. Stream

Batch-Event-Form (vereinfacht)

{
  "Records": [{
    "messageId": "abc-123",
    "body": "{\"order_id\": \"A-42\"}"
  }]
}

Die meisten Mapping-Events beginnen mit Records.
Jedes Record hat messageId und einen body-String.
body in dein eigenes Payload-Format parsen.

Walkthrough: jedes Record verarbeiten

def lambda_handler(event, context):
    records = event.get("Records", [])
    for record in records:
        body = record.get("body", "")
        print("BODY:", body)
    return {"statusCode": 200}

Records mit Standardliste lesen.
Durch jedes Record iterieren und body sicher lesen.
Nötiges loggen, dann zurückgeben.

Walkthrough: JSON-Body parsen

import json

def lambda_handler(event, context):
    record = event.get("Records", [])[0]
    payload = json.loads(record.get("body", "{}"))
    order_id = payload.get("order_id")
    print("ORDER_ID:", order_id)
    return {"statusCode": 200}

json importieren und body mit sicherem Default lesen.
Mit json.loads zu einem Dict parsen.
Benötigte Felder extrahieren; vorher validieren.

Batching: Batchgröße und -fenster

Batchgröße: Anzahl Records pro Aufruf.
Batchfenster: Wartezeit, bis Lambda den Batch füllt.
Größere Batches erhöhen Durchsatz, aber pro Lauf mehr Arbeit.
Für SQS ApproximateAgeOfOldestMessage für Rückstau beobachten.

Trade-off bei Batchgröße

Trade-offs bei der Batchgröße

Große Batches sind effizient, können aber Latenz erhöhen.
Kleine Batches senken Time-to-First-Processing, erhöhen Aufrufe.
Wähle passend zu deiner Workload.

Batchgröße vs. Latenz

Skalieren mit Concurrency

Mehrere Batches werden gleichzeitig verarbeitet.
Höhere Concurrency erhöht den Durchsatz.
Erhöht aber auch die Last nachgelagerter Systeme.

Parallele Batch-Verarbeitung

Nachgelagerte Systeme schützen

Zu viel Concurrency kann Datenbank oder API überlasten.
Mit Limits die Last steuern.
Kleine, sichere Arbeitseinheiten bevorzugen.

Schutz vor nachgelagerter Last

Teilweise Batch-Fehler

Ein Batch kann gute und fehlerhafte Records enthalten.
Ohne Teilfehler führt ein schlechtes Record zum Retry des ganzen Batches.
Teilfehler erlauben Retries nur für die fehlgeschlagenen Items.

Ablauf bei Teilfehlern im Batch

Walkthrough: Teilfehler melden (SQS)

def lambda_handler(event, context):
    failures = []
    for record in event.get("Records", []):
        try:
            process(record)
        except Exception:
            failures.append({"itemIdentifier": record["messageId"]})
    return {"batchItemFailures": failures}

messageIds fehlgeschlagener Records in batchItemFailures sammeln.
Lambda wiederholt nur diese Items.
Erfolgreiche Records werden nicht erneut gesendet.

Wichtigste Punkte

Event-Quellenzuordnungen pollen Queues und Streams.
Sie liefern Records in Batches an deinen Handler.
Batchgröße und -fenster tauschen Latenz gegen Durchsatz.
Teilfehler vermeiden erneute Verarbeitung erfolgreicher Items.

Zusammenfassung der Zuordnung

Lass uns üben!

Serverlose Anwendungen mit AWS Lambda