AWS Elasticsearch: المنتج المعيب بشكل أساسي

نيك سعر الترجمة

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

ملخص

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

عمل معيار Elasticsearch

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

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

يحتوي Standard Elasticsearch أيضًا على عدد من الإضافات المتاحة ، بما في ذلك X-Pack وميزات التدقيق و ACLs الحبيبية والرصد والتنبيهات. أصبح معظم X-Pack مؤخرًا مجانيًا ، ربما استجابة لسياسة ترخيص Splunk الجديدة.

العمل الأمازون Elasticsearch

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

هذا أمر محبط ، لكن هذه ليست أكبر مشكلة في الخدمة. إعادة التوازن بين القطع - المفهوم المركزي لـ Elasticsearch - لا يعمل في تنفيذ AWS ، الذي ينفي كل شيء جيد تقريبًا في Elasticsearch.

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

هذا غير معتمد على Amazon. قد تملأ بعض العقد (كثيرًا) بشكل أسرع من غيرها.

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

"عفوا! أنا لم reindex الكتلة بأكملها في كثير من الأحيان بما فيه الكفاية ، وكانت العقدة ممتلئة! ماذا تفعل؟ "

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

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

ولكن مهلا ، كيف يمكنني إضافة العقد أو إجراء تغييرات إذا تعذر إعادة توازن القطع؟

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

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

لذلك ، حاولت تغيير حجم الكتلة الخاصة بك ، ولم تكتمل المهمة. ماذا الان

تفاعلات أمازون

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

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

الأفكار في النهاية

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

لسهولة الاستخدام والمجموعات الصغيرة ، تعمل AWS Elasticsearch بشكل جيد ، ولكن بالنسبة للمجموعات بحجم بيتابايت ، فقد كان كابوسا لا نهاية له.

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

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

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

الحاشية: عندما كتبت هذا النص ، وجدت منشورًا منذ عامين به العديد من المطالبات المشابهة: read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f