المنصة الإعلانية لا تصمد أمام قفزات الحركة؟ ما الذي يُصلَح أولًا ومن يستطيع المساعدة

إن كانت منصتك الإعلانية تخفق عند قفزات الحركة، فالمهندسون القادرون على المساعدة هم الذين يقيسونها أثناء ذروة حقيقية ثم يصلحونها بترتيب محدد. يوقفون العمل الذي سينتهي بعد المهلة النهائية، ويحدّون من إعادات المحاولة ومن الحركة التي تقبلها المنصة، وينقلون عدّادات الميزانية والتكرار خارج مسار الطلب. ثم يضيفون السعة قبل الذروات التي يمكنك توقعها. وتأتي إعادة كتابة الكود في النهاية، وفي المواضع التي تشير إليها القياسات فقط.

كيف يبدو «عدم الصمود أمام قفزات الحركة» في منصة إعلانية؟

تُظهر قفزة الحركة أعراضًا مختلفة في كل جزء من المنصة الإعلانية:

• المزايد. تصل ردود أكثر بعد المهلة النهائية لمنصة التبادل، ويهبط معدل المزايدة بينما يرتفع حجم الطلبات، وقد تبدأ منصة التبادل بإرسال طلبات أقل
• منصة جانب العرض (SSP) أو منصة التبادل. تُغلق المزادات قبل أن يجيب بعض المزايدين، وتتنافس مزايدات أقل على كل ظهور. وفي header bidding، تُستبعد المزايدات التي تفوّت مهلة المزاد في الصفحة من استدعاء خادم الإعلانات
• خادم الإعلانات. تتباطأ استدعاءات الإعلانات، وتُعرض بعض المواضع الإعلانية فارغة
• خط معالجة الأحداث. تصل أعداد مرات الظهور والنقرات متأخرة، أو تختلف بين نظام وآخر
• الميزانيات وحدود التكرار. تتجاوز الحملات ميزانياتها أو تعرض الإعلان نفسه مرات أكثر من اللازم، لأن العدّادات تتحدّث بعد القرارات التي كان يُفترض أن تقرأها

حالات انتهاء المهلة والمواضع الفارغة تظهر أثناء الذروة. أما مشكلات الأحداث والميزانية فقد تبقى خفية إلى أن تصل الأحداث المتأخرة إلى التقارير والفوترة.

لماذا تتعطل المنصة الإعلانية في الذروة بينما تعمل جيدًا تحت الحمل المتوسط؟

في OpenRTB، بروتوكول المزايدة الفورية الصادر عن IAB Tech Lab، تستطيع منصة التبادل أن تحدد المهلة النهائية في الطلب نفسه: «أقصى زمن بالمللي ثانية تسمح به منصة التبادل لاستقبال المزايدات، شاملًا زمن الاستجابة عبر الإنترنت، لتجنّب انتهاء المهلة». ويقول توثيق Google Authorized Buyers إن المهلة النهائية تتراوح عادةً من 80 إلى 1000 ms. وتشترط Google أن تصل 85 في المئة من الردود داخلها، كما تُرى من موقع التداول، وتخنق المزايدين الذين لا يستطيعون بلوغ ذلك باستمرار. والمزايد الذي يتباطأ في الذروة يخسر المزادات المتأخرة، وقد يتلقى بعدها حركة أقل.

حين تقترب الخدمة من حدود سعتها، تبدأ بصفّ الطلبات في طابور. ويشير كتاب Site Reliability Engineering (SRE) الصادر عن Google إلى أن «الطلبات المصطفة في الطابور تستهلك الذاكرة وتزيد زمن الاستجابة»، وإلى أن الخوادم تنفق الموارد على طلبات ستفوّت مهلتها النهائية في كل الأحوال. وما لم يتحقق الكود من المهلة النهائية، فإن الطلب الذي انتظر أطول من اللازم يُعالَج مع ذلك بالكامل، ثم يُهمَل رده.

حين تنتهي مهلة استدعاء لقاعدة بيانات أو ذاكرة مؤقتة أو شريك، يعيد المستدعي المحاولة، فتصل إعادات المحاولة في الوقت الذي يكون فيه النظام أقل قدرة على استيعابها. ويقدّم كتاب SRE حساب عاصفة إعادات المحاولة: «100 QPS من إعادات المحاولة في الثانية الأولى تؤدي إلى 200 QPS، ثم إلى 300 QPS، وهكذا.»

