هذه هي المقالة التالية من السلسلة التي تصف كيفية زيادة توفر خدماتنا في Citymobil (يمكنك قراءة الأجزاء السابقة هنا:
الجزء 1 ،
الجزء 2 ،
الجزء 3 ). في أجزاء أخرى ، سأتحدث عن الحوادث والانقطاعات بالتفصيل.
1. الافراج عن سيئة: قاعدة بيانات الزائد
اسمحوا لي أن أبدأ بمثال محدد لهذا النوع من انقطاع الخدمة. لقد قمنا بنشر تحسين: إضافة USE INDEX في استعلام SQL؛ أثناء الاختبار وكذلك في الإنتاج ، أدى ذلك إلى تسريع استفسارات قصيرة ، ولكن التباطؤ الطويل - تباطأ. وقد لوحظ تباطؤ الاستفسارات الطويلة فقط في الإنتاج. نتيجة لذلك ، تسبب الكثير من الاستعلامات المتوازية الطويلة في تعطل قاعدة البيانات لمدة ساعة. درسنا بدقة طريقة استخدام INDEX. وصفناها في ملف المهام والفعل وحذرنا المهندسين من الاستخدام غير الصحيح. قمنا أيضًا بتحليل الاستعلام وأدركنا أنه يسترجع معظم البيانات التاريخية ، وبالتالي ، يمكن تشغيله على نسخة متماثلة منفصلة للطلبات التاريخية. حتى إذا انخفضت هذه النسخة المتماثلة بسبب التحميل الزائد ، فسيستمر العمل.
واصلنا التعثر في نفس القضايا بعد ذلك ، وفي مرحلة ما ، قررنا معالجة هذه المسألة. لقد درسنا الشفرة ونقلنا جميع الاستعلامات التي استطعناها دون المساس بخدمتنا في النسخ المتماثلة. تم تقسيم النسخ المتماثلة نفسها وفقًا لمستوى حرجيتها ، بحيث لا يمكن لأي منها أن يفشل ويوقف الخدمة. نتيجة لذلك ، توصلنا إلى بنية بها قواعد البيانات التالية:
- قاعدة البيانات الرئيسية - لعمليات الكتابة والاستعلامات التي تكون فائقة الحساسية لنضارة البيانات ؛
- النسخ المتماثلة للإنتاج - للاستعلامات القصيرة التي تكون أقل حساسية لنضارة البيانات ؛
- النسخ المتماثلة لمعاملات زيادة الأسعار. يمكن أن تكون هذه النسخ المتماثلة 30-60 ثانية خلف؛ هذا ليس حاسمًا حيث لا تتغير المعاملات بشكل متكرر ، وإذا تعطلت هذه النسخة المتماثلة ، فلن تتوقف الخدمة عن العمل ؛ الأسعار لن تتوافق تمامًا مع ميزان العرض والطلب ؛
- نسخة طبق الأصل للإعدادات التشغيلية ومركز الاتصال. في حالة تعطله ، سيستمر العمل في العمل ولكن بدون دعم العميل والسائق ، ولن نتمكن من تغيير بعض الإعدادات مؤقتًا ؛
- العديد من النسخ المتماثلة للتحليلات المخصصة ولوحات المعلومات ؛
- قاعدة بيانات MPP (المعالجة المتوازية بشكل كبير) لبعض التحليلات الضخمة مع شرائح كاملة على البيانات التاريخية.
زودتنا هذه البنية بمساحة واسعة للنمو وقلصت عددًا من الأعطال بسبب استعلامات SQL غير الأمثل. لكنها لا تزال بعيدة عن الكمال. نحن نخطط لتنفيذ المشاركة ، حتى نتمكن من توسيع نطاق التحديثات وحذفها وحساسية فائقة لاستعلامات تحديث البيانات. MySQL هامش السلامة ليست لانهائية. سنحتاج إلى بعض المدفعية الثقيلة في شكل قاعدة بيانات في الذاكرة (مثل Tarantool) قريبًا. بالتأكيد سأتحدث عن ذلك في مقالاتي القادمة.
أثناء تعاملنا مع التعليمات البرمجية والاستعلامات غير المثالية ، تفهمنا ما يلي: يجب إزالة أي عدم استباق قبل إصداره وليس بعده. هذا يقلل من خطر انقطاع التيار والجهود التي تبذلها فرق الهندسة لتحسين. إذا تم نشر الكود بالفعل مع بعض الإصدارات الجديدة فوقه ، فسيكون من الأصعب تحسينه. نتيجةً لذلك ، قدمنا مراجعة إلزامية للرمز لتحسينها. يتم تنفيذها من قبل مهندسينا الأكثر خبرة ، وقوة النخبة لدينا.
لقد بدأنا أيضًا في جمع أفضل أساليب تحسين الشفرة المناسبة لواقعنا في المهام والمهام. وهي مدرجة أدناه. من فضلك ، لا تأخذ هذه الممارسات كحقيقة لا يمكن إنكارها ولا تحاول تكرارها بشكل أعمى. كل طريقة منطقية فقط لبعض المواقف المحددة والأعمال المحددة. هذا مجرد مثال لتوضيح التفاصيل:
- إذا كان استعلام SQL لا يعتمد على المستخدم (على سبيل المثال ، خريطة طلب برنامج التشغيل مع أقصى الأسعار ومعاملات الزيادة - هذه الخريطة هي نفسها لأي مستخدم لتطبيق برنامج التشغيل) ، عندئذ يجب إجراء هذا الاستعلام في برنامج نصي باستخدام cron باستخدام بعض التردد المحدد (مرة واحدة في الدقيقة يكفي في هذه الحالة). يجب كتابة النتيجة في ذاكرة التخزين المؤقت (Memcached أو Redis) التي يجب استخدامها في رمز الإنتاج.
- إذا كان استعلام SQL يعمل مع البيانات التي تعتبر التأخير غير حاسم بالنسبة إلى العمل ، فيجب وضع نتائجه في ذاكرة تخزين مؤقت تحتوي على بعض TTL (30 ثانية ، على سبيل المثال) ثم قراءتها من ذاكرة التخزين المؤقت بواسطة رمز الإنتاج.
- إذا قررت تنفيذ استعلام SQL في تطبيق معين لخادم معين (بلغة PHP أو لغة أخرى من جانب الخادم) ، فعليك التأكد من أن البيانات التي تحتاجها لم تصل مع بعض استعلام SQL الآخر أو على وشك الوصول إليها الرمز الخاص بك أدناه.
- نفس ما ورد أعلاه يذهب إلى الطلبات إلى ذاكرة التخزين المؤقت. ذاكرة التخزين المؤقت سريعة ولكن لا تزال قاعدة بيانات. لذلك يمكن أيضا أن تكون مثقلة. الخطأ الشائع هو أنك تعتقد أن ذاكرة التخزين المؤقت هي نوع من المتغيرات العادية في الذاكرة واستخدامها كمتغير. لكن الوصول إليها ينطوي على رحلة ذهابا وإيابا عبر الشبكة ويولد عبء عمل على Redis أو Memcached. لذلك ، إذا كانت البيانات قد وصلت بالفعل من ذاكرة التخزين المؤقت ، فلا تأخذ فقط من ذاكرة التخزين المؤقت ما تم نقله بالفعل.
- إذا كنت بحاجة إلى استدعاء دالة أثناء معالجة طلب ويب (مرة أخرى بلغة PHP أو أي لغة أخرى) ، فيجب التأكد من أنه لن يكون هناك استعلامات SQL إضافية أو الوصول إلى ذاكرة التخزين المؤقت. إذا كانت مثل هذه الدعوة الوظيفية لا مفر منها ، يجب عليك التأكد من أنه لا يمكن تعديلها ، أو أن منطقها لم ينهار لمنع استعلامات قاعدة البيانات / ذاكرة التخزين المؤقت غير الضرورية.
- إذا كان من الضروري إجراء استعلام SQL ، يجب أن تكون متأكدًا تمامًا من أنه لا يمكن إضافة الحقول التي تحتاج إليها إلى الاستعلامات الموجودة بالفعل في التعليمات البرمجية الخاصة بك أعلاه أو أدناه.
2. التشغيل اليدوي السيئ
أمثلة على هذه الحوادث:
- غير صالح ALTER أن overloaded قاعدة البيانات أو تسبب تأخير النسخة المتماثلة؛
- DROP غير صحيح (على سبيل المثال ، صادفنا خطأ في MySQL الذي قام بحظر قاعدة البيانات أثناء إسقاط جدول) ؛
- استعلام ثقيل على رسالة ماجستير ، يتم إجراؤه يدويًا عن طريق الخطأ ؛
- تم تكوين خادم ويب على الرغم من أنه كان تحت عبء العمل الحقيقي في حين كنا نظن أنه عاطل عن العمل.
لتقليل الانقطاعات الناجمة عن هذه الأسباب ، يتعين علينا التحقق من طبيعة الحادث في كل مرة يحدث فيها. لم نتوصل إلى قاعدة عامة بعد. مرة أخرى ، دعونا نلقي نظرة على بعض الأمثلة المحددة. توقفت معاملات زيادة (أجرة التاكسي في وقت ومكان ارتفاع الطلب عليها) عن العمل في مرحلة ما. والسبب هو أنه كان هناك برنامج نصي بيثون يعمل على خادم نسخة متماثلة لقاعدة البيانات حيث تم الحصول على البيانات الخاصة بحساب المعاملات وتم استخدام البرنامج النصي لكل الذاكرة والنسخة المتماثلة. تم تشغيل البرنامج النصي لفترة من الوقت. كان يعمل على نسخة طبق الأصل من أجل الراحة. تم حل المشكلة عن طريق إعادة تشغيل البرنامج النصي. تم استخلاص الاستنتاجات التالية: لا تقم بتشغيل برامج نصية أجنبية على خادم قاعدة بيانات (تمت كتابتها في مهام Do و Do's ، وإلا ، ستكون لقطة فارغة!) ، ومراقبة استخدام الذاكرة على خادم قاعدة البيانات والتنبيه عبر الرسائل القصيرة إذا كان هذا الخادم على وشك نفاد الذاكرة.
من الضروري دائمًا استخلاص الاستنتاجات وعدم الشعور بالراحة في نوع "المشكلة" ، أو إصلاحها ، أو نسيانها ". لا يمكن تقديم خدمة عالية الجودة إلا إذا انتهى الأمر. إلى جانب ذلك ، تعد تنبيهات الرسائل القصيرة مهمة للغاية - فهي تزيد من مستوى جودة الخدمة ، ولا تسمح لها بالانخفاض وتسمح لنا بزيادة موثوقيتها. مثل متسلق الجبال الذي يصل إلى وضع مستقر ثم يسحب نفسه إلى وضع مستقر آخر ، ولكن أعلى هذه المرة فقط.
المراقبة والتنبيهات غير مرئية ، لكنها تتصرف مثل السنانير الحديدية التي تقطع الصخور المجهولة وتمنعنا من الوقوع تحت اتفاقية مستوى الخدمة التي نزيدها باستمرار.
3. بيضة عيد الفصح
ما نسميه "بيضة عيد الفصح" - هو منجم مؤجل لم نتعثر عليه بعد ، على الرغم من أنه موجود منذ فترة. خارج هذا المقال ، يستخدم هذا المصطلح للميزات غير الموثقة التي تم إنشاؤها عن قصد. في حالتنا ، ليست ميزة على الإطلاق ، ولكنها خطأ يعمل كقنبلة موقوتة ويبدو أنه تأثير جانبي لبعض الأنشطة الحسنة النية.
على سبيل المثال:
- ملء over_increment 32 بت؛
- عدم تبني الكود / التكوين ، الناتج عن عبء العمل الكبير ؛
- تأخر النسخ المتماثل بواسطة استعلام غير مثالي تم إجراؤه بواسطة نمط جديد من الاستخدام أو بسبب عبء العمل الثقيل ؛
- تأخر النسخ المتماثل بواسطة عملية UPDATE غير الأمثل على الرئيسي الذي تسبب فيه نمط عبء عمل جديد وتأخر النسخ المتماثل.
نوع آخر شعبي من بيضة عيد الفصح هو رمز غير مثالي ؛ أن تكون أكثر تحديدا - استعلام SQL غير الأمثل. كان الجدول أصغر ، وكان عبء العمل أخف وزنا - كان الاستعلام يعمل بشكل جيد. مع الزيادة الخطية في الجدول الزمني وزيادة عبء العمل الخطي ، كان استهلاك الموارد من خلال نظام إدارة قاعدة البيانات ينمو بشكل كبير. عادةً ما يؤدي ذلك إلى تأثير سلبي شديد: إنه يشبه كل شيء كان على ما يرام ثم فجأة - عفواً!
سيناريوهات أندر - مزيج من البق وبيض عيد الفصح. أدى الإصدار مع وجود خطأ إلى توسيع جدول قاعدة البيانات وزيادة عدد صفوف الجدول من نوع معين في حين تسببت بيضة عيد الفصح الموجودة بالفعل في التحميل الزائد لقاعدة البيانات بسبب تباطؤ استعلامات هذا الجدول الموسع.
اعتدنا أن يكون بعض بيض عيد الفصح لا عبء العمل ، على الرغم من. على سبيل المثال ، حقل
auto_increment 32 بت في MYSQL. بعد ما يزيد قليلاً عن ملياري صف ، تفشل عمليات الإدراج. لذلك ، في العالم الحديث ، يجب أن نستخدم حقول
auto_increment 64 بت فقط. لقد تعلمنا هذا الدرس جيدًا.
كيفية التعامل مع بيض عيد الفصح؟ تبدو الإجابة واضحة: أ) ابحث عن البيض القديم ، ب) لا تسمح للبيض الجديد بالظهور. نحن نحاول القيام بالأمرين معا. يسير البحث عن البيض القديم جنبًا إلى جنب مع التحسين المستمر للكود. قمنا بتعيين اثنين من المهندسين الأكثر خبرة لإجراء التحسين بدوام كامل تقريبًا. وجدوا الاستعلامات في slow.log التي تستخدم موارد قواعد البيانات أكثر؛ أنها تحسين هذه الاستعلامات والرمز من حولهم. نحن نخفف من احتمال ظهور بيض جديد من خلال اختبار كل التزام من أجل تحقيق أفضل أداء يقوم به مهندسون الإحساس المذكور أعلاه. مهمتهم هي الإشارة إلى الأخطاء التي تؤثر على الأداء ، واقتراح طريقة لجعل الأمور أفضل ونقل هذه المعرفة إلى المهندسين الآخرين.
في مرحلة ما ، مباشرة بعد العثور على بيضة عيد الفصح الأخرى ، أدركنا أنه من الجيد البحث عن استفسارات بطيئة ، ولكن كان علينا البحث عن الاستعلامات التي تبدو بطيئة ولكن العمل بسرعة. هؤلاء هم المتنافسون التاليون على تحطيم كل شيء في حالة حدوث نمو هائل في جدول آخر. المثال الغبي ولكن الواضح هنا هو استعلام يمسح بالكامل جدولًا يتكون من 10 صفوف دون استخدام فهارس على الإطلاق. وسوف تعمل بسرعة في الوقت الحاضر. ومع ذلك ، عندما يكون الجدول كبيرًا بما فيه الكفاية ، فإن الاستعلام سوف ينزل قاعدة البيانات. هذا هو بيضة عيد الفصح جدا.
4. أسباب خارجية
هذه هي الأسباب التي يبدو أننا غير قادرين على السيطرة بشكل جيد للغاية. بعبارة أخرى ، تلك هي الأسباب التي لا يمكن تخفيفها إلا القضاء عليها. على سبيل المثال:
- خنق طلباتنا من قبل مزود خدمة الخرائط. يمكن تخفيفه من خلال التحكم في استخدام الخدمة ، والالتزام بمستوى عبء العمل المحدد ، والتخطيط لزيادة عبء العمل مسبقًا وشراء توسيع الخدمة. ومع ذلك ، لا يمكننا الاستغناء عن الخرائط.
- فشل الشبكة في مركز البيانات. يمكن التخفيف من ذلك عن طريق وضع نسخة من الخدمة في مركز بيانات النسخ الاحتياطي. ومع ذلك ، لا يمكننا الاستغناء عن مركز البيانات الفعلي أو السحابي.
- خدمة الدفع لأسفل. يمكن التخفيف من ذلك عن طريق النسخ الاحتياطي لخدمات الدفع. ومع ذلك ، لا يمكننا الاستغناء عن المدفوعات.
- طلب حظر حركة المرور بواسطة خدمة حماية DDoS. يمكن التخفيف من ذلك عن طريق إيقاف تشغيل خدمة حماية DDoS بشكل افتراضي مع تشغيلها فقط في حالة حدوث هجوم DDoS. ومع ذلك ، لا يمكننا الاستغناء عن حماية DDoS.
نظرًا لأن التخفيف من سبب خارجي هو مسعى طويل ومكلف ، فقد بدأنا في جمع إحصائيات عن الحوادث الناجمة عن الأسباب الخارجية وانتظار تراكم الكتلة الحرج. ليس لدينا وصفة لتحديد الكتلة الحرجة. كل شيء عن مجرد حدس. على سبيل المثال ، إذا كنا متوقفين تمامًا خمس مرات بسبب مشكلات خدمة حماية DDoS ، فلنواجه المزيد من الإلحاح مع كل فترة توقف لاحقة.
من ناحية أخرى ، إذا استطعنا بطريقة ما أن نجعل كل شيء يعمل مع خدمة خارجية غير متوفرة ، فنحن نفعل ذلك بالتأكيد. تحليل ما بعد الوفاة من كل انقطاع يساعدنا هنا. يجب أن يكون هناك دائما خاتمة. مما يعني أن أعجبك ذلك أم لا - نتوصل دائمًا إلى حل بديل.
في الجزء الأخير ، سأتحدث عن نوع آخر من حالات انقطاع الخدمة والاستنتاجات التي توصلنا إليها بشأنها ، وكيف عدّلنا عملية التطوير ، وما هي الأتمتة التي قدمناها. ترقبوا!