Appodeal هي شركة تضم حوالي 100 شخص يعملون في موسكو وسان فرانسيسكو وبارول ولوتسك وكيروف وبرشلونة ، ومنذ يونيو 2018 أيضًا في مينسك.
نستثمر تطبيقات الجوال من خلال عرض الإعلانات للمستخدمين. لقد بدأنا بوساطة إعلانية ، لكن مجموعة التكنولوجيا تنمو باستمرار ، لذلك تمت إضافة منتجات أخرى من صناعة Ad Tech إلى الوساطة.
بالنسبة لأولئك الذين ليسوا على دراية بـ Ad Tech ، فهذا هو مجال عمل شركات التكنولوجيا التي تعمل في مجال الإعلان. عندما تخبر شخصًا ما بأنك تعمل في مجال إعلانات الجوّال ، غالبًا ما يتفاعل الناس مع الشك - على ما يبدو ، يتبادر إلى الذهن الإعلان المزعج "Azino Three Axes". في الواقع ، هذا مجرد غيض من فيض ، وكل هذه الإعلانات "البرية" لا علاقة لها بأعمال الإعلان الحقيقية.
وقد تجاوز قطاع الإعلان الذي نشارك فيه طويلًا شريحة الإعلان على الويب:
لماذا دمج الإعلانات في التطبيقات؟
بالطبع ، يتم إنفاق الكثير من الموارد على إنشاء التطبيقات - ويريد منشئو المحتوى / المالكون الوقت والجهد المبذولين في الدفع. يُطلق على مالكي تطبيقات الجوّال الذين ينشرون تطبيقاتهم على App store / Google Play ناشرين أو ناشرين. يطبق الناشرون نماذج مختلفة لتحقيق الدخل ، من عمليات الشراء داخل التطبيق إلى تحقيق الدخل من الإعلانات. ولكن من بين كل هذه الطرق ، فإن الطريقة الأخيرة فقط تسمح للمستخدم بعدم الدفع مقابل استخدام التطبيق - وهذا يعطي أكبر تغطية للجمهور.
نعم ، إذا كان هناك الكثير من الإعلانات ، فسيزعج الجميع ويؤثر سلبًا على الاحتفاظ بالمستخدم. وهو بالطبع لا يحتاجه أحد. لذلك ، يحاولون دائمًا دمج الإعلانات بحكمة من أجل كسب الحد الأقصى من المال في تطبيقهم وفي الوقت نفسه عدم أخذ فلسا واحدًا من المستخدمين.
كيف يعمل؟
بمجرد أن يقرر الناشر تحقيق الدخل من خلال الإعلانات ، يأتي إلى الشركة التي يمكن أن تجعل هذه المهمة سهلة قدر الإمكان بالنسبة له. كيف يحدث هذا مع Appodeal؟ بعد التسجيل على الموقع ، نقوم بدمج طلبه مع خدمتنا. يتم ذلك من خلال SDK العميل ، الذي يربط التطبيق بجزء الخادم ويتواصل مع جزء الخادم من خلال API.
إذا قمت بتصغير التفاصيل ، يتم تقليل هدف التفاعل إلى مرحلتين:
أ. تحديد الإعلان الذي سيتم عرضه الآن ؛
ب. إرسال معلومات حول الإعلان الذي تم عرضه وأيه لا ، وعرضه في الإحصائيات.
في الوقت الحالي ، تخدم Appodeal عدة آلاف من التطبيقات النشطة التي توفر ما يقرب من 400-450 مليون مرة ظهور للإعلان يوميًا ، والتي يتم تلقيها استجابة لحوالي مليار طلب لشبكات الإعلانات (والتي هي من مقدمي الإعلانات). لجعل هذا العمل ، تخدم خوادمنا حوالي 125 ألف طلب في الثانية ، أي ما يقرب من 10.8 مليار استفسار يوميًا.
ما كل هذا مبني عليه؟
نحن نستخدم تقنيات مختلفة لتوفير السرعة والموثوقية ومرونة التطوير والدعم في نفس الوقت. في الوقت الحالي ، نكتب الرمز باللغات التالية:
- / Ruby / Ruby on Rails + React.JS (الواجهة الأمامية) /: لا يزال هناك جزء كبير من واجهة برمجة التطبيقات وجزء الويب بالكامل الذي يراه المستخدمون وموظفونا
- / GoLang /: معالجة كميات كبيرة من البيانات الإحصائية وليس فقط
- / Scala /: طلبات معالجة الوقت الفعلي للعمل مع تبادل التبادل المروري باستخدام بروتوكول RTB (اقرأ المزيد عنه في نهاية المقال)
- / إكسير / فينيكس /: الجزء التجريبي. بناء بعض الخدمات الصغيرة للتعامل مع بعض الإحصائيات وواجهات برمجة التطبيقات.
لماذا هو في الأصل روبي وروبي على القضبان؟
تتنافس Appodeal في فئتها مع لاعبين كبار جدًا ، لذلك عليك التكيف بسرعة مع تغيرات السوق. غالبًا ما يبدو هذا وكأنه تغيير في عجلات السيارة بسرعة 100 كم / ساعة. سمحت لنا روبي أون ريلز بتحمل السباق والحصول على موطئ قدم في السوق بما يكفي لتكون رائدة في فئتها. المزايا الرئيسية للسكك الحديدية في رأينا:
- عدد كبير من المطورين المؤهلين
- مجتمع عظيم. عدد ضخم من الحلول والمكتبات الجاهزة
- سرعة إدخال ميزات جديدة وتغيير / حذف الميزات القديمة
من السلبيات الواضحة:
- الأداء العام ضعيف. كما أنه يؤثر على نقص JIT (في الوقت الحالي) ، ونقص القدرة على موازاة الكود (إذا لم تأخذ JRuby في الاعتبار). إلى حد ما ، يبقى هذا محتملاً لأن الاختناق عادة ما يكون قاعدة البيانات وذاكرة التخزين المؤقت. ما نراه في الصورة من NewRelic:
- لا يتم قطع متراصة السكك الحديدية بشكل جيد جدًا على الخدمات الصغيرة - فهي تتأثر بدرجة عالية من الاتصال بين منطق الأعمال ومنطق الوصول إلى البيانات (ActiveRecord).
كيف يتم تخزين البيانات؟
لدينا الكثير من البيانات. جدا. نحن نتحدث عن المليارات / عشرات / مئات المليارات من السجلات. نظرًا لأن البيانات مختلفة تمامًا ، فإننا نخزنها بطرق مختلفة. يجب ألا يقتصر أبدًا في الهندسة على أي حل واحد ، والذي يفترض أنه عالمي. تُظهر الممارسة أنه ، أولاً ، في Highload لا توجد حلول عالمية عمليًا. تعني العالمية متوسط (أو أقل بكثير من المتوسط) مؤشرات للوصول / سرعة القراءة / حجم تخزين البيانات كرسوم مقابل هذا التنوع. ثانيًا ، تحتاج إلى تجربة شيء جديد طوال الوقت ، والتجربة والبحث عن حلول غير تافهة للمهام. المجموع:
- / PostgreSQL /: نحن نحب Postgre. نعتبره أفضل حل تخزين OLTP في الوقت الحالي. يتم تخزين البيانات حول المستخدمين والتطبيقات والحملات الإعلانية وما إلى ذلك. نحن نستخدم النسخ المتماثل الأساسي. نقوم بعمل نسخ احتياطية فقط في عطلة عيد الميلاد ، لأن هذا للجبناء (مزحة).
- / VerticaDB /: قاعدة بيانات موجهة نحو العمود. نستخدمها لتخزين مليارات السجلات الإحصائية. باختصار ، تم اعتبار Vertika لبعض الوقت أفضل حل OLAP لتخزين التحليلات. العيب الرئيسي هو الثمن الضخم (الفردي) للرخصة.
- / ClickHouse /: أيضًا قاعدة بيانات موجهة نحو العمود. انتقل إليه تدريجيًا باستخدام VerticaDB. نعتبر أفضل حل OLAP في الوقت الحالي. لا يستحق قرش. يعمل بسرعة وموثوقية. النقص الرئيسي هو أنه لا يمكن حذف البيانات وتحديثها (سنتحدث عن هذا في مقال منفصل ، إذا كان أي شخص مهتمًا).
لا شيء! كيف يستحيل حذف وتعديل البيانات ؟!
- / Aerospike /: أسرع تخزين بقيمة مفتاح NoSQL في رأينا. هناك عدد من السلبيات ، ولكن بشكل عام نحن راضون. هناك أيضًا مخطط مقارنة لـ Aerospike على موقع أدائهم مع حلول أخرى: [متى يتم استخدام قاعدة بيانات Aerospike NoSQL مقابل. Redis] (https://www.aerospike.com/when-to-use-aerospike-vs-redis/)
- / Redis /: حول "الفجل" ، أعتقد أنه ليس من المنطقي أن نقول بشكل منفصل. ومن المفارقات ، أن ميزته الرئيسية هي سهولة الاستخدام والخيوط الفردية ، والتي تتجنب ظروف العرق ، على سبيل المثال ، عند العمل مع العدادات الشائعة.
- / Druid /: نستخدم لمجموعات البيانات الكبيرة في العمل مع تبادلات RTB. في الواقع ، في معظم الأحيان ، يلعب في نفس المجال مع ClickHouse ، ولكن من الناحية التاريخية ، لم نتمكن من التبديل إلى أي آلة واحدة حتى الآن.
قد تبدو هذه المجموعة مثقلة ، ولكن أولاً ، Appodeal هي مجموعة كبيرة من العديد من فرق التطوير والعديد من المشاريع داخل فريق واحد. وثانيًا ، هذه هي الحقائق القاسية لتقنية الإعلان - نحن لسنا الوحيدين الذين يستخدمون مجموعة متعددة الطوابق داخل شركة واحدة.
كيف تتبع هذا؟
نظرًا لأن تدفقات البيانات كبيرة ، يجب وضعها في قائمة الانتظار لمعالجتها. كقائمة انتظار ، نستخدم Kafka. هذا حل موثوق به عظيم مكتوب بلغة سكالا لم يخذلنا حتى الآن.
الشرط الوحيد للمستخدم في هذه الحالة هو أنه لديه الوقت الكافي لنسخ قائمة الانتظار المتزايدة بشكل أسرع مما ينمو. قاعدة بسيطة وواضحة. لذلك ، لهذه الأغراض ، نستخدم بشكل رئيسي GoLang. ومع ذلك ، هذا لا ينفي حقيقة أن ذاكرة الوصول العشوائي على هذا الخادم يجب أن تكون وفيرة.
لمراقبة كل هذا الاقتصاد ، يجب عليك مراقبة وتفويض كل شيء على التوالي. لهذا نستخدم:
- / NewRelic /: حل تم اختباره عبر الزمن يتكامل تمامًا مع خدمات Ruby on Rails و GoLang الدقيقة. ناقص NewRelic الوحيد هو سعره. لذلك ، NewRelic ليس معنا في كل مكان. بالنسبة للجزء الأكبر ، نحاول استبداله بمقاييسنا التي تم جمعها يدويًا - نضعها في Grafana.
- / Statsd + Grafana /: شيء جيد لجمع مقاييسك. مع ناقص الوحيد الذي لديك لتكوين كل شيء بنفسك و "كرر" وظيفة NewRelic من خارج منطقة الجزاء.
- / ElasticSearch + Fluentd + Kibana /: في السجلات وضعنا كل شيء على التوالي. من استعلامات PostgreSQL البطيئة إلى بعض رسائل نظام ريلز. في الواقع ، يتيح لك حل مثل Kibana استنادًا إلى ElasticSearch تجميع جميع السجلات بسهولة في مكان واحد ثم البحث عن الرسائل اللازمة عليها.
- / Airbrake /: إلزامي في هذا عملية جمع الأخطاء مع stacktrace'ami للرسالة. ننتقل حاليًا باستخدام Airbrake إلى أحد الحلول المجانية. لسبب ، مرة أخرى ، الأسعار.
عليك أن تفهم أن المراقبة المصممة بشكل صحيح هي عينيك وأذنيك. من المستحيل أعمى للعمل. تحتاج إلى معرفة ما يحدث على خوادمك في وقت معين ، لذلك يعتمد استقرار وموثوقية منتجك إلى حد كبير على مدى كفاءة بناء نظام لجمع وعرض المقاييس.
بالمناسبة ، بالحديث عن الموثوقية ، نوفر العديد من خوادم التدريج للتدقيق المسبق والتحقق من الإصدارات ، والتي نحافظ عليها مستقرة تحت التحميل ، وتكرار بعض حركة المرور الحقيقية هناك. نقوم كل أسبوع بمزامنة قواعد البيانات بين الإنتاج والتدريج. وهذا يمنحنا نوعًا من "المرآة" التي تسمح لنا باختبار تلك الأشياء التي لا يمكن التحقق منها محليًا ، بالإضافة إلى تحديد المشكلات على مستوى اختبار الحمل.
هل هو حقا معقد؟
اتضح بهذه الطريقة. كما كتب لي Elon Musk في كتابه: "أفضل العقول في جيلي مشغولة في جعل الناس ينقرون على الإعلانات" ، أخبرني جيف هامرباخر ، مهندس فيسبوك. "رعب ..." قائمة قصيرة بما يفعله Appodeal:
- نحن مدمجون مع عشرين شبكة ووكالات إعلانية. في الوضع التلقائي ، نقوم بتسجيل التطبيقات في هذه الشبكات ، بالإضافة إلى تكوين معلمات متنوعة بحيث تعمل هذه الشبكات بأقصى أداء. لا تحتوي كل شبكة على واجهات برمجة تطبيقات مقابلة ، في مكان ما عليك القيام به مع الروبوتات.
- تدفع كل شبكة أرباحًا للمستخدمين مقابل مرات الظهور ، التي يجب استلامها ، وتقسيمها حسب المعلمات المختلفة ومعالجتها. يتم ذلك دون توقف. في مكان ما ، مرة أخرى ، بواسطة الروبوتات.
- من أجل تزويد المستخدم بأقصى قدر من الدخل ، "نجعل" الشبكات تتنافس مع بعضها البعض ، وبناء ما يسمى "الشلال" من العروض الإعلانية. تم بناء الشلال على أساس مؤشرات مختلفة ، على سبيل المثال ، التكلفة الفعلية لكل ألف ظهور (متوسط السعر لكل 1000 ظهور) ، والذي نتوقعه بطرق مختلفة. كلما ارتفع عرض الإعلان في الشلال ، كلما توقعنا سعره. يتم تقديم هذا الشلال على الجهاز كلما كان ذلك مطلوبًا. كما كنت قد خمنت ، فإن الإعلان الذي لا ينقر عليه أحد والذي سيزعج الجميع فقط لا يثير اهتمام أي شخص. الاستثناء هو فقط ما يسمى. إعلانات بانر "ذات العلامات التجارية" من كوكا كولا وبيبسي وعمالقة شركات آخرين اعتادوا على التحدث عن أنفسهم دائمًا وفي كل مكان.
- جزء من هذا التفاعل مبني على بروتوكول يسمى RTB (Real-Time Bidding):
في هذه الحالة ، يتم تداول ما يسمى بالمزايدين مع بعضهم البعض عبر الإنترنت في مزاد للحصول على الحق في عرض إعلاناتهم على الجهاز المحدد. نقطة مثيرة جدا للاهتمام تستحق مقالة منفصلة. تقوم العديد من التبادلات ، مثل Google AdExchange ، بتعيين إطار عمل ضيق لوقت استجابة الخادم (على سبيل المثال ، 50 مللي ثانية) ، مما يطرح مشكلة في الأداء. في حالة العصيان - غرامة آلاف الدولارات. هذا بالضبط ما تفعله النواة المكتوبة في سكالا بالاشتراك مع درويد.
يريد كل صياد معرفة مكان جلوس الدراج ، ويريد عملاؤنا (مثلنا) معرفة من تم عرض الإعلان عليه ، ومتى ولماذا. لذلك ، علينا أن نضع في قائمة الانتظار (كافكا) جميع كومة البيانات التي لدينا ، ونعالجها ونضيفها تدريجياً إلى قاعدة بيانات OLAP (ClickHouse). يعتقد الكثير من الناس أن PostgreSQL لن تتعامل مع هذه المهمة ليس أسوأ من أي حلول "محب" ، ولكن الأمر ليس كذلك. PostgreSQL جيد ، ولكن الحل الكلاسيكي لإنشاء فهارس لسرعة الوصول إلى البيانات يتوقف عن العمل عندما يتجاوز عدد حقول التصفية والفرز 10 ، ويقترب حجم البيانات المخزنة من مليار سجل. ببساطة ليس لديك ذاكرة كافية لتخزين كل هذه الفهارس أو ستواجه مشاكل في تحديث هذه الفهارس. على أي حال ، لن تكون قادرًا على تحقيق نفس الأداء مثل الحلول الموجهة نحو العمود للاستعلامات التحليلية.
الخلاصة
في هذه المقالة ، حاولت أن أصف بإيجاز على الأقل ما نقوم به ، وكيف نقوم بتخزين البيانات ومعالجتها. أخبرنا في التعليقات عن المكدس الذي تستخدمه ، واطرح الأسئلة واطلب مقالات جديدة - يسعدنا مشاركة تجربتنا.