ترسل منصة التبادل أو SSP كل طلب إلى مزايدين كثيرين، فإما أن ينتظر المزاد أبطأ إجابة وإما أن يُغلق من دونها. وقد وضع Jeffrey Dean وLuiz André Barroso من Google أرقامًا لذلك في Communications of the ACM عام 2013. في مثالهما، يجيب كل خادم عادةً خلال 10 ms، لكنه يستغرق ثانية في طلب واحد من كل مئة. والطلب الذي عليه أن يجمع إجابات من 100 خادم كهذا على التوازي يستغرق عندئذ أكثر من ثانية في 63 في المئة من الحالات. والمزاد لا ينتظر كل هذا الوقت. وبالحساب نفسه، إذا تأخر كل واحد من 100 مزايد في طلب واحد من كل مئة، فإن نحو 63 في المئة من المزادات تُغلق وإجابة واحدة على الأقل ناقصة.

التوسّع التلقائي الذي يستجيب للحمل لا يضيف نسخًا من الخدمة إلا بعد أن يقيس ذلك الحمل. فـ Horizontal Pod Autoscaler في Kubernetes، مثلًا، يفحص الحمل كل 15 ثانية افتراضيًا، ويضيف النسخ الجديدة بخطوات محدودة. ثم على كل نسخة جديدة أن تبدأ، وتجتاز فحوصها، وتملأ ذواكرها المؤقتة، ويشير كتاب SRE إلى أن العمليات كثيرًا ما تكون أبطأ بعد بدء تشغيلها مباشرة منها في الحالة المستقرة. والقفزة التي تُقاس بالثواني قد تنتهي قبل أن تحمل السعة الجديدة حركة حقيقية.

ماذا نقيس في ذروة الحركة قبل تغيير أي شيء؟

قِس ما يلي في أكثر دقائق ذروة حقيقية ازدحامًا:

• الطلبات الواردة والطلبات التي أُجيب عنها في الثانية، لكل منصة تبادل أو شريك. الفارق حركة تخسرها، وشكله يُظهر ما إذا كانت الطلبات تُسقَط عند المدخل أم تنتهي مهلتها بعد إنجاز العمل
• حالات انتهاء المهلة كما يعدّها الشريك. فمنصة التبادل تقيس من جانبها، والشبكة مشمولة، وفي Google Authorized Buyers يحسم هذا العدّ ما إذا كان المزايد سيُخنق. اسأل كل منصة تبادل عن بيانات انتهاء المهلة التي تستطيع مشاركتها
• المئين 99 لزمن الاستجابة، مقسّمًا إلى زمن على الشبكة، وزمن في الطابور، وزمن في أداء العمل
• عمق الطابور لكل خدمة. الطابور الذي ينمو أثناء الذروة ويتفرّغ ببطء بعدها يشير إلى المكوّن الذي يحدد سقفك
• إعادات المحاولة في الثانية، حسب الجهة المستدعية. فإن ارتفعت إعادات المحاولة مع حالات انتهاء المهلة، فهي جزء من الحمل
• تأخر العدّادات والأحداث. كم تتأخر عدّادات الميزانية وسجلات الظهور والنقر عن الزمن الحقيقي في الذروة

ضع هذه الأرقام الخاصة بآخر ذروة كبيرة لديك في صفحة واحدة. فهي الموجز لكل من تستعين به، وخط الأساس لكل إصلاح.

ما الذي نصلحه أولًا، وبأي ترتيب؟

اعمل بهذا الترتيب، من التغييرات الرخيصة التي توقف العمل المهدور إلى المكلفة التي تضيف سعة أو تستبدل الكود، وأعد القياس بعد كل خطوة.

