ProHoster > Blogs > Administrācija > Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)

Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)

Å Ä·iet, ka tieÅ”saistes reklāmas jomai jābÅ«t maksimāli tehnoloÄ£iski attÄ«stÄ«tai un automatizētai. Protams, jo tur strādā tādi giganti un savas jomas eksperti kā Yandex, Mail.Ru, Google un Facebook. Bet, kā izrādÄ«jās, pilnÄ«bai nav robežu un vienmēr ir ko automatizēt.

Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)
Avots

Sakaru grupa Dentsu Aegis tÄ«kls Krievija ir lielākais digitālās reklāmas tirgus spēlētājs un aktÄ«vi investē tehnoloÄ£ijās, cenÅ”oties optimizēt un automatizēt savus biznesa procesus. Par vienu no neatrisinātajām tieÅ”saistes reklāmas tirgus problēmām ir kļuvis statistikas apkopoÅ”ana par reklāmas kampaņām no dažādām interneta platformām. Å Ä«s problēmas risinājums galu galā radÄ«ja produktu D1.Digitālais (lasÄ«t kā DiVan), par kura attÄ«stÄ«bu vēlamies runāt.

Kāpēc?

1. Projekta uzsākÅ”anas brÄ«dÄ« tirgÅ« nebija neviena gatava produkta, kas atrisinātu reklāmas kampaņu statistikas vākÅ”anas automatizācijas problēmu. Tas nozÄ«mē, ka neviens, izņemot mÅ«s paÅ”us, neapmierinās mÅ«su vajadzÄ«bas.

Tādi pakalpojumi kā Improvado, Roistat, Supermetrics, SegmentStream piedāvā integrāciju ar platformām, sociālajiem tÄ«kliem un Google Analitycs, kā arÄ« ļauj izveidot analÄ«tiskos informācijas paneļus ērtai reklāmas kampaņu analÄ«zei un kontrolei. Pirms sākām izstrādāt savu produktu, mēs mēģinājām izmantot dažas no Ŕīm sistēmām, lai vāktu datus no vietnēm, taču diemžēl tās nevarēja atrisināt mÅ«su problēmas.

Galvenā problēma bija tā, ka pārbaudītie produkti balstījās uz datu avotiem, attēlojot izvietojumu statistiku pa vietnēm, un nesniedza iespēju apkopot statistiku par reklāmas kampaņām. Šī pieeja neļāva mums vienuviet skatīt dažādu vietņu statistiku un analizēt kampaņas stāvokli kopumā.

Vēl viens faktors bija tas, ka sākotnējie produkti bija vērsti uz Rietumu tirgu un neatbalstÄ«ja integrāciju ar Krievijas vietnēm. Un tām vietnēm, ar kurām tika ieviesta integrācija, ne vienmēr visi nepiecieÅ”amie rādÄ«tāji tika lejupielādēti pietiekami detalizēti, un integrācija ne vienmēr bija ērta un pārskatāma, it Ä«paÅ”i, ja bija nepiecieÅ”ams iegÅ«t kaut ko, kas nav sistēmas saskarnē.
Kopumā nolēmām nepielāgoties treÅ”o puÅ”u produktiem, bet sākām izstrādāt savus...

2. TieÅ”saistes reklāmas tirgus pieaug gadu no gada, un 2018. gadā tas reklāmas budžetu ziņā apsteidza tradicionāli lielāko TV reklāmas tirgu. Tātad ir mērogs.

3. AtŔķirÄ«bā no TV reklāmas tirgus, kur komercreklāmas tirdzniecÄ«ba ir monopolizēta, internetā darbojas ļoti daudz individuālu dažāda lieluma reklāmas inventāra Ä«paÅ”nieku ar saviem reklāmas kontiem. Tā kā reklāmas kampaņa, kā likums, darbojas vairākās vietnēs vienlaikus, lai saprastu reklāmas kampaņas stāvokli, ir jāapkopo visu vietņu atskaites un jāapvieno tie vienā lielā pārskatā, kas parādÄ«s visu attēlu. Tas nozÄ«mē, ka pastāv optimizācijas potenciāls.

