تغيير حجم الموارد
- 11 دقائق
تتمثل أحد أهم فوائد السحابة في القدرة على تحجيم الموارد في النظام بحسب الطلب. يمكن أن يساعد تكبير الحجم (تزويد موارد أكبر حجمًا) أو التوسع (تزويد موارد إضافية) على تقليل الحمل على مورد واحد عن طريق خفض الاستخدام، كنتيجة إلى زيادة السعة أو توزيع حمل العمل على نطاق أوسع.
يمكن أن يساعد التحجيم على تحسين الأداء عن طريق زيادة معدل النقل، حيث يمكن الآن تقديم عدد أكبر من الطلبات. ويمكن أن يساعد هذا أيضًا على تقليل زمن الانتقال في أثناء أحمال الذروة، بحكم أنه يوجد عدد أقل من الطلبات في قائمة الانتظار خلال أوقات أحمال الذروة على مورد منفرد. وبالإضافة إلى ذلك، يمكن أن يساعد ذلك على تحسين موثوقية النظام عن طريق الحد من استخدام الموارد بحيث يكون أبعد من نقطة التعطل في المورد.
تجدُر الملاحظة إلى أنه على الرغم من أن السحابة تمكننا من تزويد موارد أحدث أو أفضل بسهولة، فدائمًا ما تشكل التكلفة عاملًا معارضًا يجب مراعاته. لذلك، وبالرغم من فائدة تكبير حجم الموارد أو توسيعها، فلا بُد من تمييز الوقت الذي ينبغي فيه تصغير حجم الموارد أو تقليصها توفيرًا للتكلفة. في تطبيق n-tier، من الضروري أيضاً تحديد أين توجد ازدحامات وأي المستويات يجب قياسه، سواء كانت الطبقة المسؤولة عن البيانات أو مستوى الخادم.
يُسهَّل تحجيم الموارد باستخدام موازن التحميل (ناقشنا هذا سابقًا)، مما يساعد على إخفاء جانب التحجيم في نظامٍ ما عن طريق إخفائه خلف نقطة نهاية متناسقة.
استراتيجيات التحجيم
تحجيم أفقي (توسيع النطاق وتقليصه)
التحجيم الأفقي هو استراتيجية حيث يمكن إضافة موارد إضافية إلى النظام أو يمكن إزالة الموارد الخارجية من النظام. وهذا النوع من التحجيم مفيد للطبقة المسؤولة عن الخادم، عندما يكون الحمل على النظام غير متوقع ويتقلب بصورة غير متسقة. إن الطبيعة المتقلبة للحمل تُحتم علينا تزويد الكمية الصحيحة من الموارد بكفاءة للتمكن من معالجة الحمل في جميع الأوقات.
وهناك بعض الاعتبارات التي تجعل من هذه المهمة صعبة ألا وهي وقت عرض المثيل، ونموذج التسعير لمزود الخدمة السحابية، والخسارة المحتملة في الإيرادات من تدهور جودة الخدمة (QoS) من خلال عدم التوسع في الوقت المناسب. كمثال، لنفترض في نمط الحمل التالي:
شكل 6: نمط عيني من طلب الحمل
دعونا نتخيل أننا نستخدم Amazon Web Services. دعونا نتخيل أيضا أن كل وحدة زمنية تعادل 3 ساعات من الوقت الفعلي وأننا بحاجة إلى خادم واحد لخدمة 5 آلاف طلب. إذا كنت تفكر في الحمل خلال الوحدات الزمنية من 16 إلى 22، فهناك تقلب هائل في الحمل. يمكننا اكتشاف انخفاض في الطلب في وقت قريب من الوحدة الزمنية 16 والبدء في تقليل عدد الموارد المخصصة. نظرًا لأننا ننتقل من ما يقرب من 50 ألف طلب إلى ما يقرب من 0 طلب في غضون 3 ساعات، فيمكننا أكاديميًا توفير تكلفة 10 مثيلات كانت ستصل في الوحدة الزمنية 16.
الآن دعونا نتخيل بدلًا من ذلك أن كل وحدة زمنية تساوي 20 دقيقة من الوقت الفعلي. في هذه الحالة، سيؤدي تدوير جميع الموارد في الوحدة الزمنية 16 فقط لتدوير الموارد الجديدة بعد 20 دقيقة إلى زيادة التكلفة بدلًا من الادخار، نظرًا لأن AWS تفوتر كل مثيل حساب على أساس كل ساعة.
بالإضافة إلى الاعتبارين المذكورين أعلاه، سيحتاج مزود الخدمة أيضًا إلى تقييم الخسائر التي سيتكبدها من خلال تزويد جودة الخدمة المتدهورة خلال الوحدة الزمنية 20، إذا كان لديه سعة 90 ألف طلب فقط بدلًا من 100 ألف طلب.
يعتمد التحجيم على خصائص نسبة استخدام الشبكة وحملها الناتج الذي أنشئ على خدمة ويب. إذا كانت حركة المرور تتبع نمطًا يمكن التنبؤ به (على سبيل المثال، استنادًا إلى السلوك البشري مثل بث الأفلام من خدمة الويب في المساء)، فيمكن أن يكون التحجيم متوقعًامن أجل الحفاظ على جودة الخدمة. ومع ذلك، وفي الكثير من الحالات، لا يمكن التنبؤ بنسبة استخدام الشبكة، وينبغي أن تكون أنظمة التحجيم تفاعليةعلى أساس معايير مختلفة، كما أظهرت الأمثلة أعلاه.
تحجيم الرأسي (تكبير الحجم وتصغيره)
هناك أنواع معينة من الأحمال لمقدمي الخدمات يمكن التنبؤ بها أكثر من غيرها. على سبيل المثال، إذا كنت تعلم من الأنماط التاريخية أن عدد الطلبات سيتراوح دائمًا من 10 إلى 15 ألفًا، فيمكنك أن تفترض بسهولة أن خادمًا واحدًا يمكنه خدمة 20 ألف طلب سيكون جيدًا بما يكفي لأغراض مزود الخدمة. قد تزداد هذه الأحمال في المستقبل، ولكن طالما أنها تزداد بطريقة متسقة، يمكن نقل الخدمة إلى مثيل أكبر يمكنه خدمة المزيد من الطلبات. هذا مناسب للتطبيقات الصغيرة التي تواجه نسبةً قليةً من حركة المرور.
يكمن التحدي في التحجيم الرأسي بوجه عام في أن هناك دائمًا بعض الوقت للتبديل والذي يمكن اعتباره وقت تعطل. هذا لأنه من أجل نقل جميع العمليات من المثيل الأصغر إلى مثيل أكبر، حتى لو كان وقت التبديل مجرد دقائق، فإن جودة الخدمة تتدهور أثناء تلك الفترة.
بالإضافة إلى ذلك، يقدم معظم موفري خدمة السحابة موارد الحوسبة في زيادة طاقة الحوسبة عن طريق مضاعفة طاقة الحوسبة الخاصة بالموارد. ولذلك فإن الدقة في التحجيم ليست دقيقة كما هو الحال في التحجيم الأفقي. لذلك حتى لو كان الحمل متوقعًا ويزداد باطراد مع زيادة شعبية الخدمة، يختار العديد من مقدمي الخدمات التحجيم الأفقي بدلًا من التحجيم الرأسي.
اعتبارات التحجيم
مراقبة
تُعد المراقبة أحد أهم العناصر في تحجيم الموارد بفعالية، حيث أنها تمكِّنك من الحصول على قياسات يمكن استخدامها لتفسير أي أجزاء من النظام تحتاج إلى توسيع نطاقها ومتى تحتاج إلى هذه التوسعة. تُمكِّن المراقبة من تحليل أنماط حركة المرور أو استخدام الموارد، وذلك لإجراء تقييم مستنير لمعرفة وقت وكيفية تحجيم الموارد لزيادة جودة الخدمة إلى أقصى حد مع تحقيق الربح.
هناك عدة جوانب من الموارد التي يجري مراقبتها لتشغيل تحجيم الموارد. القياس الأكثر شيوعًا هو استخدام الموارد. على سبيل المثال، يمكن لخدمة مراقبة أن تتبع استخدام معالج CPU لكل عقدة مورد وتحجيم الموارد إذا كان الاستخدام زائدًا أو منخفضًا جدًا. إذا كان استخدام كل مورد، على سبيل المثال، أعلى من 95%، فمن الجيد على الأرجح أن تُضاف المزيد من الموارد لأن النظام يواجه حملًا ثقيلًا. عادةً ما يقرر مقدمو الخدمات نقاط التشغيل هذه من خلال تحليل نقطة التعطل لعقد الموارد، ومتي ستبدأ في التعرض للفشل، وتخطيط سلوكها تحت مستويات متنوعة من الحمل. على الرغم من أنه لا بُد من الاستفادة بأقصى حد من استخدام كل مورد، لأسباب تتعلق بالتكلفة، فإنه يُنصح بترك بعض المساحة لنظام التشغيل، بحيث يُسمح بإلأنشطة العامة. وبالمثل، إذا كانت نسبة الاستخدام أقل من 50%، على سبيل المثال، فمن الممكن ألّا تكون جميع عُقد المورد مطلوبة ويمكن إلغاء تزويد بعضها.
من الناحية العملية، عادة ما يقوم موفرو الخدمات بمراقبة مجموعة من القياسات المختلفة المتعددة لعقدة الموارد من أجل تقييم وقت تحجيم الموارد. ويتضمن بعضها استخدام معالج، واستهلاك الذاكرة، ومعدل النقل، وزمن الانتقال. Azure تقدم Azure Monitor باعتبارها خدمة إضافية يمكنها مراقبة أي مورد Azure وتقديم مثل هذه القياسات.
انعدام الحالة
إن تصميم الخدمة عديمة الحالة مناسب للهندسة القابلة للتوسع. ويُقصد بالخدمة عديمة الحالة، بشكل جوهري، أن العميل يطلب جميع المعلومات اللازمة لخدمة الطلب من قِبل الخادم. لا يخزن الخادم أية معلومات متعلقة بالعميل في المثيل ولا يخزن أية معلومات متعلقة بجلسة العمل في مثيل الخادم.
تساعد الخدمة عديمة الحالة على تبديل الموارد حسب الرغبة، دون أي تكوين مطلوب للحفاظ على سياق (حالة) اتصال العميل للطلبات اللاحقة. إذا كانت الخدمة ذات حالة، فإن تحجيم المورد يتطلب استراتيجية لنقل السياق من تكوين العقدة الحالية إلى تكوين العقدة الجديدة. لاحظ أن هناك تقنيات مُخصّصة لتنفيذ الخدمات ذات الحالة، على سبيل المثال، الاحتفاظ بذاكرة التخزين المؤقت للشبكة باستخدام Memcached بحيث يمكن مشاركة السياق عبر الخوادم.
تحديد ما الذي يجب قياسه
اعتمادا على طبيعة الخدمة، يجب قياس الموارد المختلفة حسب المتطلبات. بالنسبة لطبقة الخادم، مع زيادة أحمال العمل، اعتمادًا على نوع التطبيق، قد يؤدي ذلك إلى زيادة المنافسة على اتصال الموارد من أجل المعالج أو الذاكرة أو النطاق الترددي للشبكة أو جميع ما سبق. تتيح لنا مراقبة حركة المرور تحديد المورد الذي يُقيد وتوسيع نطاق هذا المورد المحدد على نحوٍ مناسب. لا يزود مقدمو خدمة السحابة بالضرورة دقة قابلية التوسع لقياس الحوسبة أو الذاكرة فقط، ولكنهم يقدمون أنواعًا مختلفة من مثيلات الحوسبة التي تلبي على وجه التحديد التي تلبي على وجه التحديد الأحمال ثقيلة الذاكرة أو ثقيلة الحساب. لذلك، على سبيل المثال، لتطبيق يحتوي على أحمال عمل كثيفة الذاكرة، سيكون من المستحسن زيادة الموارد إلى مثيلات الذاكرة المحسنة. بالنسبة للتطبيقات التي تحتاج إلى خدمة عدد كبير من الطلبات التي لا تتطلب بالضرورة حسابًا ثقيلًا أو ذاكرة ثقيلة، فإن توسيع نطاق مثيلات الحوسبة القياسية المتعددة قد يكون استراتيجية أفضل.
قد لا تكون زيادة موارد الأجهزة ليست الحل الأفضل دائمًا لزيادة أداء الخدمة. يمكن لزيادة كفاءة الخوارزميات المستخدمة ضمن الخدمة أن تؤدي إلى تقليل المنافسة على الاتصال بالمورد وتحسين الاستخدام، والتخلص من الحاجة إلى توسيع نطاق الموارد المادية.
قياس الطبقة المسؤولة عن البيانات
في التطبيقات الموجهة نحو البيانات، حيث يوجد عدد كبير من عمليات القراءة والكتابة (أو كليهما) إلى قاعدة بيانات أو نظام تخزين، غالبًا ما يكون وقت الرحلة ذهابًا وإيابًا لكل طلب محدودًا بأوقات قراءة وكتابة الإدخال/الإخراج الخاصة بالقرص الصلب. تسمح المثيلات الأكبر بأداء إدخال/إخراج أعلى للقراءة والكتابة، مما يمكن أن يحسن أوقات البحث على القرص الصلب، والذي بدوره يمكن أن يؤدي إلى تحسن كبير في زمن انتقال الخدمة. وجود مثيلات بيانات متعددة في الطبقة المسؤولة عن البيانات يمكن أن يحسن من موثوقية التطبيق وقابلية الوصول إليه عن طريق تزويد تكرارات تجاوز الفشل. النسخ المتماثل للبيانات عبر مثيلات متعددة له مزايا إضافية في تقليل زمن انتقال الشبكة إذا كان العميل يخدمه مركز بيانات أقرب إليه فعليًا. يُعد تقسيم البيانات أو تجزئتها عبر الموارد المتعددة استراتيجية أخرى لتحجيم البيانات الأفقية، حيث تُقسم البيانات إلى شرائح وتخزن عبر خوادم البيانات المتعددة بدلًا من إنشاء نسخة مماثلة لها عبر المثيلات المتعددة.
هناك تحدي إضافي يتعلق بتحجيم الطبقة المسؤولة عن البيانات، وهو يتمثل في الحفاظ على الاتساق (تتطابق عملية القراءة في جميع النسخ المماثلة)، والإتاحة (نجاح عمليتَي القراءة والكتابة دائمًا)، وتحمل التجزئة (الحفاظ على الخصائص المضمونة في النظام عندما تؤدي حالات الفشل إلى منع التواصل عبر العقد). غالبًا ما يُشار إلى ذلك باسم نظرية CAP، والتي تنص على أنه في نظام قاعدة بيانات الموزعة، يكون من الصعب جدًا الحصول على جميع الخصائص الثلاثة كاملةً وبالتالي يمكن للنظام أن يعرض مزيجًا من اثنين من الخصائص على الأكثر. سوف تتعلم المزيد حول عن استراتيجيات توسيع قاعدة البيانات ونظرية CAP في الوحدات اللاحقة.
اختبر معلوماتك
الملاحظات
هل كانت هذه الصفحة مفيدة؟
لا
هل تحتاج إلى مساعدة مع هذا الموضوع؟
هل تريد محاولة استخدام Ask Learn لتوضيح هذا الموضوع أو إرشادك خلاله؟