Интернет-жарнама саласы барынша жоғары технологиялық және автоматтандырылған болуы керек сияқты. Әрине, өйткені онда Яндекс, Mail.Ru, Google, Facebook сияқты алыптар мен өз саласының мамандары жұмыс істейді. Бірақ, белгілі болғандай, жетілдіруге шектеу жоқ және әрқашан автоматтандыруға болатын нәрсе бар.
Коммуникациялар тобы Dentsu Aegis Network Ресей цифрлық жарнама нарығындағы ең ірі ойыншы болып табылады және бизнес-процестерін оңтайландыруға және автоматтандыруға тырысып, технологияға белсенді түрде инвестициялауда. Интернет-жарнама нарығының шешілмеген мәселелерінің бірі әртүрлі интернет-платформалардан жарнамалық науқандардың статистикасын жинау міндеті болып табылады. Бұл мәселені шешу нәтижесінде өнім жасалды D1. Сандық (DiVan деп оқылады), біз оның дамуы туралы айтқымыз келеді.
Неліктен?
1. Жоба басталған кезде нарықта жарнамалық науқандар бойынша статистикалық мәліметтерді жинауды автоматтандыру мәселесін шешетін бірде-бір дайын өнім болған жоқ. Бұл біздің қажеттіліктерімізді өзімізден басқа ешкім қанағаттандыра алмайды дегенді білдіреді.
Improvado, Roistat, Supermetrics, SegmentStream сияқты қызметтер платформалармен, әлеуметтік желілермен және Google Analytics-пен интеграцияны ұсынады, сонымен қатар жарнамалық науқандарды ыңғайлы талдау және бақылау үшін аналитикалық бақылау тақталарын құруға мүмкіндік береді. Өнімімізді әзірлеуді бастамас бұрын, біз сайттардан деректерді жинау үшін осы жүйелердің кейбірін қолдануға тырыстық, бірақ, өкінішке орай, олар біздің мәселелерімізді шеше алмады.
Негізгі мәселе сыналған өнімдердің сайттар бойынша орналастыру статистикасын көрсететін деректер көздеріне негізделгендігі және жарнамалық науқандар бойынша статистиканы жинақтау мүмкіндігін қамтамасыз етпеуі болды. Бұл тәсіл әртүрлі сайттардың статистикасын бір жерден көруге және жалпы науқанның жағдайын талдауға мүмкіндік бермеді.
Тағы бір фактор, бастапқы кезеңде өнімдер батыс нарығына бағытталған және ресейлік сайттармен интеграцияны қолдамайды. Интеграция жүзеге асырылған сайттар үшін барлық қажетті көрсеткіштер әрқашан жеткілікті егжей-тегжейлі жүктелмеді және интеграция әрқашан ыңғайлы және ашық бола бермейді, әсіресе жүйе интерфейсінде жоқ нәрсені алу қажет болғанда.
Жалпы, біз үшінші тарап өнімдеріне бейімделмейміз деп шештік, бірақ өзіміздің...
2. Интернет-жарнама нарығы жылдан жылға өсіп келеді және 2018 жылы жарнамалық бюджеттер бойынша ол дәстүрлі ең үлкен теледидарлық жарнама нарығын басып озды. Демек, таразы бар.
3. Коммерциялық жарнаманы сату монополияланған тележарнама нарығынан айырмашылығы, Интернетте өздерінің жарнамалық шоттарымен жұмыс істейтін әртүрлі көлемдегі жарнамалық инвентарлардың жеке иелері өте көп. Жарнамалық науқан, әдетте, бірден бірнеше сайтта жұмыс істейтіндіктен, жарнамалық науқанның жай-күйін түсіну үшін барлық сайттардан есептерді жинап, оларды бүкіл суретті көрсететін бір үлкен есепке біріктіру қажет. Бұл оңтайландыру мүмкіндігі бар дегенді білдіреді.
4. Бізге Интернеттегі жарнамалық инвентарь иелерінің статистикалық мәліметтерді жинау және оларды жарнамалық шоттарда көрсету үшін инфрақұрылымы бар және олар бұл деректерге API ұсына алатындай көрінді. Бұл оны жүзеге асырудың техникалық мүмкін екендігін білдіреді. Бірден айтайық, бұл соншалықты қарапайым емес болып шықты.
Жалпы, жобаны жүзеге асырудың барлық алғы шарттары бізге айқын болды, жобаны өмірге әкелуге жүгірдік...
Үлкен жоспар
Алдымен біз идеалды жүйенің көрінісін қалыптастырдық:
- 1С корпоративтік жүйесіндегі жарнамалық науқандар оған атауларымен, кезеңдерімен, бюджеттерімен және әртүрлі платформалардағы орналасуымен автоматты түрде жүктелуі керек.
- Жарнамалық науқан аясындағы әрбір орналастыру үшін барлық ықтимал статистикалар орналастыру орын алып жатқан сайттардан автоматты түрде жүктелуі керек, мысалы, әсерлер, басулар, көрулер саны және т.б.
- Кейбір жарнамалық науқандар Adriver, Weborama, DCM және т.б. сияқты жарнамалық жүйелер деп аталатын үшінші тарап мониторингі арқылы бақыланады. Сондай-ақ Ресейде өнеркәсіптік интернет есептегіш бар - Mediascope компаниясы. Біздің жоспарымызға сәйкес, тәуелсіз және өндірістік мониторинг деректері де сәйкес жарнамалық науқандарға автоматты түрде жүктелуі керек.
- Интернеттегі жарнамалық науқандардың көпшілігі Google Analytics көмегімен қадағаланатын белгілі бір мақсатты әрекеттерге (сатып алу, қоңырау шалу, сынақ дискісіне тіркелу және т.б.) бағытталған және олардың статистикасы науқанның күйін түсіну үшін маңызды және біздің құралға жүктелуі керек.
Алғашқы құймақ - бұйра
Бағдарламалық жасақтаманы әзірлеудің икемді принциптеріне (шапшаңдық, барлығына) берілгендігімізді ескере отырып, біз алдымен MVP әзірлеуді шештік, содан кейін итеративті түрде жоспарланған мақсатқа қарай жылжайық.
Біз өнім негізінде MVP құруды шештік DANBo (Dentsu Aegis желілік тақтасы), бұл біздің клиенттеріміздің жарнамалық науқандары туралы жалпы ақпараты бар веб-қосымша.
MVP үшін жоба іске асыру тұрғысынан барынша жеңілдетілді. Біз интеграция үшін платформалардың шектеулі тізімін таңдадық. Бұл Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB сияқты негізгі платформалар және Adriver және Weborama негізгі жарнамалау жүйелері болды.
API арқылы сайттардағы статистикаға қол жеткізу үшін біз бір есептік жазбаны пайдаландық. Жарнамалық науқанда статистиканы автоматты түрде жинауды пайдаланғысы келген клиенттер тобының менеджері алдымен сайттардағы қажетті жарнамалық науқандарға кіру құқығын платформа тіркелгісіне беруі керек еді.
Келесі - жүйе пайдаланушысы ДАНБо орналастыру (жарнамалық науқан, платформа, формат, орналастыру мерзімі, жоспарланған көрсеткіштер, бюджет және т.б.) және сәйкес жарнамалық науқандардың идентификаторлары туралы барлық ақпаратты қамтитын Excel жүйесіне белгілі бір форматтағы файлды жүктеуге тура келді. жарнамалау жүйелеріндегі сайттар мен есептегіштер.
Бұл, шынын айтқанда, қорқынышты көрінді:
Жүктелген деректер дерекқорға сақталды, содан кейін бөлек қызметтер олардан сайттардағы науқан идентификаторларын жинап, олар бойынша статистиканы жүктеп алды.
Әрбір сайт үшін бөлек Windows қызметі жазылды, ол күніне бір рет сайттың API жүйесінде бір қызмет тіркелгісімен өтеді және көрсетілген науқан идентификаторлары үшін статистиканы жүктеп алады. Дәл осындай жағдай жарнамалау жүйелерімен де болды.
Жүктелген деректер интерфейсте шағын теңшелетін бақылау тақтасы түрінде көрсетілді:
Біз үшін күтпеген жерден MVP жұмыс істей бастады және Интернеттегі жарнамалық науқандар бойынша ағымдағы статистиканы жүктей бастады. Біз жүйені бірнеше клиенттерге енгіздік, бірақ масштабтауға тырысқанда біз күрделі мәселелерге тап болдық:
- Негізгі мәселе деректерді жүйеге жүктеуге дайындаудың күрделілігі болды. Сондай-ақ, орналастыру деректерін жүктеу алдында қатаң бекітілген пішімге түрлендіру қажет болды. Жүктеп алу файлына әртүрлі сайттардағы нысан идентификаторларын қосу қажет болды. Техникалық білімі жоқ пайдаланушылар үшін бұл идентификаторларды сайттан қай жерден табуға болатынын және оларды файлдың қай жеріне енгізу керектігін түсіндіру өте қиын екендігімен бетпе-бет келдік. Сайттардағы науқандарды жүргізетін бөлімшелердегі қызметкерлердің санын және айналымды ескере отырып, бұл біздің тарапымыздан үлкен қолдауға әкелді, бұл бізді мүлдем қанағаттандырмайды.
- Тағы бір мәселе, барлық жарнама платформаларында басқа тіркелгілерге жарнамалық науқандарға рұқсат беру тетіктері болмаған. Делегация механизмі қол жетімді болса да, барлық жарнама берушілер өздерінің науқандарына үшінші тарап тіркелгілеріне кіруге рұқсат бергісі келмеді.
- Маңызды фактор пайдаланушылардың наразылығын тудырды, олар біздің 1С бухгалтерлік жүйемізге енгізілген барлық жоспарланған көрсеткіштер мен орналастыру мәліметтерін қайтадан енгізуі керек. ДАНБо.
Бұл бізге орналастыру туралы ақпараттың негізгі көзі біздің 1С жүйеміз болуы керек деген идеяны берді, оған барлық деректер дәл және уақтылы енгізіледі (бұл жерде шот-фактуралар 1С деректері негізінде жасалады, сондықтан деректерді 1С-ге дұрыс енгізу). әрбір KPI үшін басымдық болып табылады). Осылайша жүйенің жаңа концепциясы пайда болды...
Тұжырымдама
Біз бірінші кезекте Интернеттегі жарнамалық науқандар туралы статистиканы жинау жүйесін бөлек өнімге бөлуді шештік - D1. Сандық.
Жаңа тұжырымдамада біз жүктеуді шештік D1. Сандық 1С-тен жарнамалық науқандар мен олардың ішіндегі орналастырулар туралы ақпарат, содан кейін сайттар мен AdServing жүйелерінен осы орналастыруларға статистиканы алыңыз. Бұл пайдаланушылардың өмірін айтарлықтай жеңілдету (және әдеттегідей әзірлеушілерге көбірек жұмыс қосу) және қолдау көлемін азайтуы керек еді.
Біз кездестірген бірінші мәселе ұйымдастырушылық сипатта болды және біз әртүрлі жүйелердегі нысандарды 1С науқандары мен орналастыруларымен салыстыра алатын кілт немесе белгіні таба алмағанымызға байланысты болды. Біздің компаниядағы процесс жарнамалық науқандарды әртүрлі адамдар (медиа жоспарлаушылар, сатып алу және т.б.) әртүрлі жүйелерге енгізетіндей етіп жасалған.
Бұл мәселені шешу үшін әртүрлі жүйелердегі нысандарды бір-бірімен байланыстыратын және жүктелген деректер жиынында өте оңай және бірегей түрде анықталатын DANBoID бірегей хэштелген кілтті ойлап табуға тура келді. Бұл идентификатор әрбір жеке орналастыру үшін ішкі 1С жүйесінде жасалады және барлық сайттардағы және барлық AdServing жүйелеріндегі науқандарға, орналастыруларға және есептегіштерге тасымалданады. DANBoID-ті барлық орналастыруларға енгізу тәжірибесін енгізу біраз уақытты алды, бірақ біз мұны істей алдық :)
Содан кейін біз барлық сайттарда статистиканы автоматты түрде жинауға арналған API жоқ екенін білдік, тіпті API бар сайттар да барлық қажетті деректерді қайтармайды.
Осы кезеңде біз интеграцияға арналған платформалар тізімін айтарлықтай қысқартып, жарнамалық науқандардың басым көпшілігіне қатысатын негізгі платформаларға назар аударуды шештік. Бұл тізімге жарнама нарығының барлық ірі ойыншылары (Google, Yandex, Mail.ru), әлеуметтік желілер (VK, Facebook, Twitter), негізгі AdServing және аналитикалық жүйелері (DCM, Adriver, Weborama, Google Analytics) және басқа платформалар кіреді.
Біз таңдаған сайттардың көпшілігінде бізге қажетті көрсеткіштерді беретін API болды. API болмаған немесе қажетті деректер болмаған жағдайда, деректерді жүктеу үшін күнделікті кеңсе электрондық поштасына жіберілетін есептерді пайдаландық (кейбір жүйелерде мұндай есептерді конфигурациялауға болады, басқаларында біз осындай есептерді әзірлеуге келістік. Біз үшін).
Әртүрлі тораптардағы деректерді талдау кезінде біз нысандардың иерархиясы әртүрлі жүйелерде бірдей емес екенін білдік. Сонымен қатар, ақпаратты әртүрлі жүйелерден әртүрлі егжей-тегжейлі жүктеу қажет.
Бұл мәселені шешу үшін SubDANBoID тұжырымдамасы жасалды. SubDANBoID идеясы өте қарапайым, біз сайттағы науқанның негізгі нысанын жасалған DANBoID арқылы белгілейміз және біз бірегей сайт идентификаторлары бар барлық кірістірілген нысандарды жүктейміз және DANBoID принципі + бірінші деңгей идентификаторы бойынша SubDANBoID қалыптастырамыз. кірістірілген нысан + екінші деңгейлі кірістірілген нысанның идентификаторы +... Бұл тәсіл бізге әртүрлі жүйелердегі жарнамалық науқандарды қосуға және олар бойынша егжей-тегжейлі статистиканы жүктеп алуға мүмкіндік берді.
Бізге әртүрлі платформалардағы науқандарға қол жеткізу мәселесін шешуге тура келді. Жоғарыда жазғанымыздай, науқанға рұқсатты бөлек техникалық есептік жазбаға беру механизмі әрқашан қолданыла бермейді. Сондықтан бізге токендерді және осы токендерді жаңарту механизмдерін пайдаланып OAuth арқылы автоматты авторизациялау инфрақұрылымын әзірлеуге тура келді.
Кейінірек мақалада біз шешімнің архитектурасын және іске асырудың техникалық бөлшектерін толығырақ сипаттауға тырысамыз.
Шешім архитектурасы 1.0
Жаңа өнімді енгізуді бастаған кезде біз жаңа сайттарды қосу мүмкіндігін қамтамасыз ету қажет екенін түсіндік, сондықтан микросервис архитектурасы жолымен жүруді шештік.
Архитектураны жобалау кезінде біз барлық сыртқы жүйелерге қосқыштарды - 1С, жарнамалық платформалар мен жарнамалық жүйелерді - бөлек қызметтерге бөлдік.
Негізгі идея сайттардың барлық қосқыштарында бірдей API бар және сайт API интерфейсін бізге ыңғайлы интерфейске әкелетін адаптерлер болып табылады.
Біздің өніміміздің ортасында қызметтерге оңай бөлшектеуге болатындай етіп жасалған монолит болып табылатын веб-қосымшасы бар. Бұл қолданба жүктеп алынған деректерді өңдеуге, әртүрлі жүйелердегі статистиканы жинақтауға және оларды жүйе пайдаланушыларына ұсынуға жауапты.
Қосқыштар мен веб-бағдарлама арасында байланысу үшін бізге қосымша қызметті жасау керек болды, оны біз Connector Proxy деп атадық. Ол Service Discovery және Task Scheduler функцияларын орындайды. Бұл қызмет әр түнде әрбір қосқыш үшін деректерді жинау тапсырмаларын орындайды. Қызметтік деңгейді жазу хабарлама брокерін қосуға қарағанда оңай болды және біз үшін нәтижені мүмкіндігінше тез алу маңызды болды.
Әзірлеудің қарапайымдылығы мен жылдамдығы үшін біз барлық қызметтер Web API болады деп шештік. Бұл тұжырымдаманың дәлелін жылдам жинауға және бүкіл дизайн жұмыс істейтінін тексеруге мүмкіндік берді.
Бөлек, біршама күрделі міндет әртүрлі тіркелгілерден деректерді жинауға рұқсатты орнату болды, оны біз шешкеніміздей, пайдаланушылар веб-интерфейс арқылы жүзеге асыруы керек. Ол екі бөлек қадамнан тұрады: біріншіден, пайдаланушы тіркелгіге OAuth арқылы кіру үшін таңбалауышты қосады, содан кейін белгілі бір тіркелгіден клиент үшін деректер жинағын теңшейді. OAuth арқылы токенді алу қажет, өйткені біз бұрын жазғанымыздай, сайтта қалаған тіркелгіге рұқсат беру әрқашан мүмкін емес.
Сайттардан тіркелгіні таңдаудың әмбебап механизмін жасау үшін өзгертілген JSONEditor құрамдас бөлігі арқылы пішінге көрсетілетін JSON схемасын қайтаратын API қосқыштарына әдіс қосуға тура келді. Осылайша, пайдаланушылар деректерді жүктеп алатын тіркелгілерді таңдай алды.
Сайттарда бар сұрау шектеулеріне сәйкес болу үшін параметрлерге арналған сұрауларды бір таңбалауыш ішінде біріктіреміз, бірақ әртүрлі таңбалауыштарды қатар өңдей аламыз.
Біз MongoDB-ті веб-қосымша үшін де, қосқыштар үшін де жүктелген деректерді сақтау орны ретінде таңдадық, бұл қосымшаның нысандық үлгісі күн сайын өзгеретін дамудың бастапқы кезеңдерінде деректер құрылымы туралы тым көп алаңдамауға мүмкіндік берді.
Көп ұзамай біз барлық деректер MongoDB-ге сәйкес келмейтінін білдік және, мысалы, реляциялық дерекқорда күнделікті статистиканы сақтау ыңғайлырақ. Сондықтан деректер құрылымы реляциялық дерекқор үшін қолайлырақ қосқыштар үшін сақтау ретінде PostgreSQL немесе MS SQL Server пайдалана бастадық.
Таңдалған архитектура мен технологиялар D1.Digital өнімін салыстырмалы түрде тез жасап шығаруға мүмкіндік берді. Өнімді әзірлеудің екі жылында біз сайттарға 23 қосқыш әзірледік, үшінші тарап API интерфейстерімен жұмыс істеудің баға жетпес тәжірибесін алдық, әрқайсысының өзіндік ерекшеліктері бар әртүрлі сайттардың қателерінен аулақ болуды үйрендік, кем дегенде 3 API әзірлеуге үлес қосты. сайттар, 15 000-ға жуық науқандар және 80 000-нан астам орналастырулар туралы ақпаратты автоматты түрде жүктеп алып, пайдаланушылардан өнімнің жұмысы туралы көптеген пікірлер жинады және осы кері байланыс негізінде өнімнің негізгі процесін бірнеше рет өзгерте алды.
Шешім архитектурасы 2.0
Дамудың басталғанына екі жыл болды D1. Сандық. Жүйеге жүктеменің үнемі артуы және көбірек жаңа деректер көздерінің пайда болуы бірте-бірте қолданыстағы шешім архитектурасындағы мәселелерді анықтады.
Бірінші мәселе сайттардан жүктелетін деректер көлеміне байланысты. Біз ең үлкен сайттардан барлық қажетті деректерді жинау және жаңарту тым көп уақытты талап ете бастағанына тап болдық. Мысалы, көптеген орналастырулар бойынша статистиканы бақылайтын AdRiver жарнамалау жүйесінен деректерді жинау шамамен 12 сағатты алады.
Бұл мәселені шешу үшін біз сайттардан деректерді жүктеп алу үшін есептердің барлық түрлерін пайдалана бастадық, біз олардың жұмыс жылдамдығы біздің қажеттіліктерімізге сәйкес келетіндей етіп сайттармен бірге API әзірлеуге және деректерді жүктеуді мүмкіндігінше параллель етуге тырысамыз.
Тағы бір мәселе жүктелген деректерді өңдеуге қатысты. Енді жаңа орналастыру статистикасы келгенде, бастапқы деректерді жүктеуді, әрбір торап үшін жинақталған көрсеткіштерді есептеуді, әртүрлі көздерден алынған деректерді бір-бірімен салыстыруды және науқанға арналған жиынтық көрсеткіштерді есептеуді қамтитын көрсеткіштерді қайта есептеудің көп сатылы процесі іске қосылады. Бұл барлық есептеулерді жасайтын веб-бағдарламаға көп жүктемені тудырады. Бірнеше рет қайта есептеу процесінде қолданба сервердегі барлық жадты, шамамен 10-15 ГБ-ты тұтынды, бұл пайдаланушылардың жүйемен жұмысына ең зиянды әсер етті.
Анықталған проблемалар мен өнімді одан әрі дамытудың өршіл жоспарлары бізді қолданба архитектурасын қайта қарау қажеттілігіне әкелді.
Біз қосқыштардан бастадық.
Біз барлық қосқыштардың бір модельге сәйкес жұмыс істейтінін байқадық, сондықтан біз коннекторды жасау үшін тек қадамдардың логикасын бағдарламалау керек болатын құбыр желісін құрдық, қалғаны әмбебап болды. Егер қандай да бір қосқыш жақсартуды қажет етсе, коннектор жақсартылып жатқанда, біз оны бірден жаңа құрылымға ауыстырамыз.
Сонымен бірге біз Docker және Kubernetes қосқыштарын орналастыруды бастадық.
Біз Кубернетеске көшуді ұзақ уақыт жоспарладық, CI/CD параметрлерімен тәжірибе жасадық, бірақ бір қосқыш қатеге байланысты серверде 20 ГБ-тан астам жадты жей бастағанда ғана қозғала бастадық, бұл басқа процестерді іс жүзінде өлтіреді. . Тергеу барысында қосқыш Kubernetes кластеріне ауыстырылды, ол жерде қате түзетілгеннен кейін де қалды.
Біз тез арада Kubernetes ыңғайлы екенін түсіндік және алты ай ішінде біз ең көп ресурстарды тұтынатын 7 қосқыш пен Connectors Proxy-ді өндірістік кластерге ауыстырдық.
Қосқыштардан кейін біз қалған қолданбаның архитектурасын өзгертуді шештік.
Негізгі мәселе деректердің үлкен партиялардағы коннекторлардан прокси-серверлерге келуі, содан кейін DANBoID-ке түсіп, өңдеу үшін орталық веб-қосымшаға жіберілуінде болды. Метрикаларды қайта есептеулердің көп санына байланысты қолданбада үлкен жүктеме бар.
Сондай-ақ, пайдаланушылар не болып жатқанын және деректер неге жиналмай жатқанын көруі үшін жеке деректерді жинау жұмыстарының күйін бақылау және орталық веб-бағдарлама қосқыштарында орын алған қателер туралы есеп беру өте қиын болды.
Осы мәселелерді шешу үшін біз архитектура 2.0 әзірледік.
Архитектураның жаңа нұсқасының негізгі айырмашылығы мынада: Web API орнына біз қызметтер арасында хабарлама алмасу үшін RabbitMQ және MassTransit кітапханасын қолданамыз. Ол үшін Коннекторлар проксиін толығымен дерлік қайта жазу керек болды, оны Connectors Hub етеді. Атау өзгертілді, себебі қызметтің негізгі рөлі бұдан былай сұрауларды қосқыштарға және кері жіберуде емес, қосқыштардан метрика жинағын басқаруда.
Орталық веб-қосымшадан біз сайттардағы орналастырулар мен статистика туралы ақпаратты бөлек қызметтерге бөлдік, бұл қажетсіз қайта есептеулерден арылуға және орналастыру деңгейінде бұрыннан есептелген және жинақталған статистиканы ғана сақтауға мүмкіндік берді. Біз сондай-ақ бастапқы деректер негізінде негізгі статистиканы есептеу логикасын қайта жазып, оңтайландырдық.
Сонымен қатар, шешімді масштабтауды жеңілдету және басқаруды ыңғайлы ету үшін біз барлық қызметтер мен қолданбаларды Docker және Kubernetes жүйесіне көшіреміз.
Біз қазір қай жердеміз
Тұжырымдаманың дәлелді архитектурасы 2.0 өнімі D1. Сандық дайын және қосқыштардың шектеулі жиынтығы бар сынақ ортасында жұмыс істейді. Жаңа платформаға тағы 20 қосқышты қайта жазу, деректердің дұрыс жүктелгенін және барлық көрсеткіштердің дұрыс есептелгенін тексеру және бүкіл дизайнды өндіріске шығару ғана қалды.
Шындығында, бұл процесс бірте-бірте орындалады және бәрі жұмыс істеп тұру үшін ескі API интерфейстерімен кері үйлесімділікті қалдыруға тура келеді.
Біздің жақын арада жоспарларымызға жаңа қосқыштарды әзірлеу, жаңа жүйелермен біріктіру және қосылған сайттар мен жарнамалық жүйелерден жүктелген деректер жинағына қосымша көрсеткіштер қосу кіреді.
Біз сондай-ақ барлық қолданбаларды, соның ішінде орталық веб-қосымшаны Docker және Kubernetes-ке тасымалдауды жоспарлап отырмыз. Жаңа архитектурамен біріктірілген бұл тұтынылатын ресурстарды орналастыруды, бақылауды және бақылауды айтарлықтай жеңілдетеді.
Тағы бір идея - қазіргі уақытта MongoDB-де сақталған статистиканы сақтауға арналған дерекқорды таңдаумен тәжірибе жасау. Біз қазірдің өзінде SQL дерекқорларына бірнеше жаңа қосқыштарды ауыстырдық, бірақ бұл жерде айырмашылық дерлік байқалмайды, ал ерікті кезеңге сұралуы мүмкін күн бойынша жиынтық статистика үшін табыс айтарлықтай елеулі болуы мүмкін.
Жалпы, жоспарлар үлкен, әрі қарай жүрейік :)
R&D Dentsu Aegis Network Ресей мақаласының авторлары: Георгий Остапенко (), Михаил Коцик ()
Ақпарат көзі: www.habr.com