4. Mums Ŕķita, ka reklāmas inventāra Ä«paÅ”niekiem internetā jau ir infrastruktÅ«ra statistikas apkopoÅ”anai un attēloÅ”anai reklāmu kontos, un viņi varēs nodroÅ”ināt Å”iem datiem API. Tas nozÄ«mē, ka tehniski ir iespējams to Ä«stenot. Teiksim uzreiz, ka tas izrādÄ«jās nemaz tik vienkārÅ”i.

Kopumā visi priekÅ”noteikumi projekta Ä«stenoÅ”anai mums bija paÅ”saprotami, un skrējām projektu iedzÄ«vināt...

Lielisks plāns

Sākumā mēs izveidojām ideālas sistēmas vīziju:

  • Reklāmas kampaņas no 1C korporatÄ«vās sistēmas tajā ir automātiski jāielādē ar to nosaukumiem, periodiem, budžetiem un izvietojumiem dažādās platformās.
  • Par katru izvietojumu reklāmas kampaņā no vietnēm, kurās notiek izvietojums, automātiski jālejupielādē visa iespējamā statistika, piemēram, seansu, klikŔķu, skatÄ«jumu skaits utt.
  • Dažas reklāmas kampaņas tiek izsekotas, izmantojot treŔās puses uzraudzÄ«bu, izmantojot tā sauktās reklāmas sistēmas, piemēram, Adriver, Weborama, DCM utt. Krievijā ir arÄ« rÅ«pnieciskais interneta skaitÄ«tājs - uzņēmums Mediascope. Saskaņā ar mÅ«su plānu neatkarÄ«gā un rÅ«pnieciskā monitoringa dati bÅ«tu automātiski jāielādē attiecÄ«gajās reklāmas kampaņās.
  • Lielākā daļa reklāmas kampaņu internetā ir vērstas uz noteiktām mērÄ·a darbÄ«bām (pirkums, zvans, pierakstÄ«Å”anās testa braucienam u.c.), kuras tiek izsekotas, izmantojot Google Analytics, un kuru statistika ir svarÄ«ga arÄ« kampaņas statusa izpratnei un jāielādē mÅ«su rÄ«kā .

Pirmais pankūka ir biezs

Ņemot vērā mÅ«su apņemÅ”anos ievērot elastÄ«gus programmatÅ«ras izstrādes principus (agile, viss), mēs nolēmām vispirms izstrādāt MVP un pēc tam iteratÄ«vi virzÄ«ties uz paredzēto mērÄ·i.
Mēs nolēmām izveidot MVP, pamatojoties uz mūsu produktu DANBo (Dentsu Aegis tīkla padome), kas ir tīmekļa lietojumprogramma ar vispārīgu informāciju par mūsu klientu reklāmas kampaņām.

MVP projekts tika pēc iespējas vienkārÅ”ots Ä«stenoÅ”anas ziņā. Mēs esam izvēlējuÅ”ies ierobežotu integrācijas platformu sarakstu. Tās bija galvenās platformas, piemēram, Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB un galvenās reklāmu sistēmas Adriver un Weborama.

Lai piekļūtu vietņu statistikai, izmantojot API, mēs izmantojām vienu kontu. Klientu grupas vadÄ«tājam, kurÅ” vēlējās izmantot automātisku statistikas apkopoÅ”anu par reklāmas kampaņu, vispirms platformas kontam bija jādeleģē piekļuve nepiecieÅ”amajām reklāmas kampaņām vietnēs.

Nākamais ir sistēmas lietotājs DANBo bija jāielādē Excel sistēmā noteikta formāta fails, kurā bija visa informācija par izvietojumu (reklāmas kampaņa, platforma, formāts, izvietoÅ”anas periods, plānotie rādÄ«tāji, budžets utt.) un atbilstoÅ”o reklāmas kampaņu identifikatori uz vietnes un skaitÄ«tāji reklāmas sistēmās.

Atklāti sakot, tas izskatÄ«jās biedējoÅ”i:

Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)

Lejupielādētie dati tika saglabāti datu bāzē, un pēc tam atseviŔķi pakalpojumi savāca kampaņu identifikatorus vietnēs no tiem un lejupielādēja statistiku par tiem.

