Fallstudie: Scraping-System im laufenden Betrieb ersetzen – ohne Ausfallzeit

Im Jahr 2023 übernahm Coflnet ein Projekt für ein Werbeunternehmen aus Norddeutschland mit rund 10 Mitarbeitenden. Das Unternehmen setzte bereits seit Jahren ein gekauftes Web-Scraping-System ein und hatte damit Millionen von Artikeln von verschiedenen Webseiten gesammelt. Mit der Zeit stieß das Altsystem jedoch an seine Grenzen: Es wurde unzuverlässig, ineffizient und war nicht mehr in der Lage, die für das Unternehmen wichtigsten Seiten zuverlässig zu scrapen.

Das Unternehmen brauchte eine Web Scraping Dienstleistung, die gezielt die relevanten Webseiten erfasst, mit Layout-Änderungen und Anti-Scraping-Mechanismen umgehen kann und dem tatsächlichen Datenvolumen gewachsen ist. Hier kam Coflnet ins Spiel – wir hatten für diesen Kunden bereits zuvor ein anderes System mit gutem Ergebnis entwickelt, entsprechend naheliegend war es, auch dieses Projekt zu übernehmen.

Das Problem

Das zentrale Problem war nicht, bei null anzufangen, sondern ein bestehendes Altsystem abzulösen, auf das das Unternehmen im Tagesgeschäft angewiesen war – ohne dabei zu verlieren, was bereits aufgebaut worden war. Das eingekaufte System war überfordert: Zu oft wurden wichtige Informationen von Seiten nicht korrekt erfasst, was zu ungenauen Daten und in der Folge zu falschen Entscheidungen führte. Gleichzeitig waren mit dem alten System bereits mehrere Millionen Artikel gesammelt worden – das System konnte also nicht einfach abgeschaltet und von Grund auf neu aufgebaut werden.

Die Herausforderung bestand kurz gesagt darin, das Scraping-System ohne Ausfallzeit zu migrieren und gleichzeitig eine neue, optimierte Engine zu entwickeln, die sich auf die für das Werbeunternehmen tatsächlich relevanten Webseiten konzentrierte.

Die Vorgehensweise

Coflnet ging das Projekt mit zwei klaren Zielen an: Die vorhandenen Daten sollten zuverlässig und zugänglich bleiben, und es sollte ein neues Scraping-System entstehen, das schneller, robuster und besser auf die Anforderungen des Kunden zugeschnitten war.

1. Eine neue Scraping-Engine. Wir entwickelten eine völlig neue Scraping-Engine, ausgelegt auf die dynamische, sich ständig verändernde Struktur echter Webseiten und speziell auf die für das Werbeunternehmen wichtigsten Seiten zugeschnitten.
   • Die Scraper wurden so gebaut, dass sie anpassungsfähiger sind und mit Layout-Änderungen sowie Popups und Anti-Scraping-Mechanismen umgehen können, ohne auszufallen.
   • Das System wurde auf Geschwindigkeit optimiert, sodass neue Inhalte schnell gescraped und gespeichert werden konnten – die relevantesten Artikel für ein Werbeunternehmen sind meist die zuletzt veröffentlichten, Aktualität war also genauso wichtig wie Abdeckung.
2. Kompatibilität mit dem alten System. Die Daten aus der neuen Engine mussten mit allem funktionieren, was bereits rund um das alte System aufgebaut worden war. Deshalb speist das neue System dieselbe nachgelagerte Schnittstelle wie das alte Scraping-System – das Zielsystem und alles, was diese Daten weiterverarbeitet, funktionierte unverändert weiter.

Was „Scraping at Scale” grundsätzlich braucht

Dieses Projekt zeigt gut ein Muster, das immer dann auftritt, wenn Scraping vom „Skript, das funktioniert” zu einer Datenextraktion für Unternehmen werden muss, die dauerhaft läuft und der man vertrauen kann. Ein paar Punkte spielen dabei unabhängig von den konkreten Zielseiten eine Rolle:

• Rate Limiting. Anfragen müssen pro Domain gedrosselt statt so schnell wie möglich abgefeuert werden – sowohl um die Quelle nicht zu überlasten als auch um Blockierungen zu vermeiden, die die gesamte Pipeline lahmlegen.
• Robots.txt und Nutzungsbedingungen respektieren. Scraping at Scale bedeutet, die veröffentlichten Regeln jeder Quelle als Vorgabe für das Design des Crawlers zu behandeln, nicht als nachträgliche Ergänzung (das ist allgemeine Praxis, keine Rechtsberatung – vor dem Scraping einer konkreten Seite in größerem Umfang ist eine individuelle rechtliche Prüfung sinnvoll).
• Deduplizierung. Derselbe Artikel oder dieselbe Anzeige wird oft mehrfach erfasst, durch erneute Crawls oder verschiedene Einstiegspunkte. Ohne einen Dedup-Schritt wachsen Speicher- und Verarbeitungskosten ohne Mehrwert.
• Monitoring. Ein Scraper, der still anfängt, falsche oder leere Daten zu liefern, ist schlimmer als einer, der laut fehlschlägt – genau dieses Problem hatte das Altsystem in diesem Fall, und es ist mit ein Grund, warum es unzuverlässig wurde. Alarmierung bei sinkender Trefferquote oder veränderter Seitenstruktur fängt Fehler ab, bevor sie in den Daten landen.
• Skalierbare Speicherung. Millionen von Artikeln brauchen eine Speicherschicht, die auch bei wachsendem Datenvolumen schnell schreibt und liest, statt mit der Zeit langsamer zu werden.

Nichts davon ist spezifisch für Werbung oder Medienbeobachtung – es ist dieselbe Art von Problem für jeden, der Daten aus Quellen extrahiert, die er nicht selbst kontrolliert, und zwar in einem Umfang, bei dem manuelle Kontrolle keine Option mehr ist.

Ergebnisse

Die Migration zum neuen Scraping-System war ein voller Erfolg. Das Werbeunternehmen verfügt nun über eine schnelle, zuverlässige und gezielte Web Scraping Dienstleistung, die sich auf die für sie wichtigsten Webseiten konzentriert.

• Verbesserte Zuverlässigkeit. Das neue System ist deutlich genauer bei den gesammelten Informationen, was weniger Datenverluste und insgesamt bessere Datenqualität bedeutet.
• Schnelleres Scraping. Die optimierten Scraper sammeln und verarbeiten Informationen schneller, und die wichtigsten Seiten werden nun in einem kürzeren Interval gescraped als zuvor.
• Datenkontinuität. Dank des sorgfältigen Migrationsprozesses wurde eine Ausfallzeit vollständig vermieden – das Werbeunternehmen wechselte auf das neue System, ohne dass die Datenverfügbarkeit beeinträchtigt wurde.

Ausblick

Das neue System unterstützt das Werbeunternehmen weiterhin bei seinem Wachstum. Mit einer skalierbaren Datenbank und einer flexiblen Scraping-Engine ist das Unternehmen gut aufgestellt, um mehr Daten zu verarbeiten, in neue Märkte zu expandieren und sich an Veränderungen der Webseiten anzupassen, von denen es abhängt.

Dieses Projekt zeigt gut, warum das Ablösen eines Altsystems keine reine technische Neuentwicklung ist, sondern zuerst ein Migrationsproblem und erst danach ein Scraping-Problem. Scraping at Scale richtig umzusetzen bedeutet, dass sich das neue System schrittweise bewähren muss, bevor das alte tatsächlich abgeschaltet wird.

Häufige Fragen

Wie migriert man ein Scraping-System ohne Ausfallzeit? Indem das alte System weiterläuft, während das neue entwickelt und validiert wird, und indem das neue System dieselbe nachgelagerte Schnittstelle bedient wie das alte. So funktioniert alles, was die Daten weiterverarbeitet – Dashboards, Datenbanken, andere Dienste – während und nach der Umstellung unverändert weiter, und der Wechsel kann erfolgen, sobald sich das neue System bewährt hat, statt an einem festen Stichtag.

Warum wird ein bestehendes Scraping-System mit der Zeit unzuverlässig? Webseiten ändern ihr Layout, führen Anti-Scraping-Mechanismen wie Popups und Interstitials ein und verändern die Struktur ihrer Inhalte – ein System, das für den Stand einer Seite vor Jahren gebaut wurde, hinkt allmählich hinterher. Ohne laufende Wartung und Monitoring sinkt die Genauigkeit unbemerkt, bis den Daten nicht mehr zu trauen ist.

Wann lohnt es sich, ein Scraping-System neu entwickeln zu lassen, statt es zu flicken? Wenn das Fehlerbild strukturell statt gelegentlich ist – wenn ein System regelmäßig Daten falsch erfasst oder verpasst statt nur bei seltenen Sonderfällen zu scheitern. Ab diesem Punkt kosten schrittweise Reparaturen über die Zeit oft mehr, als eine neue, auf die tatsächlich relevanten Seiten zugeschnittene Engine zu entwickeln und sorgfältig gegen das Altsystem zu migrieren.

Wenn Ihr Unternehmen auf Datenextraktion aus Quellen angewiesen ist, die Sie nicht selbst kontrollieren, und das dahinterliegende System in die Jahre kommt: Ein Beratungsgespräch ist ein praktischer Einstieg, um Ablösung oder Neuentwicklung für Ihren Fall einzuordnen – mehr zur Infrastruktur dahinter finden Sie auf unserer Seite zu Datenplattformen.