हम 12-मंजिला तकनीक को एक साथ कैसे जोड़ते हैं और यह पागल नहीं होता है

Appodeal ~ 100 लोगों की एक कंपनी है जो मॉस्को, सैन फ्रांसिस्को, बारनाउल, लुत्स्क, किरोव, बार्सिलोना में काम करते हैं और जून 2018 से मिन्स्क में भी काम करते हैं।

हम उपयोगकर्ताओं को विज्ञापन दिखाकर मोबाइल ऐप का मुद्रीकरण करते हैं। हमने विज्ञापन मध्यस्थता के साथ शुरू किया था, लेकिन प्रौद्योगिकी स्टैक लगातार बढ़ रहा है, इसलिए विज्ञापन तकनीक उद्योग से अन्य उत्पादों को भी मध्यस्थता में जोड़ा गया है।



जो लोग एड टेक से परिचित नहीं हैं, उनके लिए यह प्रौद्योगिकी कंपनियों के काम का क्षेत्र है जो विज्ञापन के क्षेत्र में काम करती हैं। जब आप किसी को बताते हैं कि आप मोबाइल विज्ञापन के क्षेत्र में काम करते हैं, तो लोग अक्सर संदेह के साथ प्रतिक्रिया करते हैं - जाहिर है, कष्टप्रद विज्ञापन "एज़िनो थ्री एक्सिस" दिमाग में आता है। वास्तव में, यह सिर्फ हिमशैल की नोक है, और यह सब "जंगली" विज्ञापन का वास्तविक विज्ञापन व्यवसाय से कोई लेना-देना नहीं है। और जिस मोबाइल सेगमेंट में हम लगे हुए हैं वह लंबे समय तक वेब पर विज्ञापन के सेगमेंट को आगे बढ़ाता है:

विज्ञापनों में विज्ञापन क्यों एकीकृत करें?

बेशक, बहुत सारे संसाधन अनुप्रयोगों को बनाने में खर्च किए जाते हैं - और निर्माता / मालिक चाहते हैं कि भुगतान करने के लिए खर्च किया गया समय और प्रयास। मोबाइल एप्लिकेशन के मालिक जो ऐप स्टोर / Google Play पर अपना आवेदन पोस्ट करते हैं उन्हें प्रकाशक या प्रकाशक कहा जाता है। इन-ऐप खरीदारी से विज्ञापन विमुद्रीकरण तक प्रकाशक अलग-अलग मुद्रीकरण मॉडल लागू करते हैं। लेकिन इन सभी तरीकों से, केवल उत्तरार्द्ध उपयोगकर्ता को एप्लिकेशन का उपयोग करने के लिए भुगतान नहीं करने की अनुमति देता है - और यह सबसे बड़ी दर्शक कवरेज देता है।

हां, यदि बहुत अधिक विज्ञापन हैं, तो यह सभी को परेशान करेगा और उपयोगकर्ता के प्रतिधारण पर प्रतिकूल प्रभाव डालेगा। जो, ज़ाहिर है, किसी को भी ज़रूरत नहीं है। इसलिए, वे हमेशा अपने आवेदन पर अधिक से अधिक पैसा कमाने के लिए विज्ञापन को बुद्धिमानी से एकीकृत करने का प्रयास करते हैं और साथ ही साथ उपयोगकर्ताओं से एक पैसा भी नहीं लेते हैं।

यह कैसे काम करता है?

जैसे ही प्रकाशक विज्ञापन के माध्यम से विमुद्रीकरण करने का फैसला करता है, वह कंपनी के पास आता है जो उसके लिए इस कार्य को यथासंभव आसान बना सकता है। यह Appodeal के साथ कैसे होता है? साइट पर पंजीकरण करने के बाद, हम उसकी एप्लिकेशन को हमारी सेवा के साथ एकीकृत करते हैं। यह क्लाइंट एसडीके के माध्यम से किया जाता है, जो एप्लिकेशन को सर्वर भाग से जोड़ता है और एपीआई के माध्यम से सर्वर भाग के साथ संचार करता है।

यदि आप विवरण को कम करते हैं, तो इंटरैक्शन का लक्ष्य दो चरणों तक कम हो जाता है:

एक। निर्धारित करें कि अभी कौन सा विज्ञापन दिखाना है;
ख। कौन सा विज्ञापन दिखाया गया और कौन सा नहीं, इसकी जानकारी भेजें और इसे आंकड़ों में प्रदर्शित करें।