Katrai vietnei tika uzrakstÄ«ts atseviŔķs Windows serviss, kas reizi dienā nonāca zem viena pakalpojuma konta vietnes API un lejupielādēja statistiku par noteiktiem kampaņu ID. Tas pats notika ar reklāmas sistēmām.

Lejupielādētie dati tika parādīti saskarnē neliela pielāgota informācijas paneļa veidā:

Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)

Mums negaidīti MVP sāka strādāt un sāka lejupielādēt aktuālo statistiku par reklāmas kampaņām internetā. Mēs ieviesām sistēmu vairākiem klientiem, bet, mēģinot mērogot, saskārāmies ar nopietnām problēmām:

  • Galvenā problēma bija datu sagatavoÅ”anas sarežģītÄ«ba ielādei sistēmā. Tāpat izvietojuma dati pirms ielādes bija jāpārvērÅ” stingri fiksētā formātā. Lejupielādes failā bija jāiekļauj entÄ«tijas identifikatori no dažādām vietnēm. Mēs saskaramies ar faktu, ka tehniski neapmācÄ«tiem lietotājiem ir ļoti grÅ«ti izskaidrot, kur vietnē atrast Å”os identifikatorus un kur failā tie jāievada. Ņemot vērā darbinieku skaitu nodaļās, kurās notiek kampaņas objektos, un apgrozÄ«jumu, tas radÄ«ja milzÄ«gu atbalstu no mÅ«su puses, par ko mēs absolÅ«ti nebijām apmierināti.
  • Vēl viena problēma bija tā, ka ne visās reklāmas platformās bija mehānismi piekļuves reklāmas kampaņām deleģēŔanai citiem kontiem. Taču pat tad, ja bija pieejams deleģēŔanas mehānisms, ne visi reklāmdevēji vēlējās pieŔķirt treÅ”o puÅ”u kontiem piekļuvi savām kampaņām.
  • SvarÄ«gs faktors bija saÅ”utums, ko lietotāju vidÅ« izraisÄ«ja fakts, ka visi plānotie rādÄ«tāji un izvietojuma informācija, ko viņi jau ievada mÅ«su 1C grāmatvedÄ«bas sistēmā, viņiem ir jāievada atkārtoti. DANBo.

Tas radÄ«ja domu, ka primārajam informācijas avotam par izvietoÅ”anu ir jābÅ«t mÅ«su 1C sistēmai, kurā visi dati tiek ievadÄ«ti precÄ«zi un laikā (Å”eit runa ir par to, ka rēķini tiek Ä£enerēti, pamatojoties uz 1C datiem, tāpēc pareiza datu ievade 1C ir prioritāte ikvienam KPI). Tā radās jauna sistēmas koncepcija...

Jēdziens

Pirmā lieta, ko mēs nolēmām darÄ«t, bija sadalÄ«t sistēmu statistikas apkopoÅ”anai par reklāmas kampaņām internetā atseviŔķā produktā - D1.Digitālais.

Jaunajā koncepcijā mēs nolēmām ielādēt D1.Digitālais informāciju par reklāmas kampaņām un izvietojumiem tajās no 1C, un pēc tam apkopojiet statistiku no vietnēm un reklāmu apkalpoÅ”anas sistēmām uz Å”iem izvietojumiem. Tam vajadzēja ievērojami vienkārÅ”ot lietotāju dzÄ«vi (un, kā parasti, pievienot vairāk darba izstrādātājiem) un samazināt atbalsta apjomu.

Pirmā problēma, ar kuru mēs saskārāmies, bija organizatoriska rakstura, un tā bija saistÄ«ta ar faktu, ka mēs nevarējām atrast atslēgu vai zÄ«mi, pēc kuras mēs varētu salÄ«dzināt entÄ«tijas no dažādām sistēmām ar kampaņām un izvietojumiem no 1C. Fakts ir tāds, ka process mÅ«su uzņēmumā ir veidots tā, ka reklāmas kampaņas dažādās sistēmās ievada dažādi cilvēki (mediju plānotāji, pirkÅ”ana utt.).

