Een taak kan bij tien doelen stabiel werken en bij duizenden minder betrouwbaar worden. Foutclassificatie en deduplicatie, rate limiting en concurrency, hervatten na uitval, problemen met netwerkuitgangen, consistentiecontroles en enkele kernmetingen worden pas op schaal echt belangrijk.
Een verzamelscript kan op tien doelen probleemloos draaien en bij duizenden doelen ineens succespercentage verliezen. Je voegt retries toe, wisselt proxies en stelt de concurrency bij, maar dezelfde problemen blijven terugkomen. Bij nader onderzoek blijkt de bottleneck vaak niet in de parsinglogica te zitten, maar in een paar ontbrekende technische lagen. Op kleine schaal vallen die problemen meestal niet op.
Classificeer fouten eerst, dan hebben retries betekenis
Bij dataverzameling zijn fouten onvermijdelijk. Belangrijk is dat je ze indeelt: netwerkfluctuaties en verbroken verbindingen kun je direct opnieuw proberen; bij tijdelijke rate limiting moet je met backoff wachten voordat je opnieuw probeert; als een wijziging in de paginastructuur tot lege parsingresultaten leidt, helpen zelfs tienduizend retries niet en moet je dit registreren en alarmeren; als het doel niet bestaat, markeer je de taak als voltooid; als een omgeving of netwerkuitgang niet opstart, wissel je naar een andere en probeer je opnieuw.
Alles zonder onderscheid opnieuw proberen is een van de makkelijkste fouten. Problemen die menselijke tussenkomst nodig hebben verdwijnen dan achter lussen, terwijl quota en uitgangen onnodig worden verbruikt. Backoff is ook nodig: vergroot het interval tussen pogingen, anders komt een hele batch in hetzelfde tijdvenster opnieuw terug en wordt de rate limiting juist erger.
Retries leiden direct naar deduplicatie. Een taak kan door retries meerdere keren worden uitgevoerd, dus elke taak heeft een stabiele unieke identificatie nodig, bijvoorbeeld de waarde na URL-normalisatie, en writes naar de database moeten op basis daarvan idempotent zijn. Anders leveren meer retries alleen meer vervuilde data op.
Rate limiting en concurrency zijn twee verschillende zaken
Meer concurrency betekent niet automatisch meer throughput. Drie beperkingen spelen tegelijk: hoeveel de doelsite aankan voordat rate limiting de totale throughput verlaagt, het lokale geheugen en de CPU, en of één omgeving of sessie meerdere taken tegelijk kan uitvoeren.
Een stabielere aanpak is om met lage concurrency te beginnen en de belasting geleidelijk te verhogen, terwijl je succespercentage en responstijd samen bekijkt om het omslagpunt te vinden waar de prestaties duidelijk verslechteren. Rate limiting is iets anders: het bepaalt het toegangstempo tot hetzelfde doel en is niet hetzelfde als globale concurrency. Als een batch taken over meerdere sites verdeelt, moet elke site een eigen tempo krijgen.
Hervatten na uitval vraagt om persistente status
Bij een taak die uren draait, is een onderbreking normaal; helemaal opnieuw beginnen is vaak te duur. De voorwaarde is dat de status wordt opgeslagen: wachtend, bezig, voltooid, plus het aantal retries, het eerstvolgende toegestane uitvoermoment en het fouttype. Bij het starten van het proces moet de wachtrij uit opslag worden hersteld in plaats van uit het geheugen opnieuw te worden opgebouwd.
Een wachtrij alleen in het geheugen bijhouden is een veelvoorkomende implementatie die goed lijkt te werken. Zodra het proces uitvalt, verdwijnen alle wachtende taken en kloppen de aantallen niet meer.
Behandel proxy- en netwerkuitgangsfouten apart
Een uitgang die door het doel wordt geblokkeerd, een proxy die offline gaat of een regionale node die wegdrijft, blijft op grote schaal gebeuren. Dat zijn geen uitzonderingen maar normale omstandigheden. Behandel uitgangen als vervangbare resources: bepaal bij een fout eerst of het doel rate limiting toepast of de uitgang niet beschikbaar is; gebruik backoff in het eerste geval en wissel de uitgang en probeer opnieuw in het tweede. Houd ook het foutpercentage per uitgang bij en verwijder groepen die duidelijk verslechteren.
Als alle taken daarentegen één uitgang delen, kan één taak de verbinding verstoren en alles daarna raken. Voor diagnose moet je dan via de logs terugzoeken welke taak de oorzaak was.
Controleer dataconsistentie
Een geslaagde run betekent niet dat de data correct is. Na het opslaan moet je een paar vragen kunnen beantwoorden: komt het aantal voltooide taken overeen met het aantal opgeslagen rijen, welk aandeel parsingresultaten is leeg, is het percentage ontbrekende kritieke velden ongewoon gestegen en hoeveel dubbele rijen zijn er?
Deze controles hoeven niet ingewikkeld te zijn. Steekproeven per batch zijn voldoende, maar iemand moet de resultaten bekijken. Op grote schaal kan foutieve data lastiger zijn dan geen data.
Welke metrics moet je volgen
Je hebt niet veel metrics nodig. Enkele die de gezondheid van het systeem weergeven zijn genoeg.
- Succespercentage en verdeling van fouttypen, om te zien welke fouten toenemen
- Lengte van de takenwachtrij en gemiddelde wachttijd; een voortdurend groeiende achterstand wijst op een mismatch tussen instroom en verwerkingscapaciteit
- Aantal actieve omgevingen en bijbehorende processen; langdurige groei in één richting duidt vaak op lekken in resource-opruiming
- Output per tijdseenheid, om te bepalen of rate limiting de throughput afknijpt
- Foutpercentage van netwerkuitgangen, om te beslissen of een groep nodes moet worden vervangen
Als één van deze metrics langere tijd in dezelfde richting blijft bewegen, controleer dan eerst resource-opruiming en retrylogica.
Maak de omgevingslaag zelfstandig
Alles bij elkaar leidt tot dezelfde conclusie: de omgevingslaag moet los van de scripts worden beheerd. Pooling vereist dat omgevingen centraal kunnen worden ingepland in plaats van verspreid over scripts; resource-opruiming vraagt om opvraagbare status in plaats van dat elk script zichzelf probeert te redden; opnieuw proberen met een andere omgeving of uitgang werkt alleen als omgevingen onafhankelijk kunnen worden gepland.
Scripts beheren de logica; de omgevingslaag beheert resources en identiteit. In zo'n architectuur vervult PurpleMark die laag door omgevingsresources te bieden die in batches kunnen worden aangemaakt, aan onafhankelijke netwerkuitgangen kunnen worden gekoppeld en waarvan de status kan worden opgevraagd.
Compliancegrenzen
Kunnen opschalen betekent niet dat je willekeurig data mag verzamelen. Volg de robots-regels en servicevoorwaarden van de doelsite, verzamel geen persoonlijke informatie, omzeil geen technische beschermingsmaatregelen en beperk de requestfrequentie zodat de normale dienstverlening niet wordt verstoord. Stabiliteit is een technisch vraagstuk; of verzamelen is toegestaan is een ander vraagstuk. Aan beide voorwaarden moet worden voldaan.
