Vaikuttaa siltä, että verkkomainonnan alan tulisi olla teknisesti mahdollisimman kehittynyttä ja automatisoitua. Tietenkin, koska siellä työskentelevät sellaiset jättiläiset ja alansa asiantuntijat kuin Yandex, Mail.Ru, Google ja Facebook. Mutta kuten kävi ilmi, täydellisyydellä ei ole rajaa ja aina on jotain automatisoitavaa.
Viestintäryhmä Dentsu Aegis Network Venäjä on digitaalisen mainonnan markkinoiden suurin toimija ja investoi aktiivisesti teknologiaan yrittäen optimoida ja automatisoida liiketoimintaprosessejaan. Yksi verkkomainontamarkkinoiden ratkaisemattomista ongelmista on mainoskampanjoiden tilastojen kerääminen eri Internet-alustoista. Tämän ongelman ratkaisu johti lopulta tuotteen luomiseen D1.Digitaalinen (luettu nimellä DiVan), jonka kehityksestä haluamme puhua.
Miksi?
1. Hankkeen alkaessa markkinoilla ei ollut yhtään valmista tuotetta, joka olisi ratkaissut mainoskampanjoiden tilastojen keräämisen automatisoinnin. Tämä tarkoittaa, että kukaan muu kuin me itse ei täytä tarpeitamme.
Palvelut, kuten Improvado, Roistat, Supermetrics, SegmentStream, tarjoavat integroinnin alustojen, sosiaalisten verkostojen ja Google Analitycsin kanssa ja mahdollistavat myös analyyttisten kojetaulujen rakentamisen mainoskampanjoiden kätevää analysointia ja hallintaa varten. Ennen kuin aloitimme kehittää tuotettamme, yritimme käyttää joitakin näistä järjestelmistä kerätäksemme tietoja sivustoilta, mutta valitettavasti ne eivät pystyneet ratkaisemaan ongelmiamme.
Suurin ongelma oli se, että testatut tuotteet perustuivat tietolähteisiin, näyttävät sijoittelutilastoja sivustoittain, eivätkä ne tarjonneet mahdollisuutta koota tilastoja mainoskampanjoista. Tämä lähestymistapa ei antanut meille mahdollisuutta nähdä tilastoja eri sivustoilta yhdessä paikassa ja analysoida kampanjan tilaa kokonaisuutena.
Toinen tekijä oli se, että tuotteet oli alkuvaiheessa suunnattu länsimaisille markkinoille eivätkä ne tukeneet integraatiota Venäjän toimipisteisiin. Ja niille sivustoille, joiden kanssa integraatio toteutettiin, kaikkia tarvittavia mittareita ei aina ladattu riittävän yksityiskohtaisesti, ja integrointi ei aina ollut kätevää ja läpinäkyvää, varsinkin kun oli tarpeen saada jotain, joka ei ole järjestelmän käyttöliittymässä.
Yleensä päätimme olla sopeutumatta kolmansien osapuolien tuotteisiin, vaan aloimme kehittää omia...
2. Verkkomainontamarkkinat kasvavat vuosi vuodelta, ja vuonna 2018 se ohitti mainosbudjeteilla perinteisesti suurimmat tv-mainosmarkkinat. Vaaka on siis olemassa.
3. Toisin kuin TV-mainosmarkkinoilla, joilla kaupallisen mainonnan myynti on monopolisoitu, Internetissä toimii paljon erikokoisten mainosvarastojen yksittäisiä omistajia omilla mainostileillään. Koska mainoskampanja toimii pääsääntöisesti useilla sivustoilla kerralla, mainoskampanjan tilan ymmärtämiseksi on tarpeen kerätä raportteja kaikilta sivustoilta ja yhdistää ne yhdeksi suureksi raportiksi, joka näyttää kokonaiskuvan. Tämä tarkoittaa, että optimointiin on potentiaalia.
4. Meistä näytti, että Internetin mainosjakauman omistajilla on jo infrastruktuuri tilastojen keräämiseen ja niiden näyttämiseen mainostileissä, ja he voivat tarjota näille tiedoille APIn. Tämä tarkoittaa, että se on teknisesti mahdollista toteuttaa. Sanotaan heti, että se ei osoittautunut niin yksinkertaiseksi.
Yleisesti ottaen kaikki hankkeen toteuttamisen edellytykset olivat meille selvät ja juoksimme saamaan projektia eloon...
Suuri suunnitelma
Aluksi loimme näkemyksen ihanteellisesta järjestelmästä:
- Mainoskampanjat 1C-yritysjärjestelmästä tulisi ladata siihen automaattisesti nimineen, ajanjaksoineen, budjetteineen ja sijoitteluineen eri alustoille.
- Jokaisen mainoskampanjan sijoittelun osalta kaikki mahdolliset tilastot, kuten näyttökertojen, napsautusten, näyttökertojen jne. määrä, tulee ladata automaattisesti sivustoista, joissa sijoittelu tapahtuu.
- Joitakin mainoskampanjoita seurataan kolmannen osapuolen valvonnalla niin sanotuilla mainosjärjestelmillä, kuten Adriver, Weborama, DCM jne. Venäjällä on myös teollinen Internet-mittari – Mediascope-yhtiö. Suunnitelmamme mukaan myös riippumattoman ja teollisuuden seurannan tiedot tulisi ladata automaattisesti vastaaviin mainoskampanjoihin.
- Suurin osa Internetin mainoskampanjoista on suunnattu tiettyihin kohdetoimintoihin (osto, soitto, koeajolle ilmoittautuminen jne.), joita seurataan Google Analyticsin avulla ja joiden tilastot ovat tärkeitä myös kampanjan tilan ymmärtämiseksi ja tulee ladata työkaluumme.
Ensimmäinen pannukakku on rakeinen
Koska olemme sitoutuneet joustaviin ohjelmistokehityksen periaatteisiin (ketteri, kaikki asiat), päätimme ensin kehittää MVP:n ja sitten siirtyä kohti tavoitetta iteratiivisesti.
Päätimme rakentaa MVP:n tuotteemme perusteella DANBo (Dentsu Aegis Network Board), joka on verkkosovellus, joka sisältää yleistä tietoa asiakkaidemme mainoskampanjoista.
MVP:n osalta projektia yksinkertaistettiin mahdollisimman paljon toteutuksen suhteen. Olemme valinneet rajoitetun luettelon alustoja integroitavaksi. Nämä olivat tärkeimmät alustat, kuten Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB ja tärkeimmät mainosjärjestelmät Adriver ja Weborama.
Käytämme yhtä tiliä nähdäksemme sivustojen tilastot API:n kautta. Asiakasryhmän johtajan, joka halusi käyttää automaattista tilastojen keräämistä mainoskampanjasta, oli ensin delegoitava sivustojen tarvittavien mainoskampanjoiden käyttö alustatilille.
Seuraava on järjestelmän käyttäjä DANBo piti ladata Excel-järjestelmään tietyn muotoinen tiedosto, joka sisälsi kaikki tiedot sijoittelusta (mainoskampanja, alusta, muoto, sijoitusjakso, suunnitellut indikaattorit, budjetti jne.) ja vastaavien mainoskampanjoiden tunnisteet. sivustot ja laskurit mainosjärjestelmissä.
Se näytti suoraan sanoen pelottavalta:
Ladatut tiedot tallennettiin tietokantaan, jonka jälkeen erilliset palvelut keräsivät niiltä sivustojen kampanjatunnisteita ja ladasivat niistä tilastoja.
Jokaiselle sivustolle kirjoitettiin erillinen windows-palvelu, joka kerran päivässä meni yhden palvelutilin alle sivuston API:ssa ja latasi tilastot määrätyille kampanjatunnuksille. Sama tapahtui mainosjärjestelmien kanssa.
Ladatut tiedot näytettiin käyttöliittymässä pienen mukautetun kojelaudan muodossa:
Meille yllättäen MVP aloitti työnsä ja alkoi ladata Internetin mainoskampanjoita koskevia ajankohtaisia tilastoja. Otimme järjestelmän käyttöön useilla asiakkailla, mutta skaalattaessa törmäsimme vakaviin ongelmiin:
- Suurin ongelma oli tietojen valmistelun monimutkaisuus järjestelmään ladattavaksi. Lisäksi sijoitustiedot piti muuntaa tiukasti kiinteään muotoon ennen lataamista. Ladattavaan tiedostoon piti sisällyttää entiteettitunnisteet eri sivustoilta. Olemme kohdanneet sen tosiasian, että teknisesti kouluttamattomien käyttäjien on erittäin vaikea selittää, mistä nämä tunnisteet löytyvät sivustolta ja mihin kohtaan tiedostoa ne on syötettävä. Kun otetaan huomioon työmailla kampanjoita tekevien osastojen henkilöstömäärä ja liikevaihto, tämä johti valtavaan tukeen puolellamme, johon emme olleet tyytyväisiä.
- Toinen ongelma oli, että kaikilla mainosalustoilla ei ollut mekanismeja mainoskampanjoiden käyttöoikeuden delegoimiseksi muille tileille. Mutta vaikka delegointimekanismi olisi käytettävissä, kaikki mainostajat eivät olleet halukkaita myöntämään pääsyä kampanjoihinsa kolmannen osapuolen tileille.
- Tärkeä tekijä oli närkästys, joka heräsi käyttäjien keskuudessa siitä, että kaikki suunnitellut indikaattorit ja sijoitustiedot, jotka he jo syöttävät 1C-kirjanpitojärjestelmäämme, on syötettävä uudelleen. DANBo.
Tämä antoi meille ajatuksen siitä, että ensisijaisena tietolähteenä sijoittelusta tulisi olla 1C-järjestelmämme, johon kaikki tiedot syötetään tarkasti ja ajallaan (tässä on se, että laskut luodaan 1C-tietojen perusteella, joten tietojen oikea syöttö 1C:hen on kaikkien KPI:n prioriteetti). Näin syntyi uusi käsite järjestelmästä...
Käsite
Ensimmäinen asia, jonka päätimme tehdä, oli erottaa Internet-mainoskampanjoiden tilastojen keräämisjärjestelmä erilliseksi tuotteeksi - D1.Digitaalinen.
Uudessa konseptissa päätimme ladata sisään D1.Digitaalinen tiedot mainoskampanjoista ja niiden sisällä olevista sijoitteluista 1C:stä ja noutaa sitten tilastot sivustoista ja mainostennäyttöjärjestelmistä näihin sijoitteluihin. Tämän piti yksinkertaistaa huomattavasti käyttäjien elämää (ja, kuten tavallista, lisätä kehittäjien työtä) ja vähentää tuen määrää.
Ensimmäinen kohtaamamme ongelma oli organisatorinen ja liittyi siihen, että emme löytäneet avainta tai merkkiä, jonka avulla voisimme verrata eri järjestelmien kokonaisuuksia 1C:n kampanjoihin ja sijoitteluihin. Tosiasia on, että yrityksessämme prosessi on suunniteltu siten, että eri ihmiset syöttävät mainoskampanjoita eri järjestelmiin (mediasuunnittelijat, ostajat jne.).
Tämän ongelman ratkaisemiseksi meidän täytyi keksiä ainutlaatuinen hajautusavain, DANBoID, joka yhdistäisi eri järjestelmien entiteetit toisiinsa ja joka voidaan tunnistaa melko helposti ja yksilöllisesti ladatuista tietojoukoista. Tämä tunniste luodaan sisäisessä 1C-järjestelmässä jokaiselle yksittäiselle sijoittelulle ja siirretään kampanjoihin, sijoitteluihin ja laskureihin kaikilla sivustoilla ja kaikissa AdServing-järjestelmissä. DANBoID:n laittaminen kaikkiin sijoitteluihin vei jonkin aikaa, mutta onnistuimme siinä :)
Sitten huomasimme, että kaikilla sivustoilla ei ole sovellusliittymää tilastojen automaattiseen keräämiseen, ja edes niillä, joilla on API, se ei palauta kaikkia tarvittavia tietoja.
Tässä vaiheessa päätimme vähentää merkittävästi integroitavien alustojen luetteloa ja keskittyä tärkeimpiin alustoihin, jotka ovat mukana suurimmassa osassa mainoskampanjoita. Tämä luettelo sisältää kaikki mainosmarkkinoiden suurimmat toimijat (Google, Yandex, Mail.ru), sosiaaliset verkostot (VK, Facebook, Twitter), suuret AdServing- ja analytiikkajärjestelmät (DCM, Adriver, Weborama, Google Analytics) ja muut alustat.
Suurimmalla osalla valitsemistamme sivustoista oli API, joka tarjosi tarvitsemamme tiedot. Tapauksissa, joissa APIa ei ollut tai se ei sisältänyt tarvittavia tietoja, käytimme tietojen lataamiseen päivittäin toimistosähköpostiin lähetettäviä raportteja (joissakin järjestelmissä tällaisia raportteja on mahdollista konfiguroida, toisissa sovimme tällaisten raporttien kehittämisestä meille).
Analysoidessamme eri sivustojen dataa havaitsimme, että entiteettien hierarkia ei ole sama eri järjestelmissä. Lisäksi tiedot on ladattava eri yksityiskohtaisesti eri järjestelmistä.
Tämän ongelman ratkaisemiseksi kehitettiin SubDANBoID-konsepti. SubDANBoID:n idea on melko yksinkertainen, merkitsemme kampanjan pääkokonaisuuden sivustolle luodulla DANBoID:llä ja lataamme kaikki sisäkkäiset entiteetit yksilöllisillä sivustotunnisteilla ja muodostamme SubDANBoID:n DANBoID-periaatteen mukaisesti + ensimmäisen tason tunniste. sisäkkäinen entiteetti + toisen tason sisäkkäisen entiteetin tunniste +... Tämän lähestymistavan avulla pystyimme yhdistämään mainoskampanjoita eri järjestelmissä ja lataamaan niistä yksityiskohtaisia tilastoja.
Meidän piti myös ratkaista eri alustojen kampanjoiden pääsyongelma. Kuten yllä kirjoitimme, kampanjan käyttöoikeuden delegointi erilliseen tekniseen tiliin ei ole aina käytettävissä. Siksi meidän oli kehitettävä infrastruktuuri automaattista valtuutusta varten OAuthin kautta käyttämällä tunnuksia ja mekanismeja näiden tokenien päivittämiseen.
Myöhemmin artikkelissa yritämme kuvata tarkemmin ratkaisun arkkitehtuuria ja toteutuksen teknisiä yksityiskohtia.
Ratkaisuarkkitehtuuri 1.0
Aloittaessamme uuden tuotteen käyttöönottoa ymmärsimme, että meidän on välittömästi huolehdittava uusien sivustojen yhdistämisestä, joten päätimme seurata mikropalveluarkkitehtuurin polkua.
Arkkitehtuurin suunnittelussa erotimme liittimet kaikkiin ulkoisiin järjestelmiin - 1C, mainosalustoille ja mainosjärjestelmille - erillisiksi palveluiksi.
Pääideana on, että kaikilla sivustojen liittimillä on sama API ja ne ovat sovittimia, jotka tuovat sivuston API:n meille sopivaan käyttöliittymään.
Tuotteemme keskiössä on web-sovellus, joka on monoliitti, joka on suunniteltu niin, että se on helposti purettavissa palveluiksi. Tämä sovellus vastaa ladattujen tietojen käsittelystä, eri järjestelmien tilastojen kokoamisesta ja niiden esittämisestä järjestelmän käyttäjille.
Kommunikoimaan liittimien ja verkkosovelluksen välillä jouduimme luomaan lisäpalvelun, jota kutsuimme Connector Proxyksi. Se suorittaa Service Discovery- ja Task Scheduler -toiminnot. Tämä palvelu suorittaa tiedonkeruutehtäviä jokaiselle liittimelle joka ilta. Palvelukerroksen kirjoittaminen oli helpompaa kuin viestivälittäjän yhdistäminen, ja meille oli tärkeää saada lopputulos mahdollisimman nopeasti.
Yksinkertaisuuden ja kehityksen nopeuden vuoksi päätimme myös, että kaikki palvelut ovat verkkosovellusliittymiä. Näin oli mahdollista koota nopeasti konseptitodistus ja varmistaa, että koko suunnittelu toimii.
Erillinen, melko monimutkainen tehtävä oli pääsyn asettaminen tietojen keräämiseen eri tileiltä, mikä, kuten päätimme, käyttäjien tulisi suorittaa verkkokäyttöliittymän kautta. Se koostuu kahdesta erillisestä vaiheesta: ensin käyttäjä lisää tunnuksen päästäkseen tilille OAuthin kautta ja määrittää sitten asiakastietojen keräämisen tietystä tilistä. Tokenin hankkiminen OAuthin kautta on välttämätöntä, koska kuten olemme jo kirjoittaneet, ei aina ole mahdollista delegoida pääsyä haluttuun tiliin sivustolla.
Luodaksemme yleisen mekanismin tilin valitsemiseksi sivustoista meidän piti lisätä liitinsovellusliittymään menetelmä, joka palauttaa JSON-skeeman, joka hahmonnetaan lomakkeeksi muokatun JSONEditor-komponentin avulla. Tällä tavalla käyttäjät voivat valita tilit, joilta tietoja ladataan.
Sivustojen pyyntörajojen noudattamiseksi yhdistämme asetuspyynnöt yhden tunnuksen sisällä, mutta voimme käsitellä erilaisia tunnuksia rinnakkain.
Valitsimme MongoDB:n ladatun datan tallennuspaikaksi sekä verkkosovellukselle että liittimille, jolloin ei tarvinnut liikaa murehtia tietorakenteesta kehityksen alkuvaiheessa, kun sovelluksen objektimalli vaihtuu joka toinen päivä.
Pian huomasimme, että kaikki tiedot eivät sovi hyvin MongoDB:hen ja esimerkiksi päivittäisiä tilastoja on kätevämpää tallentaa relaatiotietokantaan. Siksi liittimille, joiden tietorakenne sopii paremmin relaatiotietokantaan, aloitimme käyttämään PostgreSQL:tä tai MS SQL Serveriä tallennustilana.
Valitun arkkitehtuurin ja tekniikoiden ansiosta pystyimme rakentamaan ja lanseeraamaan D1.Digital-tuotteen suhteellisen nopeasti. Kahden vuoden tuotekehityksen aikana kehitimme 23 liitintä sivustoihin, saimme korvaamattoman kokemuksen kolmansien osapuolien sovellusliittymien kanssa työskentelystä, opimme välttämään eri sivustojen sudenkuopat, joilla jokaisella oli omat, auttoimme kehittämään vähintään 3 API:n sivustot, ladasivat automaattisesti tietoja lähes 15 000 kampanjasta ja yli 80 000 sijoittelusta, keräsivät käyttäjiltä paljon palautetta tuotteen toiminnasta ja onnistuivat muuttamaan tuotteen pääprosessia useaan otteeseen tämän palautteen perusteella.
Ratkaisuarkkitehtuuri 2.0
Kehityksen alkamisesta on kulunut kaksi vuotta D1.Digitaalinen. Jatkuva järjestelmän kuormituksen lisääntyminen ja yhä useampien uusien tietolähteiden ilmaantuminen paljasti vähitellen ongelmia olemassa olevassa ratkaisuarkkitehtuurissa.
Ensimmäinen ongelma liittyy sivustoilta ladatun tiedon määrään. Kohtasimme sen tosiasian, että kaiken tarvittavan tiedon kerääminen ja päivittäminen suurimmista sivustoista alkoi viedä liikaa aikaa. Esimerkiksi tietojen kerääminen AdRiver-mainosjärjestelmästä, jolla seuraamme useimpien sijoittelujen tilastoja, kestää noin 12 tuntia.
Tämän ongelman ratkaisemiseksi ryhdyimme käyttämään kaikenlaisia raportteja tietojen lataamiseen sivustoilta, yritämme kehittää niiden API-liittymää yhdessä sivustojen kanssa niin, että sen toiminnan nopeus vastaa tarpeitamme, sekä rinnastaa tiedon lataus mahdollisimman paljon.
Toinen ongelma liittyy ladattujen tietojen käsittelyyn. Nyt, kun uudet sijoittelutilastot saapuvat, käynnistetään monivaiheinen mittareiden uudelleenlaskentaprosessi, joka sisältää raakatietojen lataamisen, kunkin sivuston koottujen mittareiden laskemisen, eri lähteiden tietojen vertailun ja kampanjan yhteenvetomittareiden laskemisen. Tämä kuormittaa paljon verkkosovellusta, joka tekee kaikki laskelmat. Uudelleenlaskentaprosessin aikana sovellus kulutti useaan otteeseen kaiken palvelimen muistin, noin 10-15 Gt, mikä vaikutti haitallisimmin käyttäjien työhön järjestelmän kanssa.
Tunnistetut ongelmat ja kunnianhimoiset suunnitelmat tuotteen jatkokehittämiseksi johtivat tarpeeseen harkita sovellusarkkitehtuuria uudelleen.
Aloitimme liittimistä.
Huomasimme, että kaikki liittimet toimivat saman mallin mukaan, joten rakensimme putkikehyksen, jossa liittimen luomiseksi piti vain ohjelmoida vaiheiden logiikka, loput olivat universaaleja. Jos jokin liitin vaatii parannusta, siirrämme sen välittömästi uuteen kehykseen samalla kun liitintä parannetaan.
Samaan aikaan aloimme ottaa käyttöön liittimiä Dockeriin ja Kubernetesiin.
Suunnittelimme muuttoa Kubernetesiin melko pitkään, kokeilimme CI/CD-asetuksia, mutta aloitimme liikkeen vasta, kun yksi liitin alkoi virheen vuoksi kuluttaa yli 20 Gt palvelimen muistia, mikä käytännössä tappaa muut prosessit. . Tutkinnan aikana liitin siirrettiin Kubernetes-klusteriin, johon se lopulta jäi, vaikka virhe oli korjattu.
Varsin nopeasti tajusimme, että Kubernetes on kätevä, ja siirsimme puolen vuoden sisällä tuotantoklusteriin 7 eniten resursseja kuluttavaa liitintä ja Connectors Proxya.
Liittimien jälkeen päätimme muuttaa muun sovelluksen arkkitehtuuria.
Suurin ongelma oli, että tiedot tulevat liittimistä välityspalvelimiin suurissa erissä, osuvat sitten DANBoID:hen ja lähetetään keskusverkkosovellukseen käsittelyä varten. Mittareiden uudelleenlaskelmien suuren määrän vuoksi sovelluksella on suuri kuormitus.
Oli myös melko vaikeaa seurata yksittäisten tiedonkeruutöiden tilaa ja raportoida liittimissä esiintyvistä virheistä keskusverkkosovellukseen, jotta käyttäjät näkivät mitä tapahtuu ja miksi tietoja ei kerätty.
Näiden ongelmien ratkaisemiseksi kehitimme arkkitehtuurin 2.0.
Suurin ero arkkitehtuurin uuden version välillä on, että käytämme Web API:n sijaan RabbitMQ:ta ja MassTransit-kirjastoa viestien vaihtamiseen palveluiden välillä. Tätä varten meidän piti kirjoittaa Connectors Proxy lähes kokonaan uudelleen, jolloin siitä tuli Connectors Hub. Nimi muutettiin, koska palvelun päärooli ei ole enää pyyntöjen välittäminen liittimiin ja takaisin, vaan liittimien mittareiden keräämisen hallinta.
Keskeisestä verkkosovelluksesta erotimme sivustojen sijoittelu- ja tilastotiedot erillisiin palveluihin, mikä mahdollisti turhien uudelleenlaskelmien välttämisen ja vain jo laskettujen ja aggregoitujen tilastojen tallentamisen sijoittelutasolle. Kirjoitimme ja optimoimme myös raakatietoihin perustuvien perustilastojen laskentalogiikkaa.
Samanaikaisesti siirrämme kaikki palvelut ja sovellukset Dockeriin ja Kubernetesiin, jotta ratkaisu olisi helpompi skaalata ja helpompi hallita.
Missä olemme nyt
Proof-of-concept arkkitehtuuri 2.0 tuote D1.Digitaalinen valmis ja toimii testiympäristössä rajoitetulla liitinsarjalla. Ei tarvitse kuin kirjoittaa vielä 20 liitintä uudelle alustalle, testata, että tiedot on ladattu oikein ja kaikki mittarit on laskettu oikein, ja viedä koko suunnittelu tuotantoon.
Itse asiassa tämä prosessi tapahtuu vähitellen, ja meidän on jätettävä taaksepäin yhteensopivuus vanhojen sovellusliittymien kanssa, jotta kaikki toimisi.
Lähisuunnitelmiimme kuuluu uusien liittimien kehittäminen, integrointi uusiin järjestelmiin ja lisämittareiden lisääminen yhdistetyiltä sivustoilta ja mainosjärjestelmistä ladattavaan dataan.
Suunnittelemme myös kaikkien sovellusten, mukaan lukien keskusverkkosovelluksen, siirtämistä Dockeriin ja Kubernetesiin. Yhdessä uuden arkkitehtuurin kanssa tämä yksinkertaistaa merkittävästi kulutettujen resurssien käyttöönottoa, seurantaa ja valvontaa.
Toinen idea on kokeilla tietokannan valintaa tilastojen tallentamiseen, joka on tällä hetkellä tallennettu MongoDB:hen. Olemme jo siirtäneet useita uusia liittimiä SQL-tietokantoihin, mutta siellä ero on lähes huomaamaton, ja päiväkohtaisissa aggregoiduissa tilastoissa, joita voidaan pyytää mielivaltaisen ajanjakson ajan, voitto voi olla melko vakava.
Yleisesti ottaen suunnitelmat ovat mahtavia, mennään eteenpäin :)
Artikkelin kirjoittajat R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mihail Kotsik ()
Lähde: will.com