Lai atrisinātu Å”o problēmu, mums bija jāizgudro unikāla jaukta atslēga DANBoID, kas saistÄ«tu entÄ«tijas dažādās sistēmās un ko varētu diezgan viegli un unikāli identificēt lejupielādētajās datu kopās. Å is identifikators tiek Ä£enerēts iekŔējā 1C sistēmā katram atseviŔķam izvietojumam un tiek pārsÅ«tÄ«ts uz kampaņām, izvietojumiem un skaitÄ«tājiem visās vietnēs un visās AdServing sistēmās. DANBoID ievietoÅ”anas prakses ievieÅ”ana visos izvietojumos prasÄ«ja zināmu laiku, bet mums tas izdevās :)

Tad mēs noskaidrojām, ka ne visās vietnēs ir API automātiskai statistikas apkopoÅ”anai, un pat tām, kurām ir API, tā neatgriež visus nepiecieÅ”amos datus.

Šajā posmā mēs nolēmām ievērojami samazināt integrācijas platformu sarakstu un koncentrēties uz galvenajām platformām, kas ir iesaistītas lielākajā daļā reklāmas kampaņu. Šajā sarakstā ir iekļauti visi lielākie spēlētāji reklāmas tirgū (Google, Yandex, Mail.ru), sociālajos tīklos (VK, Facebook, Twitter), lielākajās AdServing un analītikas sistēmās (DCM, Adriver, Weborama, Google Analytics) un citās platformās.

Lielākajai daļai mÅ«su atlasÄ«to vietņu bija API, kas nodroÅ”ināja mums nepiecieÅ”amos rādÄ«tājus. GadÄ«jumos, kad API nebija vai tas nesaturēja nepiecieÅ”amos datus, datu ielādei izmantojām atskaites, kas tika sÅ«tÄ«tas katru dienu uz mÅ«su biroja e-pastu (dažās sistēmās ir iespējams Ŕādus pārskatus konfigurēt, citās mēs vienojāmies par Ŕādu atskaiÅ”u izstrādi priekÅ” mums).

Analizējot datus no dažādām vietnēm, mēs noskaidrojām, ka entītiju hierarhija dažādās sistēmās nav vienāda. Turklāt informācija no dažādām sistēmām ir jālejupielādē dažādi.

Lai atrisinātu Å”o problēmu, tika izstrādāta SubDANBoID koncepcija. SubDANBoID ideja ir diezgan vienkārÅ”a, mēs atzÄ«mējam kampaņas galveno entÄ«tiju vietnē ar Ä£enerēto DANBoID, un mēs augÅ”upielādējam visas ligzdotās entÄ«tijas ar unikāliem vietnes identifikatoriem un veidojam SubDANBoID pēc DANBoID principa + pirmā lÄ«meņa identifikators. ligzdotā entÄ«tija + otrā lÄ«meņa ligzdotās entÄ«tijas identifikators +... Å Ä« pieeja ļāva mums savienot reklāmas kampaņas dažādās sistēmās un lejupielādēt detalizētu statistiku par tām.

Mums bija arÄ« jāatrisina problēma par piekļuvi kampaņām dažādās platformās. Kā jau rakstÄ«jām iepriekÅ”, mehānisms piekļuves kampaņai deleģēŔanai atseviŔķam tehniskajam kontam ne vienmēr ir piemērojams. Tāpēc mums bija jāizstrādā infrastruktÅ«ra automātiskai autorizācijai, izmantojot OAuth, izmantojot marÄ·ierus un mehānismus Å”o marÄ·ieru atjaunināŔanai.

Vēlāk rakstā mēģināsim sÄ«kāk aprakstÄ«t risinājuma arhitektÅ«ru un ievieÅ”anas tehniskās detaļas.

Risinājuma arhitektūra 1.0

Uzsākot jauna produkta ievieÅ”anu, sapratām, ka uzreiz jāparedz iespēja pieslēgt jaunas vietnes, tāpēc nolēmām iet mikropakalpojumu arhitektÅ«ras ceļu.

Izstrādājot arhitektÅ«ru, mēs nodalÄ«jām savienotājus visām ārējām sistēmām - 1C, reklāmas platformām un reklāmas sistēmām - atseviŔķos servisos.
Galvenā ideja ir tāda, ka visiem vietņu savienotājiem ir viena un tā pati API un tie ir adapteri, kas nodroÅ”ina vietnes API mums ērtu saskarni.

