เรารวบรวมข้อมูลเกี่ยวกับแคมเปญโฆษณาจากเว็บไซต์ออนไลน์อย่างไร (เส้นทางที่ยุ่งยากสู่ผลิตภัณฑ์)

ดูเหมือนว่าสาขาการโฆษณาออนไลน์ควรมีความก้าวหน้าทางเทคโนโลยีและเป็นอัตโนมัติที่สุดเท่าที่จะเป็นไปได้ แน่นอนว่าเพราะยักษ์ใหญ่และผู้เชี่ยวชาญในสาขาของตนเช่น 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)ซึ่งเป็นเว็บแอปพลิเคชันที่มีข้อมูลทั่วไปเกี่ยวกับแคมเปญโฆษณาของลูกค้าของเรา

สำหรับ MVP โครงการนี้ได้รับการทำให้ง่ายขึ้นมากที่สุดเท่าที่จะเป็นไปได้ในแง่ของการนำไปปฏิบัติ เราได้เลือกรายการแพลตฟอร์มที่จำกัดสำหรับการบูรณาการ เหล่านี้เป็นแพลตฟอร์มหลัก เช่น Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB และระบบโฆษณาหลัก Adriver และ Weborama

ในการเข้าถึงสถิติบนไซต์ผ่าน API เราใช้บัญชีเดียว ผู้จัดการกลุ่มลูกค้าที่ต้องการใช้การรวบรวมสถิติอัตโนมัติในแคมเปญโฆษณาจะต้องมอบหมายการเข้าถึงแคมเปญโฆษณาที่จำเป็นบนไซต์ให้กับบัญชีแพลตฟอร์มก่อน

ถัดไปคือผู้ใช้ระบบ ดันโบ ต้องอัปโหลดไฟล์ในรูปแบบที่กำหนดลงในระบบ Excel ซึ่งมีข้อมูลทั้งหมดเกี่ยวกับตำแหน่ง (แคมเปญโฆษณา แพลตฟอร์ม รูปแบบ ระยะเวลาตำแหน่ง ตัวบ่งชี้ที่วางแผนไว้ งบประมาณ ฯลฯ) และตัวระบุของแคมเปญโฆษณาที่เกี่ยวข้องบน ไซต์และเคาน์เตอร์ในระบบการโฆษณา

มันดูตรงไปตรงมาและน่ากลัว:

ข้อมูลที่ดาวน์โหลดจะถูกบันทึกลงในฐานข้อมูล จากนั้นบริการที่แยกจากกันจะรวบรวมตัวระบุแคมเปญบนไซต์ต่างๆ และสถิติที่ดาวน์โหลดไว้

สำหรับแต่ละไซต์ จะมีการเขียนบริการ Windows แยกต่างหาก ซึ่งวันละครั้งจะอยู่ภายใต้บัญชีบริการเดียวใน API ของไซต์ และดาวน์โหลดสถิติสำหรับรหัสแคมเปญที่ระบุ สิ่งเดียวกันนี้เกิดขึ้นกับระบบการโฆษณา

ข้อมูลที่ดาวน์โหลดจะแสดงบนอินเทอร์เฟซในรูปแบบของแดชบอร์ดแบบกำหนดเองขนาดเล็ก:

โดยไม่คาดคิดสำหรับเรา MVP เริ่มทำงานและเริ่มดาวน์โหลดสถิติปัจจุบันเกี่ยวกับแคมเปญโฆษณาบนอินเทอร์เน็ต เราใช้ระบบกับไคลเอนต์หลายราย แต่เมื่อพยายามขยาย เราพบปัญหาร้ายแรง:

• ปัญหาหลักคือความซับซ้อนในการเตรียมข้อมูลเพื่อโหลดเข้าระบบ นอกจากนี้ ข้อมูลตำแหน่งจะต้องถูกแปลงเป็นรูปแบบที่ตายตัวอย่างเคร่งครัดก่อนที่จะโหลด จำเป็นต้องรวมตัวระบุเอนทิตีจากไซต์ต่างๆ ในไฟล์ดาวน์โหลด เรากำลังเผชิญกับความจริงที่ว่าเป็นเรื่องยากมากสำหรับผู้ใช้ที่ไม่ผ่านการฝึกอบรมทางเทคนิคในการอธิบายว่าจะหาตัวระบุเหล่านี้ได้ที่ไหนบนไซต์และต้องป้อนไฟล์ที่ใดในไฟล์ เมื่อพิจารณาถึงจำนวนพนักงานในแผนกที่ดำเนินแคมเปญบนไซต์และการหมุนเวียน ส่งผลให้เราได้รับการสนับสนุนจำนวนมาก ซึ่งเราไม่พอใจอย่างยิ่ง
• ปัญหาอีกประการหนึ่งคือไม่ใช่ว่าทุกแพลตฟอร์มโฆษณาจะมีกลไกในการมอบหมายการเข้าถึงแคมเปญโฆษณาให้กับบัญชีอื่น แต่ถึงแม้จะมีกลไกการมอบหมาย ผู้ลงโฆษณาบางรายก็ไม่เต็มใจที่จะให้สิทธิ์การเข้าถึงแคมเปญของตนแก่บัญชีบุคคลที่สาม
• ปัจจัยสำคัญคือความขุ่นเคืองที่เกิดขึ้นในหมู่ผู้ใช้เนื่องจากข้อเท็จจริงที่ว่าตัวบ่งชี้ที่วางแผนไว้และรายละเอียดตำแหน่งทั้งหมดที่พวกเขาเข้าสู่ระบบบัญชี 1C ของเราแล้วพวกเขาจะต้องกลับเข้ามาใหม่ ดันโบ.

สิ่งนี้ทำให้เรามีแนวคิดว่าแหล่งข้อมูลหลักเกี่ยวกับตำแหน่งควรเป็นระบบ 1C ของเรา ซึ่งป้อนข้อมูลทั้งหมดอย่างถูกต้องและตรงเวลา (ประเด็นที่นี่คือใบแจ้งหนี้ถูกสร้างขึ้นตามข้อมูล 1C ดังนั้นการป้อนข้อมูลที่ถูกต้องใน 1C เป็นสิ่งสำคัญสำหรับ KPI ของทุกคน) นี่คือแนวคิดใหม่ของระบบที่เกิดขึ้น...

แนวคิด

สิ่งแรกที่เราตัดสินใจทำคือแยกระบบรวบรวมสถิติเกี่ยวกับแคมเปญโฆษณาบนอินเทอร์เน็ตออกเป็นผลิตภัณฑ์แยกต่างหาก - D1.ดิจิตอล.

ในแนวคิดใหม่ เราตัดสินใจโหลดเข้าไป D1.ดิจิตอล ข้อมูลเกี่ยวกับแคมเปญโฆษณาและตำแหน่งภายในจาก 1C จากนั้นดึงสถิติจากไซต์และระบบการแสดงโฆษณาไปยังตำแหน่งเหล่านี้ สิ่งนี้ควรจะทำให้ชีวิตของผู้ใช้ง่ายขึ้นอย่างมาก (และตามปกติคือเพิ่มงานให้กับนักพัฒนามากขึ้น) และลดจำนวนการสนับสนุน

ปัญหาแรกที่เราพบคือลักษณะขององค์กรและเกี่ยวข้องกับข้อเท็จจริงที่ว่าเราไม่สามารถค้นหากุญแจหรือเครื่องหมายซึ่งเราสามารถเปรียบเทียบเอนทิตีจากระบบที่แตกต่างกันกับแคมเปญและตำแหน่งจาก 1C ความจริงก็คือกระบวนการในบริษัทของเราได้รับการออกแบบในลักษณะที่แคมเปญโฆษณาถูกป้อนเข้าสู่ระบบที่แตกต่างกันโดยบุคคลต่างๆ (นักวางแผนโฆษณา การซื้อ ฯลฯ)