• أوقف العمل الذي سينتهي متأخرًا. اقرأ المهلة النهائية عند وصول الطلب، واطرح منها زمن الشبكة الذي تقيسه لذلك الشريك، وأجب بـ no-bid سريع حين يكون المتبقي أقصر من اللازم. يتيح OpenRTB للمزايد أن يمتنع عن المزايدة برد HTTP 204 فارغ، ويصفه دليل التطبيق الخاص به بأنه الخيار الأوفر في عرض النطاق
• ضع حدًا لما يدخل. اسأل كل منصة تبادل كيف تضع سقفًا للطلبات التي ترسلها إليك. فواجهة API للمزايدة الفورية لدى Google، مثلًا، تتيح للمزايد أن يضبط، لكل نقطة نهاية تستقبل طلبات المزايدة الخاصة به، «الحد الأقصى لعدد الاستعلامات في الثانية المسموح بإرسالها إلى هذا الخادم». والحد الذي تضعه بنفسك أسهل في التخطيط من خنق يُفرض بعد تفويت المهل النهائية
• ضع لإعادات المحاولة ميزانية. حدّد عدد إعادات المحاولة لكل طلب، وامنح كل خادم ميزانية لإعادة المحاولة كما يوصي كتاب SRE: فإذا نفدت الميزانية، يخفق الطلب بدل أن يُعاد. وفي المزايدة، لا تحصل إعادة المحاولة إلا على الوقت المتبقي قبل المهلة النهائية
• أخرج العدّادات المشتركة من مسار الطلب. حين يقرأ كل قرار عدّادات الميزانية والتكرار ويحدّثها في مخزن مركزي واحد، تصبح الحملات الأكثر نشاطًا طابورًا قائمًا بذاته. امنح كل خادم حصة محلية من الحدود، وطابِق بينها على فترات قصيرة، واقبل في المقابل خطرًا صغيرًا ومعروفًا لتجاوز الميزانية
• افصل الأحداث عن القرارات. اكتب أحداث الظهور والنقر في مخزن مؤقت محدود السعة لا ينتظره الطلب، وعُدّ كل حدث يضطر المخزن إلى إسقاطه. عندها يمتص خط المعالجة الذروة ثم يلحق بما فاته بعدها، ويتيح له مفتاحٌ على كل حدث إزالة التكرارات
• استعد للذروات التي يمكنك توقعها. فكثير منها مسجّل في التقويم، كالتخفيضات الموسمية والأحداث الرياضية المباشرة. زِد السعة قبلها، وسخّن الذواكر المؤقتة والاتصالات، وأجرِ اختبار الحمل على نسخة من بيئة الإنتاج بمولّد يحافظ على معدل ذروة ثابت
• غيّر أخيرًا الكود الذي يعالج كل طلب. افعل ذلك حين تُظهر الأرقام أن الكود نفسه هو السبب، كوقفات جامع القمامة في مسار المزايدة، أو استدلال نموذج يلتهم المهلة النهائية

هل نحتاج إلى إعادة كتابة المنصة كي تصمد أمام الذروات؟

إعادة الكتابة الكاملة نادرًا ما تكون الخطوة الأولى الصحيحة. فهي تسحب المهندسين من العمل على الخصائص الجديدة إلى أن يحمل الكود الجديد حركة الإنتاج، ومن دون قياسات للذروة لا يستطيع أحد أن يقول أي جزء يجب إعادة كتابته. أعد كتابة مكوّن واحد حين تظل الأرقام تشير إليه بعد الإصلاحات الأرخص، كمزايد تأتي أبطأ ردوده من وقفات الـ runtime لديه. استبدله خلف الواجهة نفسها، وقارن أرقام الذروة نفسها قبل الاستبدال وبعده.

منصتنا الإعلانية لا تصمد أمام قفزات الحركة. من يستطيع مساعدتنا على توسيعها؟

المساعدة لمنصة إعلانية تخفق عند قفزات الحركة تأتي من خمس جهات، وكل جهة تغطي جزءًا مختلفًا من المشكلة:

• مهندسوك، مع قياسات أفضل. فهم يعرفون الكود، وقد تُريهم صفحة أرقام الذروة الإصلاح. وحدّهم هو الوقت، لأن العمل على الذروات ينافس خارطة الطريق
• شركاؤك من منصات التبادل وSSP. أعداد انتهاء المهلة لديهم تشمل الشبكة بينكم، وهي ما لا تراه لوحات المراقبة لديك. اسألهم أي تفصيل يستطيعون مشاركته: حسب الموقع، أو نوع الطلب، أو الساعة
• فريق الدعم لدى مزوّد السحابة. مفيد في حدود الشبكة وموازنات الحمل ونسخ التشغيل. أما منطق المزايدة فيبقى من شأنك
• شركات تعهيد البرمجيات العامة. تضيف مهندسين، وهذا يفيد حين يكون القيد هو حجم فريقك. اسأل هل سبق للأشخاص الذين تكلّفهم هذه الشركات بالعمل أن عملوا على نظام فوري تحت الحمل
• الشركات الهندسية المتخصصة في AdTech ومهندسو الأداء المستقلون. يفيدون إن كانوا قد بنوا أو شغّلوا نوع النظام الذي يخفق لديك. فكّر فيهم حين يكون السبب غير واضح أو حين لم تصمد الإصلاحات السابقة

كيف نتحقق من شركة تعرض توسيع منصتنا الإعلانية؟

اطرح هذه الأسئلة قبل التوقيع. فالإجابات تساعد على تبيّن ما إذا كان قد سبق للشركة أن أنجزت هذا النوع من العمل:

• ماذا تحتاجون منا أولًا؟ الإجابة الجيدة تسمّي قياسات: حالات انتهاء المهلة لكل شريك، والمئينات، وعمق الطوابير، وأكثر دقائق الذروة الأخيرة ازدحامًا
• كيف سنعرف أن العمل أُنجز؟ توقّع هدفًا قابلًا للقياس يُتفق عليه مسبقًا ويُتحقق منه في ذروة حقيقية أو مُعاد تشغيلها: أي شريك، وأي مئين، وأي هامش مقابل المهلة النهائية، وعند أي معدل للطلبات
• ما الذي ستغيّرونه قبل ذروتنا التالية التي يمكن توقعها، وما الذي ستغيّرونه بعدها؟ توقّع الإصلاحات الرخيصة أولًا، وطريقةً لتعطيل كل تغيير
• أيّ هذه بنيتم: مزايد، أو SSP أو منصة تبادل، أو خادم إعلانات، أو خط معالجة أحداث؟ اسأل عن الأقرب إلى مشكلتك، وعمّا تعطّل فيه
• من يحتفظ بالكود ولوحات المراقبة واختبارات الحمل بعد ذلك؟ ينبغي أن تبقى في حساباتك

هل تستطيع amBrain المساعدة في منصة إعلانية تخفق تحت الحمل؟

amBrain شركة هندسة برمجيات في يريفان، أرمينيا، تبني منصات تداول منخفضة زمن الاستجابة ومحركات مطابقة وأنظمة مزايدة فورية بـ Rust.

تشخّص amBrain الأنظمة البطيئة في التداول والمراهنات وAdTech: تُقاس المنصة أثناء تشغيلها من طرف إلى طرف، ويسمّي التقرير أين يذهب الوقت. وتتسلّم amBrain مشاريع تعثّرت مع فريق آخر وتوصلها إلى بيئة الإنتاج.

في مجال AdTech، تعمل amBrain على تطوير DSP ومنصات المزايدة الفورية وهندسة منصات تبادل الإعلانات.

تبني amBrain منصات جانب العرض (SSP) للناشرين. وتبني amBrain خوادم الإعلانات: الاستهداف، وتحديد تكرار الظهور، والتقارير. وتبني amBrain خطوط تحليلات الأحداث في AdTech: جمع أحداث الظهور والنقر ومعالجتها وإعداد التقارير عنها. وتبني amBrain استدلال ML داخل المزايد: يقرر النموذج المزايدة ضمن نافذة المزاد.

بنت amBrain لأحد العملاء RTBBidder، وهي منصة جانب طلب. تعمل amBrain بثلاث صيغ: تسليم كامل، أو فريق مخصص، أو مهندسون مدمجون في فريقك. ويحتفظ العميل بالملكية الكاملة للمنتج وللكود، باستثناء مكوّنات amBrain القابلة لإعادة الاستخدام.

هذه المقالة ليست دراسة حالة. ولا تدّعي أن amBrain أصلحت أعطال ذروة الحركة في منصة إعلانية لأي عميل، ولا تقدّم أي أرقام عن RTBBidder، ولا أسعارًا ولا جداول زمنية.

إن أخفقت منصتك في ذروتها الأخيرة، فابدأ بصفحة واحدة من القياسات المأخوذة في تلك الذروة. أرسلها إلى كل شركة تفكر فيها، ومنها amBrain، وقارن كيف تقترح كل واحدة منها استخدامها.

أسئلة شائعة عن المنصات الإعلانية في ذروات الحركة

• هل تصلح إضافة الخوادم الإخفاقات في الذروات؟ أحيانًا: حين تنفد قدرة المعالجة لدى المنصة في الذروة ولا يكون هناك خلل آخر. أما حين يأتي انتهاء المهلة من عواصف إعادات المحاولة، أو من مخزن مركزي للعدّادات، أو من شريك بطيء، فإن مزيدًا من الخوادم يرفع الفاتورة ويُبقي السبب في مكانه. ومع مخزن مركزي للعدّادات، تضيف الخوادم أيضًا حملًا على الجزء الذي يشكّل الحد أصلًا
• تنتهي المهلة في SSP لدينا أثناء انتظار المزايدين. ماذا يمكننا أن نفعل؟ امنح كل مزايد مهلة داخل المهلة النهائية لمزادك أنت، واترك هامشًا قبل اللحظة التي يجب أن تردّ فيها على الناشر. وبالنسبة إلى الناشرين الذين يشغّلون Prebid.js مع Prebid Server، تقول Prebid إن مهلة جانب الخادم «ينبغي على الأرجح أن تقع ضمن نطاق 50%-75% من مهلة المزاد (Auction Timeout)»، تبعًا لتأخر شبكة المستخدم، كي تعود مزايدات الخادم إلى المتصفح في الوقت المناسب لاستدعاء خادم الإعلانات
• هل Rust ضروري للصمود أمام الذروات؟ لا. تهم اللغة حين تُظهر القياسات أن الـ runtime هو السبب، كوقفات جامع القمامة في مسار المزايدة. أما الطوابير وإعادات المحاولة والعدّادات المشتركة والسعة فتُصلَح دون تغيير اللغة