Die Architektur, auf die die meisten Scraping-Systeme zulaufen, sieht so aus: Container bei einem Cloud-Anbieter, skaliert nach Warteschlangentiefe, zustandslos und wegwerfbar. Das ist das richtige Design für die Rechenleistung. Es ist das denkbar schlechteste Design für den Egress, denn die Adressen, die diese Container erhalten, sind das Erste, was eine geschützte Website prüft.
Cloud-Provider-Bereiche sind veröffentlicht. Jeder kann sie auflisten, und die meisten Anti-Bot-Anbieter tun das auch. Traffic von dort wird nicht wegen dessen blockiert, was er getan hat, sondern nach seiner Herkunft bewertet, bevor der erste Request überhaupt abgeschlossen ist. Die Lösung sind nicht mehr Worker oder bessere Header. Es geht darum, zu trennen, wo der Code läuft, von dort, wo der Traffic austritt.
Die Egress-Schicht ist ein eigenes Thema
Das nützliche mentale Modell ist: Ihre Worker sind Rechenleistung, Ihre Adressen sind Identität, und diese sollten unabhängig voneinander skalieren.
Kurzlebige Worker sind gut: fünfzig starten, die Warteschlange abarbeiten, stoppen. Kurzlebige Identitäten sind meist schlecht: Jeder neue Worker, der von einer neuen Cloud-Adresse ankommt, ist ein Strom unbekannten Traffics. Was Sie wollen, ist ein stabiler Satz von Exit-Adressen, der über Worker-Generationen hinweg bestehen bleibt, sodass die Identität, die Ihre Ziele sehen, sich nicht jedes Mal ändert, wenn Ihr Autoscaler reagiert.
ISP-Proxys, auch bekannt als statische Residential-Proxys, passen in diese Rolle. Jeder Proxy bleibt für den gesamten Abrechnungszeitraum bei der von Ihnen gewählten Stadt und dem gewählten ISP, registriert bei einem echten ISP statt in einem Cloud-Block, und selbst wenn sich die IP aktualisiert, bleibt sie bei dieser Stadt und diesem ISP. Ihre Worker kommen und gehen; die Proxys bleiben, wo Sie sie platzieren.
Authentifizierung funktioniert von überall
Jeder Proxy hat seinen eigenen Benutzernamen, und alle verbinden sich über einen Host, isp.shifter.io, auf Port 443, sodass Ihre Worker keine feste ausgehende Adresse benötigen:
isp.shifter.io:443:USERNAME:PASSWORDDas ist die richtige Wahl, wenn Worker tatsächlich kurzlebig sind über wechselnde Adressen hinweg, oder über Regionen verteilt sind, oder in einer Umgebung laufen, in der Sie die ausgehende Adresse nicht kontrollieren. Serverless-Funktionen und Multi-Region-Deployments funktionieren genauso wie ein einzelner Server.
Verteilung der Adressen auf Worker
Sie haben N Adressen und eine variable Anzahl von Workern, also muss etwas die eine der anderen zuordnen.
Der Ansatz, der sich bewährt, besteht darin, die Adressliste als gemeinsame Ressource mit expliziten Leases zu behandeln, statt jeden Worker selbst wählen zu lassen. Ein Worker nimmt eine Adresse aus einer Koordinationsschicht, hält sie für die Dauer seines Jobs und gibt sie zurück. Zwei Eigenschaften sind wichtig: Keine zwei Worker nutzen gleichzeitig eine Adresse in einer Weise, die ihre scheinbare Request-Rate verdoppelt, und ein Worker-Absturz entfernt eine Adresse nicht dauerhaft aus dem Umlauf.
Die naive Alternative, das Hashen der Worker-Identität auf einen Index, bricht in dem Moment zusammen, in dem sich Ihre Worker-Anzahl ändert, was bei einem autoskalierten Deployment ständig geschieht. Sie bekommen Kollisionen beim Hochskalieren und ungenutzte Adressen beim Herunterskalieren.
Die Request-Rate pro Adresse ist hier das eigentliche Budget. Die Bandbreite bei ISP-Plänen ist unbegrenzt, die Beschränkung liegt also nicht in Gigabyte, sondern darin, wie viel Traffic ein Proxy plausibel erzeugen kann. Diese Zahl bestimmt, wie viele Adressen Ihr Deployment benötigt, und deshalb ist die Dimensionierung nach Durchsatz statt nach Datenvolumen die richtige Übung.
Health-Checks gehören in den Pool
Adressen fallen nicht gleichmäßig aus. Eine kann anfangen, von einem bestimmten Ziel Challenges zu erhalten, während alles andere in Ordnung ist, und ein Worker, der diese Adresse bekommt, produziert Müll, bis es jemandem auffällt.
Verfolgen Sie Ergebnisse pro Adresse statt aggregiert. Eine Erfolgsrate pro Adresse über ein rollierendes Fenster, pro Ziel, wenn Sie von mehreren sammeln, gibt Ihnen die Möglichkeit, eine einzelne Adresse unter Quarantäne zu stellen, ohne den gesamten Pool herauszuziehen. Aggregierte Metriken zeigen Ihnen einen Rückgang um fünf Prozent und verbergen die Tatsache, dass eine einzelne Adresse vollständig ausfällt.
Die Quarantäne sollte vorübergehend und automatisch sein, mit einer Prüfung, die die Adresse zurückgibt, sobald sie sich erholt hat. Die Methode, um überhaupt erst festzustellen, wie normal aussieht, findet sich unter Testen von Proxy-Geschwindigkeit, Erfolgsrate und Standortgenauigkeit.
Geografie vor dem Kauf planen
Ein Detail, das Cloud-Teams hilft: Bei Shifter-ISP-Proxys wählen Sie die Stadt und den ISP für jeden Proxy nach dem Kauf, in 120 Ländern.
Jeder Proxy bleibt dann für den Abrechnungszeitraum bei dieser Stadt und diesem ISP, entscheiden Sie die Aufteilung also anhand der Ziele, von denen Sie tatsächlich sammeln, statt sie bei jedem Deployment zu ändern.
Wenn ISP das falsche Werkzeug ist
Statische Residential-Proxys sind kein allgemeiner Ersatz für Rotation, und Cloud-Infrastruktur macht es verlockend, das Gegenteil vorzugeben, weil das operative Modell so viel einfacher ist.
Wenn Ihre Arbeitslast eine hochvolumige Sammlung über viele Ziele hinweg ist, wird die Request-Rate pro Adresse lange bevor die Kosten es tun unplausibel, und das Symptom ist verschlechterte Daten statt Fehler. Diese Arbeit gehört auf rotierende Residential-Proxys, bei denen jeder Request per Design von einer anderen Adresse kommen kann. Der Kompromiss wird dargelegt in ISP-Proxys vs. Datacenter und Residential.
Die Arbeitslasten, bei denen eine stabile Egress-Schicht wirklich richtig ist: langlebige Sessions, alles Authentifizierte, und stetige Sammlung, bei der Konsistenz wichtiger ist als Volumen. Die gemischte Architektur ist üblich und richtig, mit ISP-Adressen für die dauerhafte Arbeit und einem rotierenden Gateway für das Massengeschäft.
Betriebliche Hinweise
Halten Sie die Adressliste in der Konfiguration, nicht in Images. Container neu zu bauen, um den Pool zu ändern, ist vermeidbar. Lesen Sie sie beim Start aus Ihrem Secret Store oder Config-Service.
Loggen Sie nicht die URL mit den Zugangsdaten. Das ist der mit Abstand häufigste Weg, wie Proxy-Zugangsdaten in einen Log-Aggregator gelangen, weil die naheliegende Debug-Zeile der gesamte Verbindungsstring ist.
Begrenzen Sie die Nebenläufigkeit pro Adresse, nicht nur global. Ein globales Limit, das ungleichmäßig auf einen kleinen Pool verteilt ist, konzentriert die Last auf die Adressen, die Ihre Zuweisungslogik bevorzugt. Die relevante Mechanik findet sich unter Rate Limiting und Request Throttling.
Testen Sie von innerhalb des Deployments. Ein Konnektivitätstest von einem Laptop aus beweist, dass Ihre Zugangsdaten funktionieren. Er beweist nichts darüber, ob Ihre Task-Definition die Umgebungsvariablen durchreicht, was in den meisten Fällen der tatsächliche Fehler ist.
FAQ
Kann ich ISP-Proxys von Serverless-Funktionen aus nutzen?
Ja. Zugangsdaten funktionieren von überall, sodass die wechselnde ausgehende Adresse einer Funktion kein Problem ist.
Wie viele Adressen benötigt ein autoskaliertes Deployment?
Dimensionieren Sie nach Peak-gleichzeitigen Jobs und einer konservativen Request-Rate pro Adresse, nicht nach Worker-Anzahl. Worker leerlaufen; die Adressen sollten nicht das sein, was bei Spitzenlast ausgeht.
Wird die Proxy-Schicht zum Flaschenhals?
ISP-Proxys laufen auf verwalteter Infrastruktur mit unbegrenztem Traffic, daher ist der Durchsatz pro Proxy selten die Grenze. Die Concurrency-Policy bindet meist zuerst.
Sollte jeder Service eigene Adressen bekommen?
Wenn sich ihre Traffic-Muster wesentlich unterscheiden, ja. Einen stetigen Service mit niedriger Rate mit einem stoßweisen auf derselben Adresse zu mischen, bedeutet, dass der stoßweise bestimmt, wie beide behandelt werden.
Fazit
Cloud-Scraping-Infrastruktur wird aus einem Grund blockiert, der nichts mit der Qualität des Codes zu tun hat: Die Adressen sind als Cloud-Adressen veröffentlicht. Eine stabile ISP-Egress-Schicht vor kurzlebige Worker zu setzen, trennt Identität von Rechenleistung, was ohnehin die Trennung war, die die Architektur brauchte.
Leasen Sie Adressen explizit, verfolgen Sie den Zustand pro Adresse, dimensionieren Sie nach Request-Rate statt Bandbreite, und entscheiden Sie die Geografie bewusst, anhand der Ziele, von denen Sie tatsächlich erfassen. Pläne finden sich auf der Preisseite für ISP-Proxys.