Онлайн сурталчилгааны салбар аль болох технологийн дэвшилттэй, автоматжсан байх ёстой юм шиг санагддаг. Мэдээж Yandex, Mail.Ru, Google, Facebook зэрэг аварга том хүмүүс, салбарын мэргэжилтнүүд ажилладаг. Гэхдээ төгс төгөлдөрт хязгаар гэж байдаггүй бөгөөд автоматжуулах зүйл үргэлж байдаг.
Харилцааны бүлэг Dentsu Aegis Network Russia дижитал зар сурталчилгааны зах зээлийн хамгийн том тоглогч бөгөөд технологид идэвхтэй хөрөнгө оруулалт хийж, бизнесийн үйл явцыг оновчтой, автоматжуулахыг хичээж байна. Онлайн зар сурталчилгааны зах зээлийн шийдэгдээгүй асуудлын нэг бол янз бүрийн интернет платформуудаас зар сурталчилгааны кампанит ажлын статистик мэдээллийг цуглуулах ажил болжээ. Энэ асуудлын шийдэл нь эцсийн дүндээ бүтээгдэхүүнийг бий болгоход хүргэсэн 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 Network Board), энэ нь манай үйлчлүүлэгчдийн сурталчилгааны кампанит ажлын талаархи ерөнхий мэдээлэл бүхий вэб програм юм.
MVP-ийн хувьд төслийг хэрэгжүүлэх тал дээр аль болох хялбаршуулсан. Бид нэгтгэх платформуудын хязгаарлагдмал жагсаалтыг сонгосон. Эдгээр нь Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB зэрэг үндсэн платформууд болон Adriver, Weborama зар сурталчилгааны үндсэн системүүд байв.
API-ээр дамжуулан сайтуудын статистик мэдээлэлд хандахын тулд бид нэг бүртгэл ашигласан. Зар сурталчилгааны кампанит ажилд статистикийн автомат цуглуулгыг ашиглахыг хүссэн үйлчлүүлэгчийн бүлгийн менежер эхлээд сайтууд дээрх шаардлагатай сурталчилгааны кампанит ажилд хандах эрхийг платформын данс руу шилжүүлэх ёстой байв.
Дараагийнх нь системийн хэрэглэгч юм Данбо байршуулах (зар сурталчилгааны кампанит ажил, платформ, формат, байршуулах хугацаа, төлөвлөсөн үзүүлэлтүүд, төсөв гэх мэт) болон холбогдох сурталчилгааны кампанит ажлын тодорхойлогчийг агуулсан бүх мэдээллийг агуулсан тодорхой форматтай файлыг Excel системд байршуулах шаардлагатай болсон. зар сурталчилгааны систем дэх сайтууд болон тоолуур.
Энэ нь үнэнийг хэлэхэд аймшигтай харагдаж байв:
Татаж авсан өгөгдлийг мэдээллийн санд хадгалсан бөгөөд дараа нь тусдаа үйлчилгээнүүд тэдгээрээс сайтууд дээрх кампанит ажлын таниулбаруудыг цуглуулж, тэдгээрийн статистик мэдээллийг татаж авсан.
Сайт бүрийн хувьд тусдаа цонхны үйлчилгээг бичсэн бөгөөд энэ нь өдөрт нэг удаа сайтын API дахь нэг үйлчилгээний дансанд нэвтэрч, заасан кампанит ажлын ID-н статистик мэдээллийг татаж авдаг. Зар сурталчилгааны системд ижил зүйл тохиолдсон.
Татаж авсан өгөгдлийг интерфэйс дээр жижиг тохируулсан хяналтын самбар хэлбэрээр харуулав.
Бидний хувьд гэнэтийн байдлаар 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 үүсгэдэг. nested entity + 2-р түвшний үүрлэсэн аж ахуйн нэгжийн танигч +... Энэ арга нь бидэнд өөр өөр систем дэх сурталчилгааны кампанит ажлыг холбож, тэдгээрийн нарийвчилсан статистикийг татаж авах боломжийг олгосон.
Бид мөн өөр өөр платформ дээрх кампанит ажилд нэвтрэх асуудлыг шийдэх хэрэгтэй болсон. Дээр дурдсанчлан, кампанит ажилд нэвтрэх эрхийг тусдаа техникийн данс руу шилжүүлэх механизм нь үргэлж хэрэгждэггүй. Тиймээс бид токенууд болон эдгээр жетонуудыг шинэчлэх механизмуудыг ашиглан OAuth-ээр дамжуулан автоматаар зөвшөөрөл авах дэд бүтцийг хөгжүүлэх шаардлагатай болсон.
Сүүлд өгүүлэлд бид шийдлийн архитектур, хэрэгжилтийн техникийн нарийн ширийн зүйлийг илүү нарийвчлан тайлбарлахыг хичээх болно.
Шийдлийн архитектур 1.0
Шинэ бүтээгдхүүнийг хэрэгжүүлж эхлэхдээ бид шинэ сайтуудыг холбох боломжийг нэн даруй хангах шаардлагатай байгааг ойлгосон тул микро үйлчилгээний архитектурын замыг дагахаар шийдсэн.
Архитектурыг төлөвлөхдөө бид бүх гадаад системүүд - 1С, зар сурталчилгааны платформууд болон зар сурталчилгааны системүүдийн холбогчийг тусдаа үйлчилгээ болгон тусгаарласан.
Гол санаа нь сайтуудын бүх холбогч нь ижил API-тай бөгөөд сайтын API-г бидэнд тохиромжтой интерфэйс рүү авчирдаг адаптерууд юм.
Манай бүтээгдэхүүний төвд вэб программ байдаг бөгөөд энэ нь үйлчилгээнд хялбархан задалж болохуйц байдлаар хийгдсэн цул юм. Энэ програм нь татаж авсан өгөгдлийг боловсруулах, өөр өөр системүүдийн статистикийг нэгтгэх, системийн хэрэглэгчдэд үзүүлэх үүрэгтэй.
Холбогч болон вэб програмын хооронд холбогдохын тулд бид Холбогч прокси гэж нэрлэсэн нэмэлт үйлчилгээг бий болгох шаардлагатай болсон. Энэ нь Service Discovery болон Task Scheduler функцуудыг гүйцэтгэдэг. Энэ үйлчилгээ нь орой бүр холбогч бүрийн өгөгдөл цуглуулах ажлыг гүйцэтгэдэг. Үйлчилгээний давхарга бичих нь мессеж брокерыг холбохоос хамаагүй хялбар байсан бөгөөд бидний хувьд үр дүнг аль болох хурдан авах нь чухал байсан.
Хялбар, хурдацтай хөгжүүлэлтийн үүднээс бид бүх үйлчилгээг Web API байхаар шийдсэн. Энэ нь концепцийн нотлох баримтыг хурдан цуглуулж, дизайн бүхэлдээ ажиллаж байгаа эсэхийг шалгах боломжтой болсон.
Тусдаа, нэлээд төвөгтэй ажил бол өөр өөр данснаас мэдээлэл цуглуулах хандалтыг тохируулах явдал байсан бөгөөд бидний шийдсэнээр хэрэглэгчид вэб интерфэйсээр дамжуулан хийх ёстой. Энэ нь хоёр тусдаа алхмаас бүрдэнэ: эхлээд хэрэглэгч OAuth-ээр дамжуулан акаунт руу нэвтрэхийн тулд токен нэмж, дараа нь тодорхой данснаас үйлчлүүлэгчийн өгөгдөл цуглуулах тохиргоог хийнэ. OAuth-ээр дамжуулан жетон авах нь зайлшгүй шаардлагатай, учир нь бид аль хэдийн бичсэнчлэн сайт дээрх хүссэн данс руу нэвтрэх эрхийг шилжүүлэх боломжгүй байдаг.
Сайтуудаас акаунт сонгох бүх нийтийн механизмыг бий болгохын тулд бид JSONEditor бүрэлдэхүүн хэсгийг ашиглан маягт болгон хувиргасан JSON схемийг буцаадаг API холбогчдод аргыг нэмэх шаардлагатай болсон. Ингэснээр хэрэглэгчид өгөгдөл татаж авах дансаа сонгох боломжтой болсон.
Сайтууд дээр байгаа хүсэлтийн хязгаарлалтыг дагаж мөрдөхийн тулд бид тохиргооны хүсэлтийг нэг жетон дотор нэгтгэдэг боловч өөр өөр жетонуудыг зэрэгцүүлэн боловсруулж болно.
Бид MongoDB-ийг вэб програм болон холбогчдод ачаалагдсан өгөгдлийн сан болгон сонгосон нь програмын объект загвар өдөр бүр өөрчлөгддөг хөгжлийн эхний үе шатанд өгөгдлийн бүтцэд хэт санаа зовохгүй байх боломжийг олгосон.
Бид удалгүй MongoDB-д бүх өгөгдөл тохирохгүй байгааг олж мэдсэн бөгөөд жишээ нь өдөр тутмын статистикийг харилцааны мэдээллийн санд хадгалах нь илүү тохиромжтой юм. Тиймээс, өгөгдлийн бүтэц нь харилцааны өгөгдлийн санд илүү тохиромжтой холбогчдын хувьд бид PostgreSQL эсвэл MS SQL серверийг хадгалах газар болгон ашиглаж эхэлсэн.
Сонгосон архитектур, технологи нь D1.Digital бүтээгдэхүүнийг харьцангуй хурдан бүтээж, зах зээлд гаргах боломжийг бидэнд олгосон. Бүтээгдэхүүнийг хөгжүүлснээр бид хоёр жилийн хугацаанд сайтуудад 23 холбогч боловсруулж, гуравдагч талын API-уудтай ажиллах үнэлж баршгүй туршлага хуримтлуулж, өөр өөр сайтуудын бэрхшээлээс зайлсхийхэд суралцсан бөгөөд тус бүр өөрийн гэсэн API-г хөгжүүлэхэд хувь нэмэр оруулсан. сайтууд, бараг 3 кампанит ажлын мэдээллийг автоматаар татаж, 15 гаруй байршуулалт, бүтээгдэхүүний үйл ажиллагааны талаар хэрэглэгчдээс маш их санал хүсэлтийг цуглуулж, энэ санал хүсэлт дээр үндэслэн бүтээгдэхүүний үндсэн үйл явцыг хэд хэдэн удаа өөрчилж чадсан.
Шийдлийн архитектур 2.0
Бүтээн байгуулалт эхэлснээс хойш хоёр жил өнгөрчээ D1.Дижитал. Системийн ачаалал байнга нэмэгдэж, улам олон шинэ мэдээллийн эх үүсвэрүүд гарч ирж байгаа нь одоо байгаа шийдлийн архитектурт асуудлуудыг аажмаар илрүүлэв.
Эхний асуудал нь сайтуудаас татаж авсан өгөгдлийн хэмжээтэй холбоотой юм. Томоохон сайтуудаас шаардлагатай бүх мэдээллийг цуглуулж, шинэчлэхэд хэтэрхий их цаг зарцуулж эхэлсэнтэй бид тулгарч байсан. Жишээлбэл, ихэнх байршлын статистикийг хянадаг AdRiver зар сурталчилгааны системээс мэдээлэл цуглуулахад ойролцоогоор 12 цаг зарцуулдаг.
Энэ асуудлыг шийдэхийн тулд бид бүх төрлийн тайлангуудыг сайтуудаас өгөгдөл татаж авахын тулд ашиглаж эхэлсэн бөгөөд тэдгээрийн API-г сайтуудтай хамтран хөгжүүлж, үйл ажиллагааны хурд нь бидний хэрэгцээнд нийцэх, өгөгдөл татаж авах ажлыг аль болох зэрэгцүүлэхийг хичээж байна.
Өөр нэг асуудал бол татаж авсан өгөгдлийг боловсруулахтай холбоотой. Одоо байршлын шинэ статистик мэдээ ирэх үед хэмжигдэхүүнийг дахин тооцоолох олон үе шаттай үйл явц эхэлж байгаа бөгөөд үүнд түүхий өгөгдлийг ачаалах, сайт тус бүрийн нэгтгэсэн хэмжигдэхүүнийг тооцоолох, өөр өөр эх сурвалжаас авсан өгөгдлийг бие биетэйгээ харьцуулах, кампанит ажлын хураангуй хэмжигдэхүүнийг тооцоолох зэрэг орно. Энэ нь бүх тооцооллыг хийдэг вэб програм дээр маш их ачаалал үүсгэдэг. Хэд хэдэн удаа дахин тооцоолох явцад програм нь сервер дээрх бүх санах ойг, ойролцоогоор 10-15 ГБ-ыг зарцуулсан бөгөөд энэ нь хэрэглэгчдийн системтэй ажиллахад хамгийн муу нөлөө үзүүлсэн.
Тодорхойлсон асуудлууд, бүтээгдэхүүнийг цаашид хөгжүүлэх амбицтай төлөвлөгөө нь биднийг хэрэглээний архитектурыг эргэн харах хэрэгцээнд хүргэсэн.
Бид холбогчоос эхэлсэн.
Бүх холбогч нь ижил загварын дагуу ажилладаг болохыг бид анзаарсан тул холбогчийг бий болгохын тулд та зөвхөн алхамуудын логикийг програмчлах хэрэгтэй, үлдсэн хэсэг нь бүх нийтийнх байсан. Хэрэв холбогчийг сайжруулах шаардлагатай бол холбогчийг сайжруулж байх үед бид нэн даруй шинэ хүрээ рүү шилжүүлнэ.
Үүний зэрэгцээ бид Docker болон Kubernetes-д холбогчийг байрлуулж эхэлсэн.
Бид Кубернетес рүү шилжихээр нэлээд удаан төлөвлөж, CI/CD тохиргоог туршиж үзсэн боловч алдаа гарсны улмаас нэг холбогч сервер дээрх 20 ГБ-аас дээш санах ойг идэж, бусад процессуудыг бараг устгаж эхлэхэд л хөдөлж эхэлсэн. . Мөрдөн байцаалтын явцад холбогчийг Kubernetes кластер руу шилжүүлсэн бөгөөд алдааг зассан ч гэсэн тэндээ үлдсэн.
Бид Кубернетес нь тохиромжтой гэдгийг маш хурдан ойлгож, зургаан сарын дотор хамгийн их нөөц зарцуулдаг 7 холбогч болон Холбогч прокси-г үйлдвэрлэлийн кластерт шилжүүлсэн.
Холбогчийг дагаж, бид бусад програмын архитектурыг өөрчлөхөөр шийдсэн.
Гол асуудал нь өгөгдөл нь холбогчоос прокси руу том багц хэлбэрээр ирдэг бөгөөд дараа нь 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: Георгий Остапенко (), Михаил Коцик ()
Эх сурвалж: www.habr.com