TL;DR: Fyrir fjórum árum fór ég frá Google með hugmynd að nýju netþjónseftirlitstæki. Hugmyndin var að sameina venjulega einangraðar aðgerðir í eina þjónustu söfnun og annálagreining, mæligildasöfnun, viðvaranir og mælaborð. Ein af meginreglunum er að þjónustan verður að vera raunveruleg hratt, sem veitir devops auðvelda, gagnvirka og skemmtilega upplifun. Þetta krefst vinnslu margra gígabæta gagnasetta á sekúndubrotum á meðan það er innan fjárhagsáætlunar. Núverandi annálastjórnunartæki eru oft hæg og klunnaleg, þannig að við stóðum frammi fyrir góðri áskorun: að hanna tól á snjallan hátt til að gefa notendum nýja upplifun.

Þessi grein lýsir því hvernig við hjá Scalyr leystum þetta vandamál með því að beita gömlum skólaaðferðum, brute force nálgun, útrýma óþarfa lögum og forðast flókið gagnaskipulag. Þú getur beitt þessum lærdómum á eigin verkfræðileg vandamál.

Old School Power

Loggreining byrjar venjulega með leit: Finndu öll skilaboð sem passa við ákveðið mynstur. Í Scalyr eru þetta tugir eða hundruð gígabæta af annálum frá mörgum netþjónum. Nútíma aðferðir fela að jafnaði í sér smíði flókins gagnaskipulags sem er fínstillt fyrir leit. Ég hef svo sannarlega séð þetta á Google, þar sem þeir eru nokkuð góðir í svona hlutum. En við sættum okkur við mun grófari nálgun: línulega skönnun á annálum. Og það virkaði - við bjóðum upp á leitarviðmót sem er stærðargráðum hraðar en keppinautar okkar (sjá hreyfimynd aftast).

Lykilinnsýnin var að nútíma örgjörvar eru örugglega mjög hraðir við einfaldar og einfaldar aðgerðir. Auðvelt er að missa af þessu í flóknum fjöllaga kerfum sem byggja á I/O hraða og netaðgerðum og slík kerfi eru mjög algeng í dag. Þannig að við þróuðum hönnun sem lágmarkar lög og umfram rusl. Með mörgum örgjörvum og netþjónum samhliða nær leitarhraðinn 1 TB á sekúndu.

Helstu atriði úr þessari grein:

• Rute-force leit er raunhæf nálgun til að leysa raunveruleg vandamál í stórum stíl.
• Brute force er hönnunartækni, ekki vinnulaus lausn. Eins og öll tækni hentar hún betur sumum vandamálum en öðrum og er hægt að útfæra hana illa eða vel.
• Brute force er sérstaklega gott til að ná árangri stöðugt framleiðni.
• Árangursrík notkun á grimmdarkrafti krefst hagræðingar kóða og beita nægu fjármagni á réttum tíma. Það er hentugur ef netþjónar þínir eru undir miklu álagi sem ekki er notandi og notendaaðgerðir eru áfram í forgangi.
• Afköst eru háð hönnun alls kerfisins, ekki bara reikniritið fyrir innri lykkju.

(Þessi grein lýsir leit að gögnum í minni. Í flestum tilfellum, þegar notandi framkvæmir logaleit, hafa Scalyr þjónarnir þegar safnað þeim í skyndiminni. Í næstu grein verður fjallað um leit að óafminni annálum. Sömu meginreglur gilda: skilvirkur kóða, brute force með stórar tölvuauðlindir).

Brute force aðferð

Hefð er fyrir því að leitað er í stóru gagnasafni með því að nota leitarorðaskrá. Þegar það er notað á netþjónaskrám þýðir þetta að leita að hverju einstöku orði í skránni. Fyrir hvert orð þarftu að búa til lista yfir allar innfellingar. Þetta gerir það auðvelt að finna öll skilaboð með þessu orði, til dæmis 'villa', 'firefox' eða "transaction_16851951" - skoðaðu bara skrána.

Ég notaði þessa nálgun hjá Google og hún virkaði vel. En í Scalyr leitum við í logs bæti fyrir bæti.

Hvers vegna? Frá óhlutbundnu reikniritfræðilegu sjónarhorni eru leitarorðavísitölur mun skilvirkari en skepnaleit. Hins vegar seljum við ekki reiknirit, við seljum frammistöðu. Og árangur snýst ekki aðeins um reiknirit heldur einnig um kerfisverkfræði. Við verðum að huga að öllu: gagnamagni, gerð leitar, tiltækum vélbúnaði og hugbúnaði. Við ákváðum að fyrir tiltekið vandamál okkar hentaði eitthvað eins og 'grep' betur en vísitala.

