قابلية التوسع السحابي: متى يجب التوسع رأسيًّا مقابل التوسع رأسيًّا؟

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

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

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

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

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

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

عادة ما يرتبط التوسع الأفقي بالبنى الموزعة. هناك نوعان أساسيان من أشكال التوسع الأفقي:

• إضافة سعة بنية تحتية إضافية في كتل البنية التحتية المعبأة مسبقًا أو العُقَد (أي فائق التقارب)
• استخدام خدمة موزعة يمكنها استرجاع معلومات العملاء ولكن بشكل مستقل عن التطبيقات أو الخدمات، ومعالجة مشكلات الأداء وتحسين موارد الحوسبة السحابية

يُستَخدَم كلا النهجين اليوم من قبل مزودي الخدمات السحابية المعاصرين (CSPs)، إلى جانب التوسع الرأسي للعناصر الفردية ((الحوسبة والذاكرة والشبكة والتخزين) بهدف خفض التكاليف. يسهل التوسع الأفقي على مقدمي الخدمات تقديم البنية التحتية والخدمات بنموذج "الدفع مقابل النمو"، مما يؤثر على استراتيجيات التسعير.

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

تسمح البنية الموزعة فضفاضة الاقتران بتوسيع نطاق كل جزء من البنية بشكل مستقل، مما يقضي بشكل فعال على نقاط الاختناق. وهذا يعني أنه يمكن إنشاء مجموعة من المنتجات البرمجية ونشرها كقطع مستقلة، حتى مع عملها معًا لإدارة سير عمل كامل. يتكون كل تطبيق من مجموعة من الخدمات المُجرَّدة التي يمكن أن تعمل وتنفذ مهامها بشكل مستقل. هذا يسمح بالتوسع الأفقي على مستوى المنتج وعلى مستوى الخدمة أيضًا. ويمكن تحديد مستويات أكثر دقة من قابلية التوسع استنادًا إلى اتفاقيات مستوى الخدمة (SLAs) أو فئات العملاء (مثل البرونزي أو الفضي أو الذهبي) أو حتى وفقًا لأنواع واجهات برمجة التطبيقات (APIs) في حال وجود اختلاف في مستويات الطلب على بعض الواجهات. يمكن لهذا أن يعزز الاستخدام الفعال للتوسع ضمن بنية تحتية معينة.

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

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

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