Tundub, et veebireklaami valdkond peaks olema võimalikult tehnoloogiliselt arenenud ja automatiseeritud. Muidugi, sest seal töötavad sellised hiiglased ja oma ala asjatundjad nagu Yandex, Mail.Ru, Google ja Facebook. Kuid nagu selgus, pole täiuslikkusele piire ja alati on midagi automatiseerida.
Sidegrupp Dentsu Aegis Network Venemaa on digitaalse reklaamituru suurim tegija ning investeerib aktiivselt tehnoloogiasse, püüdes optimeerida ja automatiseerida oma äriprotsesse. Interneti-reklaamituru üks lahendamata probleeme on ülesanne koguda erinevatelt Interneti-platvormidelt reklaamikampaaniate kohta statistikat. Selle probleemi lahenduse tulemuseks oli lõpuks toote loomine D1.Digitaalne (loe DiVan), mille arendamisest tahame rääkida.
Miks?
1. Projekti käivitamise ajal ei olnud turul ühtegi valmistoodet, mis oleks lahendanud reklaamikampaaniate statistika kogumise automatiseerimise. See tähendab, et keegi peale meie enda ei rahulda meie vajadusi.
Sellised teenused nagu Improvado, Roistat, Supermetrics, SegmentStream pakuvad integratsiooni platvormide, sotsiaalvõrgustike ja Google Analitycsiga ning võimaldavad luua analüütilisi armatuurlaudu reklaamikampaaniate mugavaks analüüsiks ja juhtimiseks. Enne oma toote arendamise alustamist proovisime mõnda neist süsteemidest kasutada saitidelt andmete kogumiseks, kuid kahjuks ei suutnud need meie probleeme lahendada.
Peamine probleem seisnes selles, et testitud tooted põhinesid andmeallikatel, kuvasid paigutuste statistikat saitide kaupa ning ei võimaldanud koondada reklaamikampaaniate statistikat. Selline lähenemine ei võimaldanud meil ühes kohas näha erinevate saitide statistikat ja analüüsida kampaania olekut tervikuna.
Teiseks teguriks oli see, et algstaadiumis olid tooted suunatud lääne turule ega toetanud integreerumist Venemaa saitidega. Ja nende saitide puhul, millega integreerimist rakendati, ei laaditud kõiki vajalikke mõõdikuid alati piisavalt üksikasjalikult alla ning integreerimine ei olnud alati mugav ja läbipaistev, eriti kui oli vaja hankida midagi, mida süsteemiliideses pole.
Üldiselt otsustasime mitte kohaneda kolmandate osapoolte toodetega, vaid hakkasime välja töötama oma...
2. Interneti-reklaamiturg kasvab aasta-aastalt ning 2018. aastal möödus see reklaamieelarvete poolest traditsiooniliselt suurimast telereklaamiturust. Nii et skaala on olemas.
3. Erinevalt telereklaami turust, kus kommertsreklaami müük on monopoliseeritud, tegutseb Internetis palju erineva suurusega reklaamivarude üksikomanikke oma reklaamikontodega. Kuna reklaamikampaania töötab reeglina mitmel saidil korraga, on reklaamikampaania olukorra mõistmiseks vaja koguda aruanded kõigilt saitidelt ja ühendada need üheks suureks aruandeks, mis näitab tervikpilti. See tähendab, et optimeerimise potentsiaal on olemas.
4. Meile tundus, et internetis oleva reklaamiinventari omanikel on statistika kogumise ja reklaamikontodel kuvamise infrastruktuur juba olemas ning nad saavad nende andmete jaoks API pakkuda. See tähendab, et seda on tehniliselt võimalik rakendada. Ütleme kohe, et selgus, et see polegi nii lihtne.
Üldiselt olid kõik eeldused projekti elluviimiseks meile ilmselged ning jooksime projekti ellu äratama...
Suur plaan
Alustuseks kujundasime ideaalse süsteemi visiooni:
- 1C ettevõttesüsteemi reklaamikampaaniad tuleks sellesse automaatselt laadida koos nende nimede, perioodide, eelarvete ja paigutustega erinevatel platvormidel.
- Reklaamikampaania iga paigutuse kohta tuleks saidilt, kus paigutus toimub, automaatselt alla laadida kogu võimalik statistika, näiteks näitamiste, klikkide, vaatamiste arv jne.
- Mõnda reklaamikampaaniat jälgitakse kolmanda osapoole jälgimise abil nn reklaamisüsteemidega nagu Adriver, Weborama, DCM jne. Venemaal on ka tööstuslik Interneti-arvesti - ettevõte Mediascope. Meie plaani kohaselt tuleks vastavatesse reklaamikampaaniatesse automaatselt laadida ka sõltumatu ja tööstusliku seire andmed.
- Enamik Internetis olevaid reklaamikampaaniaid on suunatud teatud sihttoimingutele (ost, helistamine, proovisõidule registreerumine jne), mida jälgitakse Google Analyticsi abil ning mille statistika on samuti oluline kampaania oleku mõistmiseks ja tuleks laadida meie tööriista.
Esimene pannkook on kallis
Arvestades meie pühendumust tarkvaraarenduse paindlikele põhimõtetele (agiilne, kõik asjad), otsustasime esmalt välja töötada MVP ja seejärel liikuda iteratiivselt kavandatud eesmärgi poole.
Otsustasime ehitada MVP oma toote põhjal DANBo (Dentsu Aegise võrguamet), mis on veebirakendus, mis sisaldab üldist teavet meie klientide reklaamikampaaniate kohta.
MVP jaoks lihtsustati projekti elluviimise osas nii palju kui võimalik. Oleme integreerimiseks valinud piiratud loendi platvormidest. Need olid peamised platvormid, nagu Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB ning peamised reklaamisüsteemid Adriver ja Weborama.
API kaudu saitide statistikale juurdepääsuks kasutasime ühte kontot. Kliendigrupi haldur, kes soovis kasutada reklaamikampaania statistika automaatset kogumist, pidi esmalt delegeerima juurdepääsu vajalikele saitide reklaamikampaaniatele platvormi kontole.
Järgmine on süsteemi kasutaja DANBo pidi Exceli süsteemi üles laadima teatud formaadis faili, mis sisaldas kogu infot paigutuse kohta (reklaamikampaania, platvorm, formaat, paigutusperiood, planeeritud näitajad, eelarve jne) ja vastavate reklaamikampaaniate identifikaatoreid. saidid ja loendurid reklaamisüsteemides.
See nägi ausalt öeldes välja hirmutav:
Allalaaditud andmed salvestati andmebaasi ning seejärel kogusid eraldi teenused nendelt saitidelt kampaaniatunnuseid ja laadisid nende kohta alla statistika.
Iga saidi jaoks kirjutati eraldi Windowsi teenus, mis kord päevas läks saidi API-s ühe teenusekonto alla ja laadis alla statistika määratud kampaania ID-de kohta. Sama juhtus ka reklaamisüsteemidega.
Allalaaditud andmed kuvati liidesel väikese kohandatud armatuurlaua kujul:
Meie jaoks ootamatult alustas MVP tööd ja hakkas Internetist alla laadima jooksvat statistikat reklaamikampaaniate kohta. Rakendasime süsteemi mitmel kliendil, kuid skaleerimisel tekkisid tõsised probleemid:
- Peamine probleem oli andmete süsteemi laadimiseks ettevalmistamise keerukus. Samuti tuli paigutuse andmed enne laadimist teisendada rangelt fikseeritud vormingusse. Allalaaditavasse faili oli vaja lisada erinevatelt saitidelt pärit olemi identifikaatorid. Oleme silmitsi tõsiasjaga, et tehniliselt väljaõppimata kasutajatel on väga raske selgitada, kust saidilt need identifikaatorid leida ja kuhu faili need sisestada tuleb. Arvestades objektidel kampaaniaid korraldavate osakondade töötajate arvu ja käivet, tõi see meie poolel kaasa tohutu toetuse, millega me absoluutselt rahul ei olnud.
- Probleemiks oli ka see, et kõigil reklaamiplatvormidel ei olnud mehhanisme reklaamikampaaniatele juurdepääsu delegeerimiseks teistele kontodele. Kuid isegi kui delegeerimismehhanism oli saadaval, ei olnud kõik reklaamijad valmis andma juurdepääsu oma kampaaniatele kolmandate osapoolte kontodele.
- Oluliseks teguriks oli kasutajate seas nördimus, et kõik kavandatud näitajad ja paigutuse üksikasjad, mille nad juba meie 1C raamatupidamissüsteemi sisestavad, peavad uuesti sisestama. DANBo.
See andis meile idee, et esmaseks teabeallikaks paigutuse kohta peaks olema meie süsteem 1C, kuhu kõik andmed sisestatakse täpselt ja õigel ajal (asi on siin selles, et arved genereeritakse 1C andmete põhjal, seega korrektne andmete sisestamine 1C-sse on kõigi KPI jaoks prioriteet). Nii tekkis süsteemi uus kontseptsioon...
Mõiste
Esimese asjana otsustasime eraldada Internetis reklaamikampaaniate statistika kogumise süsteemi eraldi tooteks - D1.Digitaalne.
Uues kontseptsioonis otsustasime sisse laadida D1.Digitaalne teavet reklaamikampaaniate ja paigutuste kohta 1C-st ning seejärel hankige nendele paigutustele saitide ja reklaamide esitamise süsteemide statistika. See pidi oluliselt lihtsustama kasutajate elu (ja nagu tavaliselt, lisama arendajatele rohkem tööd) ja vähendama toe mahtu.
Esimene probleem, millega me kokku puutusime, oli korralduslikku laadi ja seotud sellega, et me ei leidnud võtit ega märki, mille abil saaksime võrrelda eri süsteemide üksusi 1C kampaaniate ja paigutustega. Fakt on see, et meie ettevõttes on protsess kujundatud nii, et reklaamikampaaniaid sisestavad erinevatesse süsteemidesse erinevad inimesed (meediaplaneerijad, ostmine jne).
Selle probleemi lahendamiseks pidime leiutama ainulaadse räsivõtme DANBoID, mis seoks eri süsteemide üksused omavahel ning mida saaks allalaaditud andmekogumites üsna lihtsalt ja unikaalselt tuvastada. See identifikaator luuakse sisemises 1C-süsteemis iga üksiku paigutuse jaoks ja edastatakse kampaaniatele, paigutustele ja loenduritele kõigil saitidel ja kõigis AdServingi süsteemides. DANBoID kõikidesse paigutustesse panemise praktika juurutamine võttis aega, kuid saime sellega hakkama :)
Siis avastasime, et kõigil saitidel pole automaatse statistika kogumise API-d ja isegi neil, millel on API, ei tagasta see kõiki vajalikke andmeid.
Selles etapis otsustasime oluliselt vähendada integratsiooniplatvormide loendit ja keskenduda peamistele platvormidele, mis on seotud enamiku reklaamikampaaniatega. See nimekiri sisaldab kõiki reklaamituru suurimaid tegijaid (Google, Yandex, Mail.ru), sotsiaalvõrgustikke (VK, Facebook, Twitter), suuremaid AdServing ja analüüsisüsteeme (DCM, Adriver, Weborama, Google Analytics) ja muid platvorme.
Enamikul meie valitud saitidel oli API, mis pakkus meile vajalikke mõõdikuid. Juhtudel, kui API puudus või see ei sisaldanud vajalikke andmeid, kasutasime andmete laadimiseks igapäevaselt meie kontori meilile saadetavaid aruandeid (mõnes süsteemis on selliseid aruandeid võimalik seadistada, teistes leppisime kokku selliste aruannete väljatöötamises meile).
Erinevate saitide andmeid analüüsides saime teada, et olemite hierarhia ei ole erinevates süsteemides ühesugune. Lisaks tuleb erinevatest süsteemidest teavet erineva detailsusega alla laadida.
Selle probleemi lahendamiseks töötati välja SubDANBoID kontseptsioon. SubDANBoID idee on üsna lihtne, märgime saidil kampaania põhiolemi genereeritud DANBoID-ga ja laadime kõik pesastatud olemid üles unikaalsete saidiidentifikaatoritega ja moodustame SubDANBoID vastavalt DANBoID põhimõttele + esimese taseme identifikaator pesastatud olem + teise taseme pesastatud olemi identifikaator +... See lähenemine võimaldas meil ühendada reklaamikampaaniad erinevates süsteemides ja laadida nende kohta üksikasjalikku statistikat.
Samuti tuli lahendada erinevatel platvormidel kampaaniatele juurdepääsu probleem. Nagu eespool kirjutasime, ei ole kampaaniale juurdepääsu delegeerimise mehhanism eraldi tehnilisele kontole alati rakendatav. Seetõttu pidime välja töötama infrastruktuuri OAuthi kaudu automaatseks autoriseerimiseks, kasutades žetoone ja nende žetoonide värskendamise mehhanisme.
Püüame edaspidi artiklis täpsemalt kirjeldada lahenduse arhitektuuri ja teostuse tehnilisi üksikasju.
Lahenduse arhitektuur 1.0
Uue toote juurutamist alustades mõistsime, et peame kohe pakkuma uute saitide ühendamise võimalust, mistõttu otsustasime minna mikroteenuste arhitektuuri teed.
Arhitektuuri kujundamisel eraldasime kõigi välissüsteemide - 1C, reklaamiplatvormide ja reklaamisüsteemide - pistikud eraldi teenusteks.
Põhiidee on see, et kõigil saitide konnektoritel on sama API ja need on adapterid, mis viivad saidi API meile mugavasse liidesesse.
Meie toote keskmes on veebirakendus, mis on monoliit, mis on disainitud nii, et seda saab hõlpsasti teenusteks lahti võtta. See rakendus vastutab allalaaditud andmete töötlemise, erinevate süsteemide statistika võrdlemise ja süsteemi kasutajatele esitamise eest.
Konnektorite ja veebirakenduse vaheliseks suhtlemiseks tuli luua lisateenus, mille nimetasime Connector Proxyks. See täidab teenuse tuvastamise ja ülesannete plaanija funktsioone. See teenus käitab igal õhtul iga konnektori andmete kogumise ülesandeid. Teeninduskihi kirjutamine oli lihtsam kui sõnumimaakleri ühendamine ja meie jaoks oli oluline saada tulemus võimalikult kiiresti.
Arengu lihtsuse ja kiiruse huvides otsustasime ka, et kõik teenused on veebi API-d. See võimaldas kiiresti kokku panna kontseptsiooni tõendi ja veenduda, et kogu projekt töötab.
Eraldi, üsna keeruline ülesanne oli juurdepääsu seadistamine erinevatelt kontodelt andmete kogumiseks, mida, nagu otsustasime, peaksid kasutajad läbi viima veebiliidese kaudu. See koosneb kahest eraldi etapist: esiteks lisab kasutaja OAuthi kaudu kontole juurdepääsuks loa ja seejärel konfigureerib kliendi jaoks andmete kogumise konkreetselt kontolt. Tokeni hankimine OAuthi kaudu on vajalik, sest nagu oleme juba kirjutanud, ei ole alati võimalik saidil soovitud kontole juurdepääsu delegeerida.
Universaalse mehhanismi loomiseks saitidelt konto valimiseks pidime konnektori API-le lisama meetodi, mis tagastab JSON-skeemi, mis renderdatakse vormiks, kasutades muudetud JSONEditori komponenti. Nii said kasutajad valida kontod, kust andmeid alla laadida.
Saitidel kehtivate päringupiirangute järgimiseks kombineerime seadete päringud ühes loas, kuid saame paralleelselt töödelda erinevaid lubasid.
Valisime nii veebirakenduse kui ka konnektorite jaoks laaditud andmete salvestusruumiks MongoDB, mis võimaldas meil arenduse algstaadiumis, kui rakenduse objektmudel muutub ülepäeviti, mitte liiga palju muretseda andmestruktuuri pärast.
Peagi saime teada, et MongoDB-sse kõik andmed hästi ei mahu ja näiteks igapäevast statistikat on mugavam salvestada relatsiooniandmebaasi. Seetõttu hakkasime nende konnektorite puhul, mille andmestruktuur sobib paremini relatsiooniandmebaasi jaoks, salvestusruumina kasutama PostgreSQL-i või MS SQL Serverit.
Valitud arhitektuur ja tehnoloogiad võimaldasid meil D1.Digital toote suhteliselt kiiresti üles ehitada ja turule tuua. Kaheaastase tootearenduse jooksul töötasime välja 23 saitide konnektorit, omandasime hindamatu kogemuse kolmandate osapoolte API-dega töötades, õppisime vältima erinevate saitide lõkse, millel kõigil olid omad, aitasime kaasa vähemalt 3 API arendamisele. saite, laadis automaatselt alla teavet peaaegu 15 000 kampaania ja enam kui 80 000 paigutuse kohta, kogus kasutajatelt toote toimimise kohta palju tagasisidet ja õnnestus selle tagasiside põhjal toote põhiprotsessi mitu korda muuta.
Lahenduse arhitektuur 2.0
Arendustegevuse algusest on möödunud kaks aastat D1.Digitaalne. Süsteemi koormuse pidev suurenemine ja üha uute andmeallikate ilmumine tõi järk-järgult esile probleemid olemasoleva lahenduse arhitektuuris.
Esimene probleem on seotud saitidelt alla laaditud andmete hulgaga. Olime silmitsi tõsiasjaga, et kõigi vajalike andmete kogumine ja värskendamine suurimatelt saitidelt hakkas liiga palju aega võtma. Näiteks andmete kogumine AdRiveri reklaamisüsteemist, millega jälgime enamiku paigutuste statistikat, võtab aega umbes 12 tundi.
Selle probleemi lahendamiseks hakkasime saitidelt andmete allalaadimiseks kasutama kõikvõimalikke aruandeid, proovime arendada nende API-d koos saitidega nii, et selle töökiirus vastaks meie vajadustele, ning paralleelselt andmete allalaadimist nii palju kui võimalik.
Teine probleem on seotud allalaaditud andmete töötlemisega. Nüüd, kui saabub uus paigutuste statistika, käivitatakse mitmeetapiline mõõdikute ümberarvutamise protsess, mis hõlmab algandmete laadimist, iga saidi koondmõõdikute arvutamist, eri allikate andmete omavahelist võrdlemist ja kampaania kokkuvõtlike mõõdikute arvutamist. See põhjustab kõiki arvutusi tegevat veebirakendust suure koormuse. Mitu korda kulutas rakendus ümberarvutusprotsessi käigus kogu serveri mälu, umbes 10-15 GB, mis avaldas kõige kahjulikumat mõju kasutajate tööle süsteemiga.
Tuvastatud probleemid ja ambitsioonikad plaanid toote edasiseks arendamiseks viisid meid vajaduseni rakenduse arhitektuur uuesti läbi vaadata.
Alustasime pistikutega.
Märkasime, et kõik pistikud töötavad sama mudeli järgi, mistõttu ehitasime torustiku raamistiku, milles pistiku loomiseks tuli programmeerida vaid sammude loogika, ülejäänu oli universaalne. Kui mõni pistik vajab täiustamist, siis kanname selle kohe üle uude raamistikku, samal ajal kui pistikut täiustatakse.
Samal ajal alustasime konnektorite juurutamist Dockeri ja Kubernetese jaoks.
Kubernetesesse kolimist planeerisime päris pikalt, katsetasime CI/CD seadistustega, kuid hakkasime liikuma alles siis, kui üks pistik hakkas tõrke tõttu serveris üle 20 GB mälu sööma, tappes praktiliselt teised protsessid. . Uurimise ajal viidi pistik Kubernetese klastris, kuhu see lõpuks jäi ka pärast vea parandamist.
Üsna kiiresti saime aru, et Kubernetes on mugav ning kuue kuu jooksul viisime tootmisklastrisse üle 7 pistikut ja enim ressursse tarbivat Connectors Proxy.
Pärast pistikuid otsustasime muuta ülejäänud rakenduse arhitektuuri.
Peamine probleem seisnes selles, et andmed tulevad konnektoritest puhverserveritesse suurte partiidena, tabavad seejärel DANBoID-d ja saadetakse töötlemiseks kesksesse veebirakendusse. Mõõdikute ümberarvutuste suure arvu tõttu on rakendusel suur koormus.
Üsna keeruliseks osutus ka üksikute andmekogumistööde oleku jälgimine ja konnektorites ilmnenud vigadest teavitamine kesksesse veebirakendusse, et kasutajad näeksid, mis toimub ja miks andmeid ei koguta.
Nende probleemide lahendamiseks töötasime välja arhitektuuri 2.0.
Peamine erinevus arhitektuuri uue versiooni vahel on see, et veebi API asemel kasutame teenuste vahel sõnumite vahetamiseks RabbitMQ-d ja MassTransiti teeki. Selleks pidime Connectors Proxy peaaegu täielikult ümber kirjutama, muutes selle Connectors Hubiks. Nime muudeti, kuna teenuse peamine roll ei ole enam päringute edastamine konnektoritesse ja tagasi, vaid konnektoritest mõõdikute kogumise haldamine.
Kesksest veebirakendusest eraldasime saitide paigutuste ja statistika eraldi teenusteks, mis võimaldas vabaneda tarbetutest ümberarvestustest ning salvestada paigutuse tasemel ainult juba arvutatud ja koondatud statistikat. Samuti kirjutasime ümber ja optimeerisime algandmete põhjal põhistatistika arvutamise loogikat.
Samal ajal viime kõik teenused ja rakendused üle Dockeri ja Kubernetesi, et muuta lahendus hõlpsamini skaleeritavaks ja mugavamaks hallatavaks.
Kus me nüüd oleme
Kontseptsiooni tõestusega arhitektuur 2.0 toode D1.Digitaalne valmis ja töötab piiratud hulga pistikutega testkeskkonnas. Jääb üle kirjutada veel 20 konnektorit uuele platvormile, testida, kas andmed on õigesti laaditud ja kõik mõõdikud õigesti arvutatud, ning viia kogu kujundus tootmisse.
Tegelikult toimub see protsess järk-järgult ja me peame jätma tagasiühilduvuse vanade API-dega, et kõik toimiks.
Meie lähiplaanid hõlmavad uute konnektorite väljatöötamist, integreerimist uute süsteemidega ja täiendavate mõõdikute lisamist ühendatud saitidelt ja reklaamisüsteemidelt alla laaditud andmete komplekti.
Samuti plaanime kõik rakendused, sealhulgas keskse veebirakenduse, üle viia Dockerisse ja Kubernetesesse. Koos uue arhitektuuriga lihtsustab see oluliselt tarbitud ressursside juurutamist, jälgimist ja kontrolli.
Teine idee on katsetada statistika salvestamise andmebaasi valimist, mida praegu salvestatakse MongoDB-s. Oleme SQL-i andmebaasidesse viinud juba mitu uut konnektorit, kuid seal on erinevus peaaegu märkamatu ning päevade kaupa koondatud statistika puhul, mida saab küsida suvalise perioodi jooksul, võib võit olla üsna tõsine.
Üldiselt on plaanid suurejoonelised, lähme edasi :)
Artikli R&D Dentsu Aegis Network Russia autorid: Georgi Ostapenko (), Mihhail Kotsik ()
Allikas: www.habr.com