Serverlose Datenpipeline auf AWS

Das Problem

Für die Preisprognose brauchte das Unternehmen breite, aktuelle Marktdaten. Ziel waren rund 5 Millionen Inserate pro Tag über die 7 Fahrzeugmarken, mit denen es handelt.

Die Pipeline musste zuverlässig sein, im Budget bleiben und mit einer Quelle zurechtkommen, die begrenzt, wie schnell sie gelesen werden kann.

Architektur

1. Zeitplan EventBridge startet jeden Crawl-Zyklus. Eine kleine Lambda-Funktion setzt die Tagesziele zurück.
2. Warteschlange SQS hält die anstehende Arbeit und ersetzte einen früheren Ansatz, der die Datenbank als Queue nutzte. Fehlgeschlagene Nachrichten landen in einer Dead-Letter-Queue.
3. Worker Lambda-Funktionen, als Docker-Images verpackt, laden und parsen Seiten parallel.
4. Speicherung Inserate landen in RDS PostgreSQL, mit RDS Proxy für Connection Pooling. Schreibvorgänge sind inkrementell und atomar.
5. Alarme CloudWatch-Metriken und -Alarme, mit Benachrichtigungen über SNS.

• Retry und RecoverySichere Zielvergabe, Wiederholungsversuche, Wiederherstellung hängender Jobs und DLQ-Redrive
• Monitoring-LambdaNur lesender Job, der den Zustand der Datenbank an CloudWatch meldet
• Health ChecksAWS-CLI-Skripte, die auf jedem Betriebssystem laufen

Lieber drosseln als ausfallen

Eine Datenquelle, die die Anfragerate begrenzt, wehrt sich irgendwann. Die Pipeline war darauf ausgelegt:

• Circuit Breaker. Wenn Seiten blockiert werden, pausieren die Worker, statt es noch heftiger zu versuchen. Ein gemeinsamer Cooldown-Zustand liegt in PostgreSQL.
• Adaptives Rate Limiting. Die Abstände zwischen Anfragen haben Jitter, die Pipeline fährt automatisch zurück, wenn die Quelle sich wehrt, und die Worker fahren nach einem Cooldown schrittweise wieder hoch.
• Sichere Nebenläufigkeit. Worker übernehmen Ziele sicher, wiederholen Fehlversuche und holen hängende Jobs zurück, sodass viele von ihnen parallel laufen können, ohne sich in die Quere zu kommen.

Observability und Betrieb

• Alarme für das, was zählt. CloudWatch benachrichtigt mich, wenn der Orchestrator stehen bleibt, Worker fehlschlagen, Lambda sie drosselt, die Queue sich staut oder ihre Nachrichten alt werden, Seiten blockiert werden, Datenbank-Schreibvorgänge fehlschlagen oder die tägliche Zahl der Inserate sinkt.
• Health Checks. AWS-CLI-Skripte prüfen die Pipeline von jedem Rechner aus, und eine kleine, nur lesende Lambda-Funktion meldet den Zustand der Datenbank an CloudWatch.
• Schriftliche Abläufe. Sie beschreiben, wie man die Lambdas drosselt oder stoppt und die Queues leert, damit ein außer Kontrolle geratener Job keine Kosten in die Höhe treiben kann.

Härtung nach dem Senior-Review

Ein erfahrenes Teammitglied hat die Pipeline geprüft, und ich habe sie nach diesem Review gehärtet:

• Jede Datenbankabfrage hat ein Zeitlimit, und jeder Schreibvorgang ist atomar.
• Worker rufen nur URLs von einer Allowlist ab und weisen zu große Antworten zurück.
• Eine Seite, die verdächtig leer zurückkommt, schlägt sofort fehl, und jeder Fehler wird mit seinem Kontext festgehalten.
• Ich habe ein teures COUNT(*) aus dem Hot Path entfernt und Werkzeuge für die Indexpflege ergänzt.
• Aufbewahrungsrichtlinien für ECR-Images und CloudWatch-Logs halten die Speicherkosten niedrig.

Ergebnisse

• 5 Mio./Tagdas Ziel, im Test auf der kleinsten RDS-Instanz erreicht
• ~5.000/Tagdie Rate, die die Begrenzung der Quelle in Produktion zuließ
• TäglichErfassung, Speicherung und Alarme in Produktion
• 7 Markenabgedeckt für die Preisanalysen des Unternehmens

Was ich gelernt habe: Die Pipeline konnte 5 Millionen Inserate pro Tag verarbeiten, die Quelle aber nicht. Als die Quelle ihre Ratenbegrenzung verschärfte, sank die dauerhaft mögliche Rate auf rund 5.000 Inserate pro Tag, und das wurde zum Normalbetrieb. In dieser Größenordnung setzt die Datenquelle die Grenze, nicht die Infrastruktur. Das Zurückfahren muss deshalb vom ersten Tag an Teil des Designs sein.

Diese Seite enthält keinen Code des Arbeitgebers, keine internen Daten und keine privaten URLs, und sie nennt die Datenquelle nicht.