Φαίνεται ότι ο τομέας της διαδικτυακής διαφήμισης θα πρέπει να είναι όσο το δυνατόν πιο προηγμένος τεχνολογικά και αυτοματοποιημένος. Φυσικά, γιατί τέτοιοι γίγαντες και ειδικοί στον τομέα τους όπως η Yandex, η Mail.Ru, η Google και το Facebook εργάζονται εκεί. Όμως, όπως αποδείχθηκε, δεν υπάρχει όριο στην τελειότητα και πάντα υπάρχει κάτι για αυτοματοποίηση.
Ομάδα Επικοινωνιών Dentsu Aegis Network Ρωσία είναι ο μεγαλύτερος παίκτης στην αγορά της ψηφιακής διαφήμισης και επενδύει ενεργά στην τεχνολογία, προσπαθώντας να βελτιστοποιήσει και να αυτοματοποιήσει τις επιχειρηματικές της διαδικασίες. Ένα από τα άλυτα προβλήματα της αγοράς διαδικτυακής διαφήμισης έχει γίνει η συλλογή στατιστικών στοιχείων για διαφημιστικές καμπάνιες από διαφορετικές πλατφόρμες Διαδικτύου. Η λύση σε αυτό το πρόβλημα κατέληξε τελικά στη δημιουργία ενός προϊόντος Δ1.Ψηφιακό (διαβάστε ως 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, χρησιμοποιήσαμε έναν μόνο λογαριασμό. Ένας διαχειριστής ομάδας πελατών που ήθελε να χρησιμοποιήσει την αυτόματη συλλογή στατιστικών στοιχείων σε μια διαφημιστική καμπάνια έπρεπε πρώτα να εκχωρήσει στον λογαριασμό πλατφόρμας την πρόσβαση στις απαραίτητες διαφημιστικές καμπάνιες σε ιστότοπους.
Ακολουθεί ο χρήστης του συστήματος DANBo έπρεπε να ανεβάσει ένα αρχείο συγκεκριμένης μορφής στο σύστημα Excel, το οποίο περιείχε όλες τις πληροφορίες σχετικά με την τοποθέτηση (διαφημιστική καμπάνια, πλατφόρμα, μορφή, περίοδος τοποθέτησης, προγραμματισμένοι δείκτες, προϋπολογισμός κ.λπ.) και αναγνωριστικά των αντίστοιχων διαφημιστικών καμπανιών στο τοποθεσίες και μετρητές σε συστήματα διαφημίσεων.
Φαινόταν, ειλικρινά, τρομακτικό:
Τα ληφθέντα δεδομένα αποθηκεύτηκαν σε μια βάση δεδομένων και, στη συνέχεια, ξεχωριστές υπηρεσίες συνέλεξαν αναγνωριστικά καμπάνιας σε ιστότοπους από αυτές και κατέβασαν στατιστικά στοιχεία για αυτά.
Για κάθε ιστότοπο, γράφτηκε μια ξεχωριστή υπηρεσία Windows, η οποία μια φορά την ημέρα περνούσε κάτω από έναν λογαριασμό υπηρεσίας στο API του ιστότοπου και κατέβαζε στατιστικά στοιχεία για συγκεκριμένα αναγνωριστικά καμπάνιας. Το ίδιο συνέβη με τα συστήματα διαφημίσεως.
Τα ληφθέντα δεδομένα εμφανίστηκαν στη διεπαφή με τη μορφή ενός μικρού προσαρμοσμένου πίνακα εργαλείων:
Απροσδόκητα για εμάς, το MVP άρχισε να εργάζεται και άρχισε να κατεβάζει τρέχοντα στατιστικά στοιχεία για διαφημιστικές καμπάνιες στο Διαδίκτυο. Εφαρμόσαμε το σύστημα σε πολλούς πελάτες, αλλά κατά την προσπάθεια κλιμάκωσης, αντιμετωπίσαμε σοβαρά προβλήματα:
- Το κύριο πρόβλημα ήταν η πολυπλοκότητα της προετοιμασίας δεδομένων για φόρτωση στο σύστημα. Επίσης, τα δεδομένα τοποθέτησης έπρεπε να μετατραπούν σε αυστηρά σταθερή μορφή πριν από τη φόρτωση. Ήταν απαραίτητο να συμπεριληφθούν αναγνωριστικά οντοτήτων από διαφορετικούς ιστότοπους στο αρχείο λήψης. Βρισκόμαστε αντιμέτωποι με το γεγονός ότι είναι πολύ δύσκολο για τεχνικά μη εκπαιδευμένους χρήστες να εξηγήσουν πού να βρουν αυτά τα αναγνωριστικά στον ιστότοπο και πού στο αρχείο πρέπει να εισαχθούν. Λαμβάνοντας υπόψη τον αριθμό των εργαζομένων στα τμήματα που πραγματοποιούν καμπάνιες σε ιστότοπους και τον κύκλο εργασιών, αυτό είχε ως αποτέλεσμα μια τεράστια υποστήριξη από την πλευρά μας, με την οποία δεν ήμασταν απολύτως ευχαριστημένοι.
- Ένα άλλο πρόβλημα ήταν ότι δεν διέθεταν όλες οι διαφημιστικές πλατφόρμες μηχανισμούς ανάθεσης πρόσβασης σε διαφημιστικές καμπάνιες σε άλλους λογαριασμούς. Ωστόσο, ακόμα κι αν ήταν διαθέσιμος ένας μηχανισμός ανάθεσης, δεν ήταν όλοι οι διαφημιστές πρόθυμοι να παραχωρήσουν πρόσβαση στις καμπάνιες τους σε λογαριασμούς τρίτων.
- Ένας σημαντικός παράγοντας ήταν η αγανάκτηση που προκάλεσε στους χρήστες το γεγονός ότι όλοι οι προγραμματισμένοι δείκτες και οι λεπτομέρειες τοποθέτησης που ήδη εισάγουν στο λογιστικό μας σύστημα 1C, πρέπει να επανεισαχθούν. DANBo.
Αυτό μας έδωσε την ιδέα ότι η κύρια πηγή πληροφοριών σχετικά με την τοποθέτηση θα πρέπει να είναι το σύστημά μας 1C, στο οποίο όλα τα δεδομένα εισάγονται με ακρίβεια και έγκαιρα (το θέμα εδώ είναι ότι τα τιμολόγια δημιουργούνται με βάση τα δεδομένα 1C, επομένως η σωστή εισαγωγή δεδομένων στο 1C είναι προτεραιότητα για όλους KPI). Έτσι προέκυψε μια νέα έννοια του συστήματος...
Έννοια
Το πρώτο πράγμα που αποφασίσαμε να κάνουμε ήταν να διαχωρίσουμε το σύστημα συλλογής στατιστικών στοιχείων για διαφημιστικές καμπάνιες στο Διαδίκτυο σε ένα ξεχωριστό προϊόν - Δ1.Ψηφιακό.
Στη νέα ιδέα, αποφασίσαμε να φορτώσουμε Δ1.Ψηφιακό πληροφορίες σχετικά με τις διαφημιστικές καμπάνιες και τις τοποθετήσεις σε αυτές από το 1C και, στη συνέχεια, ανακτήστε στατιστικά στοιχεία από ιστότοπους και συστήματα AdServing σε αυτές τις τοποθετήσεις. Αυτό έπρεπε να απλοποιήσει σημαντικά τη ζωή των χρηστών (και, ως συνήθως, να προσθέσει περισσότερη δουλειά στους προγραμματιστές) και να μειώσει το ποσό της υποστήριξης.
Το πρώτο πρόβλημα που αντιμετωπίσαμε ήταν οργανωτικής φύσης και αφορούσε το γεγονός ότι δεν μπορούσαμε να βρούμε ένα κλειδί ή ένα σημάδι με το οποίο θα μπορούσαμε να συγκρίνουμε οντότητες από διαφορετικά συστήματα με καμπάνιες και τοποθετήσεις από το 1C. Γεγονός είναι ότι η διαδικασία στην εταιρεία μας είναι σχεδιασμένη με τέτοιο τρόπο ώστε οι διαφημιστικές καμπάνιες να εισάγονται σε διαφορετικά συστήματα από διαφορετικά άτομα (media planners, αγορές κ.λπ.).
Για να λύσουμε αυτό το πρόβλημα, έπρεπε να εφεύρουμε ένα μοναδικό κατακερματισμένο κλειδί, το DANBoID, που θα συνέδεε οντότητες σε διαφορετικά συστήματα μεταξύ τους και το οποίο θα μπορούσε να αναγνωριστεί αρκετά εύκολα και μοναδικά στα ληφθέντα σύνολα δεδομένων. Αυτό το αναγνωριστικό δημιουργείται στο εσωτερικό σύστημα 1C για κάθε μεμονωμένη τοποθέτηση και μεταφέρεται σε καμπάνιες, τοποθετήσεις και μετρητές σε όλους τους ιστότοπους και σε όλα τα συστήματα AdServing. Η εφαρμογή της πρακτικής τοποθέτησης του DANBoID σε όλες τις τοποθετήσεις πήρε λίγο χρόνο, αλλά τα καταφέραμε :)
Στη συνέχεια, ανακαλύψαμε ότι δεν έχουν όλοι οι ιστότοποι API για αυτόματη συλλογή στατιστικών στοιχείων, ενώ ακόμη και αυτοί που διαθέτουν API, δεν επιστρέφει όλα τα απαραίτητα δεδομένα.
Σε αυτό το στάδιο, αποφασίσαμε να μειώσουμε σημαντικά τη λίστα των πλατφορμών για ενοποίηση και να επικεντρωθούμε στις κύριες πλατφόρμες που εμπλέκονται στη συντριπτική πλειοψηφία των διαφημιστικών καμπανιών. Αυτή η λίστα περιλαμβάνει όλους τους μεγαλύτερους παίκτες στη διαφημιστική αγορά (Google, Yandex, Mail.ru), τα κοινωνικά δίκτυα (VK, Facebook, Twitter), τα μεγάλα συστήματα AdServing και αναλυτικών στοιχείων (DCM, Adriver, Weborama, Google Analytics) και άλλες πλατφόρμες.
Οι περισσότεροι ιστότοποι που επιλέξαμε είχαν ένα API που παρείχε τις μετρήσεις που χρειαζόμασταν. Σε περιπτώσεις όπου δεν υπήρχε API ή δεν περιείχε τα απαραίτητα δεδομένα, χρησιμοποιούσαμε αναφορές που αποστέλλονταν καθημερινά στο email του γραφείου μας για τη φόρτωση δεδομένων (σε ορισμένα συστήματα είναι δυνατή η διαμόρφωση τέτοιων αναφορών, σε άλλα συμφωνήσαμε για την ανάπτυξη τέτοιες αναφορές για εμάς).
Κατά την ανάλυση δεδομένων από διαφορετικούς ιστότοπους, ανακαλύψαμε ότι η ιεραρχία των οντοτήτων δεν είναι η ίδια σε διαφορετικά συστήματα. Επιπλέον, οι πληροφορίες πρέπει να ληφθούν με διαφορετικές λεπτομέρειες από διαφορετικά συστήματα.
Για την επίλυση αυτού του προβλήματος, αναπτύχθηκε η έννοια SubDANBoID. Η ιδέα του SubDANBoID είναι αρκετά απλή, επισημαίνουμε την κύρια οντότητα της καμπάνιας στον ιστότοπο με το DANBoID που δημιουργήθηκε και ανεβάζουμε όλες τις ένθετες οντότητες με μοναδικά αναγνωριστικά ιστότοπου και σχηματίζουμε SubDANBoID σύμφωνα με την αρχή DANBoID + αναγνωριστικό του πρώτου επιπέδου ένθετη οντότητα + αναγνωριστικό της ένθετης οντότητας δεύτερου επιπέδου +... Αυτή η προσέγγιση μας επέτρεψε να συνδέσουμε διαφημιστικές καμπάνιες σε διαφορετικά συστήματα και να κατεβάσουμε λεπτομερή στατιστικά στοιχεία για αυτές.
Έπρεπε επίσης να λύσουμε το πρόβλημα της πρόσβασης σε καμπάνιες σε διαφορετικές πλατφόρμες. Όπως γράψαμε παραπάνω, ο μηχανισμός ανάθεσης πρόσβασης σε μια καμπάνια σε ξεχωριστό τεχνικό λογαριασμό δεν ισχύει πάντα. Ως εκ τούτου, έπρεπε να αναπτύξουμε μια υποδομή για αυτόματη εξουσιοδότηση μέσω OAuth χρησιμοποιώντας διακριτικά και μηχανισμούς για την ενημέρωση αυτών των διακριτικών.
Αργότερα στο άρθρο θα προσπαθήσουμε να περιγράψουμε πιο αναλυτικά την αρχιτεκτονική της λύσης και τις τεχνικές λεπτομέρειες της υλοποίησης.
Αρχιτεκτονική λύσεων 1.0
Ξεκινώντας την εφαρμογή ενός νέου προϊόντος, καταλάβαμε ότι έπρεπε άμεσα να προβλεφθεί η δυνατότητα σύνδεσης νέων τοποθεσιών, γι' αυτό αποφασίσαμε να ακολουθήσουμε το μονοπάτι της αρχιτεκτονικής microservice.
Κατά το σχεδιασμό της αρχιτεκτονικής, διαχωρίσαμε τις συνδέσεις σε όλα τα εξωτερικά συστήματα - 1C, διαφημιστικές πλατφόρμες και συστήματα διαφημίσεων - σε ξεχωριστές υπηρεσίες.
Η κύρια ιδέα είναι ότι όλοι οι σύνδεσμοι σε ιστότοπους έχουν το ίδιο API και είναι προσαρμογείς που φέρνουν το API του ιστότοπου σε μια διεπαφή κατάλληλη για εμάς.
Στο κέντρο του προϊόντος μας βρίσκεται μια διαδικτυακή εφαρμογή, η οποία είναι ένα μονόλιθο που έχει σχεδιαστεί με τέτοιο τρόπο ώστε να μπορεί εύκολα να αποσυναρμολογηθεί σε υπηρεσίες. Αυτή η εφαρμογή είναι υπεύθυνη για την επεξεργασία των ληφθέντων δεδομένων, τη συλλογή στατιστικών στοιχείων από διαφορετικά συστήματα και την παρουσίασή τους στους χρήστες του συστήματος.
Για να επικοινωνήσουμε μεταξύ των εφαρμογών σύνδεσης και της εφαρμογής web, έπρεπε να δημιουργήσουμε μια πρόσθετη υπηρεσία, την οποία ονομάσαμε Connector Proxy. Εκτελεί τις λειτουργίες του Service Discovery και Task Scheduler. Αυτή η υπηρεσία εκτελεί εργασίες συλλογής δεδομένων για κάθε εφαρμογή σύνδεσης κάθε βράδυ. Η σύνταξη ενός επιπέδου υπηρεσιών ήταν ευκολότερη από τη σύνδεση ενός μεσίτη μηνυμάτων και για εμάς ήταν σημαντικό να λάβουμε το αποτέλεσμα όσο το δυνατόν γρηγορότερα.
Για απλότητα και ταχύτητα ανάπτυξης, αποφασίσαμε επίσης ότι όλες οι υπηρεσίες θα είναι Web API. Αυτό κατέστησε δυνατή τη γρήγορη συναρμολόγηση μιας απόδειξης ιδέας και την επαλήθευση της λειτουργίας ολόκληρου του σχεδίου.
Μια ξεχωριστή, μάλλον περίπλοκη εργασία ήταν η δημιουργία πρόσβασης για τη συλλογή δεδομένων από διαφορετικούς λογαριασμούς, η οποία, όπως αποφασίσαμε, θα έπρεπε να εκτελείται από τους χρήστες μέσω της διεπαφής ιστού. Αποτελείται από δύο ξεχωριστά βήματα: πρώτα, ο χρήστης προσθέτει ένα διακριτικό για πρόσβαση στον λογαριασμό μέσω OAuth και, στη συνέχεια, διαμορφώνει τη συλλογή δεδομένων για τον πελάτη από έναν συγκεκριμένο λογαριασμό. Η απόκτηση ενός διακριτικού μέσω OAuth είναι απαραίτητη γιατί, όπως έχουμε ήδη γράψει, δεν είναι πάντα δυνατό να εκχωρήσετε πρόσβαση στον επιθυμητό λογαριασμό στον ιστότοπο.
Για να δημιουργήσουμε έναν καθολικό μηχανισμό για την επιλογή ενός λογαριασμού από τοποθεσίες, έπρεπε να προσθέσουμε μια μέθοδο στο API των εφαρμογών σύνδεσης που επιστρέφει το JSON Schema, το οποίο αποδίδεται σε μια φόρμα χρησιμοποιώντας ένα τροποποιημένο στοιχείο JSONEditor. Με αυτόν τον τρόπο, οι χρήστες μπορούσαν να επιλέξουν τους λογαριασμούς από τους οποίους θα κατέβαζαν δεδομένα.
Για τη συμμόρφωση με τα όρια αιτημάτων που υπάρχουν στους ιστότοπους, συνδυάζουμε αιτήματα για ρυθμίσεις μέσα σε ένα διακριτικό, αλλά μπορούμε να επεξεργαστούμε διαφορετικά διακριτικά παράλληλα.
Επιλέξαμε το MongoDB ως χώρο αποθήκευσης φορτωμένων δεδομένων τόσο για την εφαρμογή web όσο και για τις συνδέσεις, γεγονός που μας επέτρεψε να μην ανησυχούμε πολύ για τη δομή δεδομένων στα αρχικά στάδια ανάπτυξης, όταν το μοντέλο αντικειμένου της εφαρμογής αλλάζει κάθε δεύτερη μέρα.
Σύντομα ανακαλύψαμε ότι δεν ταιριάζουν όλα τα δεδομένα καλά στο MongoDB και, για παράδειγμα, είναι πιο βολικό να αποθηκεύονται καθημερινά στατιστικά στοιχεία σε μια σχεσιακή βάση δεδομένων. Επομένως, για τις συνδέσεις των οποίων η δομή δεδομένων είναι πιο κατάλληλη για μια σχεσιακή βάση δεδομένων, αρχίσαμε να χρησιμοποιούμε τον PostgreSQL ή τον MS SQL Server ως αποθήκευση.
Η επιλεγμένη αρχιτεκτονική και οι τεχνολογίες μας επέτρεψαν να δημιουργήσουμε και να λανσάρουμε το προϊόν D1.Digital σχετικά γρήγορα. Πάνω από δύο χρόνια ανάπτυξης προϊόντων, αναπτύξαμε 23 συνδέσεις σε ιστότοπους, αποκτήσαμε ανεκτίμητη εμπειρία δουλεύοντας με API τρίτων, μάθαμε να αποφεύγουμε τις παγίδες διαφορετικών τοποθεσιών, που ο καθένας είχε τους δικούς του, συνεισέφερε στην ανάπτυξη του API τουλάχιστον 3 ιστότοποι, κατέβασαν αυτόματα πληροφορίες για σχεδόν 15 καμπάνιες και για περισσότερες από 000 τοποθετήσεις, συγκέντρωσαν πολλά σχόλια από τους χρήστες σχετικά με τη λειτουργία του προϊόντος και κατάφεραν να αλλάξουν την κύρια διαδικασία του προϊόντος αρκετές φορές, με βάση αυτά τα σχόλια.
Αρχιτεκτονική λύσεων 2.0
Έχουν περάσει δύο χρόνια από την έναρξη της ανάπτυξης Δ1.Ψηφιακό. Η συνεχής αύξηση του φορτίου στο σύστημα και η εμφάνιση ολοένα και περισσότερων νέων πηγών δεδομένων αποκάλυψε σταδιακά προβλήματα στην υπάρχουσα αρχιτεκτονική λύσης.
Το πρώτο πρόβλημα σχετίζεται με τον όγκο των δεδομένων που λαμβάνονται από τους ιστότοπους. Βρεθήκαμε αντιμέτωποι με το γεγονός ότι η συλλογή και η ενημέρωση όλων των απαραίτητων δεδομένων από τους μεγαλύτερους ιστότοπους άρχισε να απαιτεί πολύ χρόνο. Για παράδειγμα, η συλλογή δεδομένων από το σύστημα διαφημίσεων AdRiver, με το οποίο παρακολουθούμε στατιστικά στοιχεία για τις περισσότερες τοποθετήσεις, διαρκεί περίπου 12 ώρες.
Για να λύσουμε αυτό το πρόβλημα, αρχίσαμε να χρησιμοποιούμε κάθε είδους αναφορές για τη λήψη δεδομένων από ιστότοπους, προσπαθούμε να αναπτύξουμε το API τους μαζί με τους ιστότοπους έτσι ώστε η ταχύτητα λειτουργίας του να ανταποκρίνεται στις ανάγκες μας και να παραλληλίσουμε τη λήψη δεδομένων όσο το δυνατόν περισσότερο.
Ένα άλλο πρόβλημα σχετίζεται με την επεξεργασία των ληφθέντων δεδομένων. Τώρα, όταν φτάνουν νέα στατιστικά στοιχεία τοποθέτησης, ξεκινά μια διαδικασία επανυπολογισμού μετρήσεων πολλαπλών σταδίων, η οποία περιλαμβάνει τη φόρτωση μη επεξεργασμένων δεδομένων, τον υπολογισμό συγκεντρωτικών μετρήσεων για κάθε ιστότοπο, τη σύγκριση δεδομένων από διαφορετικές πηγές μεταξύ τους και τον υπολογισμό συνοπτικών μετρήσεων για την καμπάνια. Αυτό προκαλεί μεγάλο φόρτο στην εφαρμογή web που κάνει όλους τους υπολογισμούς. Αρκετές φορές, κατά τη διαδικασία επανυπολογισμού, η εφαρμογή κατανάλωσε όλη τη μνήμη του διακομιστή, περίπου 10-15 GB, γεγονός που είχε την πιο επιζήμια επίδραση στην εργασία των χρηστών με το σύστημα.
Τα προβλήματα που εντοπίστηκαν και τα φιλόδοξα σχέδια για περαιτέρω ανάπτυξη του προϊόντος μας οδήγησαν στην ανάγκη επανεξέτασης της αρχιτεκτονικής εφαρμογής.
Ξεκινήσαμε με συνδέσμους.
Παρατηρήσαμε ότι όλοι οι σύνδεσμοι λειτουργούν σύμφωνα με το ίδιο μοντέλο, γι' αυτό κατασκευάσαμε ένα πλαίσιο διοχέτευσης στο οποίο για να δημιουργήσετε έναν σύνδεσμο, έπρεπε μόνο να προγραμματίσετε τη λογική των βημάτων, τα υπόλοιπα ήταν καθολικά. Εάν ένας σύνδεσμος χρειάζεται βελτίωση, τότε τον μεταφέρουμε αμέσως σε νέο πλαίσιο ταυτόχρονα με τη βελτίωση του βύσματος.
Ταυτόχρονα, ξεκινήσαμε την ανάπτυξη συνδέσεων στο Docker και το Kubernetes.
Σχεδιάσαμε τη μετάβαση στο Kubernetes για αρκετό καιρό, πειραματιστήκαμε με ρυθμίσεις CI/CD, αλλά ξεκινήσαμε να κινούμαστε μόνο όταν ένας σύνδεσμος, λόγω σφάλματος, άρχισε να καταναλώνει περισσότερα από 20 GB μνήμης στον διακομιστή, σκοτώνοντας πρακτικά άλλες διεργασίες . Κατά τη διάρκεια της έρευνας, ο σύνδεσμος μεταφέρθηκε σε ένα σύμπλεγμα Kubernetes, όπου παρέμεινε τελικά, ακόμη και μετά την επιδιόρθωση του σφάλματος.
Πολύ γρήγορα καταλάβαμε ότι το Kubernetes ήταν βολικό και μέσα σε έξι μήνες μεταφέραμε 7 συνδέσεις και διακομιστή μεσολάβησης συνδέσεων, που καταναλώνουν τους περισσότερους πόρους, στο σύμπλεγμα παραγωγής.
Ακολουθώντας τους συνδέσμους, αποφασίσαμε να αλλάξουμε την αρχιτεκτονική της υπόλοιπης εφαρμογής.
Το κύριο πρόβλημα ήταν ότι τα δεδομένα προέρχονται από συνδέσμους σε διακομιστή μεσολάβησης σε μεγάλες παρτίδες, και στη συνέχεια χτυπούν το DANBoID και αποστέλλονται στην κεντρική εφαρμογή Ιστού για επεξεργασία. Λόγω του μεγάλου αριθμού επανυπολογισμών μετρήσεων, υπάρχει μεγάλος φόρτος στην εφαρμογή.
Αποδείχτηκε επίσης αρκετά δύσκολο να παρακολουθείται η κατάσταση μεμονωμένων εργασιών συλλογής δεδομένων και να αναφέρονται σφάλματα που παρουσιάζονται στις συνδέσεις σε μια κεντρική εφαρμογή web, έτσι ώστε οι χρήστες να μπορούν να δουν τι συμβαίνει και γιατί δεν συλλέγονται δεδομένα.
Για να λύσουμε αυτά τα προβλήματα, αναπτύξαμε την αρχιτεκτονική 2.0.
Η κύρια διαφορά μεταξύ της νέας έκδοσης της αρχιτεκτονικής είναι ότι αντί για το Web API, χρησιμοποιούμε το RabbitMQ και τη βιβλιοθήκη MassTransit για την ανταλλαγή μηνυμάτων μεταξύ των υπηρεσιών. Για να γίνει αυτό, έπρεπε να ξαναγράψουμε σχεδόν πλήρως το Connectors Proxy, κάνοντάς το Connectors Hub. Το όνομα άλλαξε επειδή ο κύριος ρόλος της υπηρεσίας δεν είναι πλέον η προώθηση αιτημάτων στις εφαρμογές σύνδεσης και πίσω, αλλά στη διαχείριση της συλλογής μετρήσεων από τις εφαρμογές σύνδεσης.
Από την κεντρική διαδικτυακή εφαρμογή, διαχωρίσαμε πληροφορίες σχετικά με τοποθετήσεις και στατιστικά στοιχεία από ιστότοπους σε ξεχωριστές υπηρεσίες, γεγονός που κατέστησε δυνατή την απαλλαγή από περιττούς επανυπολογισμούς και την αποθήκευση μόνο ήδη υπολογισμένων και συγκεντρωτικών στατιστικών σε επίπεδο τοποθέτησης. Επίσης, ξαναγράψαμε και βελτιστοποιήσαμε τη λογική για τον υπολογισμό βασικών στατιστικών με βάση τα ανεπεξέργαστα δεδομένα.
Ταυτόχρονα, μεταφέρουμε όλες τις υπηρεσίες και τις εφαρμογές στο Docker και στο Kubernetes για να κάνουμε τη λύση ευκολότερη στην κλίμακα και πιο βολική στη διαχείριση.
Που είμαστε τώρα
Proof-of-concept αρχιτεκτονική 2.0 προϊόν Δ1.Ψηφιακό έτοιμο και λειτουργεί σε περιβάλλον δοκιμής με περιορισμένο σύνολο συνδέσμων. Το μόνο που μένει να κάνετε είναι να ξαναγράψετε άλλες 20 υποδοχές σύνδεσης σε μια νέα πλατφόρμα, να ελέγξετε ότι τα δεδομένα έχουν φορτωθεί σωστά και όλες οι μετρήσεις έχουν υπολογιστεί σωστά και να προωθήσετε ολόκληρο το σχέδιο στην παραγωγή.
Στην πραγματικότητα, αυτή η διαδικασία θα γίνει σταδιακά και θα πρέπει να αφήσουμε την αντίστροφη συμβατότητα με παλιά API για να συνεχίσουμε να λειτουργούν όλα.
Τα άμεσα σχέδιά μας περιλαμβάνουν την ανάπτυξη νέων εφαρμογών σύνδεσης, την ενοποίηση με νέα συστήματα και την προσθήκη πρόσθετων μετρήσεων στο σύνολο δεδομένων που λαμβάνονται από συνδεδεμένους ιστότοπους και συστήματα διαφημίσεων.
Σχεδιάζουμε επίσης να μεταφέρουμε όλες τις εφαρμογές, συμπεριλαμβανομένης της κεντρικής διαδικτυακής εφαρμογής, στο Docker και στο Kubernetes. Σε συνδυασμό με τη νέα αρχιτεκτονική, αυτό θα απλοποιήσει σημαντικά την ανάπτυξη, την παρακολούθηση και τον έλεγχο των πόρων που καταναλώνονται.
Μια άλλη ιδέα είναι να πειραματιστείτε με την επιλογή της βάσης δεδομένων για την αποθήκευση στατιστικών, η οποία αυτή τη στιγμή είναι αποθηκευμένη στο MongoDB. Έχουμε ήδη μεταφέρει αρκετές νέες συνδέσεις σε βάσεις δεδομένων SQL, αλλά εκεί η διαφορά είναι σχεδόν απαρατήρητη και για συγκεντρωτικά στατιστικά στοιχεία ανά ημέρα, τα οποία μπορούν να ζητηθούν για αυθαίρετη περίοδο, το κέρδος μπορεί να είναι αρκετά σοβαρό.
Γενικά, τα σχέδια είναι μεγαλεπήβολα, ας προχωρήσουμε :)
Συγγραφείς του άρθρου R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Μιχαήλ Κότσικ ()
Πηγή: www.habr.com