Թվում է, թե առցանց գովազդի ոլորտը պետք է լինի հնարավորինս տեխնոլոգիապես զարգացած և ավտոմատացված։ Իհարկե, քանի որ այնտեղ աշխատում են այնպիսի հսկաներ և իրենց ոլորտի փորձագետներ, ինչպիսիք են Yandex-ը, Mail.Ru-ն, Google-ը և Facebook-ը։ Բայց, ինչպես պարզվեց, կատարելության սահման չկա, և միշտ կա ավտոմատացնելու բան:
Հաղորդակցության խումբ Dentsu Aegis Network Ռուսաստան թվային գովազդի շուկայում ամենամեծ խաղացողն է և ակտիվորեն ներդրումներ է կատարում տեխնոլոգիաների մեջ՝ փորձելով օպտիմալացնել և ավտոմատացնել իր բիզնես գործընթացները: Առցանց գովազդի շուկայի չլուծված խնդիրներից մեկը դարձել է տարբեր ինտերնետային հարթակներից գովազդային արշավների վերաբերյալ վիճակագրություն հավաքելու խնդիրը։ Այս խնդրի լուծումը, ի վերջո, հանգեցրեց արտադրանքի ստեղծմանը D1.Թվային (կարդացեք որպես DiVan), որի զարգացման մասին ուզում ենք խոսել։
Ինչու?
1. Ծրագրի մեկնարկի պահին շուկայում չկար ոչ մի պատրաստի արտադրանք, որը լուծեր գովազդային արշավների վերաբերյալ վիճակագրության հավաքագրման ավտոմատացման խնդիրը։ Սա նշանակում է, որ մեզանից բացի ոչ ոք չի բավարարի մեր կարիքները։
Ծառայությունները, ինչպիսիք են Improvado-ն, Roistat-ը, Supermetrics-ը, SegmentStream-ը, առաջարկում են ինտեգրում հարթակների, սոցիալական ցանցերի և Google Analitycs-ի հետ, ինչպես նաև հնարավորություն են տալիս ստեղծել վերլուծական վահանակներ՝ հարմար վերլուծության և գովազդային արշավների վերահսկման համար: Նախքան մեր արտադրանքի մշակումը սկսելը, մենք փորձեցինք օգտագործել այդ համակարգերից մի քանիսը կայքերից տվյալներ հավաքելու համար, բայց, ցավոք, դրանք չկարողացան լուծել մեր խնդիրները:
Հիմնական խնդիրն այն էր, որ փորձարկված ապրանքները հիմնված էին տվյալների աղբյուրների վրա, ցուցադրում էին տեղաբաշխման վիճակագրությունը ըստ կայքի և չէին ապահովում գովազդային արշավների վերաբերյալ վիճակագրությունը համախմբելու հնարավորություն: Այս մոտեցումը թույլ չտվեց մեզ տեսնել տարբեր կայքերի վիճակագրությունը մեկ տեղում և վերլուծել քարոզարշավի վիճակը որպես ամբողջություն:
Մյուս գործոնն այն էր, որ սկզբնական փուլում արտադրանքն ուղղված էր դեպի արևմտյան շուկա և չէր աջակցում ռուսական կայքերի հետ ինտեգրմանը։ Եվ այն կայքերի համար, որոնց հետ ինտեգրումն իրականացվել է, բոլոր անհրաժեշտ չափորոշիչները միշտ չէ, որ ներբեռնվում էին բավարար մանրամասնությամբ, և ինտեգրումը միշտ չէ, որ հարմար և թափանցիկ էր, հատկապես, երբ անհրաժեշտ էր ստանալ այնպիսի բան, որը չկա համակարգի միջերեսում:
Ընդհանուր առմամբ, մենք որոշեցինք չհարմարվել երրորդ կողմի արտադրանքներին, այլ սկսեցինք զարգացնել մեր սեփական...
2. Առցանց գովազդի շուկան տարեցտարի աճում է, իսկ 2018-ին գովազդային բյուջեներով առաջ է անցել ավանդաբար հեռուստագովազդի ամենամեծ շուկայից։ Այսպիսով, կա սանդղակ.
3. Ի տարբերություն հեռուստատեսային գովազդի շուկայի, որտեղ կոմերցիոն գովազդի վաճառքը մենաշնորհված է, ինտերնետում գործում են տարբեր չափերի գովազդային գույքագրման բազմաթիվ անհատ սեփականատերեր՝ սեփական գովազդային հաշիվներով։ Քանի որ գովազդային արշավը, որպես կանոն, գործում է միանգամից մի քանի կայքերում, գովազդային արշավի վիճակը հասկանալու համար անհրաժեշտ է հավաքել հաշվետվություններ բոլոր կայքերից և միավորել դրանք մեկ մեծ հաշվետվության մեջ, որը ցույց կտա ամբողջ պատկերը: Սա նշանակում է, որ կա օպտիմալացման ներուժ:
4. Մեզ թվում էր, որ ինտերնետում գովազդային գույքագրման տերերն արդեն ունեն վիճակագրություն հավաքելու և գովազդային աքաունթներում դրանք ցուցադրելու ենթակառուցվածք, և նրանք կկարողանան API տրամադրել այս տվյալների համար։ Սա նշանակում է, որ տեխնիկապես հնարավոր է դա իրականացնել։ Միանգամից ասենք, որ պարզվեց, որ այդքան էլ պարզ չէ։
Ընդհանուր առմամբ, նախագծի իրականացման բոլոր նախադրյալները մեզ համար ակնհայտ էին, և մենք վազեցինք նախագիծը կյանքի կոչելու...
Մեծ պլան
Սկզբից մենք ձևավորեցինք իդեալական համակարգի տեսլականը.
- 1C կորպորատիվ համակարգից գովազդային արշավները պետք է ավտոմատ կերպով բեռնվեն դրա մեջ իրենց անուններով, ժամանակաշրջաններով, բյուջեներով և տարբեր հարթակներում տեղաբաշխմամբ:
- Գովազդային արշավի յուրաքանչյուր տեղաբաշխման համար բոլոր հնարավոր վիճակագրությունը պետք է ավտոմատ կերպով ներբեռնվի այն կայքերից, որտեղ տեղաբաշխումը տեղի է ունենում, օրինակ՝ տպավորությունների, սեղմումների, դիտումների քանակը և այլն:
- Որոշ գովազդային արշավներ հետևվում են երրորդ կողմի մոնիտորինգի միջոցով, այսպես կոչված, գովազդային համակարգերի միջոցով, ինչպիսիք են Adriver, Weborama, DCM և այլն: Ռուսաստանում կա նաև արդյունաբերական ինտերնետ հաշվիչ՝ Mediascope ընկերությունը։ Մեր պլանի համաձայն, անկախ և արդյունաբերական մոնիտորինգի տվյալները նույնպես պետք է ավտոմատ կերպով բեռնվեն համապատասխան գովազդային արշավներում:
- Ինտերնետում գովազդային արշավների մեծ մասն ուղղված է որոշակի թիրախային գործողությունների (գնում, զանգահարում, գրանցում թեստային դրայվի համար և այլն), որոնք հետևվում են Google Analytics-ի միջոցով, և վիճակագրությունը, որի համար նույնպես կարևոր է արշավի կարգավիճակը և ըմբռնումը: պետք է բեռնվի մեր գործիքի մեջ:
Առաջին անիծված միակ
Հաշվի առնելով մեր հավատարմությունը ծրագրային ապահովման մշակման ճկուն սկզբունքներին (արագաշարժ, ամեն ինչ), մենք որոշեցինք նախ մշակել MVP, այնուհետև շարունակաբար շարժվել դեպի նախատեսված նպատակը:
Մենք որոշեցինք ստեղծել MVP մեր արտադրանքի հիման վրա DANBo (Dentsu Aegis Network Board), որը մեր հաճախորդների գովազդային արշավների վերաբերյալ ընդհանուր տեղեկություններով վեբ հավելված է:
MVP-ի համար նախագիծը հնարավորինս պարզեցվել է իրականացման առումով: Մենք ընտրել ենք հարթակների սահմանափակ ցանկ ինտեգրման համար: Սրանք այն հիմնական հարթակներն էին, ինչպիսիք են Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, և հիմնական գովազդային համակարգերը՝ Adriver և Weborama:
API-ի միջոցով կայքերի վիճակագրություն մուտք գործելու համար մենք օգտագործեցինք մեկ հաշիվ: Հաճախորդների խմբի մենեջերը, ով ցանկանում էր օգտագործել գովազդային արշավի վրա վիճակագրության ավտոմատ հավաքագրումը, նախ պետք է պլատֆորմի հաշվին փոխանցեր կայքերի անհրաժեշտ գովազդային արշավների հասանելիությունը:
Հաջորդը համակարգի օգտագործողն է ԴԱՆԲՈ պետք է ներբեռներ որոշակի ձևաչափի ֆայլ Excel համակարգ, որը պարունակում էր տեղաբաշխման մասին ամբողջ տեղեկատվությունը (գովազդային արշավ, հարթակ, ձևաչափ, տեղաբաշխման ժամկետ, պլանավորված ցուցանիշներ, բյուջե և այլն) և համապատասխան գովազդային արշավների նույնացուցիչները: կայքեր և հաշվիչներ գովազդային համակարգերում:
Անկեղծ ասած, սարսափելի տեսք ուներ.
Ներբեռնված տվյալները պահվել են տվյալների բազայում, այնուհետև առանձին ծառայություններ հավաքել են կայքերի քարոզարշավի նույնացուցիչները դրանցից և ներբեռնել դրանց վերաբերյալ վիճակագրությունը:
Յուրաքանչյուր կայքի համար գրվել է առանձին windows ծառայություն, որը օրական մեկ անգամ անցնում է կայքի API-ի մեկ սպասարկման հաշվի տակ և ներբեռնում վիճակագրություն նշված քարոզարշավի ID-ների համար: Նույնը տեղի ունեցավ գովազդային համակարգերի դեպքում:
Ներբեռնված տվյալները ցուցադրվել են ինտերֆեյսի վրա փոքր հատուկ վահանակի տեսքով.
Մեզ համար անսպասելիորեն MVP-ն սկսեց աշխատել և սկսեց ներբեռնել ինտերնետում գովազդային արշավների ընթացիկ վիճակագրությունը: Մենք համակարգը ներդրել ենք մի քանի հաճախորդների վրա, բայց երբ փորձում էինք մասշտաբել, բախվեցինք լուրջ խնդիրների.
- Հիմնական խնդիրը համակարգում բեռնման համար տվյալների պատրաստման բարդությունն էր: Բացի այդ, տեղադրման տվյալները պետք է փոխարկվեին խիստ ֆիքսված ձևաչափի նախքան բեռնումը: Ներբեռնման ֆայլում անհրաժեշտ էր ներառել տարբեր կայքերի իդենտիֆիկատորներ: Մենք կանգնած ենք այն փաստի հետ, որ տեխնիկապես ոչ պատրաստված օգտատերերի համար շատ դժվար է բացատրել, թե որտեղ կարելի է գտնել այս նույնացուցիչները կայքում և որտեղ պետք է դրանք մուտքագրվեն ֆայլում: Հաշվի առնելով կայքերում արշավներ իրականացնող գերատեսչությունների աշխատակիցների թիվը և շրջանառությունը, դա հանգեցրեց մեր կողմից հսկայական աջակցության, ինչից մենք բացարձակապես գոհ չէինք:
- Մյուս խնդիրն այն էր, որ ոչ բոլոր գովազդային հարթակներում ունեին գովազդային արշավների հասանելիությունը այլ հաշիվներին պատվիրակելու մեխանիզմներ: Բայց նույնիսկ եթե պատվիրակման մեխանիզմը հասանելի լիներ, ոչ բոլոր գովազդատուներն էին ցանկանում իրենց արշավներին հասանելիություն տրամադրել երրորդ կողմի հաշիվներին:
- Կարևոր գործոն էր այն վրդովմունքը, որն առաջացրել էր օգտատերերի մոտ այն փաստը, որ բոլոր պլանավորված ցուցանիշները և տեղաբաշխման մանրամասները, որոնք նրանք արդեն մուտքագրում են մեր 1C հաշվապահական համակարգ, նրանք պետք է նորից մուտքագրեն: ԴԱՆԲՈ.
Սա մեզ գաղափար տվեց, որ տեղաբաշխման մասին տեղեկատվության առաջնային աղբյուրը պետք է լինի մեր 1C համակարգը, որտեղ բոլոր տվյալները մուտքագրվում են ճշգրիտ և ժամանակին (այստեղ հարցն այն է, որ հաշիվ-ապրանքագրերը ստեղծվում են 1C տվյալների հիման վրա, ուստի տվյալների ճիշտ մուտքագրումը 1C առաջնահերթություն է բոլորի համար KPI): Ահա թե ինչպես է առաջացել համակարգի նոր հայեցակարգ...
Հայեցակարգ
Առաջին բանը, որ մենք որոշեցինք անել, Ինտերնետում գովազդային արշավների վիճակագրության հավաքագրման համակարգը առանձնացնելն էր առանձին ապրանքի մեջ. D1.Թվային.
Նոր հայեցակարգում մենք որոշեցինք ներբեռնել D1.Թվային տեղեկատվություն գովազդային արշավների և դրանցում տեղաբաշխումների մասին 1C-ից, և այնուհետև վիճակագրությունը կայքերից և AdServing համակարգերից դեպի այդ տեղաբաշխումները: Ենթադրվում էր, որ սա զգալիորեն կպարզեցներ օգտատերերի կյանքը (և, ինչպես միշտ, ավելի շատ աշխատանք կավելացներ ծրագրավորողներին) և կնվազեցներ աջակցության քանակը:
Առաջին խնդիրը, որին հանդիպեցինք, կազմակերպչական բնույթ ուներ և կապված էր այն բանի հետ, որ մենք չկարողացանք գտնել բանալի կամ նշան, որով մենք կարող էինք համեմատել տարբեր համակարգերի կազմակերպությունները 1C-ից արշավների և տեղաբաշխումների հետ: Փաստն այն է, որ մեր ընկերությունում գործընթացը նախագծված է այնպես, որ գովազդային արշավները տարբեր մարդկանց կողմից մուտքագրվում են տարբեր համակարգեր (մեդիա պլանավորողներ, գնումներ և այլն):
Այս խնդիրը լուծելու համար մենք պետք է հայտնագործեինք եզակի հեշավորված բանալի՝ DANBoID, որը կկապեր տարբեր համակարգերի սուբյեկտները միմյանց հետ, և որը կարող էր բավականին հեշտությամբ և եզակի նույնականացվել ներբեռնված տվյալների հավաքածուներում: Այս նույնացուցիչը ստեղծվում է ներքին 1C համակարգում յուրաքանչյուր առանձին տեղաբաշխման համար և փոխանցվում է բոլոր կայքերի և բոլոր AdServing համակարգերի արշավներին, տեղաբաշխումներին և հաշվիչներին: Բոլոր տեղաբաշխումներում DANBoID-ի տեղադրման պրակտիկայի իրականացումը որոշ ժամանակ պահանջեց, բայց մեզ հաջողվեց դա անել :)
Հետո պարզեցինք, որ ոչ բոլոր կայքերն ունեն API՝ ավտոմատ կերպով վիճակագրություն հավաքելու համար, և նույնիսկ նրանք, որոնք ունեն API, այն չի վերադարձնում բոլոր անհրաժեշտ տվյալները։
Այս փուլում մենք որոշեցինք զգալիորեն կրճատել ինտեգրման համար նախատեսված հարթակների ցանկը և կենտրոնանալ այն հիմնական հարթակների վրա, որոնք ներգրավված են գովազդային արշավների ճնշող մեծամասնության մեջ։ Այս ցանկը ներառում է գովազդային շուկայի բոլոր խոշոր խաղացողները (Google, Yandex, Mail.ru), սոցիալական ցանցերը (VK, Facebook, Twitter), խոշոր AdServing և վերլուծական համակարգեր (DCM, Adriver, Weborama, Google Analytics) և այլ հարթակներ:
Մեր ընտրած կայքերի մեծ մասն ուներ API, որն ապահովում էր մեզ անհրաժեշտ չափումները: Այն դեպքերում, երբ չկար API կամ այն չէր պարունակում անհրաժեշտ տվյալներ, մենք օգտագործում էինք հաշվետվություններ, որոնք ուղարկվում էին ամեն օր մեր գրասենյակի էլ. մեզ համար).
Տարբեր կայքերի տվյալները վերլուծելիս պարզեցինք, որ տարբեր համակարգերում սուբյեկտների հիերարխիան նույնը չէ: Ավելին, տեղեկատվությունը տարբեր համակարգերից պետք է ներբեռնվի տարբեր մանրամասներով:
Այս խնդիրը լուծելու համար մշակվել է SubDANBoID հայեցակարգը: SubDANBoID-ի գաղափարը բավականին պարզ է, մենք կայքում նշում ենք արշավի հիմնական սուբյեկտը ստեղծված DANBoID-ով, և մենք վերբեռնում ենք բոլոր ներդիր սուբյեկտները կայքի եզակի նույնացուցիչներով և ձևավորում SubDANBoID DANBoID սկզբունքի համաձայն + առաջին մակարդակի նույնացուցիչ: nested entity + identifier of the second level nested entity +... Այս մոտեցումը մեզ թույլ տվեց միացնել գովազդային արշավները տարբեր համակարգերում և ներբեռնել դրանց վերաբերյալ մանրամասն վիճակագրություն:
Պետք է լուծեինք նաև տարբեր հարթակներում արշավների հասանելիության խնդիրը։ Ինչպես վերևում գրեցինք, քարոզարշավի մուտքը առանձին տեխնիկական հաշվին փոխանցելու մեխանիզմը միշտ չէ, որ կիրառելի է: Հետևաբար, մենք պետք է մշակեինք OAuth-ի միջոցով ավտոմատ թույլտվության ենթակառուցվածք՝ օգտագործելով նշաններ և մեխանիզմներ՝ այդ նշանները թարմացնելու համար:
Հետագայում հոդվածում մենք կփորձենք ավելի մանրամասն նկարագրել լուծման ճարտարապետությունը և իրականացման տեխնիկական մանրամասները:
Լուծման ճարտարապետություն 1.0
Նոր պրոդուկտի ներդրումը սկսելիս մենք հասկացանք, որ անմիջապես անհրաժեշտ է ապահովել նոր կայքերի միացման հնարավորությունը, ուստի որոշեցինք գնալ միկրոսերվիսային ճարտարապետության ճանապարհով։
Ճարտարապետությունը նախագծելիս մենք բոլոր արտաքին համակարգերին՝ 1C-ին, գովազդային հարթակներին և գովազդային համակարգերին, բաժանեցինք առանձին ծառայությունների միակցիչները:
Հիմնական գաղափարն այն է, որ կայքերի բոլոր միակցիչները ունեն նույն API-ն և ադապտերներ են, որոնք կայքի API-ն բերում են մեզ համար հարմար ինտերֆեյսի:
Մեր արտադրանքի կենտրոնում վեբ հավելվածն է, որը մոնոլիտ է, որը նախագծված է այնպես, որ այն հեշտությամբ կարելի է ապամոնտաժել ծառայությունների: Այս հավելվածը պատասխանատու է ներբեռնված տվյալների մշակման, տարբեր համակարգերից վիճակագրություն հավաքելու և դրանք համակարգի օգտատերերին ներկայացնելու համար:
Միակցիչների և վեբ հավելվածի միջև հաղորդակցվելու համար մենք պետք է ստեղծեինք լրացուցիչ ծառայություն, որը մենք անվանեցինք Connector Proxy: Այն իրականացնում է ծառայության հայտնաբերման և առաջադրանքների ժամանակացույցի գործառույթները: Այս ծառայությունն ամեն գիշեր կատարում է տվյալների հավաքագրման առաջադրանքներ յուրաքանչյուր միակցիչի համար: Ծառայության շերտ գրելն ավելի հեշտ էր, քան հաղորդագրության բրոքերին միացնելը, և մեզ համար կարևոր էր հնարավորինս արագ արդյունք ստանալ:
Զարգացման պարզության և արագության համար մենք նաև որոշեցինք, որ բոլոր ծառայությունները կլինեն վեբ API: Սա հնարավորություն տվեց արագ հավաքել հայեցակարգի ապացույց և ստուգել, որ ամբողջ դիզայնը աշխատում է:
Առանձին, բավականին բարդ խնդիր էր տարբեր հաշիվներից տվյալների հավաքագրման հասանելիության կարգավորումը, որը, ինչպես մենք որոշեցինք, պետք է իրականացնեն օգտվողները վեբ ինտերֆեյսի միջոցով: Այն բաղկացած է երկու առանձին քայլերից. նախ, օգտվողը ավելացնում է նշան OAuth-ի միջոցով հաշիվ մուտք գործելու համար, այնուհետև կարգավորում է հաճախորդի համար տվյալների հավաքագրումը կոնկրետ հաշվից: OAuth-ի միջոցով նշան ստանալը անհրաժեշտ է, քանի որ, ինչպես արդեն գրել ենք, միշտ չէ, որ հնարավոր է պատվիրակել մուտքը դեպի ցանկալի հաշիվ կայքում:
Կայքերից հաշիվ ընտրելու ունիվերսալ մեխանիզմ ստեղծելու համար մենք պետք է API-ի միակցիչներին ավելացնեինք մեթոդ, որը վերադարձնում է JSON Schema-ն, որը ձևափոխվում է JSONEditor-ի փոփոխված բաղադրիչի միջոցով: Այս կերպ օգտատերերը կարողացել են ընտրել այն հաշիվները, որոնցից կարող են ներբեռնել տվյալները:
Կայքերում առկա հարցումների սահմանափակումներին համապատասխանելու համար մենք միավորում ենք կարգավորումների հարցումները մեկ նշանի շրջանակներում, բայց կարող ենք զուգահեռ մշակել տարբեր նշաններ:
Մենք ընտրեցինք MongoDB-ն որպես բեռնված տվյալների պահեստ՝ ինչպես վեբ հավելվածի, այնպես էլ միակցիչների համար, ինչը թույլ տվեց մեզ շատ չանհանգստանալ տվյալների կառուցվածքի մասին զարգացման սկզբնական փուլերում, երբ հավելվածի օբյեկտի մոդելը փոխվում է ամեն օր:
Շուտով մենք պարզեցինք, որ ոչ բոլոր տվյալները լավ են տեղավորվում MongoDB-ում և, օրինակ, ավելի հարմար է ամենօրյա վիճակագրությունը պահել հարաբերական տվյալների բազայում: Հետևաբար, միակցիչների համար, որոնց տվյալների կառուցվածքն ավելի հարմար է հարաբերական տվյալների բազայի համար, մենք սկսեցինք օգտագործել PostgreSQL կամ MS SQL Server որպես պահեստ:
Ընտրված ճարտարապետությունն ու տեխնոլոգիաները մեզ թույլ տվեցին համեմատաբար արագ կառուցել և գործարկել D1.Digital արտադրանքը: Արտադրանքի մշակման երկու տարվա ընթացքում մենք մշակեցինք կայքերի 23 միակցիչ, ձեռք բերեցինք երրորդ կողմի API-ների հետ աշխատելու անգնահատելի փորձ, սովորեցինք խուսափել տարբեր կայքերի թակարդներից, որոնք յուրաքանչյուրն ուներ իր սեփականը, նպաստեցինք առնվազն 3 API-ի զարգացմանը: կայքերը, ավտոմատ կերպով ներբեռնելով տեղեկատվություն գրեթե 15 արշավների և ավելի քան 000 տեղաբաշխումների մասին, օգտատերերից շատ արձագանքներ են հավաքել արտադրանքի աշխատանքի վերաբերյալ և կարողացել են մի քանի անգամ փոխել արտադրանքի հիմնական գործընթացը՝ հիմնվելով այս կարծիքի վրա:
Լուծման ճարտարապետություն 2.0
Զարգացման մեկնարկից անցել է երկու տարի D1.Թվային. Համակարգի վրա բեռի մշտական աճը և տվյալների ավելի ու ավելի նոր աղբյուրների ի հայտ գալը աստիճանաբար բացահայտեցին առկա լուծումների ճարտարապետության խնդիրները:
Առաջին խնդիրը կապված է կայքերից ներբեռնվող տվյալների քանակի հետ։ Մենք կանգնած էինք այն փաստի հետ, որ խոշորագույն կայքերից բոլոր անհրաժեշտ տվյալների հավաքագրումն ու թարմացումը սկսեց չափազանց շատ ժամանակ խլել: Օրինակ, AdRiver գովազդային համակարգից տվյալների հավաքագրումը, որով մենք հետևում ենք տեղաբաշխումների մեծ մասի վիճակագրությանը, տևում է մոտ 12 ժամ:
Այս խնդիրը լուծելու համար մենք սկսել ենք օգտագործել բոլոր տեսակի հաշվետվությունները՝ կայքերից տվյալներ ներբեռնելու համար, կայքերի հետ միասին փորձում ենք զարգացնել դրանց API-ն, որպեսզի դրա գործողության արագությունը համապատասխանի մեր կարիքներին և հնարավորինս զուգահեռաբար ներբեռնի տվյալների ներբեռնումը։
Մեկ այլ խնդիր վերաբերում է ներբեռնված տվյալների մշակմանը: Այժմ, երբ տեղաբաշխման նոր վիճակագրությունը գալիս է, գործարկվում է չափումների վերահաշվարկի բազմափուլ գործընթաց, որը ներառում է չմշակված տվյալների բեռնում, յուրաքանչյուր կայքի համար ագրեգացված չափումների հաշվարկ, տարբեր աղբյուրների տվյալները միմյանց հետ համեմատելը և արշավի ամփոփ չափումների հաշվարկը: Սա մեծ բեռ է առաջացնում վեբ հավելվածի վրա, որը կատարում է բոլոր հաշվարկները: Մի քանի անգամ, վերահաշվարկի ընթացքում, հավելվածը սպառել է սերվերի ամբողջ հիշողությունը՝ մոտ 10-15 ԳԲ, ինչը ամենավնասակար ազդեցությունն է ունեցել համակարգի հետ օգտատերերի աշխատանքի վրա։
Հայտնաբերված խնդիրները և արտադրանքի հետագա զարգացման հավակնոտ ծրագրերը մեզ հանգեցրին հավելվածի ճարտարապետությունը վերանայելու անհրաժեշտությանը:
Մենք սկսեցինք միակցիչներով:
Մենք նկատեցինք, որ բոլոր միակցիչները աշխատում են նույն մոդելի համաձայն, ուստի մենք կառուցեցինք խողովակաշարի շրջանակ, որում միակցիչ ստեղծելու համար անհրաժեշտ էր միայն ծրագրավորել քայլերի տրամաբանությունը, մնացածը ունիվերսալ էր: Եթե ինչ-որ միակցիչ բարելավում է պահանջում, ապա մենք անմիջապես այն տեղափոխում ենք նոր շրջանակ՝ միակցիչի կատարելագործման հետ միաժամանակ:
Միևնույն ժամանակ, մենք սկսեցինք միացումներ տեղադրել Docker-ի և Kubernetes-ի համար:
Մենք բավականին երկար պլանավորեցինք տեղափոխությունը Kubernetes, փորձարկեցինք CI/CD պարամետրերով, բայց սկսեցինք շարժվել միայն այն ժամանակ, երբ մի միակցիչը, սխալի պատճառով, սկսեց խժռել ավելի քան 20 ԳԲ հիշողություն սերվերի վրա՝ գործնականում սպանելով այլ գործընթացներ։ . Հետաքննության ընթացքում միակցիչը տեղափոխվեց Kubernetes կլաստեր, որտեղ այն ի վերջո մնաց նույնիսկ սխալը շտկելուց հետո:
Շատ արագ մենք հասկացանք, որ Kubernetes-ը հարմար է, և վեց ամսվա ընթացքում մենք 7 միակցիչ և Connectors Proxy-ն, որոնք սպառում են ամենաշատ ռեսուրսները, փոխանցեցինք արտադրական կլաստերին:
Հետևելով միակցիչներին, մենք որոշեցինք փոխել մնացած հավելվածի ճարտարապետությունը:
Հիմնական խնդիրն այն էր, որ տվյալները գալիս են միակցիչներից դեպի վստահված անձինք մեծ խմբաքանակներով, այնուհետև հարվածում են DANBoID-ին և ուղարկվում կենտրոնական վեբ հավելված՝ մշակման համար: Չափման վերահաշվարկների մեծ քանակի պատճառով հավելվածի վրա մեծ ծանրաբեռնվածություն կա:
Բավականին դժվար էր նաև վերահսկել անհատական տվյալների հավաքագրման աշխատանքների կարգավիճակը և հաղորդել սխալների մասին, որոնք տեղի են ունենում կենտրոնական վեբ հավելվածի միակցիչներում, որպեսզի օգտվողները կարողանան տեսնել, թե ինչ է տեղի ունենում և ինչու չեն հավաքվում տվյալները:
Այս խնդիրները լուծելու համար մենք մշակեցինք ճարտարապետություն 2.0:
Ճարտարապետության նոր տարբերակի հիմնական տարբերությունն այն է, որ Web API-ի փոխարեն մենք օգտագործում ենք RabbitMQ և MassTransit գրադարանը՝ ծառայությունների միջև հաղորդագրություններ փոխանակելու համար։ Դա անելու համար մենք ստիպված էինք գրեթե ամբողջությամբ վերաշարադրել Connectors Proxy-ը՝ դարձնելով այն Connectors Hub: Անունը փոխվեց, քանի որ ծառայության հիմնական դերն այլևս ոչ թե կապակցիչներ և հետադարձ հարցումներ ուղարկելն է, այլ միակցիչներից չափումների հավաքագրումը կառավարելը։
Կենտրոնական վեբ հավելվածից մենք կայքերից առանձնացրել ենք տեղաբաշխումների և վիճակագրության մասին տեղեկությունները առանձին ծառայությունների, ինչը հնարավորություն է տվել ազատվել ավելորդ վերահաշվարկներից և տեղաբաշխման մակարդակում պահել միայն արդեն հաշվարկված և ագրեգացված վիճակագրությունը: Մենք նաև վերագրել և օպտիմիզացրել ենք հում տվյալների հիման վրա հիմնական վիճակագրությունը հաշվարկելու տրամաբանությունը:
Միևնույն ժամանակ, մենք տեղափոխում ենք բոլոր ծառայություններն ու հավելվածները Docker և Kubernetes՝ լուծումն ավելի հեշտ մասշտաբային և ավելի հարմար կառավարելու համար:
Որտեղ ենք մենք հիմա
Կոնցեպտի ապացույցի ճարտարապետություն 2.0 արտադրանք D1.Թվային պատրաստ է և աշխատում է թեստային միջավայրում՝ միակցիչների սահմանափակ հավաքածուով: Մնում է ևս 20 միակցիչ վերաշարադրել նոր հարթակում, ստուգել, որ տվյալները ճիշտ են բեռնված, և բոլոր չափումները ճիշտ են հաշվարկված, և ամբողջ դիզայնը թողարկել արտադրության մեջ:
Փաստորեն, այս գործընթացը տեղի կունենա աստիճանաբար, և մենք ստիպված կլինենք թողնել հետընթաց համատեղելիությունը հին API-ների հետ, որպեսզի ամեն ինչ աշխատի:
Մեր անմիջական ծրագրերը ներառում են նոր միակցիչների մշակում, նոր համակարգերի հետ ինտեգրում և միացված կայքերից և գովազդային համակարգերից ներբեռնվող տվյալների հավաքածուին հավելյալ չափումների ավելացում:
Մենք նաև նախատեսում ենք բոլոր հավելվածները, ներառյալ կենտրոնական վեբ հավելվածը, տեղափոխել Docker և Kubernetes: Համակցված նոր ճարտարապետության հետ՝ սա զգալիորեն կհեշտացնի սպառված ռեսուրսների տեղակայումը, մոնիտորինգը և վերահսկումը:
Մեկ այլ գաղափար է փորձարկել վիճակագրության պահպանման տվյալների բազայի ընտրությունը, որը ներկայումս պահվում է MongoDB-ում: Մենք արդեն մի քանի նոր միակցիչներ ենք փոխանցել SQL տվյալների շտեմարաններին, բայց այնտեղ տարբերությունը գրեթե աննկատ է, և օրվա ագրեգացված վիճակագրության դեպքում, որը կարող է պահանջվել կամայական ժամանակահատվածի համար, շահույթը կարող է բավականին լուրջ լինել:
Ընդհանրապես ծրագրերը մեծ են, անցնենք առաջ :)
Հոդվածի հեղինակներ R&D Dentsu Aegis Network Russia. Գեորգի Օստապենկո (), Միխայիլ Կոցիկ ()
Source: www.habr.com