Mae'n ymddangos y dylai maes hysbysebu ar-lein fod mor ddatblygedig yn dechnolegol ac mor awtomataidd â phosibl. Wrth gwrs, oherwydd bod cewri ac arbenigwyr o'r fath yn eu maes fel Yandex, Mail.Ru, Google a Facebook yn gweithio yno. Ond, fel y digwyddodd, nid oes terfyn ar berffeithrwydd ac mae rhywbeth i'w awtomeiddio bob amser.
Grŵp cyfathrebu Rhwydwaith Dentsu Aegis Rwsia yw'r chwaraewr mwyaf yn y farchnad hysbysebu digidol ac mae'n buddsoddi'n weithredol mewn technoleg, gan geisio optimeiddio ac awtomeiddio ei brosesau busnes. Un o broblemau heb eu datrys y farchnad hysbysebu ar-lein yw'r dasg o gasglu ystadegau ar ymgyrchoedd hysbysebu o wahanol lwyfannau Rhyngrwyd. Arweiniodd yr ateb i'r broblem hon yn y pen draw at greu cynnyrch D1.Digidol (darllener fel DiVan), datblygiad yr ydym am siarad amdano.
Pam?
1. Ar adeg cychwyn y prosiect, nid oedd un cynnyrch parod ar y farchnad a oedd yn datrys y broblem o awtomeiddio casglu ystadegau ar ymgyrchoedd hysbysebu. Mae hyn yn golygu na fydd unrhyw un ac eithrio ni ein hunain yn diwallu ein hanghenion.
Mae gwasanaethau fel Improvado, Roistat, Supermetrics, SegmentStream yn cynnig integreiddio â llwyfannau, rhwydweithiau cymdeithasol a Google Analitycs, a hefyd yn ei gwneud hi'n bosibl adeiladu dangosfyrddau dadansoddol ar gyfer dadansoddi a rheoli ymgyrchoedd hysbysebu yn gyfleus. Cyn i ni ddechrau datblygu ein cynnyrch, fe wnaethom geisio defnyddio rhai o'r systemau hyn i gasglu data o safleoedd, ond, yn anffodus, ni allent ddatrys ein problemau.
Y brif broblem oedd bod y cynhyrchion a brofwyd yn dibynnu ar ffynonellau data, gan arddangos ystadegau lleoliad fesul safle, ac nid oeddent yn darparu'r gallu i agregu ystadegau ar ymgyrchoedd hysbysebu. Nid oedd y dull hwn yn caniatáu inni weld ystadegau o wahanol safleoedd mewn un lle a dadansoddi cyflwr yr ymgyrch yn ei gyfanrwydd.
Ffactor arall oedd bod y cynhyrchion wedi'u hanelu at farchnad y Gorllewin yn ystod y camau cychwynnol ac nid oeddent yn cefnogi integreiddio â safleoedd Rwsiaidd. Ac ar gyfer y safleoedd hynny y gweithredwyd integreiddio â nhw, nid oedd yr holl fetrigau angenrheidiol bob amser yn cael eu llwytho i lawr gyda digon o fanylion, ac nid oedd yr integreiddio bob amser yn gyfleus ac yn dryloyw, yn enwedig pan oedd angen cael rhywbeth nad yw yn y rhyngwyneb system.
Yn gyffredinol, fe wnaethom benderfynu peidio ag addasu i gynhyrchion trydydd parti, ond dechreuon ni ddatblygu ein cynnyrch ein hunain...
2. Mae'r farchnad hysbysebu ar-lein yn tyfu o flwyddyn i flwyddyn, ac yn 2018, o ran cyllidebau hysbysebu, goddiweddodd y farchnad hysbysebu teledu mwyaf traddodiadol. Felly mae yna raddfa.
3. Yn wahanol i'r farchnad hysbysebu teledu, lle mae gwerthu hysbysebion masnachol yn cael ei fonopoleiddio, mae yna lawer o berchnogion unigol rhestr eiddo hysbysebu o wahanol feintiau yn gweithredu ar y Rhyngrwyd gyda'u cyfrifon hysbysebu eu hunain. Gan fod ymgyrch hysbysebu, fel rheol, yn rhedeg ar sawl safle ar unwaith, i ddeall cyflwr yr ymgyrch hysbysebu, mae angen casglu adroddiadau o bob safle a'u cyfuno mewn un adroddiad mawr a fydd yn dangos y darlun cyfan. Mae hyn yn golygu bod potensial ar gyfer optimeiddio.
4. Roedd yn ymddangos i ni fod gan berchnogion rhestr eiddo hysbysebu ar y Rhyngrwyd eisoes y seilwaith ar gyfer casglu ystadegau a'u harddangos mewn cyfrifon hysbysebu, a byddant yn gallu darparu API ar gyfer y data hwn. Mae hyn yn golygu ei bod yn dechnegol bosibl ei gweithredu. Gadewch i ni ddweud ar unwaith nad oedd mor syml â hynny.
Yn gyffredinol, roedd yr holl ragofynion ar gyfer gweithredu'r prosiect yn amlwg i ni, a rhedasom i ddod â'r prosiect yn fyw ...
Cynllun mawr
I ddechrau, gwnaethom lunio gweledigaeth o system ddelfrydol:
- Dylai ymgyrchoedd hysbysebu o system gorfforaethol 1C gael eu llwytho i mewn iddi yn awtomatig gyda'u henwau, cyfnodau, cyllidebau a lleoliadau ar lwyfannau amrywiol.
- Ar gyfer pob lleoliad o fewn ymgyrch hysbysebu, dylid lawrlwytho'r holl ystadegau posibl yn awtomatig o'r safleoedd lle mae'r lleoliad yn digwydd, megis nifer yr argraffiadau, cliciau, golygfeydd, ac ati.
- Mae rhai ymgyrchoedd hysbysebu yn cael eu holrhain gan ddefnyddio monitro trydydd parti gan systemau hysbysebu fel y'u gelwir fel Adriver, Weborama, DCM, ac ati. Mae yna hefyd mesurydd Rhyngrwyd diwydiannol yn Rwsia - y cwmni Mediascope. Yn ôl ein cynllun, dylai data o fonitro annibynnol a diwydiannol hefyd gael ei lwytho'n awtomatig i'r ymgyrchoedd hysbysebu cyfatebol.
- Mae'r rhan fwyaf o ymgyrchoedd hysbysebu ar y Rhyngrwyd wedi'u hanelu at rai gweithredoedd targed (prynu, galw, cofrestru ar gyfer gyriant prawf, ac ati), sy'n cael eu holrhain gan ddefnyddio Google Analytics, ac ystadegau sydd hefyd yn bwysig ar gyfer deall statws yr ymgyrch a Dylid ei lwytho i mewn i'n teclyn.
Mae'r crempog cyntaf yn lympiog
O ystyried ein hymrwymiad i egwyddorion hyblyg datblygu meddalwedd (ystwyth, popeth), fe wnaethom benderfynu datblygu MVP yn gyntaf ac yna symud tuag at y nod a fwriadwyd yn ailadroddol.
Fe wnaethom benderfynu adeiladu MVP yn seiliedig ar ein cynnyrch DANBo (Bwrdd Rhwydwaith Densu Aegis), sy'n gymhwysiad gwe gyda gwybodaeth gyffredinol am ymgyrchoedd hysbysebu ein cleientiaid.
Ar gyfer MVP, symleiddiwyd y prosiect cymaint â phosibl o ran gweithredu. Rydym wedi dewis rhestr gyfyngedig o lwyfannau ar gyfer integreiddio. Y rhain oedd y prif lwyfannau, megis Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, a'r prif systemau hysbysebu Adriver a Weborama.
I gyrchu ystadegau ar wefannau trwy'r API, fe wnaethom ddefnyddio un cyfrif. Roedd yn rhaid i reolwr grŵp cleient a oedd am ddefnyddio casgliad awtomatig o ystadegau ar ymgyrch hysbysebu ddirprwyo mynediad i'r ymgyrchoedd hysbysebu angenrheidiol ar safleoedd i'r cyfrif platfform yn gyntaf.
Nesaf yw defnyddiwr y system DANBo roedd yn rhaid i chi lwytho ffeil o fformat penodol i mewn i'r system Excel, a oedd yn cynnwys yr holl wybodaeth am y lleoliad (ymgyrch hysbysebu, platfform, fformat, cyfnod lleoli, dangosyddion cynlluniedig, cyllideb, ac ati) a dynodwyr yr ymgyrchoedd hysbysebu cyfatebol ar y safleoedd a chownteri mewn systemau hysbysebu.
Roedd yn edrych, a dweud y gwir, yn frawychus:
Cadwyd y data a lawrlwythwyd i gronfa ddata, ac yna bu i wasanaethau wahanu dynodwyr ymgyrch ar safleoedd oddi wrthynt a llwytho ystadegau i lawr arnynt.
Ar gyfer pob gwefan, ysgrifennwyd gwasanaeth ffenestri ar wahân, a oedd unwaith y dydd yn mynd o dan un cyfrif gwasanaeth yn API y wefan ac yn lawrlwytho ystadegau ar gyfer IDau ymgyrch penodedig. Digwyddodd yr un peth gyda systemau hysbysebu.
Dangoswyd y data a lawrlwythwyd ar y rhyngwyneb ar ffurf dangosfwrdd bach wedi'i deilwra:
Yn annisgwyl i ni, dechreuodd MVP weithio a dechreuodd lawrlwytho ystadegau cyfredol ar ymgyrchoedd hysbysebu ar y Rhyngrwyd. Rhoesom y system ar waith ar sawl cleient, ond wrth geisio graddio, cawsom broblemau difrifol:
- Y brif broblem oedd cymhlethdod paratoi data i'w lwytho i mewn i'r system. Hefyd, bu'n rhaid trosi'r data lleoliad i fformat cwbl sefydlog cyn ei lwytho. Roedd angen cynnwys dynodwyr endid o wahanol safleoedd yn y ffeil lawrlwytho. Rydym yn wynebu'r ffaith ei bod yn anodd iawn i ddefnyddwyr technegol heb eu hyfforddi esbonio ble i ddod o hyd i'r dynodwyr hyn ar y wefan a ble yn y ffeil y mae angen eu mewnbynnu. O ystyried nifer y gweithwyr yn yr adrannau sy'n cynnal ymgyrchoedd ar safleoedd a'r trosiant, arweiniodd hyn at lawer iawn o gefnogaeth ar ein hochr ni, ac nid oeddem yn hapus ag ef o gwbl.
- Problem arall oedd nad oedd gan bob platfform hysbysebu fecanweithiau ar gyfer dirprwyo mynediad i ymgyrchoedd hysbysebu i gyfrifon eraill. Ond hyd yn oed pe bai mecanwaith dirprwyo ar gael, nid oedd pob hysbysebwr yn fodlon caniatáu mynediad i'w hymgyrchoedd i gyfrifon trydydd parti.
- Ffactor pwysig oedd y dicter a gododd ymhlith defnyddwyr gan y ffaith bod yn rhaid i'r holl ddangosyddion cynlluniedig a manylion lleoliadau y maent eisoes yn eu cynnwys yn ein system gyfrifo 1C ail-ymuno â nhw. DANBo.
Rhoddodd hyn y syniad i ni mai’r brif ffynhonnell o wybodaeth am leoliad ddylai fod ein system 1C, lle mae’r holl ddata’n cael ei fewnbynnu’n gywir ac ar amser (y pwynt yma yw bod anfonebau’n cael eu cynhyrchu ar sail data 1C, felly mewnbynnu data’n gywir i 1C yn flaenoriaeth i bawb DPA). Dyma sut y daeth cysyniad newydd o'r system i'r amlwg...
Cysyniad
Y peth cyntaf i ni benderfynu ei wneud oedd gwahanu'r system ar gyfer casglu ystadegau ar ymgyrchoedd hysbysebu ar y Rhyngrwyd yn gynnyrch ar wahân - D1.Digidol.
Yn y cysyniad newydd, fe benderfynon ni lwytho i mewn D1.Digidol gwybodaeth am ymgyrchoedd hysbysebu a lleoliadau ynddynt o 1C, ac yna tynnu ystadegau o safleoedd a systemau AdServing i'r lleoliadau hyn. Roedd hyn i fod i symleiddio bywyd defnyddwyr yn sylweddol (ac, yn ôl yr arfer, ychwanegu mwy o waith i ddatblygwyr) a lleihau faint o gefnogaeth.
Roedd y broblem gyntaf y daethom ar ei thraws yn un o natur sefydliadol ac roedd yn ymwneud â'r ffaith na allem ddod o hyd i allwedd neu arwydd y gallem ei ddefnyddio i gymharu endidau o systemau gwahanol ag ymgyrchoedd a lleoliadau o 1C. Y ffaith yw bod y broses yn ein cwmni wedi'i chynllunio yn y fath fodd fel bod gwahanol bobl yn ymuno ag ymgyrchoedd hysbysebu mewn systemau gwahanol (cynllunwyr cyfryngau, prynu, ac ati).
I ddatrys y broblem hon, roedd yn rhaid i ni ddyfeisio allwedd stwnsh unigryw, DANBoID, a fyddai'n cysylltu endidau mewn systemau gwahanol â'i gilydd, ac y gellid ei nodi'n weddol hawdd ac unigryw mewn setiau data a lawrlwythwyd. Cynhyrchir y dynodwr hwn yn y system 1C fewnol ar gyfer pob lleoliad unigol a chaiff ei drosglwyddo i ymgyrchoedd, lleoliadau a chownteri ar bob safle ac ym mhob system AdServing. Cymerodd dipyn o amser i roi’r arfer o roi DANBoID ym mhob lleoliad ar waith, ond fe wnaethom lwyddo i wneud hynny :)
Yna fe wnaethom ddarganfod nad oes gan bob gwefan API ar gyfer casglu ystadegau yn awtomatig, a hyd yn oed y rhai sydd ag API, nid yw'n dychwelyd yr holl ddata angenrheidiol.
Ar y cam hwn, penderfynasom leihau'n sylweddol y rhestr o lwyfannau ar gyfer integreiddio a chanolbwyntio ar y prif lwyfannau sy'n ymwneud â mwyafrif helaeth yr ymgyrchoedd hysbysebu. Mae'r rhestr hon yn cynnwys yr holl chwaraewyr mwyaf yn y farchnad hysbysebu (Google, Yandex, Mail.ru), rhwydweithiau cymdeithasol (VK, Facebook, Twitter), prif systemau AdServing a dadansoddeg (DCM, Adriver, Weborama, Google Analytics) a llwyfannau eraill.
Roedd gan y mwyafrif o'r gwefannau a ddewiswyd gennym API a oedd yn darparu'r metrigau yr oedd eu hangen arnom. Mewn achosion lle nad oedd API neu lle nad oedd yn cynnwys y data angenrheidiol, fe wnaethom ddefnyddio adroddiadau a anfonwyd yn ddyddiol i e-bost ein swyddfa i lwytho data (mewn rhai systemau mae'n bosibl ffurfweddu adroddiadau o'r fath, mewn eraill fe wnaethom gytuno ar ddatblygu adroddiadau o'r fath i ni).
Wrth ddadansoddi data o wahanol safleoedd, fe wnaethom ddarganfod nad yw hierarchaeth endidau yr un peth mewn systemau gwahanol. At hynny, mae angen lawrlwytho gwybodaeth mewn gwahanol fanylion o wahanol systemau.
I ddatrys y broblem hon, datblygwyd cysyniad SubDANBoID. Mae'r syniad o SubDANBoID yn eithaf syml, rydym yn nodi prif endid yr ymgyrch ar y wefan gyda'r DANBoID a gynhyrchir, ac rydym yn uwchlwytho pob endid nythu gyda dynodwyr safle unigryw ac yn ffurfio SubDANBoID yn unol ag egwyddor DANBoID + dynodwr y lefel gyntaf endid nythu + dynodwr yr endid nythu ail lefel +... Roedd y dull hwn yn caniatáu i ni gysylltu ymgyrchoedd hysbysebu mewn systemau gwahanol a lawrlwytho ystadegau manwl arnynt.
Roedd yn rhaid i ni hefyd ddatrys problem mynediad i ymgyrchoedd ar wahanol lwyfannau. Fel y gwnaethom ysgrifennu uchod, nid yw'r mecanwaith ar gyfer dirprwyo mynediad i ymgyrch i gyfrif technegol ar wahân bob amser yn berthnasol. Felly, bu'n rhaid i ni ddatblygu seilwaith ar gyfer awdurdodi awtomatig drwy OAuth gan ddefnyddio tocynnau a mecanweithiau ar gyfer diweddaru'r tocynnau hyn.
Yn ddiweddarach yn yr erthygl byddwn yn ceisio disgrifio'n fanylach bensaernïaeth yr ateb a manylion technegol y gweithrediad.
Pensaernïaeth datrysiad 1.0
Wrth ddechrau gweithredu cynnyrch newydd, roeddem yn deall bod angen i ni ddarparu ar unwaith ar gyfer y posibilrwydd o gysylltu safleoedd newydd, felly penderfynasom ddilyn llwybr pensaernïaeth microwasanaeth.
Wrth ddylunio'r bensaernïaeth, fe wnaethom wahanu cysylltwyr i bob system allanol - 1C, llwyfannau hysbysebu a systemau hysbysebu - yn wasanaethau ar wahân.
Y prif syniad yw bod gan bob cysylltydd i safleoedd yr un API a'u bod yn addaswyr sy'n dod â'r API safle i ryngwyneb sy'n gyfleus i ni.
Yng nghanol ein cynnyrch mae cymhwysiad gwe, sef monolith sydd wedi'i ddylunio yn y fath fodd fel y gellir ei ddadosod yn hawdd i wasanaethau. Mae'r cymhwysiad hwn yn gyfrifol am brosesu'r data a lawrlwythwyd, casglu ystadegau o wahanol systemau a'u cyflwyno i ddefnyddwyr system.
Er mwyn cyfathrebu rhwng y cysylltwyr a'r cymhwysiad gwe, roedd yn rhaid i ni greu gwasanaeth ychwanegol, a elwir yn Connector Proxy. Mae'n cyflawni swyddogaethau Darganfod Gwasanaeth a Threfnydd Tasg. Mae'r gwasanaeth hwn yn cynnal tasgau casglu data ar gyfer pob cysylltydd bob nos. Roedd ysgrifennu haen gwasanaeth yn haws na chysylltu brocer negeseuon, ac i ni roedd yn bwysig cael y canlyniad cyn gynted â phosibl.
Ar gyfer symlrwydd a chyflymder datblygiad, fe wnaethom hefyd benderfynu y bydd pob gwasanaeth yn API Gwe. Roedd hyn yn ei gwneud hi'n bosibl casglu prawf o gysyniad yn gyflym a gwirio bod y dyluniad cyfan yn gweithio.
Tasg ar wahân, braidd yn gymhleth, oedd sefydlu mynediad i gasglu data o wahanol gyfrifon, a ddylai, fel y penderfynasom, gael ei wneud gan ddefnyddwyr drwy'r rhyngwyneb gwe. Mae'n cynnwys dau gam ar wahân: yn gyntaf, mae'r defnyddiwr yn ychwanegu tocyn i gael mynediad i'r cyfrif trwy OAuth, ac yna'n ffurfweddu'r casgliad data ar gyfer y cleient o gyfrif penodol. Mae cael tocyn trwy OAuth yn angenrheidiol oherwydd, fel yr ydym wedi ysgrifennu eisoes, nid yw bob amser yn bosibl dirprwyo mynediad i'r cyfrif dymunol ar y wefan.
Er mwyn creu mecanwaith cyffredinol ar gyfer dewis cyfrif o wefannau, roedd yn rhaid i ni ychwanegu dull at yr API cysylltwyr sy'n dychwelyd Sgema JSON, sy'n cael ei rendro i ffurf gan ddefnyddio cydran JSONEditor wedi'i haddasu. Fel hyn, roedd defnyddwyr yn gallu dewis y cyfrifon i lawrlwytho data ohonynt.
Er mwyn cydymffurfio â'r terfynau ceisiadau sy'n bodoli ar safleoedd, rydym yn cyfuno ceisiadau am osodiadau o fewn un tocyn, ond gallwn brosesu gwahanol docynnau ochr yn ochr.
Dewisasom MongoDB fel storfa ar gyfer data wedi'i lwytho ar gyfer y cymhwysiad gwe a'r cysylltwyr, a oedd yn caniatáu inni beidio â phoeni gormod am y strwythur data yn ystod camau cychwynnol y datblygiad, pan fydd model gwrthrych y cais yn newid bob yn ail ddiwrnod.
Fe wnaethom ddarganfod yn fuan nad yw'r holl ddata yn cyd-fynd yn dda yn MongoDB ac, er enghraifft, ei bod yn fwy cyfleus storio ystadegau dyddiol mewn cronfa ddata berthynol. Felly, ar gyfer cysylltwyr y mae eu strwythur data yn fwy addas ar gyfer cronfa ddata berthynol, fe wnaethom ddechrau defnyddio PostgreSQL neu MS SQL Server fel storfa.
Roedd y bensaernïaeth a'r technolegau a ddewiswyd yn ein galluogi i adeiladu a lansio'r cynnyrch D1.Digital yn gymharol gyflym. Dros ddwy flynedd o ddatblygu cynnyrch, fe wnaethom ddatblygu 23 o gysylltwyr i safleoedd, ennill profiad amhrisiadwy o weithio gydag APIs trydydd parti, dysgu i osgoi peryglon gwahanol safleoedd, yr oedd gan bob un eu rhai eu hunain, a gyfrannodd at ddatblygiad yr API o 3 o leiaf. safleoedd, wedi lawrlwytho gwybodaeth yn awtomatig ar bron i 15 o ymgyrchoedd ac ar gyfer mwy na 000 o leoliadau, wedi casglu llawer o adborth gan ddefnyddwyr ar weithrediad y cynnyrch ac wedi llwyddo i newid prif broses y cynnyrch sawl gwaith, yn seiliedig ar yr adborth hwn.
Pensaernïaeth datrysiad 2.0
Mae dwy flynedd wedi mynd heibio ers dechrau'r datblygiad D1.Digidol. Yn raddol, datgelodd y cynnydd cyson yn y llwyth ar y system ac ymddangosiad mwy a mwy o ffynonellau data newydd broblemau yn y pensaernïaeth datrysiad presennol.
Mae'r broblem gyntaf yn ymwneud â faint o ddata sy'n cael ei lawrlwytho o'r gwefannau. Roeddem yn wynebu'r ffaith bod casglu a diweddaru'r holl ddata angenrheidiol o'r safleoedd mwyaf wedi dechrau cymryd gormod o amser. Er enghraifft, mae casglu data o system hysbysebu AdRiver, yr ydym yn ei defnyddio i olrhain ystadegau ar gyfer y rhan fwyaf o leoliadau, yn cymryd tua 12 awr.
Er mwyn datrys y broblem hon, rydym wedi dechrau defnyddio pob math o adroddiadau i lawrlwytho data o safleoedd, rydym yn ceisio datblygu eu API ynghyd â'r safleoedd fel bod cyflymder ei weithrediad yn bodloni ein hanghenion, a chyfochrog lawrlwytho data cymaint â phosibl.
Mae problem arall yn ymwneud â phrosesu data wedi'i lawrlwytho. Nawr, pan fydd ystadegau lleoli newydd yn cyrraedd, mae proses aml-gam o ailgyfrifo metrigau yn cael ei lansio, sy'n cynnwys llwytho data crai, cyfrifo metrigau cyfanredol ar gyfer pob safle, cymharu data o wahanol ffynonellau â'i gilydd, a chyfrifo metrigau cryno ar gyfer yr ymgyrch. Mae hyn yn achosi llawer o lwyth ar y rhaglen we sy'n gwneud yr holl gyfrifiadau. Sawl gwaith, yn ystod y broses ailgyfrifo, defnyddiodd y cymhwysiad yr holl gof ar y gweinydd, tua 10-15 GB, a gafodd yr effaith fwyaf niweidiol ar waith defnyddwyr gyda'r system.
Arweiniodd y problemau a nodwyd a chynlluniau uchelgeisiol ar gyfer datblygu'r cynnyrch ymhellach ni at yr angen i ailystyried pensaernïaeth y cais.
Dechreuon ni gyda chysylltwyr.
Sylwasom fod yr holl gysylltwyr yn gweithio yn ôl yr un model, felly fe wnaethom adeiladu fframwaith piblinell i greu cysylltydd dim ond i raglennu rhesymeg y camau y bu'n rhaid i chi ei raglennu, roedd y gweddill yn gyffredinol. Os oes angen gwella rhai cysylltydd, yna byddwn yn ei drosglwyddo ar unwaith i fframwaith newydd ar yr un pryd ag y mae'r cysylltydd yn cael ei wella.
Ar yr un pryd, dechreuon ni ddefnyddio cysylltwyr i Docker a Kubernetes.
Fe wnaethon ni gynllunio'r symudiad i Kubernetes am amser eithaf hir, arbrofi gyda gosodiadau CI / CD, ond fe ddechreuon ni symud dim ond pan ddechreuodd un cysylltydd, oherwydd gwall, fwyta mwy na 20 GB o gof ar y gweinydd, gan ladd prosesau eraill yn ymarferol. . Yn ystod yr ymchwiliad, symudwyd y cysylltydd i glwstwr Kubernetes, lle arhosodd yn y pen draw, hyd yn oed ar ôl trwsio'r gwall.
Yn weddol gyflym sylweddolon ni fod Kubernetes yn gyfleus, ac o fewn chwe mis fe wnaethom drosglwyddo 7 cysylltydd a Connectors Proxy, sy'n defnyddio'r mwyaf o adnoddau, i'r clwstwr cynhyrchu.
Yn dilyn y cysylltwyr, penderfynasom newid pensaernïaeth gweddill y cais.
Y brif broblem oedd bod data'n dod o gysylltwyr i ddirprwyon mewn sypiau mawr, ac yna'n taro'r DANBoID ac yn cael ei anfon i'r cymhwysiad gwe canolog i'w brosesu. Oherwydd y nifer fawr o ailgyfrifiadau metrigau, mae llwyth mawr ar y cais.
Roedd hefyd yn eithaf anodd monitro statws swyddi casglu data unigol ac adrodd am gamgymeriadau sy'n digwydd o fewn cysylltwyr i raglen we ganolog fel bod defnyddwyr yn gallu gweld beth oedd yn digwydd a pham nad oedd data'n cael ei gasglu.
I ddatrys y problemau hyn, rydym wedi datblygu pensaernïaeth 2.0.
Y prif wahaniaeth rhwng y fersiwn newydd o'r bensaernïaeth yw ein bod yn defnyddio RabbitMQ a llyfrgell MassTransit i gyfnewid negeseuon rhwng gwasanaethau yn lle'r API Gwe. I wneud hyn, bu'n rhaid i ni ailysgrifennu Connectors Proxy bron yn llwyr, gan ei wneud yn Connectors Hub. Newidiwyd yr enw oherwydd nid prif rôl y gwasanaeth bellach yw anfon ceisiadau at gysylltwyr ac yn ôl, ond wrth reoli'r casgliad o fetrigau o gysylltwyr.
O'r cymhwysiad gwe canolog, fe wnaethom wahanu gwybodaeth am leoliadau ac ystadegau o safleoedd yn wasanaethau ar wahân, a oedd yn ei gwneud hi'n bosibl cael gwared ar ailgyfrifiadau diangen a storio dim ond ystadegau a gyfrifwyd ac a agregwyd eisoes ar lefel lleoliad. Fe wnaethom hefyd ailysgrifennu a gwneud y gorau o'r rhesymeg ar gyfer cyfrifo ystadegau sylfaenol yn seiliedig ar ddata crai.
Ar yr un pryd, rydym yn mudo pob gwasanaeth a chymhwysiad i Docker a Kubernetes i wneud yr ateb yn haws i'w raddfa ac yn fwy cyfleus i'w reoli.
Ble rydyn ni nawr
Prawf-o-cysyniad pensaernïaeth 2.0 cynnyrch D1.Digidol yn barod ac yn gweithio mewn amgylchedd prawf gyda set gyfyngedig o gysylltwyr. Y cyfan sydd ar ôl i'w wneud yw ailysgrifennu 20 cysylltydd arall i blatfform newydd, profi bod y data wedi'i lwytho'n gywir a bod yr holl fetrigau'n cael eu cyfrifo'n gywir, a chyflwyno'r dyluniad cyfan i gynhyrchu.
Mewn gwirionedd, bydd y broses hon yn digwydd yn raddol a bydd yn rhaid inni adael cydnawsedd yn ôl â hen APIs i gadw popeth i weithio.
Mae ein cynlluniau uniongyrchol yn cynnwys datblygu cysylltwyr newydd, integreiddio â systemau newydd ac ychwanegu metrigau ychwanegol at y set o ddata sy'n cael ei lawrlwytho o safleoedd cysylltiedig a systemau hysbysebu.
Rydym hefyd yn bwriadu trosglwyddo pob cais, gan gynnwys y cymhwysiad gwe canolog, i Docker a Kubernetes. Ar y cyd â'r bensaernïaeth newydd, bydd hyn yn symleiddio'r broses o leoli, monitro a rheoli adnoddau a ddefnyddir yn sylweddol.
Syniad arall yw arbrofi gyda'r dewis o gronfa ddata ar gyfer storio ystadegau, sy'n cael ei storio ar hyn o bryd yn MongoDB. Rydym eisoes wedi trosglwyddo sawl cysylltydd newydd i gronfeydd data SQL, ond mae'r gwahaniaeth bron yn anweledig, ac ar gyfer ystadegau cyfanredol yn ystod y dydd, y gellir gofyn amdanynt am gyfnod mympwyol, gall yr ennill fod yn eithaf difrifol.
Yn gyffredinol, mae'r cynlluniau'n fawreddog, gadewch i ni symud ymlaen :)
Awduron yr erthygl R&D Dentsu Aegis Network Rwsia: Georgy Ostapenko (), Mikhail Kotsik ()
Ffynhonnell: hab.com