เพื่อแก้ไขปัญหานี้ เราต้องประดิษฐ์คีย์แฮชที่ไม่ซ้ำกัน DANBoID ที่จะเชื่อมโยงเอนทิตีในระบบต่างๆ เข้าด้วยกัน และอาจระบุได้ง่ายและไม่ซ้ำกันในชุดข้อมูลที่ดาวน์โหลด ตัวระบุนี้สร้างขึ้นในระบบ 1C ภายในสำหรับแต่ละตำแหน่ง และถูกโอนไปยังแคมเปญ ตำแหน่ง และตัวนับบนไซต์ทั้งหมดและในระบบการแสดงโฆษณาทั้งหมด การนำแนวทางปฏิบัติในการใส่ DANBoID ในทุกตำแหน่งนั้นใช้เวลาพอสมควร แต่เราก็สามารถทำมันได้ :)

จากนั้นเราพบว่าไม่ใช่ทุกไซต์ที่มี API สำหรับการรวบรวมสถิติโดยอัตโนมัติ และแม้แต่ไซต์ที่มี API ก็ไม่ได้ส่งคืนข้อมูลที่จำเป็นทั้งหมด

ในขั้นตอนนี้ เราตัดสินใจที่จะลดรายการแพลตฟอร์มสำหรับการบูรณาการลงอย่างมาก และมุ่งเน้นไปที่แพลตฟอร์มหลักที่เกี่ยวข้องกับแคมเปญโฆษณาส่วนใหญ่ รายการนี้ประกอบด้วยผู้เล่นรายใหญ่ที่สุดในตลาดโฆษณา (Google, Yandex, Mail.ru), เครือข่ายโซเชียล (VK, Facebook, Twitter), การแสดงโฆษณาและระบบการวิเคราะห์ที่สำคัญ (DCM, Adriver, Weborama, Google Analytics) และแพลตฟอร์มอื่น ๆ

ไซต์ส่วนใหญ่ที่เราเลือกมี API ที่ให้ตัวชี้วัดที่เราต้องการ ในกรณีที่ไม่มี API หรือไม่มีข้อมูลที่จำเป็น เราใช้รายงานที่ส่งทุกวันไปยังอีเมลสำนักงานของเราเพื่อโหลดข้อมูล (ในบางระบบสามารถกำหนดค่ารายงานดังกล่าวได้ ในบางระบบเราตกลงในการพัฒนา รายงานดังกล่าวสำหรับเรา)

เมื่อวิเคราะห์ข้อมูลจากไซต์ต่างๆ เราพบว่าลำดับชั้นของเอนทิตีไม่เหมือนกันในระบบที่ต่างกัน นอกจากนี้จำเป็นต้องดาวน์โหลดข้อมูลในรายละเอียดที่แตกต่างจากระบบต่างๆ

เพื่อแก้ไขปัญหานี้ แนวคิด SubDANBoID จึงได้รับการพัฒนา แนวคิดของ SubDANBoID นั้นค่อนข้างง่าย เราทำเครื่องหมายเอนทิตีหลักของแคมเปญบนไซต์ด้วย DANBoID ที่สร้างขึ้น และเราอัปโหลดเอนทิตีที่ซ้อนกันทั้งหมดด้วยตัวระบุไซต์ที่ไม่ซ้ำกัน และสร้าง SubDANBoID ตามหลักการ DANBoID + ตัวระบุของระดับแรก เอนทิตีที่ซ้อนกัน + ตัวระบุของเอนทิตีที่ซ้อนกันระดับที่สอง +... วิธีการนี้ช่วยให้เราสามารถเชื่อมต่อแคมเปญโฆษณาในระบบต่างๆ และดาวน์โหลดสถิติโดยละเอียดได้

