Ko'rinishidan, onlayn reklama sohasi iloji boricha texnologik va avtomatlashtirilgan bo'lishi kerak. Albatta, chunki u erda Yandex, Mail.Ru, Google va Facebook kabi gigantlar va o'z sohasining mutaxassislari ishlaydi. Ammo, ma'lum bo'lishicha, mukammallikka cheklov yo'q va har doim avtomatlashtirish uchun biror narsa bor.
Aloqa guruhi Dentsu Aegis Network Rossiya raqamli reklama bozoridagi eng yirik o'yinchi bo'lib, texnologiyaga faol sarmoya kiritmoqda, biznes jarayonlarini optimallashtirish va avtomatlashtirishga harakat qilmoqda. Onlayn reklama bozorining hal etilmagan muammolaridan biri bu turli xil Internet platformalaridan reklama kampaniyalari bo'yicha statistik ma'lumotlarni yig'ish vazifasidir. Bu muammoning yechimi oxir-oqibat mahsulot yaratilishiga olib keldi D1.Raqamli (DiVan deb o'qing), biz uning rivojlanishi haqida gapirmoqchimiz.
Nima uchun?
1. Loyiha boshlangan vaqtda bozorda reklama kampaniyalari bo'yicha statistik ma'lumotlarni yig'ishni avtomatlashtirish muammosini hal qiladigan birorta ham tayyor mahsulot yo'q edi. Bu shuni anglatadiki, o'zimizdan boshqa hech kim bizning ehtiyojlarimizni qondira olmaydi.
Improvado, Roistat, Supermetrics, SegmentStream kabi xizmatlar platformalar, ijtimoiy tarmoqlar va Google Analytics bilan integratsiyani taklif qiladi, shuningdek, reklama kampaniyalarini qulay tahlil qilish va nazorat qilish uchun analitik asboblar panelini yaratish imkonini beradi. Mahsulotimizni ishlab chiqishni boshlashdan oldin, biz saytlardan ma'lumotlarni yig'ish uchun ushbu tizimlarning ba'zilaridan foydalanishga harakat qildik, ammo, afsuski, ular bizning muammolarimizni hal qila olmadi.
Asosiy muammo shundaki, sinovdan o'tgan mahsulotlar ma'lumotlar manbalariga asoslangan bo'lib, saytlar bo'yicha joylashtirish statistikasini aks ettiradi va reklama kampaniyalari bo'yicha statistik ma'lumotlarni jamlash imkoniyatini bermaydi. Bunday yondashuv turli saytlarning statistik ma’lumotlarini bir joyda ko‘rish va kampaniya holatini bir butun sifatida tahlil qilish imkonini bermadi.
Yana bir omil shundaki, dastlabki bosqichlarda mahsulotlar G'arb bozoriga yo'naltirilgan va Rossiya saytlari bilan integratsiyani qo'llab-quvvatlamagan. Va integratsiya amalga oshirilgan saytlar uchun barcha kerakli ko'rsatkichlar har doim ham etarli darajada batafsil yuklab olinmagan va integratsiya har doim ham qulay va shaffof bo'lmagan, ayniqsa tizim interfeysida bo'lmagan narsalarni olish kerak bo'lganda.
Umuman olganda, biz uchinchi tomon mahsulotlariga moslashmaslikka qaror qildik, lekin o'zimiznikini ishlab chiqishni boshladik ...
2. Onlayn reklama bozori yildan-yilga o'sib bormoqda va 2018 yilda reklama byudjeti bo'yicha u an'anaviy eng yirik telereklama bozorini ortda qoldirdi. Shunday qilib, o'lchov bor.
3. Televidenie reklama bozoridan farqli o'laroq, tijorat reklamalari sotuvi monopollashtiriladi, Internetda o'z reklama akkauntlari bilan ishlaydigan turli o'lchamdagi reklama inventarlarining individual egalari juda ko'p. Reklama kampaniyasi, qoida tariqasida, bir vaqtning o'zida bir nechta saytlarda ishlayotganligi sababli, reklama kampaniyasining holatini tushunish uchun barcha saytlardan hisobotlarni to'plash va ularni butun rasmni ko'rsatadigan bitta katta hisobotga birlashtirish kerak. Bu optimallashtirish uchun potentsial mavjudligini anglatadi.
4. Bizga shunday tuyuldiki, Internetdagi reklama inventarlari egalari allaqachon statistik ma'lumotlarni yig'ish va ularni reklama hisoblarida ko'rsatish uchun infratuzilmaga ega va ular ushbu ma'lumotlar uchun API taqdim etishlari mumkin. Bu shuni anglatadiki, uni amalga oshirish texnik jihatdan mumkin. Darhol aytaylik, bu unchalik oddiy emas edi.
Umuman olganda, loyihani amalga oshirish uchun barcha shart-sharoitlar bizga ayon edi va biz loyihani hayotga tatbiq etishga yugurdik...
Katta reja
Boshlash uchun biz ideal tizim haqidagi tasavvurni shakllantirdik:
- 1C korporativ tizimidagi reklama kampaniyalari unga nomlari, muddatlari, byudjetlari va turli platformalardagi joylashuvi bilan avtomatik ravishda yuklanishi kerak.
- Reklama kampaniyasi doirasidagi har bir joylashtirish uchun barcha mumkin bo'lgan statistik ma'lumotlar joylashtirish amalga oshirilayotgan saytlardan avtomatik ravishda yuklab olinishi kerak, masalan, taassurotlar, bosishlar, ko'rishlar soni va boshqalar.
- Ba'zi reklama kampaniyalari Adriver, Weborama, DCM va boshqalar kabi reklama tizimlari deb ataladigan uchinchi tomon monitoringi yordamida kuzatiladi. Rossiyada sanoat Internet hisoblagichi ham mavjud - Mediascope kompaniyasi. Bizning rejamizga ko'ra, mustaqil va sanoat monitoringi ma'lumotlari ham tegishli reklama kampaniyalariga avtomatik ravishda yuklanishi kerak.
- Internetdagi aksariyat reklama kampaniyalari muayyan maqsadli harakatlarga (sotib olish, qo'ng'iroq qilish, test drayveriga ro'yxatdan o'tish va h.k.) qaratilgan bo'lib, ular Google Analytics yordamida kuzatib boriladi va statistik ma'lumotlar kampaniyaning holatini tushunish uchun ham muhimdir. bizning vositamizga yuklanishi kerak.
Birinchi ko'zoynak pushti
Dasturiy ta'minotni ishlab chiqishning moslashuvchan tamoyillariga (chaqqonlik, hamma narsa) sodiqligimizni inobatga olgan holda, biz birinchi navbatda MVPni ishlab chiqishga qaror qildik va keyin ko'zlangan maqsad sari iterativ tarzda harakat qildik.
Biz mahsulotimiz asosida MVP yaratishga qaror qildik DANBo (Dentsu Aegis Network Board), bu bizning mijozlarimizning reklama kampaniyalari haqida umumiy ma'lumotga ega veb-ilova.
MVP uchun loyiha amalga oshirish nuqtai nazaridan imkon qadar soddalashtirildi. Biz integratsiya uchun platformalarning cheklangan ro'yxatini tanladik. Bular Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB kabi asosiy platformalar hamda Adriver va Weborama asosiy reklama tizimlari edi.
API orqali saytlar statistikasiga kirish uchun biz bitta hisobdan foydalandik. Reklama kampaniyasida statistik ma'lumotlarni avtomatik to'plashdan foydalanmoqchi bo'lgan mijozlar guruhi menejeri birinchi navbatda saytlardagi kerakli reklama kampaniyalariga kirish huquqini platforma hisobiga topshirishi kerak edi.
Keyingi - tizim foydalanuvchisi DANBo joylashtirish (reklama kampaniyasi, platforma, format, joylashtirish davri, rejalashtirilgan ko'rsatkichlar, byudjet va boshqalar) va tegishli reklama kampaniyalarining identifikatorlari haqidagi barcha ma'lumotlarni o'z ichiga olgan ma'lum formatdagi faylni Excel tizimiga yuklashi kerak edi. reklama tizimlarida saytlar va hisoblagichlar.
Ochig'i, dahshatli ko'rinardi:
Yuklab olingan ma'lumotlar ma'lumotlar bazasiga saqlandi, so'ngra alohida xizmatlar ulardan saytlardagi kampaniya identifikatorlarini to'pladi va ular bo'yicha statistik ma'lumotlarni yuklab oldi.
Har bir sayt uchun alohida Windows xizmati yozildi, u kuniga bir marta sayt API-da bitta xizmat hisobiga o'tdi va belgilangan kampaniya identifikatorlari uchun statistik ma'lumotlarni yuklab oldi. Xuddi shu narsa reklama tizimlari bilan sodir bo'ldi.
Yuklab olingan ma'lumotlar interfeysda kichik shaxsiy boshqaruv paneli ko'rinishida ko'rsatildi:
Biz uchun kutilmaganda MVP ishlay boshladi va Internetdagi reklama kampaniyalari bo'yicha joriy statistik ma'lumotlarni yuklab olishni boshladi. Biz tizimni bir nechta mijozlarga tatbiq etdik, lekin miqyosni kengaytirishga harakat qilganimizda, biz jiddiy muammolarga duch keldik:
- Asosiy muammo tizimga yuklash uchun ma'lumotlarni tayyorlashning murakkabligi edi. Bundan tashqari, yuklashdan oldin joylashtirish ma'lumotlari qat'iy belgilangan formatga aylantirilishi kerak edi. Yuklab olish fayliga turli saytlardan ob'ekt identifikatorlarini kiritish kerak edi. Texnik jihatdan o'qimagan foydalanuvchilar uchun ushbu identifikatorlarni saytning qayerdan topish va faylning qayeriga kiritish kerakligini tushuntirish juda qiyin ekanligiga duch keldik. Saytlarda kampaniya o'tkazayotgan bo'limlardagi xodimlar soni va aylanmani hisobga olsak, bu biz tomonda katta miqdordagi qo'llab-quvvatlashga olib keldi, bu bizni mutlaqo qoniqtirmadi.
- Yana bir muammo shundaki, barcha reklama platformalarida reklama kampaniyalariga kirishni boshqa hisoblarga topshirish mexanizmlari mavjud emas edi. Ammo delegatsiya mexanizmi mavjud bo'lsa ham, barcha reklama beruvchilar o'z kampaniyalariga uchinchi tomon hisoblariga kirish huquqini berishga tayyor emaslar.
- Muhim omil foydalanuvchilar orasida barcha rejalashtirilgan ko'rsatkichlar va joylashtirish tafsilotlarini bizning 1C buxgalteriya tizimiga kiritgan holda, ular qayta kiritishlari kerakligi sababli g'azabni uyg'otdi. DANBo.
Bu bizga joylashtirish haqidagi asosiy ma'lumot manbai barcha ma'lumotlar aniq va o'z vaqtida kiritiladigan 1C tizimi bo'lishi kerak degan fikrni berdi (bu erda gap schyot-fakturalar 1C ma'lumotlari asosida yaratilgan, shuning uchun 1C ga ma'lumotlarni to'g'ri kiritish) har bir KPI uchun ustuvor hisoblanadi). Shunday qilib, tizimning yangi kontseptsiyasi paydo bo'ldi ...
tushuncha
Biz qilishga qaror qilgan birinchi narsa Internetdagi reklama kampaniyalari bo'yicha statistik ma'lumotlarni to'plash tizimini alohida mahsulotga ajratish edi - D1.Raqamli.
Yangi kontseptsiyada biz yuklashga qaror qildik D1.Raqamli 1C dan reklama kampaniyalari va ulardagi joylashtirishlar haqida ma'lumot oling, so'ngra saytlar va AdServing tizimlaridan ushbu joylashtirishlarga statistik ma'lumotlarni oling. Bu foydalanuvchilarning hayotini sezilarli darajada soddalashtirishi (va odatdagidek, ishlab chiquvchilarga ko'proq ish qo'shishi) va qo'llab-quvvatlash miqdorini kamaytirishi kerak edi.
Biz duch kelgan birinchi muammo tashkiliy xususiyatga ega edi va biz turli tizimlardagi ob'ektlarni 1C kampaniyalari va joylashtirishlari bilan taqqoslashimiz mumkin bo'lgan kalit yoki belgini topa olmaganimiz bilan bog'liq edi. Gap shundaki, bizning kompaniyamizdagi jarayon shunday tuzilganki, reklama kampaniyalari turli xil tizimlarga turli odamlar tomonidan kiritiladi (media-rejalashtiruvchilar, xaridlar va boshqalar).
Ushbu muammoni hal qilish uchun biz turli xil tizimlardagi ob'ektlarni bir-biriga bog'laydigan va yuklab olingan ma'lumotlar to'plamlarida juda oson va noyob tarzda aniqlanishi mumkin bo'lgan noyob xeshlangan kalitni - DANBoIDni ixtiro qilishimiz kerak edi. Ushbu identifikator har bir alohida joylashtirish uchun ichki 1C tizimida yaratiladi va barcha saytlar va barcha AdServing tizimlaridagi kampaniyalar, joylashtirishlar va hisoblagichlarga o'tkaziladi. DANBoID-ni barcha joylashtirishlarga qo'yish amaliyotini amalga oshirish biroz vaqt talab qildi, lekin biz buni uddaladik :)
Keyin biz hamma saytlarda statistik ma'lumotlarni avtomatik yig'ish uchun API mavjud emasligini va hatto API mavjud bo'lganlar ham barcha kerakli ma'lumotlarni qaytarmasligini aniqladik.
Ushbu bosqichda biz integratsiya uchun platformalar ro'yxatini sezilarli darajada qisqartirishga va reklama kampaniyalarining katta qismiga jalb qilingan asosiy platformalarga e'tibor qaratishga qaror qildik. Ushbu ro'yxatga reklama bozorining barcha yirik o'yinchilari (Google, Yandex, Mail.ru), ijtimoiy tarmoqlar (VK, Facebook, Twitter), yirik AdServing va tahlil tizimlari (DCM, Adriver, Weborama, Google Analytics) va boshqa platformalar kiradi.
Biz tanlagan saytlarning aksariyatida bizga kerakli ko'rsatkichlarni taqdim etadigan API mavjud edi. Agar API mavjud bo'lmasa yoki unda kerakli ma'lumotlar bo'lmasa, biz ma'lumotlarni yuklash uchun har kuni ofisimiz elektron pochtasiga yuboriladigan hisobotlardan foydalanardik (ba'zi tizimlarda bunday hisobotlarni sozlash mumkin, boshqalarida biz bunday hisobotlarni ishlab chiqishga kelishib oldik. Biz uchun).
Turli saytlardan olingan ma'lumotlarni tahlil qilganda, biz ob'ektlar ierarxiyasi turli tizimlarda bir xil emasligini aniqladik. Bundan tashqari, ma'lumotni turli tizimlardan har xil tafsilotlarda yuklab olish kerak.
Ushbu muammoni hal qilish uchun SubDANBoID kontseptsiyasi ishlab chiqilgan. SubDANBoID g'oyasi juda oddiy, biz saytdagi kampaniyaning asosiy ob'ektini yaratilgan DANBoID bilan belgilaymiz va biz barcha o'rnatilgan ob'ektlarni noyob sayt identifikatorlari bilan yuklaymiz va DANBoID printsipi + birinchi darajali identifikatorga muvofiq SubDANBoID ni shakllantiramiz. ichki joylashtirilgan ob'ekt + ikkinchi darajali ichki kiritilgan ob'ekt identifikatori +... Bu yondashuv bizga turli tizimlardagi reklama kampaniyalarini ulash va ular bo'yicha batafsil statistik ma'lumotlarni yuklab olish imkonini berdi.
Shuningdek, biz turli platformalardagi kampaniyalarga kirish muammosini hal qilishimiz kerak edi. Yuqorida yozganimizdek, kampaniyaga kirish huquqini alohida texnik hisobga o'tkazish mexanizmi har doim ham qo'llanilmaydi. Shuning uchun biz tokenlar va ushbu tokenlarni yangilash mexanizmlaridan foydalangan holda OAuth orqali avtomatik avtorizatsiya qilish uchun infratuzilmani ishlab chiqishimiz kerak edi.
Keyinchalik maqolada biz yechimning arxitekturasini va amalga oshirishning texnik tafsilotlarini batafsilroq tasvirlashga harakat qilamiz.
Yechim arxitekturasi 1.0
Yangi mahsulotni joriy qilishni boshlaganimizda, biz darhol yangi saytlarni ulash imkoniyatini ta'minlashimiz kerakligini tushundik, shuning uchun biz mikroservis arxitekturasi yo'lidan borishga qaror qildik.
Arxitekturani loyihalashda biz barcha tashqi tizimlar - 1C, reklama platformalari va reklama tizimlari uchun ulagichlarni alohida xizmatlarga ajratdik.
Asosiy g'oya shundaki, saytlarning barcha konnektorlari bir xil APIga ega va sayt API-ni biz uchun qulay interfeysga olib keladigan adapterlardir.
Mahsulotimizning markazida veb-ilova mavjud bo'lib, u monolit bo'lib, uni xizmatlarga osongina qismlarga ajratish mumkin bo'lgan tarzda ishlab chiqilgan. Ushbu dastur yuklab olingan ma'lumotlarni qayta ishlash, turli tizimlardagi statistik ma'lumotlarni yig'ish va ularni tizim foydalanuvchilariga taqdim etish uchun javobgardir.
Ulagichlar va veb-ilova o'rtasida aloqa o'rnatish uchun biz qo'shimcha xizmatni yaratishimiz kerak edi, biz uni Connector Proxy deb nomladik. U Service Discovery va Task Scheduler funksiyalarini bajaradi. Ushbu xizmat har kecha har bir ulagich uchun ma'lumotlarni yig'ish vazifalarini bajaradi. Xizmat qatlamini yozish xabarlar brokerini ulashdan ko'ra osonroq edi va biz uchun natijani imkon qadar tezroq olish muhim edi.
Rivojlanishning soddaligi va tezligi uchun biz barcha xizmatlar Web API bo'lishiga qaror qildik. Bu tezda kontseptsiya isbotini yig'ish va butun dizayn ishlashini tekshirish imkonini berdi.
Alohida, juda murakkab vazifa turli xil hisoblardan ma'lumotlarni to'plash uchun kirishni o'rnatish edi, biz qaror qilganimizdek, foydalanuvchilar veb-interfeys orqali amalga oshirishlari kerak. U ikkita alohida bosqichdan iborat: birinchidan, foydalanuvchi OAuth orqali akkauntga kirish uchun token qo'shadi va keyin ma'lum bir hisobdan mijoz uchun ma'lumotlar to'plamini sozlaydi. OAuth orqali token olish zarur, chunki biz allaqachon yozganimizdek, saytda istalgan hisob qaydnomasiga kirish huquqini har doim ham topshirish mumkin emas.
Saytlardan hisobni tanlashning universal mexanizmini yaratish uchun biz o'zgartirilgan JSONEditor komponenti yordamida shaklga keltiriladigan JSON sxemasini qaytaruvchi API ulagichlariga usul qo'shishimiz kerak edi. Shunday qilib, foydalanuvchilar ma'lumotlarni yuklab olish uchun hisoblarni tanlashlari mumkin edi.
Saytlarda mavjud bo'lgan so'rov cheklovlariga rioya qilish uchun biz sozlamalar uchun so'rovlarni bitta token doirasida birlashtiramiz, lekin biz parallel ravishda turli tokenlarni qayta ishlashimiz mumkin.
Biz MongoDB-ni veb-ilova uchun ham, ulagichlar uchun ham yuklangan ma'lumotlarni saqlash joyi sifatida tanladik, bu bizga dasturning ob'ekt modeli har kuni o'zgarganda, rivojlanishning dastlabki bosqichlarida ma'lumotlar tuzilishi haqida ko'p tashvishlanmaslikka imkon berdi.
Tez orada biz barcha ma'lumotlar MongoDB-ga mos kelmasligini va, masalan, kundalik statistik ma'lumotlarni relyatsion ma'lumotlar bazasida saqlash qulayroq ekanligini bilib oldik. Shuning uchun, ma'lumotlar tuzilmasi relyatsion ma'lumotlar bazasi uchun ko'proq mos keladigan ulagichlar uchun biz PostgreSQL yoki MS SQL Serverdan saqlash sifatida foydalanishni boshladik.
Tanlangan arxitektura va texnologiyalar D1.Digital mahsulotini nisbatan tez qurish va ishga tushirish imkonini berdi. Ikki yillik mahsulotni ishlab chiqish davomida biz saytlarga 23 ta konnektorni ishlab chiqdik, uchinchi tomon API-lari bilan ishlashda bebaho tajribaga ega bo'ldik, har biri o'ziga xos bo'lgan turli saytlarning tuzoqlaridan qochishni o'rgandik va kamida 3 ta API rivojlanishiga hissa qo'shdik. saytlar, deyarli 15 000 ta kampaniyalar va 80 000 dan ortiq joylashtirishlar bo'yicha ma'lumotlarni avtomatik ravishda yuklab olgan holda, foydalanuvchilarning mahsulot ishlashi bo'yicha ko'plab fikr-mulohazalarini to'pladi va ushbu fikr-mulohazalar asosida mahsulotning asosiy jarayonini bir necha marta o'zgartirishga muvaffaq bo'ldi.
Yechim arxitekturasi 2.0
Rivojlanish boshlanganidan ikki yil o'tdi D1.Raqamli. Tizimga yukning doimiy ortib borishi va tobora ko'proq yangi ma'lumotlar manbalarining paydo bo'lishi asta-sekin mavjud yechim arxitekturasidagi muammolarni ochib berdi.
Birinchi muammo saytlardan yuklab olingan ma'lumotlar miqdori bilan bog'liq. Biz eng yirik saytlardan barcha kerakli ma'lumotlarni yig'ish va yangilash juda ko'p vaqtni talab qila boshlaganiga duch keldik. Masalan, AdRiver reklama tizimidan ma'lumotlarni yig'ish, uning yordamida biz ko'pchilik joylashtirishlar bo'yicha statistikani kuzatamiz, taxminan 12 soat davom etadi.
Ushbu muammoni hal qilish uchun biz saytlardan ma'lumotlarni yuklab olish uchun barcha turdagi hisobotlardan foydalanishni boshladik, biz saytlar bilan birgalikda ularning API-larini ishlab chiqishga harakat qilmoqdamiz, shunda uning ishlash tezligi bizning ehtiyojlarimizga javob beradi va ma'lumotlarni yuklab olishni iloji boricha parallellashtiramiz.
Yana bir muammo yuklab olingan ma'lumotlarni qayta ishlash bilan bog'liq. Endi, yangi joylashtirish statistik ma'lumotlari kelganda, ko'rsatkichlarni qayta hisoblashning ko'p bosqichli jarayoni ishga tushiriladi, bu xom ma'lumotlarni yuklash, har bir sayt uchun jamlangan ko'rsatkichlarni hisoblash, turli manbalardan olingan ma'lumotlarni bir-biri bilan solishtirish va kampaniya uchun umumiy ko'rsatkichlarni hisoblashni o'z ichiga oladi. Bu barcha hisob-kitoblarni amalga oshiradigan veb-ilovaga juda ko'p yuk olib keladi. Bir necha marta, qayta hisoblash jarayonida dastur serverdagi barcha xotirani iste'mol qildi, taxminan 10-15 Gb, bu foydalanuvchilarning tizim bilan ishlashiga eng yomon ta'sir ko'rsatdi.
Aniqlangan muammolar va mahsulotni yanada rivojlantirish bo'yicha ulkan rejalar bizni dastur arxitekturasini qayta ko'rib chiqish zarurligiga olib keldi.
Biz ulagichlardan boshladik.
Biz barcha ulagichlar bir xil modelga muvofiq ishlayotganini payqadik, shuning uchun biz konnektorni yaratish uchun siz faqat qadamlarning mantiqini dasturlashingiz kerak bo'lgan quvur liniyasi tizimini qurdik, qolganlari universal edi. Agar ba'zi bir ulagich takomillashtirishni talab qilsa, u holda ulagichni takomillashtirish bilan bir vaqtda uni darhol yangi ramkaga o'tkazamiz.
Shu bilan birga, biz Docker va Kubernetes-ga ulagichlarni o'rnatishni boshladik.
Biz Kubernetesga o'tishni ancha vaqt rejalashtirgan edik, CI/CD sozlamalari bilan tajriba o'tkazdik, lekin faqat bitta ulagich xatolik tufayli serverdagi 20 Gb dan ortiq xotirani egallab, boshqa jarayonlarni deyarli yo'q qila boshlaganida harakatlana boshladik. . Tekshiruv davomida ulagich Kubernetes klasteriga ko'chirildi va xato tuzatilgandan keyin ham u erda qoldi.
Biz Kubernetes qulay ekanligini tezda angladik va olti oy ichida biz eng ko'p resurslarni iste'mol qiladigan 7 konnektor va Proksi-server konnektorlarini ishlab chiqarish klasteriga o'tkazdik.
Ulagichlardan so'ng biz dasturning qolgan qismining arxitekturasini o'zgartirishga qaror qildik.
Asosiy muammo shundaki, ma'lumotlar konnektorlardan proksi-serverlarga katta partiyalarda keladi va keyin DANBoID-ga tushadi va qayta ishlash uchun markaziy veb-ilovaga yuboriladi. Ko'p sonli ko'rsatkichlarni qayta hisoblash tufayli dasturda katta yuk mavjud.
Shuningdek, foydalanuvchilar nima sodir bo'layotganini va nima uchun ma'lumotlar yig'ilmayotganini ko'rishlari uchun markaziy veb-ilovaga ulagichlar ichida sodir bo'lgan xatolar haqida ma'lumot yig'ish ishlarining holatini kuzatish va hisobot berish juda qiyin bo'ldi.
Ushbu muammolarni hal qilish uchun biz arxitektura 2.0 ni ishlab chiqdik.
Arxitekturaning yangi versiyasi o'rtasidagi asosiy farq shundaki, biz xizmatlar o'rtasida xabar almashish uchun Web API o'rniga RabbitMQ va MassTransit kutubxonasidan foydalanamiz. Buning uchun biz Connectors Proxy-ni deyarli butunlay qayta yozishimiz kerak edi, bu esa uni Connectors Hubga aylantirdi. Nom o'zgartirildi, chunki xizmatning asosiy roli endi so'rovlarni ulagichlarga va orqaga yo'naltirishda emas, balki ulagichlardan ko'rsatkichlar to'plamini boshqarishda.
Markaziy veb-ilovadan biz saytlardan joylashtirish va statistika haqidagi ma'lumotlarni alohida xizmatlarga ajratdik, bu esa keraksiz qayta hisob-kitoblardan xalos bo'lish va faqat allaqachon hisoblangan va jamlangan statistik ma'lumotlarni joylashtirish darajasida saqlash imkonini berdi. Biz, shuningdek, xom ma'lumotlarga asoslangan asosiy statistikani hisoblash mantiqini qayta yozdik va optimallashtirdik.
Shu bilan birga, biz barcha xizmatlar va ilovalarni Docker va Kubernetes’ga ko‘chirmoqdamiz, bu yechimni kengaytirish va boshqarishni qulayroq qilish uchun.
Biz hozir qayerdamiz
Proof-of-kontseptsiya arxitekturasi 2.0 mahsuloti D1.Raqamli tayyor va cheklangan konnektorlar to'plami bilan sinov muhitida ishlaydi. Yana 20 ta konnektorni yangi platformaga qayta yozish, maʼlumotlarning toʻgʻri yuklanganligini va barcha koʻrsatkichlar toʻgʻri hisoblanganligini tekshirish va butun dizaynni ishlab chiqarishga yoʻnaltirish qoladi.
Aslida, bu jarayon asta-sekin sodir bo'ladi va biz hamma narsani ishlashini ta'minlash uchun eski API bilan orqaga qarab muvofiqlikni qoldirishimiz kerak.
Bizning yaqin rejalarimiz yangi konnektorlarni ishlab chiqish, yangi tizimlar bilan integratsiya va ulangan saytlar va reklama tizimlaridan yuklab olingan ma'lumotlar to'plamiga qo'shimcha o'lchovlarni qo'shishni o'z ichiga oladi.
Shuningdek, biz barcha ilovalarni, shu jumladan markaziy veb-ilovani Docker va Kubernetes-ga o'tkazishni rejalashtirmoqdamiz. Yangi arxitektura bilan birgalikda bu iste'mol qilinadigan resurslarni joylashtirish, monitoring qilish va nazorat qilishni sezilarli darajada soddalashtiradi.
Yana bir g'oya - hozirda MongoDB da saqlanadigan statistik ma'lumotlarni saqlash uchun ma'lumotlar bazasini tanlash bilan tajriba o'tkazish. Biz allaqachon bir nechta yangi konnektorlarni SQL ma'lumotlar bazalariga o'tkazdik, ammo bu erda farq deyarli sezilmaydi va o'zboshimchalik bilan talab qilinishi mumkin bo'lgan kunlik jamlangan statistika uchun daromad juda jiddiy bo'lishi mumkin.
Umuman olganda, rejalar juda katta, kelinglar :)
R&D Dentsu Aegis Network Rossiya maqola mualliflari: Georgiy Ostapenko (), Mixail Kotsik ()
Manba: www.habr.com