Mapping delle origini evento e stream processing

Applicazioni serverless con AWS Lambda

Claudio Canales

Senior DevOps Engineer

Dove si inseriscono le event source mapping

Code e stream sono spesso interrogati in batch.
Le event source mapping gestiscono polling e batching.

Posizione delle event source mapping

Cos'è una event source mapping?

Una risorsa che collega una sorgente alla tua funzione.
Lambda interroga la sorgente per i record.
Lambda invoca l'handler con un batch.

Flusso event source mapping

Push vs poll (perché conta)

Modello push

Le sorgenti push inviano eventi subito.
Esempio: un upload su Amazon S3.

Modello poll

Le sorgenti poll vengono controllate da Lambda.
Lambda crea un batch e invoca l'handler.
Questo cambia latenza e retry.

Modelli push vs poll

Coda vs stream

Coda (Amazon SQS)

Una coda di messaggi gestita, come una inbox.

Stream (DynamoDB Streams)

Un log delle modifiche di una tabella DynamoDB.
Entrambi arrivano come Records, ma il significato cambia.

Confronto coda vs stream

Forma dell'evento batch (semplificata)

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

La maggior parte degli eventi mappati inizia con Records.
Ogni record ha un messageId e una stringa body.
Fai il parse di body nel tuo payload.

Walkthrough: processa ogni record

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

Leggi Records con una lista di default.
Itera i record e leggi body in modo sicuro.
Logga il necessario, poi ritorna.

Walkthrough: fai il parse del body JSON

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}

Importa json e leggi body con un default sicuro.
Fai il parse con json.loads per ottenere un dict.
Estrai i campi necessari; valida sempre prima.

Batching: batch size e batch window

Batch size: quanti record per invocazione.
Batch window: quanto Lambda attende per riempire un batch.
Batch più grandi migliorano il throughput ma aumentano il lavoro per run.
Per SQS, monitora ApproximateAgeOfOldestMessage per l'arretrato.

Diagramma compromesso batch size

Compromessi del batch size

Batch grandi sono efficienti ma aumentano la latenza.
Batch piccoli riducono il time-to-first-processing ma aumentano le invocazioni.
Scegli in base al carico.

Grafico batch size vs latenza

Scalare con la concorrenza

Più batch vengono elaborati in parallelo.
Maggiore concorrenza aumenta il throughput.
Ma aumenta anche il carico a valle.

Elaborazione batch concorrente

Proteggi i sistemi a valle

Troppa concorrenza può saturare un database o un'API.
Usa limiti per controllare il carico.
Preferisci unità di lavoro piccole e sicure.

Protezione dal carico a valle

Failure parziali del batch

Un batch può contenere record buoni e cattivi.
Senza failure parziali, un record errato ritenta l'intero batch.
La gestione delle failure parziali ritenta solo gli elementi falliti.

Flusso di failure parziale del batch

Walkthrough: segnalare failure parziali (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}

Raccogli i messageId dei record falliti in batchItemFailures.
Lambda ritenta solo quegli elementi.
I record riusciti non vengono reinviati.

Punti chiave

Le event source mapping interrogano code e stream.
Consegnano i Records in batch al tuo handler.
Batch size e window scambiano latenza con throughput.
Le failure parziali evitano di rielaborare i successi.

Diagramma riepilogo mapping

Ayo berlatih!

Applicazioni serverless con AWS Lambda