Crawling na dużą skalę nie musi kosztować fortuny. Pokazujemy jak.

Kiedy stajemy przed zadaniem zebrania setek milionów stron, pierwsze pytanie brzmi zawsze tak samo: ile to będzie kosztować? Standardowe instancje cloud — czy to GCP, AWS czy Azure — szybko generują rachunki, które skutecznie ograniczają apetyt na skalę. Dlatego przy projekcie indeksowania 400 milionów stron postawiliśmy na Google Cloud Preemptible VMs (dziś znane też jako Spot VMs). Wynik: $2 za milion zaindeksowanych stron.

Poniżej tłumaczymy dlaczego to rozwiązanie działa idealnie do crawlingu i co trzeba wziąć pod uwagę przy wdrożeniu.

Czym są Preemptible VMs

Google Cloud Preemptible VM to instancja uruchamiana na nadmiarowej pojemności obliczeniowej GCP. W zamian za to, że Google może ją w dowolnym momencie odebrać (preemptować), dostajemy maszynę tego samego typu i tej samej wydajności co standardowa instancja — ale nawet do 91% taniej.

Stara nazwa „preemptible” odnosi się do wersji z ograniczeniem do 24 godzin ciągłego działania. Nowsza forma, Spot VM – nie ma tego limitu i Google oficjalnie rekomenduje jej używanie zamiast starszego wariantu. Oba warianty działają na tym samym modelu cenowym.

Kluczowe cechy:

  • Cena stała w danym dniu (zmienia się nie częściej niż raz dziennie, w praktyce znacznie rzadziej)
  • Google może zatrzymać maszynę w każdej chwili, dając 30 sekund na graceful shutdown
  • Jeśli instancja zostanie zatrzymana w ciągu pierwszej minuty – nie płacisz za ten czas
  • Dostępne wszystkie typy maszyn, GPU, Local SSD

Dlaczego crawling i preemptible to idealne dopasowanie

Crawling jest z natury workloadem fault-tolerant i łatwo paralowalnym. Każda strona do pobrania to niezależne zadanie. Jeśli worker zginie w połowie – kolejka URL-i nie znika, inny worker podejmie pracę. Nie ma stanu, który trzeba chronić.

To dokładnie ten typ obciążenia, dla którego preemptible zostały stworzone:

Każde zadanie jest atomowe. Pobranie strony trwa sekundy. Nawet agresywna preempcja nie marnuje wykonanej pracy, najwyżej kilka URL-i wróci do kolejki.

Skala pozioma działa naturalnie. Zamiast jednej dużej maszyny uruchamiamy dziesiątki małych. Przy preemptible koszt tej samej mocy obliczeniowej jest kilkakrotnie niższy.

Przerwy nie wpływają na wynik końcowy. Nie zależy nam na ciągłości działania konkretnej instancji -zależy nam na tym, żeby kolejka URL-i była stopniowo opróżniana. Preempcja spowalnia jedynie tempo, nie psuje danych.

Wzorzec pracy pasuje do dostępności. Crawling zazwyczaj nie jest zadaniem real-time – kilkugodzinne opóźnienie w przetworzeniu batcha jest akceptowalne. To daje buffor na ewentualne braki pojemności spot.

Wynik: 400 milionów stron, $2 za milion

W naszym projekcie uruchomiliśmy flotę małych instancji n2d-standard-2 (2 vCPU, 8 GB RAM) w trybie preemptible. Każdy worker pobierał URL-e z centralnej kolejki Redis, zapisywał wyniki do GCS i kończył zadanie.

Łączne koszty compute za zaindeksowanie 400 milionów stron zamknęły się w ~$800. To daje $2 za każdy milion stron.

Dla porównania: ten sam wolumen na standardowych instancjach on-demand kosztowałby 8–12 razy więcej.

Jeden ważny minus: nie używamy Dockera

Jest jeden kompromis, który warto znać zanim zaczniesz.

Preemptible VMs — a raczej sposób w jaki zarządza się ich flotą przez Managed Instance Groups — najlepiej współpracuje z gold image (custom VM image), nie z kontenerami Docker uruchamianymi przez systemd czy podobne.

Dlaczego? Managed Instance Group tworzy nowe instancje z szablonu. Jeśli ten szablon to obraz VM z zainstalowanym już całym środowiskiem crawlera, nowa maszyna startuje w kilkanaście sekund i od razu zaczyna pracować. Nie musi pobierać obrazu Docker, nie zależy od dostępności zewnętrznego registry, nie ma cold start z pobieraniem zależności.

W praktyce oznacza to:

  • Budujesz gold image raz (Packer lub ręcznie), baking’ujesz do niego Scrapy, Playwright, konfigurację agenta
  • Instance Template w GCP wskazuje na ten obraz
  • Managed Instance Group startuje N instancji z szablonu — każda gotowa do pracy od pierwszej sekundy

To nieco inny workflow niż Docker Compose czy Kubernetes, ale dla tej klasy zadania jest prostszy i bardziej niezawodny. Nie ma rejestrów, warstw, health-checków na poziomie kontenera. VM startuje, skrypt crawlera startuje razem z nią.

Kluczowe założenia projektowe:

  • Każdy worker pobiera z brokera kolejki paczkę 100 URL-i, fetuje strony, przetwarza i zapisuje wyniki do bazy danych, odznacza zadania jako wykonane, po czym wraca do brokera po kolejną paczkę.
  • Broker kolejki działa na osobnej małej instancji on-demand. Ta jedna maszyna nigdy nie jest preemptible — to jedyna część systemu, która musi działać nieprzerwanie. Wszystko inne może być zatrzymane i zastąpione w dowolnym momencie.
  • Liczba równoległych workerów jest w pełni pod Twoją kontrolą. Chcesz zaindeksować szybciej — odpalasz więcej instancji. Chcesz ciąć koszty — zmniejszasz flotę. MIG może to robić automatycznie na podstawie długości kolejki, ale możesz też zarządzać tym ręcznie.

Kiedy to podejście ma sens, a kiedy nie

Dobre zastosowania:

  • Duże, jednorazowe crawle (one-shot indexing)
  • Cykliczne indeksowanie z dopuszczalnym opóźnieniem
  • Wszystkie workloady, gdzie dane idą przez kolejkę, nie przez bezpośrednie połączenie między maszynami

Mniej odpowiednie gdy:

  • Crawl musi zakończyć się w ściśle określonym, krótkim oknie czasowym i nie ma buforu na przestoje
  • Używasz Playwright z długotrwałymi sesjami przeglądarkowymi (preempcja w środku sesji wymaga przemyślanego state management)
  • Twoje źródła rate-limitują per IP i resetowanie instancji zmienia IP w nieodpowiednim momencie

Podsumowanie

Google Cloud Preemptible / Spot VMs to jeden z najbardziej niedocenianych narzędzi w toolboxie crawlera. Workload crawlujący jest niemal idealnie dopasowany do modelu spot — atomowy, fault-tolerant, łatwo skalowalny poziomo.

Jedyny kompromis to rezygnacja z Dockera jako mechanizmu deploymentu na rzecz gold image VM. W praktyce jest to prostszy i szybszy sposób na zarządzanie flotą maszyn przy tego typu zadaniu.

Wynik mówi sam za siebie: 400 milionów stron, $2 za milion.

Jeśli planujesz podobny projekt — crawling na własnej infrastrukturze lub zlecenie indeksowania, zapraszamy do kontaktu.