Get best of the week

كيف استطعنا النجاة من الزيادة الحادة في حمل X10 على الموقع البعيد وما هي النتائج

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



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

عند إدارة فريق ، من المهم أن تفهم وتجد التوازن بين ما تحتاجه الأعمال واحتياجات كل مطور معين. ينمو SberMarket الآن 13 مرة عامًا بعد عام ، وهذا يؤثر على المنتج ، مما يتطلب زيادة مستمرة في حجم ووتيرة التطوير. على الرغم من ذلك ، نكرس وقتًا كافيًا للمطورين لإجراء التحليل الأولي وكتابة التعليمات البرمجية عالية الجودة. لا يساعد النهج المتشكل فقط في إنشاء منتج عامل ، ولكن أيضًا في زيادة تطويره وتطويره. نتيجة لهذا النمو ، أصبح SberMarket بالفعل رائدًا بين خدمات توصيل الطعام: نقدم حوالي 18 ألف طلب يوميًا ، على الرغم من وجود حوالي 3500 طلب في بداية فبراير.


وبمجرد أن طلب العميل من SberMarket توصيل المنتجات إليه دون اتصال - مباشرة إلى الشرفة

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

الرقيق في حالة تأهب كامل


حتى قبل أن يبدأ الوباء ، واجهنا زيادة في عدد الطلبات إلى خوادمنا الخلفية. بدأ الاتجاه لطلب المنتجات مع التوصيل إلى المنزل في اكتساب الزخم ، ومع إدخال أول تدابير العزل الذاتي فيما يتعلق بـ COVID-19 ، نما الحمل بشكل كبير أمام أعيننا طوال اليوم. كانت هناك حاجة لتفريغ الخوادم الرئيسية لقاعدة البيانات الرئيسية بسرعة ونقل جزء من طلبات القراءة إلى خوادم النسخ المتماثلة (العبيد).

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

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

حتى مستوى معين من الحمل ، كان لدينا ما يكفي من المعالجات للكتابة والقراءة عند معالجة طلبات http. في منتصف مارس ، عندما قررت Sbermarket التبديل تمامًا إلى موقع بعيد ، بدأنا في زيادة متعددة في RPS. ذهب المزيد والمزيد من عملائنا إلى العزلة الذاتية أو العمل من المنزل ، وهو ما انعكس في مؤشرات الحمل.

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

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

عندما اكتشفنا أسباب "زحف" العبد الرئيسي ، فشل التحليل بالفعل لنفس السبب. على الرغم من وجود خادمين إضافيين ، قمنا بالتخطيط لهما لنقل الحمولة في حالة حدوث عطل رئيسي ، بسبب خطأ مؤسف ، اتضح أنه في اللحظة الحرجة لا يوجد.

ولكن نظرًا لأننا لم نقم فقط بتفريغ قاعدة البيانات (كان الباقي في ذلك الوقت حوالي 5 ساعات) ، ولكن أيضًا لقطة الخادم الرئيسي ، تمكنا من بدء النسخة المتماثلة في غضون ساعتين. صحيح ، بعد ذلك كان من المتوقع أن ننقل سجل النسخ المتماثل لفترة طويلة (لأن العملية في وضع الخيوط الفردية ، لكن هذه قصة مختلفة تمامًا).

: , readonly . , .

« »


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

أثناء استرداد خوادم Slave ، استمرت الدقائق ببطء ، وظل السيد محملاً فوق طاقته ، وكرسنا جميع جهودنا لتحسين المهام النشطة وفقًا لقاعدة باريتو: لقد اخترنا طلبات TOP التي أعطت أكبر قدر من الحمل وبدأنا في الضبط. تم ذلك مباشرة "على الطاير".

