مرونة مُحسَّنة مع الضغط المرتد والتحكم في الدخول لخدمة Amazon OpenSearch Service | خدمات أمازون ويب

خدمة Amazon OpenSearch هي خدمة مُدارة تجعل من السهل تأمين مجموعات OpenSearch ونشرها وتشغيلها على نطاق واسع في سحابة AWS. في العام الماضي ، قدمنا الضغط الخلفي لفهرسة شارد و مراقبة الدخول، الذي يراقب موارد المجموعة وحركة المرور الواردة لرفض الطلبات بشكل انتقائي التي من شأنها أن تشكل مخاطر استقرار مثل نفاد الذاكرة والتأثير على أداء المجموعة بسبب احتكاكات الذاكرة وتشبع وحدة المعالجة المركزية وحمل GC ، والمزيد.

نحن الآن متحمسون لتقديم Search Backpressure والتحكم في القبول المعتمد على وحدة المعالجة المركزية لخدمة OpenSearch Service ، مما يعزز مرونة المجموعات. هذه التحسينات متاحة لجميع إصدارات OpenSearch 1.3 أو أعلى.

بحث الضغط الخلفي

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

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

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

يوضح الرسم البياني التالي سير عمل Search Backpressure.

تُرجع طلبات البحث رمز حالة HTTP 429 "طلبات كثيرة جدًا" عند الإلغاء. يعرض OpenSearch نتائج جزئية إذا فشلت بعض الأجزاء فقط وتم السماح بالنتائج الجزئية. انظر الكود التالي:

{ "error": { "root_cause": [ { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]" } ], "type": "search_phase_execution_exception", "reason": "SearchTask was cancelled", "phase": "fetch", "grouped": true, "failed_shards": [ { "shard": 0, "index": "nyc_taxis", "node": "9gB3PDp6Speu61KvOheDXA", "reason": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]" } } ], "caused_by": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]" } }, "status": 429
}

مراقبة ضغط البحث

يمكنك مراقبة حالة ضغط البحث التفصيلي باستخدام واجهة برمجة تطبيقات إحصائيات العقدة:

curl -X GET "https://{endpoint}/_nodes/stats/search_backpressure"

يمكنك أيضًا عرض ملخص على مستوى المجموعة لعمليات الإلغاء باستخدام الأمازون CloudWatch. المقاييس التالية متاحة الآن في ES / OpenSearchService مساحة الاسم:

• البحث - عدد عمليات إلغاء عقد المنسق
• البحث - عدد عمليات إلغاء عقدة البيانات

تُظهر لقطة الشاشة التالية مثالاً لتتبع هذه المقاييس على وحدة تحكم CloudWatch.

التحكم بالدخول المعتمد على وحدة المعالجة المركزية

التحكم في الدخول هو آلية لحفظ البوابة تحد بشكل استباقي من عدد الطلبات إلى العقدة استنادًا إلى قدرتها الحالية ، لكل من الزيادات العضوية والارتفاعات في حركة المرور.

بالإضافة إلى ضغط ذاكرة JVM وحدود حجم الطلب ، فإنه يراقب الآن أيضًا متوسط ​​استخدام وحدة المعالجة المركزية المتداول لكل عقدة لرفض الوارد _search و _bulk الطلبات. يمنع العقد من الانغماس في الكثير من الطلبات التي تؤدي إلى نقاط فعالة ومشاكل في الأداء وانتهاء مهلات الطلبات وغيرها من حالات الفشل المتتالية. تعيد الطلبات الزائدة رمز حالة HTTP 429 "طلبات كثيرة جدًا" عند الرفض.

معالجة أخطاء HTTP 429

ستتلقى أخطاء HTTP 429 إذا أرسلت حركة مرور زائدة إلى عقدة. يشير إما إلى عدم كفاية موارد الكتلة ، أو طلبات البحث كثيفة الموارد ، أو زيادة غير مقصودة في عبء العمل.

يوفر Search Backpressure سبب الرفض ، والذي يمكن أن يساعد في ضبط طلبات البحث كثيفة الاستخدام للموارد. بالنسبة لارتفاع حركة المرور ، نوصي بإعادة المحاولات من جانب العميل مع التراجع الأسي والارتعاش.

يمكنك أيضًا اتباع أدلة استكشاف الأخطاء وإصلاحها هذه لتصحيح أخطاء الرفض المفرط:

وفي الختام

يعد Search Backpressure آلية تفاعلية لإلقاء الحمل الزائد ، في حين أن التحكم في القبول هو آلية استباقية للحد من عدد الطلبات إلى عقدة تتجاوز سعتها. يعمل كلاهما جنبًا إلى جنب لتحسين المرونة الكلية لمجموعة OpenSearch.

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

عن المؤلفين

كيتان فيرما هو أحد كبار SDE يعمل على Amazon OpenSearch Service. إنه متحمس لبناء أنظمة موزعة على نطاق واسع ، وتحسين الأداء ، وتبسيط الأفكار المعقدة بأفكار تجريدية بسيطة. خارج العمل ، يحب القراءة وتحسين مهاراته في تحضير القهوة في المنزل.

سوريش NS هو أحد كبار SDE يعمل على Amazon OpenSearch Service. إنه متحمس لحل المشكلات في الأنظمة الموزعة على نطاق واسع.

بريتكومار لاداني هو SDE-2 يعمل على Amazon OpenSearch Service. يحب المساهمة في تطوير البرمجيات مفتوحة المصدر ، وهو متحمس للأنظمة الموزعة. إنه لاعب كرة ريشة هاو ويستمتع بالرحلات.

بختيار خان هو مهندس رئيسي يعمل في Amazon OpenSearch Service. يهتم ببناء الأنظمة الموزعة والمستقلة. وهو مشرف ومساهم نشط في OpenSearch.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• تمويل EVM. واجهة موحدة للتمويل اللامركزي. الوصول هنا.
• مجموعة كوانتوم ميديا. تضخيم IR / PR. الوصول هنا.
• أفلاطونايستريم. ذكاء بيانات Web3. تضخيم المعرفة. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/big-data/improved-resiliency-with-backpressure-and-admission-control-for-amazon-opensearch-service/