Den teuren Pfad begrenzen, nicht den Crawler

Bots zu blockieren ist einfach und meistens falsch. Suchmaschinen bringen Ihnen Besucher, Link-Vorschauen bringen Ihnen Klicks, und selbst aggressive KI-Crawler sind oft Traffic, den Sie lieber bremsen als aussperren möchten. Der bessere Ansatz ist, herauszufinden, wo Crawler Sie tatsächlich Geld kosten, nämlich auf einer Handvoll ungecachter, datenbanklastiger Pfade, und die Rate dort zu steuern, am Load Balancer. So machen wir es.

Herausfinden, was teuer ist, bevor Sie eine Regel schreiben

Die Kosten liegen auf den Pfaden, die am Cache vorbeigehen und PHP und die Datenbank erreichen: on-the-fly erzeugte Sitemaps, Suche, Facettennavigation, bei der jede Filterkombination eine frische Abfrage ist, und alles mit einem Query-String, den der Cache nicht kennt.

Ihr Access-Log sagt Ihnen bereits, welche das sind. Wenn das Log die Anfragezeit aufzeichnet (zum Beispiel $request_time von nginx als letztes Feld), summieren Sie die aufgewendete Zeit pro Pfad:

awk '{split($7, p, "?"); t[p[1]] += $NF; n[p[1]]++}
     END {for (u in t) printf "%10.1f s %8d req  %s\n", t[u], n[u], u}' access.log \
  | sort -rn | head -20

Dann sehen Sie nach, wer sie verbraucht, nach User-Agent, auf diesen Pfaden:

awk -F'"' '$2 ~ /sitemap|search|filter=/ {print $6}' access.log \
  | sort | uniq -c | sort -rn | head -20

Zwei Listen, ein Abend Arbeit, und Sie wissen genau, wo sich eine Regel auszahlt.

Rate Limiting mit HAProxy Stick Tables

HAProxy kann Anfrageraten pro Client und pro User-Agent im Speicher zählen, mit Leitungsgeschwindigkeit, und darauf reagieren. Eine minimale Konfiguration, die nur die teuren Pfade schützt:

backend st_src
    stick-table type ipv6 size 200k expire 10m store http_req_rate(10s)

backend st_ua
    stick-table type string len 128 size 20k expire 10m store http_req_rate(10s)

frontend fe_web
    # bind lines and certificates as usual
    acl expensive path_beg /sitemap /search
    acl expensive url_sub -i filter=
    http-request track-sc0 src table st_src if expensive
    http-request track-sc1 req.fhdr(user-agent) table st_ua if expensive
    http-request deny deny_status 429 hdr Retry-After 60 if expensive { sc_http_req_rate(0) gt 20 }
    http-request deny deny_status 429 hdr Retry-After 60 if expensive { sc_http_req_rate(1) gt 60 }

Drei Designentscheidungen zählen hier. Nur teure Pfade werden verfolgt, also wird sonst nichts auf der Site berührt. Die Antwort ist ein 429 mit einem Retry-After-Header, den wohlerzogene Crawler als «langsamer, und komm später wieder» verstehen, nicht als Fehler, für den sie Sie abstrafen. Und die zweite Tabelle zählt pro User-Agent, was einen über viele Adressen verteilten Crawler erfasst, der unter einem Limit pro Adresse durchrutschen würde. Die Schwellenwerte oben sind Platzhalter: Setzen Sie Ihre aus dem, was der Pfad tatsächlich ungecacht ausliefern kann.

Crawler sorgfältig identifizieren

User-Agents locker abgleichen

Crawler ändern das Format ihrer User-Agent-Strings, fügen Versions-Tokens, URLs oder neue Produktnamen hinzu. Eine Regel, die den ganzen String exakt abgleicht, hört an dem Tag auf zu funktionieren, an dem er sich ändert. Ein Teilstring-Abgleich auf den stabilen Teil (hdr_sub(user-agent) -i <name>) funktioniert weiter.

Die Suchmaschine nicht aus Versehen blockieren

Verifizieren Sie einen Crawler, bevor Sie ihn besonders behandeln. Die großen Suchmaschinen veröffentlichen, wie: Eine Reverse-DNS-Abfrage auf die Client-Adresse sollte einen Hostnamen in ihrer Domain zurückgeben, und eine Forward-Abfrage auf diesen Hostnamen sollte dieselbe Adresse zurückgeben.

host <client-address>        # should return a name in the engine's published domain
host <name-returned-above>   # should return the same client address

Echte Crawler werden dann auf den teuren Pfaden begrenzt wie alle anderen und crawlen den Rest der Site weiter frei. Hochstapler bekommen keine Gefälligkeiten.

Die Formen ablehnen, die nie legitim sind

Manche Anfragemuster haben keinen legitimen Zweck: URLs, die immer wieder neu kodiert wurden, bis sie Tausende Zeichen lang sind, unmögliche Parameterkombinationen, dieselbe Prozentkodierung dreimal angewendet. Eine einzige Regel am Edge lehnt sie ab, bevor sie irgendetwas kosten:

http-request deny deny_status 400 if { url_sub -i %2525 }

Passen Sie das Muster an das an, was Ihre Logs zeigen. Der Punkt ist, dass der Load Balancer der günstigste Ort im Stack ist, um Nein zu sagen.

PHP vor dem schützen, was durchkommt

Keine Edge-Regel ist perfekt, also braucht die Anwendungsebene ihre eigenen Grenzen. In jedem PHP-FPM-Pool verhindert ein Beendigungs-Timeout, dass eine einzelne pathologische Anfrage einen Worker minutenlang festhält, und eine Speicherobergrenze verhindert, dass sie unbegrenzt wächst:

request_terminate_timeout = 60s
php_admin_value[memory_limit] = 256M
pm.max_requests = 500

Setzen Sie diese zusammen mit den Edge-Regeln, damit die beiden Ebenen sich einig sind, wie eine vernünftige Anfrage aussieht. Währenddessen liefert Varnish weiter gecachte Seiten aus, sodass Leser und Käufer nichts davon spüren.

Wie wir es betreiben

Auf den Nachrichten- und Onlineshop-Properties, die wir betreiben, bekommen Sitemap-, Such- und gefilterte Listenpfade vom ersten Tag an Ratenwächter, dimensioniert auf das, was jede Site ungecacht ausliefern kann. Neue Regeln werden aus den Access-Logs geschrieben, auf jedes Edge der Property ausgerollt und mit Vorher- und Nachher-Zahlen für den Kunden dokumentiert. Taucht ein neuer Crawler auf, kann eine gezielte Regel üblicherweise innerhalb von Minuten nach dem Erkennen des Musters auf jedem Edge stehen.

Prüfen Sie Ihr eigenes Edge

• Welche fünf Pfade haben letzte Woche die meiste PHP- und Datenbankzeit gekostet?
• Wer hat sie angefragt, nach User-Agent?
• Gelten Ihre Limits nur dort, wo die Kosten sind, oder für die ganze Site?
• Antworten Sie mit 429 und Retry-After, oder mit einer Sperre?
• Wann hat zuletzt jemand bestätigt, dass die Regeln noch zum Live-Traffic passen?

Wenn Crawler Ihre Kapazität auffressen, können wir Ihre Logs mit Ihnen lesen und die Regeln schreiben. Mit einem Ingenieur sprechen

Related

• /what-we-do/operations/edge-traffic-control/
• /what-we-do/data-web/high-availability-web-tiers/
• /what-we-do/data-web/performance-audits/