MÅ«su produkta centrā ir tÄ«mekļa lietojumprogramma, kas ir monolÄ«ts, kas veidots tā, lai to varētu viegli izjaukt servisos. Å Ä« lietojumprogramma ir atbildÄ«ga par lejupielādēto datu apstrādi, dažādu sistēmu statistikas apkopoÅ”anu un prezentÄ“Å”anu sistēmas lietotājiem.

Lai sazinātos starp savienotājiem un tÄ«mekļa lietojumprogrammu, mums bija jāizveido papildu pakalpojums, ko nosaucām Connector Proxy. Tas veic pakalpojumu noteikÅ”anas un uzdevumu plānotāja funkcijas. Å is pakalpojums katru nakti veic datu vākÅ”anas uzdevumus katram savienotājam. Pakalpojuma slāņa rakstÄ«Å”ana bija vienkārŔāka nekā ziņojumu brokera savienoÅ”ana, un mums bija svarÄ«gi pēc iespējas ātrāk iegÅ«t rezultātu.

VienkārŔības un izstrādes ātruma labad mēs arÄ« nolēmām, ka visi pakalpojumi bÅ«s Web API. Tas ļāva ātri salikt koncepcijas pierādÄ«jumu un pārbaudÄ«t, vai viss dizains darbojas.

Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)

AtseviŔķs, diezgan sarežģīts uzdevums bija piekļuves iestatÄ«Å”ana datu vākÅ”anai no dažādiem kontiem, kas, kā mēs nolēmām, lietotājiem bÅ«tu jāveic, izmantojot tÄ«mekļa saskarni. Tas sastāv no divām atseviŔķām darbÄ«bām: pirmkārt, lietotājs pievieno pilnvaru, lai piekļūtu kontam, izmantojot OAuth, un pēc tam konfigurē datu vākÅ”anu klientam no konkrēta konta. Pilnvaras iegÅ«Å”ana, izmantojot OAuth, ir nepiecieÅ”ama, jo, kā jau rakstÄ«jām, ne vienmēr ir iespējams deleģēt piekļuvi vēlamajam kontam vietnē.

Lai izveidotu universālu mehānismu konta atlasei no vietnēm, savienotāju API bija jāpievieno metode, kas atgriež JSON shēmu, kas tiek atveidota formā, izmantojot modificētu JSONEditor komponentu. Tādā veidā lietotāji varēja izvēlēties kontus, no kuriem lejupielādēt datus.

Lai ievērotu vietnēs pastāvoÅ”os pieprasÄ«jumu ierobežojumus, mēs apvienojam iestatÄ«jumu pieprasÄ«jumus vienā pilnvarā, taču vienlaikus varam apstrādāt dažādas pilnvaras.

Mēs izvēlējāmies MongoDB kā ielādēto datu krātuvi gan tīmekļa lietojumprogrammai, gan savienotājiem, kas ļāva mums pārāk neuztraukties par datu struktūru sākotnējās izstrādes stadijās, kad aplikācijas objekta modelis mainās katru otro dienu.

Drīz vien mēs noskaidrojām, ka ne visi dati labi iederas MongoDB un, piemēram, ikdienas statistiku ir ērtāk glabāt relāciju datu bāzē. Tāpēc savienotājiem, kuru datu struktūra ir piemērotāka relāciju datu bāzei, kā krātuvi sākām izmantot PostgreSQL vai MS SQL Server.

Izvēlētā arhitektÅ«ra un tehnoloÄ£ijas ļāva mums salÄ«dzinoÅ”i ātri izveidot un palaist D1.Digital produktu. Divu gadu produktu izstrādes laikā mēs izstrādājām 23 vietņu savienotājus, guvām nenovērtējamu pieredzi darbā ar treÅ”o puÅ”u API, iemācÄ«jāmies izvairÄ«ties no dažādu vietņu kļūdām, kurām katrai bija savas, veicinājām vismaz 3 API izstrādi. vietnēs, automātiski lejupielādēja informāciju par gandrÄ«z 15 000 kampaņām un vairāk nekā 80 000 izvietojumiem, apkopoja daudz lietotāju atsauksmes par produkta darbÄ«bu un, pamatojoties uz Ŕīm atsauksmēm, vairākas reizes izdevās mainÄ«t produkta galveno procesu.

