Rugsėjo 14-oji
Šios dienos laukėme kelias savaites. Mūsų gyvenamųjų (residential) proxy serverių tiekėjas liepos mėnesį dingo dėl atsiskaitymo gedimo, ir du mėnesius vis didesnė dalis mūsų 1 375 šaltinių veikė pablogintu režimu arba nebeveikė visai — užklausos baigėsi laiko limitu, IP adresai buvo blokuojami vidury sesijos, tai yra toks lėtas nutekėjimas, kuris neatrodo kaip gedimas, o tiesiog kaip mažėjantis skaičius, kurio niekas nepastebi, kol nesidaro gėda. Atnaujinome. Naujas telkinys, 20 000 besisukančių gyvenamųjų sesijos eilučių, kiekvienas išėjimo taškas patikrintas prieš leidžiant jam prisijungti prie gamybinės sistemos. 100% patikrinimų praėjo sėkmingai. AE, DE, JP — visi aktyvūs, visi švarūs.
Tad paleidome prižiūrimą skenavimą — tokį, kurio metu kažkas tikrai stebi informacijos skydelį, o ne pasitiki cron užduotimi. Tikėjausi visiško priešingybės katastrofai.
Vietoj to gavome duomenų bazę, kuri per vieną ciklą pametė 84 401 eilutę, o 102 šaltiniai sumažėjo daugiau nei 25 % lyginant su ankstesniu nuotrauku (snapshot). Blogiau nei per tuos du mėnesius proxy serverių badavimo, kurį tik ką buvome pataisę.
Klaidinga teorija, trumpai
Pirmoji mano mintis — ir šį kartą sąžiningai prisipažinsiu — buvo, kad naujasis telkinys kažkodėl veikia blogiau, nei rodė patikrinimas. Galbūt sesijų IP adresai buvo apriboti (rate-limited) skenavimo metu taip, kaip vienkartinis patikrinimas to neparodytų. Teorija pagrįsta. Tačiau ji buvo klaidinga, ir tikėjimas ja net pusę dienos atsiėmė laiko, kurio neturėjome, nes skenavimo cron užduotis lieka pristabdyta visą laiką, kol tikrinama tokia teorija — nenori, kad blogas ciklas perrašytų gerą nuotrauką, kol tu dar tik spėlioji.
Teoriją sugriovė dubizzle atvejis. Vienas iš didžiausios apimties JAE (UAE) šaltinių — per tą ciklą jis realiai nuskaitė 32 595 skelbimus — visiškai sveikas skaičius, proxy serveriai akivaizdžiai veikė — o tada beveik visus juos atmetė. Ne nepavyko nuskaityti. Nuskaitė ir tada išmetė.
Rugsėjo 16-oji: tikrosios klaidos radimas
Tuomet istorija apie proxy serverius pavirto istorija apie eilučių pakeitimą (row replacement). Mūsų duomenų išsaugojimo lygmuo kiekvieną ciklą perrašo šaltinio nuotrauką pilnai — tik dabartiniai skelbimai, visa lentelė pakeičiama iš naujo faile <site>_cars_for_sale.csv. Tai teisingas elgesys, kai skenavimas pavyksta iki galo. Tačiau tai katastrofa, kai skenavimas baigiasi laiko limitu per vidurį, ir scraper'is įrašo tą dalinę partiją, kurią sugebėjo surinkti, kaip jeigu tai būtų pilna nuotrauka. Šaltinis, kuriame paprastai būna 9 000 aktyvių skelbimų, perrašomas tik su 1 200 nuskaitytų iki laiko pabaigos, o kiti 7 800 tiesiog dingsta — ne todėl, kad automobiliai buvo parduoti, o todėl, kad mūsų pačių kodas nusprendė, kad nebaigtas nuskaitymas yra baigtas.
Proxy serveriai mūsų ne apgaudinėjo. Problema buvo pakartotinio bandymo (retry) logikoje, ir ji tyliai buvo bloga labai ilgai — tiesiog tai slėpė sveikesnis telkinys, kuris anksčiau spėjo baigti nuskaitymus, kol šis trūkumas tapo reikšmingas.
Štai kiek realiai kainavo šis bandymų ciklas, kai apskaičiavome:
| Senas pakartotinių bandymų ciklas | Pataisytas ciklas | |
|---|---|---|
| Bandymų skaičius vienam proxy | 3 | 1 |
| Delsa tarp bandymų | 1s | — |
| Efektyvi riba visam 50 proxy telkiniui | ~56 minutės vienam URL | 120 sekundžių bendras biudžetas |
| Elgesys laiko limitui baigiantis | dalinė partija įrašoma kaip pilna nuotrauka | šaltinis praleidžiamas, paliekama ankstesnė nuotrauka |
56 minutės, kol pasiduodama dėl vieno URL. Padauginkite tai per skenavimą, apimantį daugiau nei tūkstantį šaltinių, ir gausite lygiai tokį tylų, netolygiai paskirstytą gedimą, kokį ir matėme — kai kurie šaltiniai veikė gerai, 102 buvo nuniokoti, ir žurnaluose nebuvo nieko, kas šauktų „proxy serverių gedimas“, nes, techniškai, jo ir nebuvo.
Rugsėjo 25-oji: pataisymas ir tai, kas svarbu jums
Pataisymas, kuris išleistas po devynių dienų, padarė du nelabai įspūdingus dalykus. Jis apribojo bandymų matematiką, kad užstrigęs nuskaitymas greitai pasiduotų, vietoj to, kad suėstų beveik visą valandą, ir — tai tas dalykas, kuris realiai apsaugo nuo duomenų praradimo — dalinis nuskaitymas nebeperrašo pilno eilučių rinkinio. Jei šaltinis gauna tik 1 200 iš įprastų 9 000 skelbimų, mes paliekame ankstesnę pilną nuotrauką, o ne perrašome ją dalimi. Tą pačią dieną buvo įdiegtas ir antras pakeitimas, kuris įrašo matomą CRAWL_PAUSED žymę, kurią mūsų stebėsenos sistema tikrina prieš siunčiant kam nors pranešimą apie kritimą — taip tyčinis pristabdymas skaitomas kaip pristabdymas, o ne kaip pavojaus signalas.
Kodėl tai turėtų rūpėti skaitytojui, ieškančiam naudoto Hyundai? Nes žemiau rinkos kainos skelbimų žymės, kurias publikuojame — šią savaitę jų svetainėje aktyvios 12 823 — yra teisingos tik tuo atveju, jei kohorta, su kuria lyginame skelbimą, yra tikra, pilna regiono rinka, o ne laiko limito nukarpyta jos nuotrupa. Pasiūlymo ženklelis, sukurtas pagal nuotrauką, pametusią tris ketvirtadalius palyginimo rinkinio, nėra pasiūlymo ženklelis — tai triukšmas, apsirengęs žalia etikete. Mes mieliau pristabdysime skenavimą devynioms dienoms, nei publikuosime tai.
Šiandien duomenų rinkinys sudaro 1 108 535 skelbimus iš 73 regionų ir 1 375 šaltinių — didesnis nei prieš visa šitai, su atnaujintais proxy serveriais ir uždaryta eilučių pakeitimo klaida. Tačiau skaičius, prie kurio sugrįžtu vis iš naujo, nėra bendra suma. Tai 84 401 — atotrūkis tarp skenavimo, kuris proxy lygmenyje atrodė sveikas, ir to, kuris realiai buvo.