كان التأثير المثير للاهتمام هو أن MySQL الذي تم تحميله على مقلة العين يستجيب حتى للتحسن الطفيف في العمليات. أظهر تحسين زوج من الطلبات ، والذي أعطى 5 ٪ فقط من إجمالي الحمل ، بالفعل تفريغًا ملموسًا لوحدة المعالجة المركزية. ونتيجة لذلك ، تمكنا من توفير مصدر مقبول من الموارد للماجستير للعمل مع قاعدة البيانات والحصول على الوقت اللازم لاستعادة النسخ المتماثلة. 

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

تنظيم مراقبة أداء خدمات الشركاء


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

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

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

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

: . , « », , . , ,   . 

, « » ()


لقد اعتدنا على "التوصيل" في قاعدة البيانات الرئيسية أو خوادم التطبيقات ، ولكن عند التوسع ، يمكن أن تظهر المشاكل حيث لم تكن متوقعة. للبحث عن نص كامل على الموقع ، نستخدم محرك Apache Solr. مع زيادة الحمل ، لاحظنا انخفاضًا في وقت الاستجابة ، ووصل تحميل معالج الخادم إلى 100٪. ما يمكن أن يكون أبسط - سنقدم المزيد من الموارد للحاوية مع Solr.

بدلاً من مكاسب الأداء المتوقعة ، "مات" الخادم ببساطة. تم تحميله على الفور بنسبة 100 ٪ واستجاب ببطء أكثر. في البداية ، كان لدينا 2 نوى و 2 غيغابايت من ذاكرة الوصول العشوائي. قررنا أن نفعل ما يساعد عادة - قدمنا ​​الخادم 8 النوى و 32 غيغابايت. لقد أصبح كل شيء أسوأ بكثير (بالضبط كيف ولماذا - سنخبر في منشور منفصل). 

لعدة أيام ، اكتشفنا تعقيدات هذه المشكلة ، وحققنا الأداء الأمثل مع 8 نوى و 32 غيغابايت. يتيح لنا هذا التكوين الاستمرار في زيادة الحمل اليوم ، وهو أمر مهم جدًا لأن النمو ليس فقط من حيث العملاء ، ولكن أيضًا في عدد المتاجر المتصلة - فقد تضاعف عددهم على مدار شهرين. 

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

عديم الجنسية - مفتاح التحجيم الأفقي السهل


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

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

الخلاصة: يجب احترام قاعدة انعدام الجنسية لجميع المكونات ، دون استثناء ، حتى لو بدا "أننا لا نتعب أنفسنا بالتأكيد". من الأفضل قضاء بعض الوقت في التنظيم الصحيح لعمل جميع الأنظمة بدلاً من إعادة كتابة الرمز في عجلة من أمره وإصلاح الخدمة التي تعاني من الحمل الزائد.

7 مبادئ للنمو المكثف


على الرغم من توافر السعة الإضافية ، فقد خطونا في بضع خطوات في عملية النمو. خلال هذا الوقت ، زاد عدد الطلبات بأكثر من 4 مرات. الآن نقدم بالفعل أكثر من 17000 طلب في اليوم في 62 مدينة ونخطط لتوسيع جغرافيتنا إلى أبعد من ذلك - في النصف الأول من عام 2020 ، من المتوقع إطلاق الخدمة في جميع أنحاء روسيا. من أجل التعامل مع الحمل المتزايد ، مع مراعاة المطبات الكاملة بالفعل ، قمنا بتطوير لأنفسنا 7 مبادئ أساسية للعمل في ظروف النمو المستمر:

  1. -. Jira,   . . — . , , , , .
  2. . « » . , , . , .
  3. . -, . -, , .
  4. stateless. , . . , , S3. https://12factor.net. , .
  5. . , . , , - . , . 
  6. . , . , SMS . , .
  7. . , . , , . API, -. .


ليس من دون خسائر ، لكننا نجونا من هذه المرحلة ، واليوم نحاول الالتزام بجميع المبادئ الموجودة ، ولدى كل آلة القدرة على زيادة أداء x4 بسهولة للتعامل مع أي مفاجآت. 

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

More articles:


All Articles