वर्तमान में, Appodeal कई हजार सक्रिय एप्लिकेशन परोसती है, जो प्रति दिन लगभग 400-450 मिलियन विज्ञापन इंप्रेशन प्रदान करते हैं, जो विज्ञापन नेटवर्क (जो कि विज्ञापन प्रदान करने वाले हैं) के लगभग 1 बिलियन अनुरोधों के जवाब में प्राप्त हुए हैं। इस कार्य को करने के लिए, हमारे सर्वर प्रति सेकंड लगभग 125 हजार अनुरोधों की सेवा करते हैं, अर्थात्। प्रति दिन लगभग 10.8 बिलियन प्रश्न।

यह सब किस पर बनाया गया है?

हम विकास और समर्थन के लचीलेपन और एक ही समय में लचीलापन प्रदान करने के लिए विभिन्न तकनीकों का उपयोग करते हैं। फिलहाल, हम निम्नलिखित भाषाओं में कोड लिख रहे हैं:

• / रूबी / रूबी ऑन रेल्स + रिएक्ट.जेएस (फ्रंट-एंड) /: अभी भी एपीआई और पूरे वेब पार्ट का एक बड़ा हिस्सा है जिसे उपयोगकर्ता और हमारे कर्मचारी देखते हैं
• / GoLang /: बड़ी मात्रा में सांख्यिकी डेटा संसाधित करना और न केवल
• / स्काला /: आरटीबी प्रोटोकॉल का उपयोग करके ट्रैफ़िक एक्सचेंज एक्सचेंजों के साथ काम करने के लिए रीयल-टाइम अनुरोध (लेख के अंत में इसके बारे में और पढ़ें)
• / अमृत / फीनिक्स /: बल्कि प्रायोगिक भाग। कुछ आँकड़ों और एपीआई को संभालने के लिए कुछ सूक्ष्म सेवाओं का निर्माण।

यह मूल रूप से रूबी और रूबी रेल पर क्यों है?

Appodeal अपने सेगमेंट में बहुत बड़े खिलाड़ियों के साथ प्रतिस्पर्धा करती है, इसलिए आपको बाजार में बदलाव के लिए जल्दी से अनुकूल होना होगा। अक्सर यह 100 किमी / घंटा की गति से कार के पहियों में बदलाव की तरह महसूस होता है। रूबी ऑन रेल्स ने हमें दौड़ का सामना करने और बाजार में एक ऐसा मुकाम हासिल करने की अनुमति दी, जो अपने सेगमेंट में एक लीडर बन सके। हमारी राय में रेल के मुख्य लाभ:

• बड़ी संख्या में योग्य डेवलपर्स
• महान समुदाय। बड़ी संख्या में तैयार समाधान और पुस्तकालय
• नई सुविधाओं को शुरू करने और पुराने को बदलने / हटाने की गति

स्पष्ट minuses की:

• कुल मिलाकर प्रदर्शन खराब है। यह JIT (फिलहाल) की कमी को प्रभावित करता है, कोड को समानांतर बनाने की क्षमता की कमी (यदि आप JRuby को ध्यान में नहीं रखते हैं)। कुछ हद तक, यह सहने योग्य है क्योंकि अड़चन आमतौर पर डेटाबेस और कैश है। हम न्यूरेलिक से चित्र में क्या देखते हैं:

• रेल मोनोलिथ्स को माइक्रोसेर्विस पर बहुत अच्छी तरह से नहीं काटा जाता है - वे व्यापार तर्क और डेटा एक्सेस लॉजिक (ActiveRecord) के बीच उच्च स्तर की कनेक्टिविटी से प्रभावित होते हैं।

डेटा कैसे संग्रहीत किया जाता है?

हमारे पास बहुत सारा डेटा है। बहुत। हम अरबों / दसियों / सैकड़ों अरबों रिकॉर्डों के बारे में बात कर रहे हैं। चूंकि डेटा पूरी तरह से अलग है, हम उन्हें अलग-अलग तरीकों से संग्रहीत करते हैं। यह वास्तुकला में कभी भी किसी एक समाधान तक सीमित नहीं होना चाहिए, जो माना जाता है कि सार्वभौमिक है। अभ्यास से पता चलता है कि, सबसे पहले, हाईलोड में व्यावहारिक रूप से कोई सार्वभौमिक समाधान नहीं हैं। सार्वभौमिकता का अर्थ है इस अत्यंत बहुमुखी प्रतिभा के शुल्क के रूप में एक्सेस / रीड स्पीड / डेटा स्टोरेज साइज के लिए औसत (या औसत से काफी कम) संकेतक। दूसरे, आपको हर समय कुछ नया आज़माने की ज़रूरत है, कार्यों के लिए गैर-तुच्छ समाधान की तलाश करें। कुल:

• / PostgreSQL /: हमें Postgre से प्यार है। हम इसे फिलहाल सबसे अच्छा ओएलटीपी स्टोरेज समाधान मानते हैं। उपयोगकर्ता, एप्लिकेशन, विज्ञापन अभियान आदि के बारे में डेटा वहां संग्रहीत किया जाता है। हम प्राथमिक-प्रतिकृति प्रतिकृति का उपयोग करते हैं। हम केवल क्रिसमस की छुट्टियों पर बैकअप करते हैं, क्योंकि यह विम्प्स (एक मजाक) के लिए है।
• / VerticaDB /: स्तंभ-उन्मुख डेटाबेस। हम अरबों आँकड़े रिकॉर्ड करने के लिए उपयोग करते हैं। संक्षेप में, वर्टिका को कुछ समय के लिए एनालिटिक्स के भंडारण के लिए सबसे अच्छा OLAP समाधान माना जाता था। मुख्य नुकसान लाइसेंस के लिए बड़ी (व्यक्तिगत) कीमत है।
• / ClickHouse /: एक स्तंभ-उन्मुख डेटाबेस भी। धीरे-धीरे इसे वर्टिकाबीडी के साथ स्विच करें। हम इस समय सबसे अच्छा OLAP समाधान मानते हैं। एक पैसा भी नहीं। यह बहुत जल्दी और मज़बूती से काम करता है। मुख्य ऋण यह है कि डेटा को हटाया नहीं जा सकता है और अपडेट नहीं किया जा सकता है (हम इस बारे में एक अलग लेख में बात करेंगे, यदि कोई रुचि रखता है)।

Nichosi! डेटा को हटाना और संशोधित करना कैसे असंभव है?