Risinājuma arhitektūra 2.0

Ir pagājuÅ”i divi gadi kopÅ” izstrādes sākuma D1.Digitālais. PastāvÄ«gā sistēmas slodzes palielināŔanās un arvien jaunu datu avotu parādÄ«Å”anās pakāpeniski atklāja problēmas esoÅ”ajā risinājuma arhitektÅ«rā.

Pirmā problēma ir saistÄ«ta ar no vietnēm lejupielādēto datu apjomu. Mēs saskārāmies ar faktu, ka visu nepiecieÅ”amo datu apkopoÅ”ana un atjaunināŔana no lielākajām vietnēm sāka aizņemt pārāk daudz laika. Piemēram, datu apkopoÅ”ana no AdRiver reklamÄ“Å”anas sistēmas, ar kuru mēs izsekojam statistiku lielākajai daļai izvietojumu, aizņem apmēram 12 stundas.

Lai atrisinātu Å”o problēmu, sākām izmantot visa veida atskaites datu lejupielādei no vietnēm, cenÅ”amies kopā ar vietnēm attÄ«stÄ«t to API, lai tās darbÄ«bas ātrums atbilstu mÅ«su vajadzÄ«bām, un maksimāli paralēli datu lejupielādei.

Vēl viena problēma ir saistÄ«ta ar lejupielādēto datu apstrādi. Tagad, kad tiek saņemta jauna izvietojumu statistika, tiek uzsākts daudzpakāpju metrikas pārrēķināŔanas process, kas ietver neapstrādātu datu ielādi, apkopotās metrikas aprēķināŔanu katrai vietnei, dažādu avotu datu savstarpēju salÄ«dzināŔanu un kampaņas kopsavilkuma metrikas aprēķināŔanu. Tas rada lielu slodzi tÄ«mekļa lietojumprogrammai, kas veic visus aprēķinus. Vairākas reizes pārrēķina procesā lietojumprogramma patērēja visu servera atmiņu, aptuveni 10-15 GB, kas visvairāk ietekmēja lietotāju darbu ar sistēmu.

Konstatētās problēmas un vērienÄ«gie plāni produkta tālākai attÄ«stÄ«bai noveda pie nepiecieÅ”amÄ«bas pārskatÄ«t lietojumprogrammu arhitektÅ«ru.

Mēs sākām ar savienotājiem.
Mēs pamanÄ«jām, ka visi savienotāji darbojas pēc viena modeļa, tāpēc izveidojām konveijeru karkasu, kurā, lai izveidotu savienotāju, bija tikai jāieprogrammē soļu loÄ£ika, pārējais bija universāls. Ja kādam savienotājam ir nepiecieÅ”ami uzlabojumi, mēs to nekavējoties pārnesam uz jaunu ietvaru vienlaikus ar savienotāja uzlaboÅ”anu.

Tajā paŔā laikā mēs sākām izvietot savienotājus Docker un Kubernetes.
Pāreju uz Kubernetes plānojām diezgan ilgi, eksperimentējām ar CI/CD iestatÄ«jumiem, bet sākām kustēties tikai tad, kad viens savienotājs kļūdas dēļ sāka apēst vairāk nekā 20 GB atmiņu serverÄ«, praktiski nogalinot citus procesus. . IzmeklÄ“Å”anas laikā savienotājs tika pārvietots uz Kubernetes kopu, kur tas galu galā palika pat pēc kļūdas novērÅ”anas.

Diezgan ātri sapratām, ka Kubernetes ir ērts, un seÅ”u mēneÅ”u laikā pārnesām uz ražoÅ”anas klasteri 7 savienotājus un Connectors Proxy, kas patērē visvairāk resursu.

Pēc savienotājiem mēs nolēmām mainīt pārējās lietojumprogrammas arhitektūru.
Galvenā problēma bija tā, ka dati tiek piegādāti no savienotājiem uz starpniekserveriem lielās partijās, pēc tam nonāk DANBoID un tiek nosūtīti uz centrālo tīmekļa lietojumprogrammu apstrādei. Sakarā ar lielo metrikas pārrēķinu skaitu, lietojumprogrammai ir liela slodze.

