TL; DR: Pedair blynedd yn Γ΄l gadewais Google gyda syniad am offeryn monitro gweinydd newydd. Y syniad oedd cyfuno swyddogaethau sydd fel arfer yn ynysig yn un gwasanaeth a dadansoddi logiau, casglu metrigau, a dangosfyrddau. Un o'r egwyddorion yw bod yn rhaid i'r gwasanaeth fod yn wirioneddol cyflym, gan ddarparu devops gyda phrofiad hawdd, rhyngweithiol, pleserus. Mae hyn yn gofyn am brosesu setiau data aml-gigabeit mewn ffracsiynau o eiliad tra'n aros o fewn y gyllideb. Mae offer rheoli boncyffion presennol yn aml yn araf ac yn drwsgl, felly roedd her dda yn ein hwynebu: dylunio teclyn yn drwsiadus i roi profiad newydd i ddefnyddwyr.
Mae'r erthygl hon yn disgrifio sut y gwnaethom ni yn Scalyr ddatrys y broblem hon trwy gymhwyso hen ddulliau ysgol, dull gweithredu 'n Ysgrublaidd, dileu haenau diangen ac osgoi strwythurau data cymhleth. Gallwch gymhwyso'r gwersi hyn at eich problemau peirianneg eich hun.
Pwer yr Hen Ysgol
Mae dadansoddiad log fel arfer yn dechrau gyda chwiliad: darganfyddwch yr holl negeseuon sy'n cyfateb i batrwm penodol. Yn Scalyr, mae'r rhain yn ddegau neu gannoedd o gigabeit o foncyffion o lawer o weinyddion. Mae dulliau modern, fel rheol, yn cynnwys adeiladu rhywfaint o strwythur data cymhleth wedi'i optimeiddio ar gyfer chwilio. Rwyf yn sicr wedi gweld hyn ar Google, lle maen nhw'n eithaf da ar y math hwn o beth. Ond fe wnaethom setlo ar ddull llawer mwy amrwd: sganio llinol o foncyffion. Ac fe weithiodd - rydym yn darparu rhyngwyneb chwiliadwy sy'n orchmynion maint yn gyflymach na'n cystadleuwyr (gweler animeiddiad ar y diwedd).
Y mewnwelediad allweddol oedd bod proseswyr modern yn wir yn gyflym iawn mewn gweithrediadau syml, syml. Mae hyn yn hawdd i'w golli mewn systemau cymhleth, aml-haen sy'n dibynnu ar gyflymder I/O a gweithrediadau rhwydwaith, ac mae systemau o'r fath yn gyffredin iawn heddiw. Felly fe wnaethom ddatblygu dyluniad sy'n lleihau haenau a malurion gormodol. Gyda phroseswyr a gweinyddwyr lluosog ochr yn ochr, mae'r cyflymder chwilio yn cyrraedd 1 TB yr eiliad.
Siopau cludfwyd allweddol o'r erthygl hon:
- Mae chwilio grymus yn ddull ymarferol o ddatrys problemau mawr yn y byd go iawn.
- Techneg ddylunio yw grym cryf, nid datrysiad di-waith. Fel unrhyw dechneg, mae'n fwy addas ar gyfer rhai problemau nag eraill, a gellir ei gweithredu'n wael neu'n dda.
- Mae grym cryf yn arbennig o dda ar gyfer cyflawni sefydlog cynhyrchiant.
- Mae defnydd effeithiol o rym 'n ysgrublaidd yn gofyn am optimeiddio'r cod a chymhwyso adnoddau digonol ar yr amser cywir. Mae'n addas os yw'ch gweinyddwyr o dan lwyth trwm nad yw'n ddefnyddwyr a bod gweithrediadau defnyddwyr yn parhau i fod yn flaenoriaeth.
- Mae perfformiad yn dibynnu ar ddyluniad y system gyfan, nid dim ond yr algorithm dolen fewnol.
(Mae'r erthygl hon yn disgrifio chwilio am ddata yn y cof. Yn y rhan fwyaf o achosion, pan fydd defnyddiwr yn perfformio chwiliad log, mae'r gweinyddwyr Scalyr eisoes wedi ei storio. Bydd yr erthygl nesaf yn trafod chwilio am logiau heb eu storio. Mae'r un egwyddorion yn berthnasol: cod effeithlon, grym 'n Ysgrublaidd gydag adnoddau cyfrifiadurol mawr).
Dull grym 'n Ysgrublaidd
Yn draddodiadol, mae set ddata fawr yn cael ei chwilio gan ddefnyddio mynegai geiriau allweddol. Pan gaiff ei gymhwyso i logiau gweinydd, mae hyn yn golygu chwilio am bob gair unigryw yn y log. Ar gyfer pob gair, mae angen i chi wneud rhestr o'r holl gynhwysion. Mae hyn yn ei gwneud hi'n hawdd dod o hyd i bob neges gyda'r gair hwn, er enghraifft 'error', 'firefox' neu "transaction_16851951" - edrychwch yn y mynegai.
Defnyddiais y dull hwn yn Google a gweithiodd yn dda. Ond yn Scalyr rydym yn chwilio'r logiau beit fesul beit.
Pam? O safbwynt algorithmig haniaethol, mae mynegeion allweddair yn llawer mwy effeithlon na chwiliadau grym 'n ysgrublaidd. Fodd bynnag, nid ydym yn gwerthu algorithmau, rydym yn gwerthu perfformiad. Ac mae perfformiad nid yn unig yn ymwneud ag algorithmau, ond hefyd yn ymwneud Γ’ pheirianneg systemau. Rhaid inni ystyried popeth: cyfaint y data, math o chwiliad, caledwedd sydd ar gael a chyd-destun meddalwedd. Fe wnaethom benderfynu ar gyfer ein problem benodol, fod rhywbeth fel 'grep' yn fwy addas na mynegai.
Mae mynegeion yn wych, ond mae ganddynt gyfyngiadau. Mae un gair yn hawdd i'w ddarganfod. Ond mae chwilio am negeseuon gyda geiriau lluosog, fel 'googlebot' a '404', yn llawer anoddach. Mae chwilio am ymadrodd fel 'eithriad heb ei ddal' yn gofyn am fynegai mwy beichus sy'n cofnodi nid yn unig bob neges gyda'r gair hwnnw, ond hefyd lleoliad penodol y gair.
Daw'r gwir anhawster pan nad ydych chi'n chwilio am eiriau. Gadewch i ni ddweud eich bod am weld faint o draffig sy'n dod o bots. Y syniad cyntaf yw chwilio'r logiau am y gair 'bot'. Dyma sut y byddwch chi'n dod o hyd i rai bots: Googlebot, Bingbot a llawer o rai eraill. Ond yma nid gair yw 'bot', ond rhan ohono. Os byddwn yn chwilio am 'bot' yn y mynegai, ni fyddwn yn dod o hyd i unrhyw bostiadau gyda'r gair 'Googlebot'. Os byddwch yn gwirio pob gair yn y mynegai ac yna'n sganio'r mynegai am yr allweddeiriau a ddarganfuwyd, bydd y chwiliad yn arafu'n fawr. O ganlyniad, nid yw rhai rhaglenni log yn caniatΓ‘u chwiliadau rhan-eiriau nac (ar y gorau) yn caniatΓ‘u cystrawen arbennig gyda pherfformiad is. Rydym am osgoi hyn.
Problem arall yw atalnodi. Ydych chi am ddod o hyd i bob cais gan 50.168.29.7? Beth am ddadfygio logiau sy'n cynnwys [error]? Mae tanysgrifiadau fel arfer yn hepgor atalnodi.
Yn olaf, mae peirianwyr yn caru offer pwerus, ac weithiau dim ond gyda mynegiant rheolaidd y gellir datrys problem. Nid yw'r mynegai allweddair yn addas iawn ar gyfer hyn.
Yn ogystal, mae'r mynegeion cymhleth. Mae angen ychwanegu pob neges at sawl rhestr allweddair. Dylid cadw'r rhestrau hyn mewn fformat hawdd ei chwilio bob amser. Mae angen trosi ymholiadau ag ymadroddion, darnau o eiriau, neu ymadroddion rheolaidd yn weithrediadau aml-restr, a sganio a chyfuno'r canlyniadau i gynhyrchu set o ganlyniadau. Yng nghyd-destun gwasanaeth aml-denant ar raddfa fawr, mae'r cymhlethdod hwn yn creu problemau perfformiad nad ydynt yn weladwy wrth ddadansoddi'r algorithmau.
Mae mynegeion allweddair hefyd yn cymryd llawer o le, ac mae storio yn gost fawr mewn system rheoli logiau.
Ar y llaw arall, gall pob chwiliad ddefnyddio llawer o bΕ΅er cyfrifiadurol. Mae ein defnyddwyr yn gwerthfawrogi chwiliadau cyflym am ymholiadau unigryw, ond yn gymharol anaml y gwneir ymholiadau o'r fath. Ar gyfer ymholiadau chwilio nodweddiadol, er enghraifft, ar gyfer dangosfwrdd, rydym yn defnyddio technegau arbennig (byddwn yn eu disgrifio yn yr erthygl nesaf). Mae ceisiadau eraill yn ddigon anaml fel mai anaml y bydd yn rhaid i chi brosesu mwy nag un ar y tro. Ond nid yw hyn yn golygu nad yw ein gweinyddion yn brysur: maent yn brysur gyda'r gwaith o dderbyn, dadansoddi a chywasgu negeseuon newydd, gwerthuso rhybuddion, cywasgu hen ddata, ac ati. Felly, mae gennym gyflenwad eithaf sylweddol o broseswyr y gellir eu defnyddio i gyflawni ymholiadau.
Mae grym 'n Ysgrublaidd yn gweithio os oes gennych chi broblem 'n Ysgrublaidd (a llawer o rym)
Mae grym cryf yn gweithio orau ar broblemau syml gyda dolenni mewnol bach. Yn aml, gallwch chi wneud y gorau o'r ddolen fewnol i redeg ar gyflymder uchel iawn. Os yw'r cod yn gymhleth, mae'n llawer anoddach ei optimeiddio.
Yn wreiddiol roedd gan ein cod chwilio ddolen fewnol eithaf mawr. Rydym yn storio negeseuon ar dudalennau yn 4K; mae pob tudalen yn cynnwys rhai negeseuon (yn UTF-8) a metadata ar gyfer pob neges. Mae metadata yn strwythur sy'n amgodio hyd y gwerth, ID neges fewnol, a meysydd eraill. Roedd y cylch chwilio yn edrych fel hyn:
Mae hwn yn fersiwn symlach o'r cod gwirioneddol. Ond hyd yn oed yma, mae lleoliadau gwrthrychau lluosog, copΓ―au data, a galwadau swyddogaeth yn weladwy. Mae'r JVM yn eithaf da am optimeiddio galwadau swyddogaeth a dyrannu gwrthrychau byrhoedlog, felly fe weithiodd y cod hwn yn well nag yr oeddem yn ei haeddu. Yn ystod y profion, roedd cwsmeriaid yn ei ddefnyddio'n eithaf llwyddiannus. Ond yn y pen draw aethom ag ef i'r lefel nesaf.
(Efallai y byddwch yn gofyn pam ein bod yn storio negeseuon yn y fformat hwn gyda thudalennau 4K, testun a metadata, yn hytrach na gweithio gyda logiau yn uniongyrchol. Mae yna lawer o resymau, sy'n berwi i lawr i'r ffaith bod injan Scalyr yn fewnol yn debycach i gronfa ddata ddosbarthedig nag a system ffeiliau. Mae chwiliad testun yn aml yn cael ei gyfuno Γ’ hidlwyr arddull DBMS yn yr ymylon ar Γ΄l dosrannu logiau. Gallwn chwilio miloedd lawer o logiau ar yr un pryd, ac nid yw ffeiliau testun syml yn addas ar gyfer ein rheolaeth data trafodion, wedi'u hatgynhyrchu, wedi'u dosbarthu).
I ddechrau, roedd yn ymddangos nad oedd cod o'r fath yn addas iawn ar gyfer optimeiddio grym 'n ysgrublaidd. "Gwaith go iawn" yn String.indexOf() nid oedd hyd yn oed yn dominyddu proffil y CPU. Hynny yw, ni fyddai optimeiddio'r dull hwn yn unig yn dod ag effaith sylweddol.
Mae'n digwydd felly ein bod yn storio metadata ar ddechrau pob tudalen, ac mae testun pob neges yn UTF-8 wedi'i bacio ar y pen arall. Gan fanteisio ar hyn, fe wnaethom ailysgrifennu'r ddolen i chwilio'r dudalen gyfan ar unwaith:
Mae'r fersiwn hwn yn gweithio'n uniongyrchol ar y golwg raw byte[] ac yn chwilio pob neges ar unwaith ar draws y dudalen 4K gyfan.
Mae hyn yn llawer haws i'w optimeiddio ar gyfer y dull grym 'n ysgrublaidd. Gelwir y ddolen chwilio fewnol ar yr un pryd ar gyfer y dudalen 4K gyfan, yn hytrach nag ar wahΓ’n ar bob post. Nid oes unrhyw gopΓ―o data, dim dyraniad gwrthrychau. A dim ond pan fydd y canlyniad yn gadarnhaol y gelwir gweithrediadau metadata mwy cymhleth, ac nid ar bob neges. Fel hyn rydym wedi dileu tunnell o orbenion, ac mae gweddill y llwyth wedi'i ganoli mewn dolen chwilio fewnol fach, sy'n addas iawn ar gyfer optimeiddio pellach.
Mae ein algorithm chwilio gwirioneddol yn seiliedig ar . Mae'n debyg i algorithm Boyer-Moore, gan hepgor tua hyd y llinyn chwilio ar bob cam. Y prif wahaniaeth yw ei fod yn gwirio dau beit ar y tro i leihau cyfatebiaethau ffug.
Mae ein gweithrediad yn gofyn am greu tabl chwilio 64K ar gyfer pob chwiliad, ond nid yw hynny'n ddim o'i gymharu Γ’'r gigabeit o ddata rydym yn chwilio drwyddo. Mae'r ddolen fewnol yn prosesu sawl gigabeit yr eiliad ar un craidd. Yn ymarferol, mae perfformiad sefydlog tua 1,25 GB yr eiliad ar bob craidd, ac mae lle i wella. Mae'n bosibl dileu rhywfaint o'r uwchben y tu allan i'r ddolen fewnol, ac rydym yn bwriadu arbrofi gyda dolen fewnol yn C yn lle Java.
Rydym yn defnyddio grym
Rydym wedi trafod y gellir gweithredu chwilio logiau "yn fras", ond faint o "bwer" sydd gennym? Eitha tipyn.
1 craidd: Pan gaiff ei ddefnyddio'n gywir, mae un craidd o brosesydd modern yn eithaf pwerus ynddo'i hun.
8 craidd: Ar hyn o bryd rydym yn rhedeg ar weinyddion Amazon hi1.4xlarge a i2.4xlarge SSD, pob un Γ’ chraidd 8 (16 edafedd). Fel y soniwyd uchod, mae'r creiddiau hyn fel arfer yn brysur gyda gweithrediadau cefndir. Pan fydd y defnyddiwr yn gwneud chwiliad, mae gweithrediadau cefndir yn cael eu hatal, gan ryddhau pob un o'r 8 craidd ar gyfer chwilio. Mae'r chwiliad fel arfer yn dod i ben mewn eiliad hollt, ac ar Γ΄l hynny mae gwaith cefndir yn ailddechrau (mae'r rhaglen sbri yn sicrhau nad yw'r morglawdd o ymholiadau chwilio yn ymyrryd Γ’ gwaith cefndir pwysig).
16 craidd: ar gyfer dibynadwyedd, rydym yn trefnu gweinyddion yn grwpiau meistr/caethweision. Mae gan bob meistr un SSD ac un gweinydd EBS o dan ei orchymyn. Os bydd y prif weinydd yn damwain, mae'r gweinydd SSD yn cymryd ei le ar unwaith. Bron drwy'r amser, mae meistr a chaethweision yn gweithio'n iawn, fel bod modd chwilio pob bloc data ar ddau weinydd gwahanol (mae gan weinydd caethweision EBS brosesydd gwan, felly nid ydym yn ei ystyried). Rhannwn y dasg rhyngddynt, fel bod gennym gyfanswm o 16 craidd ar gael.
Llawer o greiddiau: Yn y dyfodol agos, byddwn yn dosbarthu data ar draws gweinyddwyr yn y fath fodd fel eu bod i gyd yn cymryd rhan mewn prosesu pob cais nad yw'n ddibwys. Bydd pob craidd yn gweithio. [Nodyn: gweithredwyd y cynllun gennym a chynyddwyd y cyflymder chwilio i 1 TB/s, gweler y nodyn ar ddiwedd yr erthygl].
Mae symlrwydd yn sicrhau dibynadwyedd
Mantais arall y dull grym 'n ysgrublaidd yw ei berfformiad eithaf cyson. Yn nodweddiadol, nid yw chwilio yn sensitif iawn i fanylion y broblem a'r set ddata (mae'n debyg mai dyna pam y'i gelwir yn "bras").
Weithiau mae'r mynegai geiriau allweddol yn cynhyrchu canlyniadau hynod gyflym, ac ar adegau eraill nid yw'n gwneud hynny. Gadewch i ni ddweud bod gennych chi 50 GB o logiau lle mae'r term 'cwsmer_5987235982' yn ymddangos yn union dair gwaith. Mae chwiliad am y term hwn yn cyfrif tri lleoliad yn uniongyrchol o'r mynegai a bydd yn cael ei gwblhau ar unwaith. Ond gall chwiliadau cardiau gwyllt cymhleth sganio miloedd o eiriau allweddol a chymryd amser hir.
Ar y llaw arall, mae chwiliadau grym 'n ysgrublaidd yn perfformio ar yr un cyflymder fwy neu lai ar gyfer unrhyw ymholiad. Mae chwilio am eiriau hir yn well, ond mae hyd yn oed chwilio am un nod yn eithaf cyflym.
Mae symlrwydd y dull grym 'n ysgrublaidd yn golygu bod ei berfformiad yn agos at ei uchafswm damcaniaethol. Mae llai o opsiynau ar gyfer gorlwytho disgiau annisgwyl, haeriad clo, mynd ar drywydd pwyntydd, a miloedd o resymau eraill dros fethiant. Edrychais ar y ceisiadau a wnaed gan ddefnyddwyr Scalyr yr wythnos diwethaf ar ein gweinydd prysuraf. Cafwyd 14 o geisiadau. Cymerodd wyth ohonynt yn union fwy nag un eiliad; Cwblhawyd 000% o fewn 99 milieiliad (os nad ydych wedi defnyddio offer dadansoddi log, ymddiriedwch ynof: mae'n gyflym).
Mae perfformiad sefydlog, dibynadwy yn bwysig er mwyn hwyluso defnydd o'r gwasanaeth. Os bydd yn llusgo o bryd i'w gilydd, bydd defnyddwyr yn ei weld yn annibynadwy ac yn amharod i'w ddefnyddio.
Logio chwiliad ar waith
Dyma animeiddiad byr sy'n dangos chwiliad Scalyr ar waith. Mae gennym ni gyfrif demo lle rydyn ni'n mewnforio pob digwyddiad ym mhob ystorfa Github gyhoeddus. Yn y demo hwn, rwy'n archwilio gwerth wythnos o ddata: tua 600 MB o logiau amrwd.
Recordiwyd y fideo yn fyw, heb baratoi'n arbennig, ar fy n ben-desg (tua 5000 cilomedr o'r gweinydd). Mae'r perfformiad a welwch yn bennaf oherwydd , yn ogystal Γ’ backend cyflym a dibynadwy. Pryd bynnag y bydd saib heb ddangosydd 'llwytho', mae'n rhaid i mi oedi fel y gallwch ddarllen yr hyn yr wyf ar fin ei bwyso.
I gloi
Wrth brosesu llawer iawn o ddata, mae'n bwysig dewis algorithm da, ond nid yw "da" yn golygu "ffansi." Meddyliwch sut y bydd eich cod yn gweithio'n ymarferol. Mae'r dadansoddiad damcaniaethol o algorithmau yn gadael allan rhai ffactorau a all fod o bwysigrwydd mawr yn y byd go iawn. Mae algorithmau symlach yn haws i'w optimeiddio ac yn fwy sefydlog mewn sefyllfaoedd ymylol.
Meddyliwch hefyd am y cyd-destun y bydd y cod yn cael ei weithredu ynddo. Yn ein hachos ni, mae angen gweinyddwyr digon pwerus i reoli tasgau cefndir. Yn gymharol anaml y mae defnyddwyr yn cychwyn chwiliadau, felly gallwn fenthyg grΕ΅p cyfan o weinyddion am y cyfnod byr sydd ei angen i gwblhau pob chwiliad.
Gan ddefnyddio dull 'n ysgrublaidd, fe wnaethom weithredu chwiliad cyflym, dibynadwy a hyblyg ar draws set o logiau. Gobeithiwn y bydd y syniadau hyn yn ddefnyddiol ar gyfer eich prosiectau.
Golygu: Mae'r teitl a'r testun wedi newid o "Chwilio ar 20 GB yr eiliad" i "Chwilio ar 1 TB yr eiliad" i adlewyrchu'r cynnydd mewn perfformiad dros yr ychydig flynyddoedd diwethaf. Mae'r cynnydd hwn mewn cyflymder yn bennaf oherwydd newidiadau yn y math a nifer y gweinyddwyr EC2 rydym yn eu gosod heddiw i wasanaethu ein sylfaen cwsmeriaid gynyddol. Mae newidiadau yn dod yn fuan a fydd yn rhoi hwb dramatig arall mewn effeithlonrwydd gweithredol, ac ni allwn aros i'w rhannu.
Ffynhonnell: hab.com