Duket se fusha e reklamimit online duhet të jetë sa më e avancuar dhe e automatizuar teknologjikisht. Sigurisht, sepse gjigantë dhe ekspertë të tillë në fushën e tyre si Yandex, Mail.Ru, Google dhe Facebook punojnë atje. Por, siç doli, nuk ka kufi për përsosmërinë dhe gjithmonë ka diçka për të automatizuar.
Grupi i komunikimit Dentsu Aegis Network Russia është lojtari më i madh në tregun e reklamave dixhitale dhe po investon në mënyrë aktive në teknologji, duke u përpjekur të optimizojë dhe automatizojë proceset e tij të biznesit. Një nga problemet e pazgjidhura të tregut të reklamave online është bërë detyra e mbledhjes së statistikave për fushatat reklamuese nga platforma të ndryshme të internetit. Zgjidhja e këtij problemi përfundimisht rezultoi në krijimin e një produkti D1.Dixhital (lexo si DiVan), zhvillimi i të cilit duam të flasim.
Pse?
1. Në momentin e fillimit të projektit nuk kishte asnjë produkt të gatshëm në treg që të zgjidhte problemin e automatizimit të mbledhjes së statistikave për fushatat reklamuese. Kjo do të thotë që askush përveç nesh nuk do të kënaqë nevojat tona.
Shërbime të tilla si Improvado, Roistat, Supermetrics, SegmentStream ofrojnë integrim me platformat, rrjetet sociale dhe Google Analitycs, si dhe bëjnë të mundur ndërtimin e paneleve analitike për analiza dhe kontroll të përshtatshëm të fushatave reklamuese. Përpara se të fillonim zhvillimin e produktit tonë, ne u përpoqëm të përdornim disa nga këto sisteme për të mbledhur të dhëna nga faqet, por, për fat të keq, ato nuk mund të zgjidhnin problemet tona.
Problemi kryesor ishte se produktet e testuara bazoheshin në burimet e të dhënave, duke shfaqur statistikat e vendosjes sipas faqes dhe nuk ofronin mundësinë për të grumbulluar statistika për fushatat reklamuese. Kjo qasje nuk na lejoi të shohim statistika nga faqe të ndryshme në një vend dhe të analizojmë gjendjen e fushatës në tërësi.
Një faktor tjetër ishte se në fazat fillestare produktet synonin tregun perëndimor dhe nuk mbështetnin integrimin me faqet ruse. Dhe për ato faqe me të cilat u zbatua integrimi, të gjitha metrikat e nevojshme nuk shkarkoheshin gjithmonë me detaje të mjaftueshme, dhe integrimi nuk ishte gjithmonë i përshtatshëm dhe transparent, veçanërisht kur ishte e nevojshme të merrej diçka që nuk është në ndërfaqen e sistemit.
Në përgjithësi, ne vendosëm të mos përshtatemi me produktet e palëve të treta, por filluam të zhvillojmë tonën...
2. Tregu i reklamave online po rritet nga viti në vit dhe në vitin 2018 për sa i përket buxheteve të reklamave ka kaluar tregun tradicionalisht më të madh të reklamave televizive. Pra, ka një shkallë.
3. Ndryshe nga tregu i reklamave televizive, ku shitja e reklamave komerciale është e monopolizuar, ka shumë pronarë individualë të inventarit reklamues të madhësive të ndryshme që operojnë në internet me llogaritë e tyre reklamuese. Meqenëse një fushatë reklamuese, si rregull, zhvillohet në disa site njëherësh, për të kuptuar gjendjen e fushatës reklamuese, është e nevojshme të mblidhen raporte nga të gjitha faqet dhe t'i kombinohen ato në një raport të madh që do të tregojë të gjithë pamjen. Kjo do të thotë se ka potencial për optimizim.
4. Na u duk se pronarët e inventarit të reklamave në internet tashmë kanë infrastrukturën për mbledhjen e statistikave dhe shfaqjen e tyre në llogaritë e reklamave dhe ata do të mund të ofrojnë një API për këto të dhëna. Kjo do të thotë se është teknikisht e mundur të zbatohet. Le të themi menjëherë se doli të mos ishte aq e thjeshtë.
Në përgjithësi, të gjitha parakushtet për zbatimin e projektit ishin të dukshme për ne dhe vrapuam për ta sjellë në jetë projektin...
Plani i madh
Për të filluar, ne formuam një vizion të një sistemi ideal:
- Fushatat reklamuese nga sistemi i korporatës 1C duhet të ngarkohen automatikisht në të me emrat, periudhat, buxhetet dhe vendosjet e tyre në platforma të ndryshme.
- Për çdo vendosje brenda një fushate reklamuese, të gjitha statistikat e mundshme duhet të shkarkohen automatikisht nga faqet ku bëhet vendosja, si numri i përshtypjeve, klikimeve, shikimeve, etj.
- Disa fushata reklamimi gjurmohen duke përdorur monitorimin e palëve të treta nga të ashtuquajturat sisteme reklamimi si Adriver, Weborama, DCM, etj. Ekziston edhe një matës industrial i Internetit në Rusi - kompania Mediascope. Sipas planit tonë, të dhënat nga monitorimi i pavarur dhe industrial duhet gjithashtu të ngarkohen automatikisht në fushatat përkatëse reklamuese.
- Shumica e fushatave reklamuese në internet synojnë veprime të caktuara të synuara (blerje, telefonatë, regjistrim për një test drive, etj.), të cilat gjurmohen duke përdorur Google Analytics dhe statistikat për të cilat janë gjithashtu të rëndësishme për të kuptuar statusin e fushatës dhe duhet të ngarkohet në mjetin tonë.
Gjëja e parë e mallkuar është me gunga
Duke pasur parasysh angazhimin tonë ndaj parimeve fleksibël të zhvillimit të softuerit (të shkathët, të gjitha gjërat), ne vendosëm të zhvillojmë fillimisht një MVP dhe më pas të lëvizim drejt qëllimit të synuar në mënyrë të përsëritur.
Ne vendosëm të ndërtojmë MVP bazuar në produktin tonë DANBo (Dentsu Aegis Network Board), i cili është një aplikacion ueb me informacion të përgjithshëm mbi fushatat reklamuese të klientëve tanë.
Për MVP, projekti u thjeshtua sa më shumë përsa i përket zbatimit. Ne kemi zgjedhur një listë të kufizuar platformash për integrim. Këto ishin platformat kryesore, si Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB dhe sistemet kryesore të reklamimit Adriver dhe Weborama.
Për të hyrë në statistikat në sajte nëpërmjet API-së, ne përdorëm një llogari të vetme. Një menaxher i grupit të klientëve, i cili dëshironte të përdorte mbledhjen automatike të statistikave në një fushatë reklamuese, duhej së pari të delegonte aksesin në fushatat e nevojshme reklamuese në faqet në llogarinë e platformës.
Tjetra është përdoruesi i sistemit DANBo duhej të ngarkonte një skedar të një formati të caktuar në sistemin Excel, i cili përmbante të gjithë informacionin rreth vendosjes (fushatën reklamuese, platformën, formatin, periudhën e vendosjes, treguesit e planifikuar, buxhetin, etj.) dhe identifikuesit e fushatave përkatëse reklamuese në faqet dhe sportelet në sistemet e reklamimit.
Dukej, sinqerisht, e frikshme:
Të dhënat e shkarkuara u ruajtën në një bazë të dhënash, dhe më pas shërbime të veçanta mblodhën identifikuesit e fushatës në sajte prej tyre dhe shkarkuan statistika mbi to.
Për çdo sajt, u shkrua një shërbim i veçantë Windows, i cili një herë në ditë kalonte nën një llogari shërbimi në API-në e sajtit dhe shkarkonte statistika për ID-të e fushatave të specifikuara. E njëjta gjë ndodhi me sistemet e reklamimit.
Të dhënat e shkarkuara u shfaqën në ndërfaqe në formën e një pulti të vogël me porosi:
Papritur për ne, MVP filloi të punojë dhe filloi të shkarkojë statistikat aktuale të fushatave reklamuese në internet. Ne e implementuam sistemin në disa klientë, por kur u përpoqëm të shkallëzuam, hasëm probleme serioze:
- Problemi kryesor ishte kompleksiteti i përgatitjes së të dhënave për ngarkimin në sistem. Gjithashtu, të dhënat e vendosjes duhej të konvertoheshin në një format rreptësisht fiks përpara se të ngarkoheshin. Ishte e nevojshme të përfshiheshin identifikuesit e entitetit nga sajte të ndryshme në skedarin e shkarkimit. Jemi përballë faktit se është shumë e vështirë për përdoruesit e patrajnuar teknikisht të shpjegojnë se ku mund t'i gjejnë këta identifikues në faqe dhe ku në skedar duhet të futen. Duke marrë parasysh numrin e punonjësve në departamentet që zhvillojnë fushata në faqe dhe qarkullimin, kjo rezultoi në një mbështetje të madhe nga ana jonë, me të cilën nuk ishim absolutisht të kënaqur.
- Një problem tjetër ishte se jo të gjitha platformat e reklamimit kishin mekanizma për delegimin e aksesit në fushatat reklamuese në llogari të tjera. Por edhe nëse ekzistonte një mekanizëm delegimi, jo të gjithë reklamuesit ishin të gatshëm t'u jepnin akses në fushatat e tyre llogarive të palëve të treta.
- Një faktor i rëndësishëm ishte indinjata që ngjalli në mesin e përdoruesve nga fakti se të gjithë treguesit e planifikuar dhe detajet e vendosjes që ata tashmë hyjnë në sistemin tonë të kontabilitetit 1C, ata duhet të rifusin në DANBo.
Kjo na dha idenë se burimi kryesor i informacionit për vendosjen duhet të jetë sistemi ynë 1C, në të cilin të gjitha të dhënat futen me saktësi dhe në kohë (çështja këtu është që faturat gjenerohen bazuar në të dhënat 1C, kështu që futja e saktë e të dhënave në 1C është një prioritet për të gjithë KPI). Kështu doli një koncept i ri i sistemit...
koncept
Gjëja e parë që vendosëm të bënim ishte të veçonim sistemin për mbledhjen e statistikave për fushatat reklamuese në internet në një produkt të veçantë - D1.Dixhital.
Në konceptin e ri, ne vendosëm të ngarkojmë D1.Dixhital informacion mbi fushatat reklamuese dhe vendosjet brenda tyre nga 1C, dhe më pas tërhiqni statistika nga faqet dhe sistemet e AdServing në këto vendosje. Kjo supozohej të thjeshtonte ndjeshëm jetën për përdoruesit (dhe, si zakonisht, t'u shtonte më shumë punë zhvilluesve) dhe të zvogëlonte sasinë e mbështetjes.
Problemi i parë që hasëm ishte i një natyre organizative dhe lidhej me faktin se nuk mund të gjenim një çelës apo shenjë me të cilën mund të krahasonim entitete nga sisteme të ndryshme me fushatat dhe vendosjet nga 1C. Fakti është se procesi në kompaninë tonë është projektuar në atë mënyrë që fushatat reklamuese të futen në sisteme të ndryshme nga njerëz të ndryshëm (planifikues media, blerje, etj.).
Për të zgjidhur këtë problem, na u desh të shpiknim një çelës unik hash, DANBoID, që do të lidhë entitete në sisteme të ndryshme së bashku dhe që mund të identifikohej mjaft lehtë dhe në mënyrë unike në grupet e të dhënave të shkarkuara. Ky identifikues gjenerohet në sistemin e brendshëm 1C për çdo vendosje individuale dhe transferohet në fushata, vendosje dhe sportele në të gjitha sajtet dhe në të gjitha sistemet e AdServing. Zbatimi i praktikës së vendosjes së DANBoID në të gjitha vendosjet mori pak kohë, por ne ia dolëm :)
Më pas zbuluam se jo të gjitha faqet kanë një API për mbledhjen automatike të statistikave, madje edhe ato që kanë një API, nuk i kthen të gjitha të dhënat e nevojshme.
Në këtë fazë, ne vendosëm të reduktojmë ndjeshëm listën e platformave për integrim dhe të fokusohemi në platformat kryesore që përfshihen në shumicën dërrmuese të fushatave reklamuese. Kjo listë përfshin të gjithë lojtarët më të mëdhenj në tregun e reklamave (Google, Yandex, Mail.ru), rrjetet sociale (VK, Facebook, Twitter), sistemet kryesore të AdServing dhe analitike (DCM, Adriver, Weborama, Google Analytics) dhe platforma të tjera.
Shumica e sajteve që zgjodhëm kishin një API që ofronte matjet që na nevojiteshin. Në rastet kur nuk kishte API ose nuk përmbante të dhënat e nevojshme, ne përdornim raporte të dërguara çdo ditë në emailin tonë të zyrës për të ngarkuar të dhëna (në disa sisteme është e mundur të konfiguroni raporte të tilla, në të tjera ne ramë dakord për zhvillimin e raporteve të tilla për NE).
Kur analizuam të dhënat nga site të ndryshme, zbuluam se hierarkia e entiteteve nuk është e njëjtë në sisteme të ndryshme. Për më tepër, informacioni duhet të shkarkohet në detaje të ndryshme nga sisteme të ndryshme.
Për të zgjidhur këtë problem, u zhvillua koncepti SubDANBoID. Ideja e SubDANBoID është mjaft e thjeshtë, ne shënojmë entitetin kryesor të fushatës në faqe me DANBoID-in e gjeneruar dhe ngarkojmë të gjitha entitetet e mbivendosur me identifikues unik të faqes dhe formojmë SubDANBoID sipas parimit DANBoID + identifikues i nivelit të parë. entitet i ndërlidhur + identifikues i entitetit të ndërlidhur të nivelit të dytë +... Kjo qasje na lejoi të lidhnim fushatat reklamuese në sisteme të ndryshme dhe të shkarkojmë statistika të detajuara mbi to.
Ne gjithashtu duhej të zgjidhnim problemin e aksesit në fushata në platforma të ndryshme. Siç kemi shkruar më lart, mekanizmi i delegimit të aksesit në një fushatë në një llogari të veçantë teknike nuk është gjithmonë i zbatueshëm. Prandaj, na u desh të zhvillonim një infrastrukturë për autorizimin automatik nëpërmjet OAuth duke përdorur shenja dhe mekanizma për përditësimin e këtyre shenjave.
Më vonë në artikull do të përpiqemi të përshkruajmë më në detaje arkitekturën e zgjidhjes dhe detajet teknike të zbatimit.
Arkitektura e zgjidhjeve 1.0
Me fillimin e implementimit të një produkti të ri, kuptuam se duhej të siguronim menjëherë mundësinë e lidhjes së faqeve të reja, ndaj vendosëm të ndiqnim rrugën e arkitekturës së mikroservisit.
Gjatë projektimit të arkitekturës, ne i ndamë lidhësit me të gjitha sistemet e jashtme - 1C, platformat e reklamimit dhe sistemet e reklamimit - në shërbime të veçanta.
Ideja kryesore është që të gjithë lidhësit në faqet kanë të njëjtin API dhe janë përshtatës që e sjellin API-në e faqes në një ndërfaqe të përshtatshme për ne.
Në qendër të produktit tonë është një aplikacion ueb, i cili është një monolit i dizajnuar në mënyrë të tillë që të mund të çmontohet lehtësisht në shërbime. Ky aplikacion është përgjegjës për përpunimin e të dhënave të shkarkuara, mbledhjen e statistikave nga sisteme të ndryshme dhe prezantimin e tyre tek përdoruesit e sistemit.
Për të komunikuar ndërmjet lidhësve dhe aplikacionit në ueb, na u desh të krijonim një shërbim shtesë, të cilin e quajtëm Connector Proxy. Ai kryen funksionet e Zbulimit të Shërbimit dhe Planifikimit të Detyrave. Ky shërbim kryen detyrat e mbledhjes së të dhënave për çdo lidhës çdo natë. Shkrimi i një shtrese shërbimi ishte më i lehtë sesa lidhja e një ndërmjetësi mesazhesh, dhe për ne ishte e rëndësishme të merrnim rezultatin sa më shpejt që të ishte e mundur.
Për thjeshtësi dhe shpejtësi të zhvillimit, ne gjithashtu vendosëm që të gjitha shërbimet të jenë API të uebit. Kjo bëri të mundur që shpejt të mblidhej një provë e konceptit dhe të verifikohej që i gjithë dizajni funksionon.
Një detyrë e veçantë, mjaft komplekse ishte vendosja e aksesit për të mbledhur të dhëna nga llogari të ndryshme, të cilat, siç vendosëm, duhet të kryheshin nga përdoruesit përmes ndërfaqes në internet. Ai përbëhet nga dy hapa të veçantë: së pari, përdoruesi shton një shenjë për të hyrë në llogari nëpërmjet OAuth dhe më pas konfiguron mbledhjen e të dhënave për klientin nga një llogari specifike. Marrja e një token përmes OAuth është e nevojshme sepse, siç kemi shkruar tashmë, nuk është gjithmonë e mundur të delegoni aksesin në llogarinë e dëshiruar në sit.
Për të krijuar një mekanizëm universal për zgjedhjen e një llogarie nga faqet, na u desh të shtonim një metodë në API-në e lidhësve që kthen skemën JSON, e cila jepet në një formë duke përdorur një komponent të modifikuar JSONEditor. Në këtë mënyrë, përdoruesit ishin në gjendje të zgjidhnin llogaritë nga të cilat do të shkarkonin të dhënat.
Për të përmbushur kufijtë e kërkesave që ekzistojnë në sajte, ne kombinojmë kërkesat për cilësime brenda një tokeni, por mund të përpunojmë paralelisht shenja të ndryshme.
Ne zgjodhëm MongoDB si një ruajtje për të dhënat e ngarkuara si për aplikacionin në internet ashtu edhe për lidhësit, gjë që na lejoi të mos shqetësoheshim shumë për strukturën e të dhënave në fazat fillestare të zhvillimit, kur modeli i objektit të aplikacionit ndryshon çdo ditë tjetër.
Së shpejti zbuluam se jo të gjitha të dhënat përshtaten mirë në MongoDB dhe, për shembull, është më i përshtatshëm për të ruajtur statistikat ditore në një bazë të dhënash relacionale. Prandaj, për lidhësit, struktura e të dhënave të të cilëve është më e përshtatshme për një bazë të dhënash relacionale, filluam të përdorim PostgreSQL ose MS SQL Server si ruajtje.
Arkitektura dhe teknologjitë e zgjedhura na lejuan të ndërtonim dhe lëshonim produktin D1.Digital relativisht shpejt. Gjatë dy viteve të zhvillimit të produktit, ne zhvilluam 23 lidhje me faqet, fituam përvojë të paçmuar duke punuar me API-të e palëve të treta, mësuam të shmangim kurthet e faqeve të ndryshme, të cilat secila kishte të vetat, kontribuan në zhvillimin e API-së prej të paktën 3 faqet, të shkarkuara automatikisht informacione për pothuajse 15 fushata dhe për më shumë se 000 vendosje, mblodhën shumë reagime nga përdoruesit për funksionimin e produktit dhe arritën të ndryshojnë disa herë procesin kryesor të produktit, bazuar në këtë reagim.
Arkitektura e zgjidhjeve 2.0
Kanë kaluar dy vjet nga fillimi i zhvillimit D1.Dixhital. Rritja e vazhdueshme e ngarkesës në sistem dhe shfaqja e gjithnjë e më shumë burimeve të reja të të dhënave zbuloi gradualisht probleme në arkitekturën ekzistuese të zgjidhjeve.
Problemi i parë lidhet me sasinë e të dhënave të shkarkuara nga faqet. Ne u përballëm me faktin se mbledhja dhe përditësimi i të gjitha të dhënave të nevojshme nga faqet më të mëdha filloi të merrte shumë kohë. Për shembull, mbledhja e të dhënave nga sistemi i reklamimit AdRiver, me të cilin gjurmojmë statistikat për shumicën e vendosjeve, zgjat rreth 12 orë.
Për të zgjidhur këtë problem, ne filluam të përdorim të gjitha llojet e raporteve për të shkarkuar të dhëna nga faqet, po përpiqemi të zhvillojmë API-në e tyre së bashku me faqet në mënyrë që shpejtësia e funksionimit të tij të plotësojë nevojat tona dhe të paralelizojë sa më shumë shkarkimin e të dhënave.
Një problem tjetër lidhet me përpunimin e të dhënave të shkarkuara. Tani, kur mbërrijnë statistikat e reja të vendosjes, fillon një proces shumëfazor i rillogaritjes së metrikës, i cili përfshin ngarkimin e të dhënave të papërpunuara, llogaritjen e metrikave të grumbulluara për çdo sajt, krahasimin e të dhënave nga burime të ndryshme me njëra-tjetrën dhe llogaritjen e metrikës përmbledhëse për fushatën. Kjo shkakton shumë ngarkesë në aplikacionin në internet që bën të gjitha llogaritjet. Disa herë, gjatë procesit të rillogaritjes, aplikacioni konsumoi të gjithë memorien në server, rreth 10-15 GB, gjë që pati efektin më të dëmshëm në punën e përdoruesve me sistemin.
Problemet e identifikuara dhe planet ambicioze për zhvillimin e mëtejshëm të produktit na çuan në nevojën për të rishqyrtuar arkitekturën e aplikacionit.
Ne filluam me lidhësit.
Ne vumë re se të gjithë lidhësit funksionojnë sipas të njëjtit model, kështu që ndërtuam një kornizë tubacioni në të cilën për të krijuar një lidhës ju duhej vetëm të programoni logjikën e hapave, pjesa tjetër ishte universale. Nëse ndonjë lidhës kërkon përmirësim, atëherë e transferojmë menjëherë në një kornizë të re në të njëjtën kohë kur lidhësi po përmirësohet.
Në të njëjtën kohë, ne filluam vendosjen e lidhësve në Docker dhe Kubernetes.
Ne planifikuam lëvizjen në Kubernetes për një kohë mjaft të gjatë, eksperimentuam me cilësimet CI/CD, por filluam të lëviznim vetëm kur një lidhës, për shkak të një gabimi, filloi të hante më shumë se 20 GB memorie në server, duke vrarë praktikisht procese të tjera . Gjatë hetimit, lidhësi u zhvendos në një grup Kubernetes, ku në fund mbeti, edhe pasi gabimi u rregullua.
Shumë shpejt e kuptuam se Kubernetes ishte i përshtatshëm dhe brenda gjashtë muajve transferuam 7 lidhës dhe Proxy Connectors, të cilat konsumojnë më shumë burime, në grupin e prodhimit.
Duke ndjekur lidhësit, vendosëm të ndryshonim arkitekturën e pjesës tjetër të aplikacionit.
Problemi kryesor ishte se të dhënat vijnë nga lidhësit në proxies në grupe të mëdha, dhe më pas godasin DANBoID dhe dërgohen në aplikacionin qendror të uebit për përpunim. Për shkak të numrit të madh të rillogaritjeve të metrikës, ka një ngarkesë të madhe në aplikacion.
Gjithashtu ishte mjaft e vështirë monitorimi i statusit të punëve individuale të mbledhjes së të dhënave dhe raportimi i gabimeve që ndodhin brenda lidhësve të një aplikacioni qendror në ueb, në mënyrë që përdoruesit të mund të shihnin se çfarë po ndodhte dhe pse të dhënat nuk po mblidheshin.
Për të zgjidhur këto probleme, ne zhvilluam arkitekturën 2.0.
Dallimi kryesor midis versionit të ri të arkitekturës është se në vend të Web API, ne përdorim RabbitMQ dhe bibliotekën MassTransit për të shkëmbyer mesazhe midis shërbimeve. Për ta bërë këtë, na u desh të rishkruajmë pothuajse plotësisht Proxy Connectors, duke e bërë atë Connectors Hub. Emri u ndryshua sepse roli kryesor i shërbimit nuk është më në përcjelljen e kërkesave te lidhësit dhe mbrapa, por në menaxhimin e mbledhjes së metrikës nga lidhësit.
Nga aplikacioni qendror në internet, ne ndamë informacionin rreth vendosjeve dhe statistikave nga faqet në shërbime të veçanta, gjë që bëri të mundur heqjen e rillogaritjeve të panevojshme dhe ruajtjen e vetëm statistikave të llogaritura dhe të grumbulluara tashmë në nivelin e vendosjes. Ne gjithashtu rishkruam dhe optimizuam logjikën për llogaritjen e statistikave bazë bazuar në të dhëna të papërpunuara.
Në të njëjtën kohë, ne po migrojmë të gjitha shërbimet dhe aplikacionet në Docker dhe Kubernetes për ta bërë zgjidhjen më të lehtë në shkallë dhe më të përshtatshme për t'u menaxhuar.
Ku jemi tani
Produkt i arkitekturës 2.0 me prova të konceptit D1.Dixhital gati dhe duke punuar në një mjedis testimi me një grup të kufizuar lidhësish. E tëra çfarë mbetet për të bërë është të rishkruash 20 lidhës të tjerë në një platformë të re, të testosh nëse të dhënat janë ngarkuar saktë dhe të gjitha metrikat janë llogaritur saktë dhe të hedhësh të gjithë dizajnin në prodhim.
Në fakt, ky proces do të ndodhë gradualisht dhe ne do të duhet të lëmë pajtueshmërinë e prapambetur me API-të e vjetra për të mbajtur gjithçka në funksion.
Planet tona të menjëhershme përfshijnë zhvillimin e lidhësve të rinj, integrimin me sisteme të reja dhe shtimin e metrikave shtesë në grupin e të dhënave të shkarkuara nga faqet e lidhura dhe sistemet e reklamimit.
Ne gjithashtu planifikojmë të transferojmë të gjitha aplikacionet, përfshirë aplikacionin qendror të ueb-it, te Docker dhe Kubernetes. E kombinuar me arkitekturën e re, kjo do të thjeshtojë ndjeshëm vendosjen, monitorimin dhe kontrollin e burimeve të konsumuara.
Një ide tjetër është të eksperimentoni me zgjedhjen e bazës së të dhënave për ruajtjen e statistikave, e cila aktualisht ruhet në MongoDB. Tashmë kemi transferuar disa lidhës të rinj në bazat e të dhënave SQL, por atje ndryshimi është pothuajse i pavërejshëm, dhe për statistikat e grumbulluara për ditë, të cilat mund të kërkohen për një periudhë arbitrare, fitimi mund të jetë mjaft serioz.
Në përgjithësi, planet janë madhështore, le të vazhdojmë :)
Autorët e artikullit R&D Dentsu Aegis Network Rusi: Georgy Ostapenko (), Mikhail Kotsik ()
Burimi: www.habr.com