Vísitölur eru frábærar, en þær hafa takmarkanir. Eitt orð er auðvelt að finna. En það er miklu erfiðara að leita að skilaboðum með mörgum orðum, eins og „googlebot“ og „404“. Að leita að orðasambandi eins og 'óveidd undantekning' krefst fyrirferðarmeiri vísitölu sem skráir ekki aðeins öll skilaboð með því orði, heldur einnig tiltekna staðsetningu orðsins.

Raunverulegir erfiðleikar koma þegar þú ert ekki að leita að orðum. Segjum að þú viljir sjá hversu mikil umferð kemur frá vélmennum. Fyrsta hugsunin er að leita í annálunum að orðinu „bot“. Svona finnurðu nokkur vélmenni: Googlebot, Bingbot og marga aðra. En hér er „bot“ ekki orð, heldur hluti af því. Ef við leitum að 'bot' í skránni, finnum við engar færslur með orðinu 'Googlebot'. Ef þú athugar hvert orð í skránni og skannar síðan skrána fyrir leitarorðin sem finnast mun leitin hægja mjög á. Þar af leiðandi leyfa sum logforrit ekki leit að hluta orðum eða leyfa (í besta falli) sérstaka setningafræði með minni afköstum. Við viljum forðast þetta.

Annað vandamál er greinarmerki. Viltu finna allar beiðnir frá 50.168.29.7? Hvað með að kemba logs sem innihalda [error]? Áskrifendur sleppa venjulega greinarmerkjum.

Að lokum elska verkfræðingar öflug verkfæri og stundum er vandamál aðeins hægt að leysa með reglulegri tjáningu. Leitarorðaskráin hentar ekki mjög vel í þetta.

Auk þess eru vísitölurnar flókið. Bæta þarf hverju skeyti við nokkra leitarorðalista. Þessum listum ætti alltaf að vera á sniði sem auðvelt er að leita að. Fyrirspurnir með orðasamböndum, orðabrotum eða reglulegum orðasamböndum þarf að þýða yfir í fjöllistaaðgerðir og skanna niðurstöðurnar og sameina þær til að mynda niðurstöðusett. Í samhengi við umfangsmikla þjónustu fyrir marga leigjendur skapar þessi margbreytileiki frammistöðuvandamál sem eru ekki sýnileg þegar reikniritin eru greind.

Leitarorðavísitölur taka líka mikið pláss og geymsla er stór kostnaður í logstjórnunarkerfi.

Á hinn bóginn getur hver leit eytt miklu tölvuorku. Notendur okkar kunna að meta háhraða leit að einstökum fyrirspurnum, en slíkar fyrirspurnir eru tiltölulega sjaldan gerðar. Fyrir dæmigerðar leitarfyrirspurnir, til dæmis fyrir mælaborð, notum við sérstakar aðferðir (við munum lýsa þeim í næstu grein). Aðrar beiðnir eru það sjaldgæfar að þú þarft sjaldan að afgreiða fleiri en eina í einu. En þetta þýðir ekki að netþjónarnir okkar séu ekki uppteknir: þeir eru uppteknir við að taka á móti, greina og þjappa nýjum skilaboðum, meta tilkynningar, þjappa gömlum gögnum o.s.frv. Þannig höfum við nokkuð umtalsvert framboð af örgjörvum sem hægt er að nota til að framkvæma fyrirspurnir.

Rute force virkar ef þú ert með gróft vandamál (og mikið afl)

Brute force virkar best á einföldum vandamálum með litlum innri lykkjum. Oft er hægt að fínstilla innri lykkjuna til að keyra á mjög miklum hraða. Ef kóðinn er flókinn er mun erfiðara að fínstilla hann.

Leitarkóðinn okkar hafði upphaflega nokkuð stóra innri lykkju. Við geymum skilaboð á síðum í 4K; hver síða inniheldur nokkur skilaboð (í UTF-8) og lýsigögn fyrir hvert skeyti. Lýsigögn eru uppbygging sem kóðar lengd gildisins, auðkenni innra skilaboða og annarra reita. Leitarlotan leit svona út:

Þetta er einfölduð útgáfa af raunverulegum kóða. En jafnvel hér eru margar staðsetningar hlutar, gagnaafrit og aðgerðarköll sýnilegar. JVM er nokkuð gott í að fínstilla aðgerðarköll og úthluta skammvinnum hlutum, svo þessi kóði virkaði betur en við áttum skilið. Við prófun notuðu viðskiptavinir það með góðum árangri. En á endanum tókum við það á næsta stig.