IzrādÄ«jās arÄ« diezgan grÅ«ti pārraudzÄ«t atseviŔķu datu vākÅ”anas darbu statusu un ziņot par kļūdām, kas raduŔās savienotājos uz centrālo tÄ«mekļa lietojumprogrammu, lai lietotāji varētu redzēt, kas notiek un kāpēc dati netiek vākti.

Lai atrisinātu Ŕīs problēmas, mēs izstrādājām arhitektÅ«ru 2.0.

Galvenā atŔķirÄ«ba starp jauno arhitektÅ«ras versiju ir tā, ka Web API vietā mēs izmantojam RabbitMQ un MassTransit bibliotēku, lai apmainÄ«tos ar ziņojumiem starp pakalpojumiem. Lai to izdarÄ«tu, mums bija gandrÄ«z pilnÄ«bā jāpārraksta Connectors Proxy, padarot to Connectors Hub. Nosaukums tika mainÄ«ts, jo pakalpojuma galvenā loma vairs nav pieprasÄ«jumu pārsÅ«tÄ«Å”ana uz savienotājiem un atpakaļ, bet gan savienotāju metrikas vākÅ”anas pārvaldÄ«ba.

No centrālās tÄ«mekļa lietojumprogrammas informāciju par izvietojumiem un statistiku no vietnēm nodalÄ«jām atseviŔķos pakalpojumos, kas ļāva atbrÄ«voties no nevajadzÄ«giem pārrēķiniem un izvietojuma lÄ«menÄ« saglabāt tikai jau aprēķināto un apkopoto statistiku. Mēs arÄ« pārrakstÄ«jām un optimizējām pamata statistikas aprēķināŔanas loÄ£iku, pamatojoties uz neapstrādātiem datiem.

Vienlaikus mēs migrējam visus pakalpojumus un lietojumprogrammas uz Docker un Kubernetes, lai padarītu risinājumu vieglāk mērogojamu un ērtāk pārvaldāmu.

Kā mēs apkopojām datus par reklāmas kampaņām no tieÅ”saistes vietnēm (ērkŔķains ceļŔ uz produktu)

Kur mēs tagad esam

Koncepcijas arhitektÅ«ras 2.0 produkts D1.Digitālais gatavs un darbojas testa vidē ar ierobežotu savienotāju komplektu. Atliek tikai pārrakstÄ«t vēl 20 savienotājus uz jaunu platformu, pārbaudÄ«t, vai dati ir pareizi ielādēti un visi rādÄ«tāji ir pareizi aprēķināti, un ieviest visu dizainu ražoÅ”anā.

Faktiski Ŕis process notiks pakāpeniski, un mums būs jāatstāj atgriezeniskā savietojamība ar vecajām API, lai viss darbotos.

MÅ«su tuvākajos plānos ietilpst jaunu savienotāju izstrāde, integrācija ar jaunām sistēmām un papildu metrikas pievienoÅ”ana datu kopai, kas lejupielādēta no saistÄ«tajām vietnēm un reklāmu sistēmām.

Mēs arÄ« plānojam pārsÅ«tÄ«t visas lietojumprogrammas, tostarp centrālo tÄ«mekļa lietojumprogrammu, uz Docker un Kubernetes. Apvienojumā ar jauno arhitektÅ«ru tas ievērojami vienkārÅ”os patērēto resursu izvietoÅ”anu, uzraudzÄ«bu un kontroli.

Vēl viena ideja ir eksperimentēt ar datu bāzes izvēli statistikas glabāŔanai, kas Å”obrÄ«d tiek glabāta MongoDB. Uz SQL datu bāzēm jau esam pārcēluÅ”i vairākus jaunus savienotājus, taču tur atŔķirÄ«ba ir gandrÄ«z nemanāma, un apkopotai statistikai pa dienām, ko var pieprasÄ«t patvaļīgi, ieguvums var bÅ«t diezgan nopietns.

Vispār plāni grandiozi, ejam tālāk :)

Raksta R&D Dentsu Aegis Network Russia autori: Georgijs Ostapenko (shmiigaa), Mihails Kotsiks (hitexx)

Avots: www.habr.com

Pievieno komentāru