เรายังต้องแก้ไขปัญหาการเข้าถึงแคมเปญบนแพลตฟอร์มต่างๆ ดังที่เราเขียนไว้ข้างต้น กลไกของการมอบหมายการเข้าถึงแคมเปญไปยังบัญชีทางเทคนิคที่แยกต่างหากนั้นอาจไม่สามารถใช้ได้เสมอไป ดังนั้นเราจึงต้องพัฒนาโครงสร้างพื้นฐานสำหรับการอนุญาตอัตโนมัติผ่าน OAuth โดยใช้โทเค็นและกลไกในการอัปเดตโทเค็นเหล่านี้

ต่อไปในบทความเราจะพยายามอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับสถาปัตยกรรมของโซลูชันและรายละเอียดทางเทคนิคของการใช้งาน

สถาปัตยกรรมโซลูชัน 1.0

เมื่อเริ่มต้นการใช้งานผลิตภัณฑ์ใหม่ เราเข้าใจว่าเราจำเป็นต้องจัดเตรียมความเป็นไปได้ในการเชื่อมต่อไซต์ใหม่ทันที ดังนั้นเราจึงตัดสินใจเดินตามเส้นทางของสถาปัตยกรรมไมโครเซอร์วิส

เมื่อออกแบบสถาปัตยกรรม เราได้แยกตัวเชื่อมต่อไปยังระบบภายนอกทั้งหมด - 1C, แพลตฟอร์มโฆษณา และระบบโฆษณา - ออกเป็นบริการที่แยกจากกัน
แนวคิดหลักคือตัวเชื่อมต่อทั้งหมดไปยังไซต์มี API เดียวกันและเป็นอะแดปเตอร์ที่นำ API ของไซต์มาสู่อินเทอร์เฟซที่สะดวกสำหรับเรา

ศูนย์กลางของผลิตภัณฑ์ของเราคือเว็บแอปพลิเคชัน ซึ่งเป็นเสาหินที่ได้รับการออกแบบในลักษณะที่สามารถแยกประกอบเป็นบริการได้อย่างง่ายดาย แอปพลิเคชั่นนี้มีหน้าที่ประมวลผลข้อมูลที่ดาวน์โหลด รวบรวมสถิติจากระบบต่างๆ และนำเสนอต่อผู้ใช้ระบบ

ในการสื่อสารระหว่างตัวเชื่อมต่อและเว็บแอปพลิเคชัน เราต้องสร้างบริการเพิ่มเติม ซึ่งเราเรียกว่า Connector Proxy มันทำหน้าที่ของ Service Discovery และ Task Scheduler บริการนี้รันงานรวบรวมข้อมูลสำหรับตัวเชื่อมต่อแต่ละตัวทุกคืน การเขียนชั้นบริการนั้นง่ายกว่าการเชื่อมต่อกับนายหน้าข้อความ และสำหรับเรา สิ่งสำคัญคือต้องได้รับผลลัพธ์โดยเร็วที่สุด

เพื่อความง่ายและรวดเร็วในการพัฒนา เรายังตัดสินใจว่าบริการทั้งหมดจะเป็น Web API ทำให้สามารถประกอบการพิสูจน์แนวคิดได้อย่างรวดเร็วและตรวจสอบว่าการออกแบบทั้งหมดใช้งานได้

งานที่แยกต่างหากและค่อนข้างซับซ้อนคือการตั้งค่าการเข้าถึงเพื่อรวบรวมข้อมูลจากบัญชีต่างๆ ซึ่งตามที่เราตัดสินใจแล้ว ผู้ใช้ควรดำเนินการผ่านอินเทอร์เฟซเว็บ ตามที่เราตัดสินใจ ประกอบด้วยสองขั้นตอนแยกกัน: ขั้นแรก ผู้ใช้เพิ่มโทเค็นเพื่อเข้าถึงบัญชีผ่าน OAuth จากนั้นกำหนดค่าการรวบรวมข้อมูลสำหรับลูกค้าจากบัญชีเฉพาะ การได้รับโทเค็นผ่าน OAuth เป็นสิ่งที่จำเป็น เนื่องจากตามที่เราได้เขียนไปแล้ว ไม่สามารถมอบสิทธิ์การเข้าถึงบัญชีที่ต้องการบนไซต์ได้เสมอไป