(Þú gætir spurt hvers vegna við geymum skilaboð á þessu sniði með 4K síðum, texta og lýsigögnum, frekar en að vinna með annálum beint. Það eru margar ástæður sem snúa að því að innbyrðis er Scalyr vélin meira eins og dreifður gagnagrunnur en a skráarkerfi. Textaleit er oft sameinuð síum í DBMS-stíl á spássíu eftir greiningu annála. Við getum samtímis leitað í mörgum þúsundum annála í einu og einfaldar textaskrár henta ekki fyrir viðskipta-, endurtekna, dreifða gagnastjórnun okkar).

Upphaflega virtist sem slíkur kóði væri ekki mjög hentugur til hagræðingar á skepnukrafti. "Alvöru vinna" í String.indexOf() var ekki einu sinni ráðandi í CPU prófílnum. Það er að fínstilla þessa aðferð ein og sér myndi ekki hafa veruleg áhrif.

Það vill svo til að við geymum lýsigögn í upphafi hverrar síðu og texti allra skilaboða í UTF-8 er pakkaður í hinum endanum. Með því að nýta þetta, endurskrifuðum við lykkjuna til að leita á allri síðunni í einu:

Þessi útgáfa virkar beint á útsýnið raw byte[] og leitar í öllum skilaboðum í einu á allri 4K síðunni.

Þetta er miklu auðveldara að fínstilla fyrir brute force aðferðina. Innri leitarlykkjan er kölluð samtímis fyrir alla 4K síðuna, frekar en sérstaklega í hverri færslu. Það er engin afritun gagna, engin úthlutun á hlutum. Og flóknari lýsigagnaaðgerðir eru aðeins kallaðar til þegar niðurstaðan er jákvæð, en ekki á öllum skilaboðum. Þannig höfum við útrýmt tonn af kostnaði og restin af álaginu safnast saman í litla innri leitarlykkju, sem hentar vel til frekari hagræðingar.

Raunveruleg leitarreiknirit okkar byggist á frábær hugmynd Leonid Volnitsky. Það er svipað og Boyer-Moore reikniritið, sleppir um það bil lengd leitarstrengsins í hverju skrefi. Helsti munurinn er sá að það athugar tvö bæti í einu til að lágmarka falskar samsvörun.

Útfærsla okkar krefst þess að búa til 64K uppflettitöflu fyrir hverja leit, en það er ekkert miðað við gígabæta af gögnum sem við erum að leita í gegnum. Innri lykkjan vinnur nokkur gígabæt á sekúndu á einum kjarna. Í reynd er stöðug frammistaða um 1,25 GB á sekúndu á hverjum kjarna og það er pláss fyrir umbætur. Það er hægt að útrýma einhverju af kostnaðinum utan innri lykkjunnar og við ætlum að gera tilraunir með innri lykkju í C í stað Java.

Við beitum valdi

Við höfum rætt um að hægt sé að útfæra leit í annálum „í grófum dráttum“ en hversu mikið „vald“ höfum við? Ansi mikið.

1 kjarna: Þegar það er notað á réttan hátt er einn kjarni nútíma örgjörva nokkuð öflugur í sjálfu sér.

8 kjarna: Við erum núna að keyra á Amazon hi1.4xlarge og i2.4xlarge SSD netþjónum, hver með 8 kjarna (16 þræði). Eins og getið er hér að ofan eru þessir kjarnar venjulega uppteknir við bakgrunnsaðgerðir. Þegar notandinn framkvæmir leit stöðvast bakgrunnsaðgerðir, sem losar um alla 8 kjarna fyrir leit. Leitinni lýkur venjulega á sekúndubroti, eftir það hefst bakgrunnsvinna á ný (inngjöfarforritið tryggir að fjöldi leitarfyrirspurna truflar ekki mikilvæga bakgrunnsvinnu).

16 kjarna: fyrir áreiðanleika skipuleggjum við netþjóna í master/slave hópa. Hver meistari hefur einn SSD og einn EBS netþjón undir hans stjórn. Ef aðalþjónninn hrynur tekur SSD miðlarinn strax sinn stað. Næstum allan tímann virka húsbóndi og þræll vel, þannig að hver gagnablokk er hægt að leita á tveimur mismunandi netþjónum (EBS þrælaþjónninn er með veikan örgjörva, svo við teljum það ekki). Við skiptum verkefninu á milli þeirra þannig að við höfum samtals 16 kjarna tiltæka.