• / Aerospike /: हमारी राय में सबसे तेज NoSQL कुंजी-मूल्य भंडारण। बहुत से मंत्री हैं, लेकिन सामान्य तौर पर हम संतुष्ट हैं। अन्य समाधानों के साथ उनके प्रदर्शन स्थल पर एयरोस्पाइक के लिए एक तुलना चार्ट भी है: [जब एयरोस्पेस नूएसक्यूएल डेटाबेस का उपयोग करना है तो बनाम। रेडिस] (https://www.aerospike.com/when-to-use-aerospike-vs-redis/)
• / रेडिस /: "मूली" के बारे में, मुझे लगता है, यह अलग से बताने का कोई मतलब नहीं है। विरोधाभासी रूप से, इसका मुख्य लाभ उपयोग और एकल-थ्रेडिंग में आसानी है, जो दौड़ की स्थिति से बचा जाता है, उदाहरण के लिए, जब सामान्य काउंटरों के साथ काम करते हैं।
• / ड्र्यूड /: हम RTB एक्सचेंजों के साथ काम में बड़े डेटा सेट के लिए उपयोग करते हैं। वास्तव में, अधिकांश भाग के लिए, वह ClickHouse के साथ एक ही मैदान पर खेलता है, लेकिन ऐतिहासिक रूप से, हम अभी तक किसी एक उपकरण पर स्विच नहीं कर पाए हैं।

ऐसा सेट ओवरलोडेड लग सकता है, लेकिन सबसे पहले, Appodeal कई विकास टीमों और एक के भीतर कई परियोजनाओं का एक बड़ा समूह है। और दूसरी बात, ये विज्ञापन तकनीक की कठोर वास्तविकताएं हैं - हम केवल एक कंपनी के अंदर मल्टी-स्टोरी स्टैक का उपयोग करने वाले नहीं हैं।

आप इसका अनुसरण कैसे करते हैं?

क्योंकि डेटा स्ट्रीम बड़ी हैं, उन्हें प्रोसेस करने के लिए कतारबद्ध होने की आवश्यकता है। कतार के रूप में हम काफ्का का उपयोग करते हैं। यह स्काला में लिखा गया एक महान विश्वसनीय समाधान है जो हमें अभी तक विफल नहीं हुआ है।



इस मामले में उपयोगकर्ता के लिए एकमात्र आवश्यकता यह है कि उसके पास बढ़ती हुई कतार की तुलना में तेज़ी से बढ़ने के लिए समय है। एक सरल और स्पष्ट नियम। इसलिए, इन उद्देश्यों के लिए, हम मुख्य रूप से GoLang का उपयोग करते हैं। हालांकि, यह इस तथ्य को नकारता नहीं है कि इस सर्वर पर रैम प्रचुर मात्रा में होनी चाहिए।

इस सभी अर्थव्यवस्था की निगरानी के लिए, आपको एक पंक्ति में शाब्दिक रूप से सब कुछ की निगरानी और प्रतिनिधि करना होगा। इसके लिए हम उपयोग करते हैं:

• / NewRelic /: एक समय-परीक्षणित समाधान जो रूबी के साथ रेल और गोलांग माइक्रो सेवाओं पर पूरी तरह से एकीकृत है। NewRelic का एकमात्र माइनस इसकी कीमत है। इसलिए, NewRelic हमारे साथ हर जगह नहीं है। अधिकांश भाग के लिए, हम इसे अपने हाथों से एकत्र किए गए मीट्रिक के साथ बदलने की कोशिश करते हैं - हमने उन्हें ग्राफाना में डाल दिया।
• / Statsd + Grafana /: अपने मैट्रिक्स को इकट्ठा करने के लिए एक अच्छी बात है। एकमात्र माइनस के साथ जिसे आपको खुद को सब कुछ कॉन्फ़िगर करना पड़ता है और बॉक्स से न्यूरेलिक कार्यक्षमता को "दोहराएं"।
• / इलास्टिकसर्च + फ्लुएंट + किबाना /: लॉग्स में हम सब कुछ एक पंक्ति में रखते हैं। धीमी पोस्टग्रेक्यूएल प्रश्नों से लेकर कुछ रेल प्रणाली संदेशों तक। दरअसल, इलास्टिकसर्च पर आधारित किबाना जैसा एक समाधान आपको सभी लॉग को एक स्थान पर आसानी से एकत्र करने और फिर उन पर आवश्यक संदेशों की खोज करने की अनुमति देता है।
• / Airbrake /: इसमें कंपल्सरी, मैसेज स्टेक्ट्रेस'आमी के साथ त्रुटियों को इकट्ठा करने की प्रक्रिया है। हम वर्तमान में Airbrake के साथ एक मुफ्त समाधान के लिए आगे बढ़ रहे हैं। एक कारण के लिए, फिर से, कीमतों।

आपको यह समझने की आवश्यकता है कि ठीक से निर्मित निगरानी आपकी आंखें और कान हैं। काम करने के लिए अंधा असंभव है। आपको यह देखने की जरूरत है कि किसी विशेष बिंदु पर आपके सर्वर पर क्या हो रहा है, इसलिए आपके उत्पाद की स्थिरता और विश्वसनीयता बहुत हद तक इस बात पर निर्भर करेगी कि आप मैट्रिक्स को इकट्ठा करने और प्रदर्शित करने के लिए कितने सिस्टम का निर्माण करते हैं।

वैसे, विश्वसनीयता की बात करें तो हमारे पास पूर्व-रोलिंग आउट और रिलीज़ की जाँच के लिए कई मंचन-सर्वर हैं, जिन्हें हम लोड के तहत स्थिर रखते हैं, जिससे कुछ वास्तविक ट्रैफ़िक की नकल होती है। हर हफ्ते हम उत्पादन और मंचन के बीच डेटाबेस को सिंक्रनाइज़ करते हैं। यह हमें एक प्रकार का "दर्पण" प्रदान करता है जो हमें उन चीजों का परीक्षण करने की अनुमति देता है जिन्हें स्थानीय स्तर पर सत्यापित नहीं किया जा सकता है, साथ ही लोड परीक्षण के स्तर पर समस्याओं की पहचान की जा सकती है।

क्या यह वास्तव में जटिल है?

यह इस तरह से पता चला है। जैसा कि एलोन मस्क ने अपनी पुस्तक में लिखा है: "मेरी पीढ़ी के सर्वश्रेष्ठ दिमाग लोगों को विज्ञापनों पर क्लिक करने में व्यस्त कर रहे हैं," जेफ़ हैमरबैकर, एक पूर्व फेसबुक इंजीनियर ने मुझे बताया। "डरावना ..." Appodeal क्या करता है की एक छोटी सूची:

• हम दो दर्जन विज्ञापन नेटवर्क और एजेंसियों के साथ एकीकृत हैं। स्वचालित मोड में, हम इन नेटवर्कों में एप्लिकेशन को पंजीकृत करते हैं, साथ ही विभिन्न मापदंडों को कॉन्फ़िगर करते हैं ताकि ये नेटवर्क अधिकतम प्रदर्शन पर काम करें। प्रत्येक नेटवर्क में संबंधित API नहीं होते हैं, कहीं न कहीं आपको इसे रोबोट के साथ करना होता है।
• प्रत्येक नेटवर्क उपयोगकर्ताओं को छापों के लिए राजस्व का भुगतान करता है, जिसे प्राप्त किया जाना चाहिए, विभिन्न मापदंडों द्वारा टूट गया और संसाधित किया जाना चाहिए। यह बिना रुके किया जाता है। कहीं, फिर से, रोबोट द्वारा।
• उपयोगकर्ता को अधिकतम आय प्रदान करने के लिए, हम विज्ञापन प्रस्तावों से तथाकथित "झरना" का निर्माण करते हुए ग्रिड एक दूसरे के साथ प्रतिस्पर्धा करते हैं। झरना विभिन्न संकेतकों के आधार पर बनाया गया है, उदाहरण के लिए, eCPM (प्रति 1000 छापों की औसत कीमत), जिसकी हम विभिन्न तरीकों से भविष्यवाणी करते हैं। जलप्रपात में विज्ञापन की पेशकश जितनी अधिक होगी, हम उतनी ही अधिक कीमत की भविष्यवाणी करेंगे। यह झरना डिवाइस पर जितनी बार आवश्यक हो पेश किया जाता है। जैसा कि आपने अनुमान लगाया होगा, एक ऐसा विज्ञापन जिस पर कोई भी क्लिक नहीं करता है और जो केवल सभी को नाराज करेगा वह किसी को भी दिलचस्पी नहीं लेता है। अपवाद केवल तथाकथित है। कोका-कोला, पेप्सी और अन्य कॉर्पोरेट दिग्गजों से "ब्रांडेड" बैनर विज्ञापन जो हमेशा और हर जगह अपने बारे में बात करने के लिए उपयोग किए जाते हैं।
• इस सहभागिता का एक हिस्सा तथाकथित आरटीबी (रियल-टाइम बिडिंग) प्रोटोकॉल पर बनाया गया है:

इस मामले में, तथाकथित बोलीदाताओं को चयनित डिवाइस पर अपने विज्ञापन दिखाने के अधिकार के लिए एक नीलामी में ऑनलाइन एक दूसरे के साथ कारोबार किया जाता है। एक बहुत ही दिलचस्प बिंदु एक अलग लेख के योग्य है। Google AdExchange जैसे कई एक्सचेंज, सर्वर रिस्पांस टाइम (उदाहरण के लिए, 50ms) के लिए एक तंग फ्रेमवर्क सेट करते हैं, जो परफॉर्मेंस एज-ऑन का मुद्दा बनता है। अवज्ञा के मामले में - हजारों डॉलर का जुर्माना। यह ठीक वैसा ही है जैसा कि स्काला में लिखा गया कर्नेल ड्र्यूड के संयोजन में करता है।

प्रत्येक शिकारी जानना चाहता है कि तीतर कहाँ बैठता है, और हमारे ग्राहक (हमारे जैसे) जानना चाहते हैं कि विज्ञापन किसको, कब और क्यों दिखाया गया था। इसलिए, हमें अपने पास मौजूद डेटा के सभी ढेर (कफ़्का) को धीरे-धीरे संसाधित करना होगा और OLAP डेटाबेस (ClickHouse) में जोड़ना होगा। बहुत से लोग सोचते हैं कि PostgreSQL इस कार्य को किसी भी "हिपस्टर" समाधान से बदतर नहीं करेगा, लेकिन ऐसा नहीं है। PostgreSQL अच्छा है, लेकिन डेटा एक्सेस स्पीड के लिए अनुक्रमित निर्माण के लिए क्लासिक समाधान तब काम करना बंद कर देता है जब फ़िल्टरिंग और सॉर्टिंग के लिए फ़ील्ड की संख्या 10 से अधिक हो जाती है, और संग्रहीत डेटा की मात्रा 1 बिलियन रिकॉर्ड तक पहुंच जाती है। इन सभी सूचियों को संग्रहीत करने के लिए आपके पास पर्याप्त मेमोरी नहीं है या आपको इन अनुक्रमणिकाओं को अपडेट करने में समस्याएँ होंगी। किसी भी स्थिति में, आप विश्लेषणात्मक प्रश्नों के स्तंभ-उन्मुख समाधान के समान प्रदर्शन प्राप्त करने में सक्षम नहीं होंगे।

निष्कर्ष

इस लेख में, मैंने कम से कम संक्षेप में यह बताने की कोशिश की कि हम क्या करते हैं, हम डेटा को कैसे स्टोर और प्रोसेस करते हैं। हमें टिप्पणियों में बताएं कि आप किस स्टैक का उपयोग करते हैं, सवाल पूछते हैं और नए लेखों का अनुरोध करते हैं - हमें अपने अनुभव को साझा करने में खुशी होगी।