مرحبًا بالجميع، اسمي ألكساندر، وأعمل في CIAN كمهندس وأشارك في إدارة النظام وأتمتة عمليات البنية التحتية. في التعليقات على إحدى المقالات السابقة، طُلب منا أن نخبرنا من أين نحصل على 4 تيرابايت من السجلات يوميًا وماذا نفعل بها. نعم، لدينا الكثير من السجلات، وتم إنشاء مجموعة بنية تحتية منفصلة لمعالجتها، مما يسمح لنا بحل المشكلات بسرعة. سأتحدث في هذه المقالة عن كيفية تكييفنا له على مدار عام للعمل مع التدفق المتزايد للبيانات.
من أين بدأنا
على مدى السنوات القليلة الماضية، زاد الحمل على cian.ru بسرعة كبيرة، وبحلول الربع الثالث من عام 2018، وصلت حركة الموارد إلى 11.2 مليون مستخدم فريد شهريًا. في ذلك الوقت، فقدنا في اللحظات الحرجة ما يصل إلى 40% من السجلات، ولهذا السبب لم نتمكن من التعامل بسرعة مع الحوادث وقضينا الكثير من الوقت والجهد في حلها. كما أننا في كثير من الأحيان لم نتمكن من العثور على سبب المشكلة، وسوف تتكرر بعد مرور بعض الوقت. لقد كان الجحيم وكان لا بد من فعل شيء حيال ذلك.
في ذلك الوقت، استخدمنا مجموعة من 10 عقد بيانات مع الإصدار 5.5.2 من ElasticSearch مع إعدادات الفهرس القياسية لتخزين السجلات. تم تقديمه منذ أكثر من عام كحل شائع وبأسعار معقولة: ثم لم يكن تدفق السجلات كبيرًا جدًا، ولم يكن هناك أي معنى في التوصل إلى تكوينات غير قياسية.
تم توفير معالجة السجلات الواردة بواسطة Logstash على منافذ مختلفة على خمسة منسقين لـ ElasticSearch. يتألف الفهرس الواحد، بغض النظر عن حجمه، من خمس شظايا. تم تنظيم تناوب كل ساعة ويومي، ونتيجة لذلك، ظهر حوالي 100 شظية جديدة في المجموعة كل ساعة. على الرغم من عدم وجود الكثير من السجلات، تعاملت المجموعة بشكل جيد ولم يهتم أحد بإعداداتها.
تحديات النمو السريع
نما حجم السجلات التي تم إنشاؤها بسرعة كبيرة، حيث تداخلت عمليتان مع بعضهما البعض. فمن ناحية، زاد عدد مستخدمي الخدمة. ومن ناحية أخرى، بدأنا في التحول بنشاط إلى بنية الخدمات الصغيرة، ونشرنا وحداتنا القديمة في C# وPython. أنتجت العشرات من الخدمات الصغيرة الجديدة التي حلت محل أجزاء من الوحدة المتراصة عددًا أكبر بكثير من السجلات لمجموعة البنية التحتية.
لقد كان التوسع هو الذي قادنا إلى النقطة التي أصبحت فيها المجموعة غير قابلة للإدارة عمليًا. عندما بدأت السجلات في الوصول بمعدل 20 ألف رسالة في الثانية، أدى التدوير المتكرر غير المفيد إلى زيادة عدد الأجزاء إلى 6 آلاف، وكان هناك أكثر من 600 جزء لكل عقدة.
أدى ذلك إلى مشاكل في تخصيص ذاكرة الوصول العشوائي (RAM)، وعندما تعطلت العقدة، بدأت جميع الأجزاء في التحرك في وقت واحد، مما أدى إلى مضاعفة حركة المرور وتحميل العقد الأخرى، مما جعل من المستحيل تقريبًا كتابة البيانات إلى المجموعة. وخلال هذه الفترة بقينا بدون سجلات. وإذا كانت هناك مشكلة في الخادم، فقد فقدنا 1/10 من المجموعة. أضاف عدد كبير من الفهارس الصغيرة التعقيد.
بدون سجلات، لم نفهم أسباب الحادث ويمكننا عاجلاً أم آجلاً أن نخطو على نفس أشعل النار مرة أخرى، وفي أيديولوجية فريقنا كان هذا غير مقبول، لأن جميع آليات عملنا مصممة للقيام بالعكس تمامًا - لا تكرر أبدًا نفس المشاكل. للقيام بذلك، كنا بحاجة إلى الحجم الكامل للسجلات وتسليمها في الوقت الفعلي تقريبًا، حيث قام فريق من المهندسين المناوبين بمراقبة التنبيهات ليس فقط من المقاييس، ولكن أيضًا من السجلات. لفهم حجم المشكلة، كان الحجم الإجمالي للسجلات في ذلك الوقت حوالي 2 تيرابايت يوميًا.
لقد وضعنا هدفًا يتمثل في القضاء تمامًا على فقدان السجلات وتقليل وقت تسليمها إلى مجموعة ELK إلى 15 دقيقة كحد أقصى أثناء القوة القاهرة (اعتمدنا لاحقًا على هذا الرقم كمؤشر أداء رئيسي داخلي).
آلية دوران جديدة وعقد ساخنة دافئة
لقد بدأنا تحويل المجموعة عن طريق تحديث إصدار ElasticSearch من 5.5.2 إلى 6.4.3. مرة أخرى، ماتت مجموعة الإصدار 5 الخاصة بنا، وقررنا إيقاف تشغيلها وتحديثها بالكامل - لا توجد سجلات حتى الآن. لذلك قمنا بهذا التحول في بضع ساعات فقط.
كان التحول الأكثر اتساعًا في هذه المرحلة هو تنفيذ Apache Kafka على ثلاث عقد مع وجود منسق كمخزن مؤقت وسيط. لقد أنقذنا وسيط الرسائل من فقدان السجلات أثناء حدوث مشكلات في ElasticSearch. وفي الوقت نفسه، أضفنا عقدتين إلى المجموعة وتحولنا إلى بنية ساخنة دافئة مع ثلاث عقد "ساخنة" موجودة في رفوف مختلفة في مركز البيانات. لقد قمنا بإعادة توجيه السجلات إليهم باستخدام قناع لا ينبغي فقدانه تحت أي ظرف من الظروف - nginx، بالإضافة إلى سجلات أخطاء التطبيق. تم إرسال السجلات الثانوية إلى العقد المتبقية - تصحيح الأخطاء والتحذير وما إلى ذلك، وبعد 2 ساعة، تم نقل السجلات "المهمة" من العقد "الساخنة".
ومن أجل عدم زيادة عدد المؤشرات الصغيرة، قمنا بالتبديل من التدوير الزمني إلى آلية التمديد. كان هناك الكثير من المعلومات في المنتديات تفيد بأن التدوير حسب حجم الفهرس غير موثوق به على الإطلاق، لذلك قررنا استخدام التدوير حسب عدد المستندات الموجودة في الفهرس. قمنا بتحليل كل فهرس وسجلنا عدد المستندات التي يجب أن يتم التناوب بعدها. وهكذا وصلنا إلى الحجم الأمثل للجزء - لا يزيد عن 50 جيجابايت.
تحسين الكتلة
ومع ذلك، فإننا لم نتخلص تماما من المشاكل. لسوء الحظ، لا تزال تظهر فهارس صغيرة: لم تصل إلى الحجم المحدد، ولم يتم تدويرها، وتم حذفها عن طريق التنظيف الشامل للفهارس الأقدم من ثلاثة أيام، حيث قمنا بإزالة التدوير حسب التاريخ. أدى ذلك إلى فقدان البيانات بسبب اختفاء الفهرس من المجموعة تمامًا، كما أن محاولة الكتابة إلى فهرس غير موجود خرقت منطق المنسق الذي استخدمناه للإدارة. تم تحويل الاسم المستعار للكتابة إلى فهرس وكسر منطق التمديد، مما تسبب في نمو غير منضبط لبعض الفهارس يصل إلى 600 جيجابايت.
على سبيل المثال، بالنسبة لتكوين التدوير:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
إذا لم يكن هناك اسم مستعار للتمرير، حدث خطأ:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
لقد تركنا حل هذه المشكلة للتكرار التالي وتناولنا مشكلة أخرى: لقد تحولنا إلى منطق السحب الخاص بـ Logstash، الذي يعالج السجلات الواردة (إزالة المعلومات غير الضرورية وإثرائها). لقد وضعناه في عامل الإرساء، والذي نطلقه عبر docker-compose، كما وضعنا أيضًا logstash-exporter هناك، والذي يرسل المقاييس إلى Prometheus للمراقبة التشغيلية لتدفق السجل. وبهذه الطريقة، منحنا أنفسنا الفرصة لتغيير عدد مثيلات السجل المسؤولة عن معالجة كل نوع من أنواع السجلات بسلاسة.
أثناء قيامنا بتحسين المجموعة، زادت حركة مرور cian.ru إلى 12,8 مليون مستخدم فريد شهريًا. ونتيجة لذلك، اتضح أن تحولاتنا كانت متخلفة قليلا عن التغييرات في الإنتاج، وواجهنا حقيقة أن العقد "الدافئة" لم تتمكن من التعامل مع الحمل وتباطأت تسليم السجلات بالكامل. لقد تلقينا بيانات "ساخنة" دون أي أعطال، ولكن كان علينا التدخل في تسليم الباقي وإجراء تبديل يدوي من أجل توزيع الفهارس بالتساوي.
في الوقت نفسه، كان قياس وتغيير إعدادات مثيلات logstash في المجموعة معقدًا بسبب حقيقة أنها كانت عبارة عن عامل إرساء محلي، وتم تنفيذ جميع الإجراءات يدويًا (لإضافة نهايات جديدة، كان من الضروري المرور عبر جميع الإجراءات يدويًا الخوادم والقيام بعمل docker-compose up -d في كل مكان).
إعادة توزيع السجل
في سبتمبر من هذا العام، كنا لا نزال نقطع المونوليث، وكان الحمل على المجموعة يتزايد، وكان تدفق السجلات يقترب من 30 ألف رسالة في الثانية.
لقد بدأنا التكرار التالي بتحديث الأجهزة. لقد تحولنا من خمسة منسقين إلى ثلاثة، واستبدلنا عقد البيانات وفزنا من حيث المال ومساحة التخزين. بالنسبة للعقد نستخدم تكوينين:
- بالنسبة للعقد "الساخنة": E3-1270 v6 / 960 جيجا بايت SSD / 32 جيجا بايت × 3 × 2 (3 لـ Hot1 و3 لـ Hot2).
- بالنسبة للعقد "الدافئة": E3-1230 v6 / 4 تيرابايت SSD / 32 جيجا بايت × 4.
في هذا التكرار، قمنا بنقل الفهرس الذي يحتوي على سجلات الوصول للخدمات الصغيرة، والذي يشغل نفس المساحة التي تشغلها سجلات nginx في الخط الأمامي، إلى المجموعة الثانية المكونة من ثلاث عقد "ساخنة". نقوم الآن بتخزين البيانات على العقد "الساخنة" لمدة 20 ساعة، ثم ننقلها إلى العقد "الساخنة" إلى بقية السجلات.
لقد قمنا بحل مشكلة اختفاء الفهارس الصغيرة عن طريق إعادة تكوين دورانها. الآن يتم تدوير الفهارس كل 23 ساعة على أي حال، حتى لو كان هناك القليل من البيانات هناك. أدى هذا إلى زيادة طفيفة في عدد الشظايا (كان هناك حوالي 800 منها)، ولكن من وجهة نظر أداء المجموعة، فهذا أمر مقبول.
ونتيجة لذلك، كان هناك ستة عقد "ساخنة" وأربعة فقط "دافئة" في المجموعة. يؤدي هذا إلى تأخير طفيف في الطلبات على فترات زمنية طويلة، ولكن زيادة عدد العقد في المستقبل سوف يحل هذه المشكلة.
أدى هذا التكرار أيضًا إلى إصلاح مشكلة عدم وجود مقياس شبه تلقائي. وللقيام بذلك، قمنا بنشر مجموعة Nomad للبنية التحتية - على غرار ما قمنا بنشره بالفعل في الإنتاج. في الوقت الحالي، لا يتغير مقدار Logstash تلقائيًا اعتمادًا على الحمل، لكننا سنصل إلى هذا.
خطط للمستقبل
يتم ضبط التكوين المطبق بشكل مثالي، ونحن الآن نقوم بتخزين 13,3 تيرابايت من البيانات - جميع السجلات لمدة 4 أيام، وهو أمر ضروري لتحليل التنبيهات في حالات الطوارئ. نقوم بتحويل بعض السجلات إلى مقاييس، والتي نضيفها إلى الجرافيت. لتسهيل عمل المهندسين، لدينا مقاييس لمجموعة البنية التحتية وبرامج نصية للإصلاح شبه التلقائي للمشكلات الشائعة. وبعد زيادة عدد عقد البيانات، المخطط لها في العام المقبل، سننتقل إلى تخزين البيانات من 4 إلى 7 أيام. سيكون هذا كافيا للعمل التشغيلي، لأننا نحاول دائما التحقيق في الحوادث في أقرب وقت ممكن، وللتحقيقات طويلة المدى هناك بيانات القياس عن بعد.
في أكتوبر 2019، زادت حركة المرور إلى cian.ru بالفعل إلى 15,3 مليون مستخدم فريد شهريًا. لقد أصبح هذا اختبارًا جديًا للحل المعماري لتوصيل جذوع الأشجار.
نحن الآن نستعد لتحديث ElasticSearch إلى الإصدار 7. ومع ذلك، لهذا سيتعين علينا تحديث تعيين العديد من الفهارس في ElasticSearch، نظرًا لأنها انتقلت من الإصدار 5.5 وتم الإعلان عنها على أنها مهملة في الإصدار 6 (فهي ببساطة غير موجودة في الإصدار) 7). هذا يعني أنه أثناء عملية التحديث سيكون هناك بالتأكيد نوع من القوة القاهرة، مما سيتركنا بدون سجلات حتى يتم حل المشكلة. من الإصدار 7، نحن نتطلع بشدة إلى Kibana بواجهة محسنة ومرشحات جديدة.
لقد حققنا هدفنا الرئيسي: توقفنا عن فقدان السجلات وقللنا وقت التوقف عن العمل لمجموعة البنية التحتية من 2-3 أعطال أسبوعيًا إلى بضع ساعات من أعمال الصيانة شهريًا. كل هذا العمل في الإنتاج يكاد يكون غير مرئي. ومع ذلك، يمكننا الآن تحديد ما يحدث بالضبط مع خدمتنا، ويمكننا القيام بذلك بسرعة في وضع هادئ دون القلق من فقدان السجلات. وبشكل عام نحن راضون وسعداء ونستعد لمآثر جديدة سنتحدث عنها لاحقا.
المصدر: www.habr.com