Margir kjarna: Í náinni framtíð munum við dreifa gögnum milli netþjóna á þann hátt að þeir taki allir þátt í að vinna úr öllum óskilum sem ekki eru léttvæg. Sérhver kjarni mun virka. [Athugið: við útfærðum áætlunina og hækkuðum leitarhraðann í 1 TB/s, sjá athugasemd í lok greinarinnar].

Einfaldleiki tryggir áreiðanleika

Annar kostur við brute force aðferðina er nokkuð stöðug frammistaða hennar. Venjulega er leit ekki mjög viðkvæm fyrir smáatriðum vandamálsins og gagnasettsins (ég býst við að það sé þess vegna sem það er kallað "gróft").

Leitarorðavísitalan skilar stundum ótrúlega hröðum árangri og stundum ekki. Segjum að þú sért með 50 GB af annálum þar sem hugtakið 'customer_5987235982' birtist nákvæmlega þrisvar sinnum. Leit að þessu hugtaki telur þrjá staði beint úr skránni og lýkur samstundis. En flókin leit með algildi getur skannað þúsundir leitarorða og tekið langan tíma.

Á hinn bóginn virkar grófa aflsleit á nokkurn veginn sama hraða fyrir hvaða fyrirspurn sem er. Það er betra að leita að löngum orðum, en jafnvel leit að einum staf er frekar hröð.

Einfaldleiki skepnukraftsaðferðarinnar þýðir að frammistaða hennar er nálægt fræðilegu hámarki. Það eru færri valkostir fyrir óvænt ofhleðslu diska, læsingardeilur, eltingar á bendili og þúsundir annarra ástæðna fyrir bilun. Ég skoðaði bara beiðnirnar frá Scalyr notendum í síðustu viku á annasamasta netþjóninum okkar. Það voru 14 beiðnir. Nákvæmlega átta þeirra tóku meira en eina sekúndu; 000% lokið innan 99 millisekúndna (ef þú hefur ekki notað verkfæri til greiningar á annálum, treystu mér: það er hratt).

Stöðug, áreiðanleg frammistaða er mikilvæg til að auðvelda notkun þjónustunnar. Ef það tefur reglulega, munu notendur skynja það sem óáreiðanlegt og vera tregir til að nota það.

Innskráningarleit í aðgerð

Hér er stutt hreyfimynd sem sýnir Scalyr leit í aðgerð. Við erum með kynningarreikning þar sem við flytjum alla viðburði inn í hverja opinbera Github geymslu. Í þessari kynningu skoða ég gögn fyrir viku: um það bil 600 MB af hráum annálum.

Myndbandið var tekið upp í beinni, án sérstaks undirbúnings, á skjáborðinu mínu (um 5000 kílómetrum frá þjóninum). Frammistaðan sem þú munt sjá er að miklu leyti að þakka hagræðingu vefbiðlara, sem og fljótur og áreiðanlegur bakendi. Alltaf þegar það er hlé án „hleðslu“ vísir er það ég sem er að gera hlé svo þú getir lesið það sem ég er að fara að ýta á.

Að lokum

Þegar unnið er úr miklu magni af gögnum er mikilvægt að velja gott reiknirit, en „gott“ þýðir ekki „fínt“. Hugsaðu um hvernig kóðinn þinn mun virka í reynd. Fræðileg greining reiknirita skilur eftir nokkra þætti sem geta skipt miklu máli í hinum raunverulega heimi. Einfaldari reiknirit er auðveldara að fínstilla og stöðugra í jaðaraðstæðum.

Hugsaðu líka um samhengið sem kóðinn verður keyrður í. Í okkar tilviki þurfum við nægilega öfluga netþjóna til að stjórna bakgrunnsverkefnum. Notendur hefja leit tiltölulega sjaldan, þannig að við getum fengið lánaðan heilan hóp netþjóna í þann stutta tíma sem þarf til að ljúka hverri leit.

Með því að nota brute force aðferð innleiddum við hraðvirka, áreiðanlega, sveigjanlega leit í safni annála. Við vonum að þessar hugmyndir séu gagnlegar fyrir verkefnin þín.

Breyta: Titillinn og textinn hefur breyst úr „Leita á 20 GB á sekúndu“ í „Leita með 1 TB á sekúndu“ til að endurspegla árangursaukninguna undanfarin ár. Þessi aukning á hraða er fyrst og fremst vegna breytinga á gerð og fjölda EC2 netþjóna sem við erum að setja upp í dag til að þjóna auknum viðskiptavinahópi okkar. Það eru breytingar á næstunni sem munu veita enn eina stórkostlega aukningu í rekstrarhagkvæmni og við getum ekki beðið eftir að deila þeim.

Heimild: www.habr.com