ในการสร้างกลไกที่เป็นสากลสำหรับการเลือกบัญชีจากไซต์ เราต้องเพิ่มวิธีการให้กับ Connectors API ที่ส่งคืน JSON Schema ซึ่งแสดงผลเป็นแบบฟอร์มโดยใช้ส่วนประกอบ JSONEditor ที่ได้รับการแก้ไข ด้วยวิธีนี้ ผู้ใช้สามารถเลือกบัญชีที่จะดาวน์โหลดข้อมูลได้

เพื่อให้เป็นไปตามขีดจำกัดคำขอที่มีอยู่ในไซต์ เราจะรวมคำขอสำหรับการตั้งค่าไว้ภายในโทเค็นเดียว แต่เราสามารถประมวลผลโทเค็นที่แตกต่างกันไปพร้อมๆ กันได้

เราเลือก MongoDB เป็นที่จัดเก็บข้อมูลสำหรับข้อมูลที่โหลดสำหรับทั้งเว็บแอปพลิเคชันและตัวเชื่อมต่อ ซึ่งช่วยให้เราไม่ต้องกังวลมากเกินไปเกี่ยวกับโครงสร้างข้อมูลในระยะเริ่มต้นของการพัฒนา เมื่อโมเดลออบเจ็กต์ของแอปพลิเคชันเปลี่ยนแปลงวันเว้นวัน

ในไม่ช้าเราก็พบว่าข้อมูลบางอย่างไม่เหมาะกับ MongoDB และตัวอย่างเช่น การจัดเก็บสถิติรายวันในฐานข้อมูลเชิงสัมพันธ์จะสะดวกกว่า ดังนั้น สำหรับตัวเชื่อมต่อที่มีโครงสร้างข้อมูลเหมาะสมกับฐานข้อมูลเชิงสัมพันธ์มากกว่า เราจึงเริ่มใช้ PostgreSQL หรือ MS SQL Server เป็นที่เก็บข้อมูล

สถาปัตยกรรมและเทคโนโลยีที่เลือกทำให้เราสามารถสร้างและเปิดตัวผลิตภัณฑ์ D1.Digital ได้ค่อนข้างรวดเร็ว กว่าสองปีของการพัฒนาผลิตภัณฑ์ เราได้พัฒนาตัวเชื่อมต่อ 23 ตัวไปยังไซต์ต่างๆ ได้รับประสบการณ์อันล้ำค่าในการทำงานกับ API ของบุคคลที่สาม เรียนรู้ที่จะหลีกเลี่ยงข้อผิดพลาดของไซต์ต่างๆ ซึ่งแต่ละไซต์มีของตัวเอง ซึ่งมีส่วนช่วยในการพัฒนา API อย่างน้อย 3 รายการ เว็บไซต์ดาวน์โหลดข้อมูลโดยอัตโนมัติในเกือบ 15 แคมเปญและสำหรับตำแหน่งมากกว่า 000 ตำแหน่ง รวบรวมคำติชมจำนวนมากจากผู้ใช้เกี่ยวกับการดำเนินงานของผลิตภัณฑ์และจัดการเพื่อเปลี่ยนแปลงกระบวนการหลักของผลิตภัณฑ์หลายครั้งตามคำติชมนี้

สถาปัตยกรรมโซลูชัน 2.0

สองปีผ่านไปนับตั้งแต่เริ่มพัฒนา D1.ดิจิตอล- ภาระงานที่เพิ่มขึ้นอย่างต่อเนื่องบนระบบและการเกิดขึ้นของแหล่งข้อมูลใหม่ ๆ ค่อยๆ เผยปัญหาในสถาปัตยกรรมโซลูชันที่มีอยู่

ปัญหาแรกเกี่ยวข้องกับจำนวนข้อมูลที่ดาวน์โหลดจากไซต์ เราต้องเผชิญกับความจริงที่ว่าการรวบรวมและอัปเดตข้อมูลที่จำเป็นทั้งหมดจากไซต์ที่ใหญ่ที่สุดเริ่มใช้เวลานานเกินไป ตัวอย่างเช่น การรวบรวมข้อมูลจากระบบการแสดงโฆษณา AdRiver ซึ่งเราติดตามสถิติสำหรับตำแหน่งส่วนใหญ่ จะใช้เวลาประมาณ 12 ชั่วโมง

เพื่อแก้ไขปัญหานี้ เราเริ่มใช้รายงานทุกประเภทเพื่อดาวน์โหลดข้อมูลจากไซต์ต่างๆ เรากำลังพยายามพัฒนา API ร่วมกับไซต์ต่างๆ เพื่อให้ความเร็วของการดำเนินการตรงตามความต้องการของเรา และทำการดาวน์โหลดข้อมูลแบบขนานให้มากที่สุด

ปัญหาอีกประการหนึ่งเกี่ยวข้องกับการประมวลผลข้อมูลที่ดาวน์โหลด ขณะนี้ เมื่อสถิติตำแหน่งใหม่มาถึง กระบวนการคำนวณเมตริกใหม่แบบหลายขั้นตอนจะเริ่มขึ้น ซึ่งรวมถึงการโหลดข้อมูลดิบ การคำนวณเมตริกรวมสำหรับแต่ละไซต์ การเปรียบเทียบข้อมูลจากแหล่งที่มาต่างๆ ระหว่างกัน และการคำนวณเมตริกสรุปสำหรับแคมเปญ ซึ่งทำให้มีภาระงานบนเว็บแอปพลิเคชันที่ทำการคำนวณทั้งหมดเป็นจำนวนมาก หลายครั้งในระหว่างกระบวนการคำนวณใหม่ แอปพลิเคชันใช้หน่วยความจำทั้งหมดบนเซิร์ฟเวอร์ประมาณ 10-15 GB ซึ่งส่งผลเสียต่อการทำงานของผู้ใช้กับระบบมากที่สุด

ปัญหาที่ระบุและแผนการอันทะเยอทะยานในการพัฒนาผลิตภัณฑ์เพิ่มเติมทำให้เราจำเป็นต้องพิจารณาสถาปัตยกรรมแอปพลิเคชันอีกครั้ง

เราเริ่มต้นด้วยตัวเชื่อมต่อ
เราสังเกตเห็นว่าตัวเชื่อมต่อทั้งหมดทำงานตามโมเดลเดียวกัน ดังนั้นเราจึงสร้างเฟรมเวิร์กไปป์ไลน์ซึ่งคุณสามารถสร้างตัวเชื่อมต่อที่คุณเพียงแค่ต้องตั้งโปรแกรมลอจิกของขั้นตอนต่างๆ ส่วนที่เหลือเป็นแบบสากล หากตัวเชื่อมต่อบางตัวต้องมีการปรับปรุง เราจะโอนตัวเชื่อมต่อนั้นไปยังเฟรมเวิร์กใหม่ทันทีพร้อมกับที่ตัวเชื่อมต่อกำลังได้รับการปรับปรุง

ในเวลาเดียวกัน เราเริ่มปรับใช้ตัวเชื่อมต่อกับ Docker และ Kubernetes
เราวางแผนการย้ายไปยัง Kubernetes มาเป็นเวลานาน โดยทดลองใช้การตั้งค่า CI/CD แต่เริ่มย้ายเฉพาะเมื่อตัวเชื่อมต่อตัวหนึ่งเริ่มกินหน่วยความจำมากกว่า 20 GB บนเซิร์ฟเวอร์ เนื่องจากมีข้อผิดพลาด ส่งผลให้กระบวนการอื่น ๆ เสียหายในทางปฏิบัติ . ในระหว่างการตรวจสอบ ตัวเชื่อมต่อถูกย้ายไปยังคลัสเตอร์ 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: Georgy Ostapenko (ชมิกา), มิคาอิล คอตซิก (ไฮเท็กซ์)

ที่มา: will.com