COLA: التوسع التلقائي الجماعي للخدمات المصغرة السحابية

1. المقدمة

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

2. مشكلة التوسع التلقائي المستقل

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

3. COLA: نهج التوسع التلقائي الجماعي

يعيد COLA صياغة مشكلة التوسع التلقائي كـ مشكلة تحسين مقيدة. فهو يستبدل عدة موسعات تلقائية مستقلة بوحدة تحكم مركزية واحدة تتمتع برؤية شاملة لبنية الخدمات المصغرة وأداء التطبيق.

4. التفاصيل التقنية والصياغة الرياضية

يمكن تمثيل مشكلة التحسين الأساسية بشكل مجرد على النحو التالي:

$$\min_{\{n_i\}} \sum_{i=1}^{M} C_i(n_i)$$ $$\text{subject to: } L_{e2e}(\{n_i\}, \lambda) \leq L_{target}$$ $$n_i \in \mathbb{Z}^+$$ حيث:

• $M$: عدد الخدمات المصغرة.
• $n_i$: عدد وحدات الموارد (مثل الآلات الافتراضية) للخدمة المصغرة $i$.
• $C_i(n_i)$: دالة التكلفة للخدمة المصغرة $i$ مع $n_i$ وحدة.
• $L_{e2e}$: دالة زمن الاستجابة الشامل، تعتمد على جميع $n_i$ وكثافة حمل العمل $\lambda$.
• $L_{target}$: هدف مستوى الخدمة (SLO) المطلوب لزمن الاستجابة.

5. النتائج التجريبية والتقييم

تم تقييم COLA بدقة مقابل عدة موسعات تلقائية أساسية (قائمة على الاستخدام وقائمة على التعلم الآلي) على Google Kubernetes Engine (GKE).

6. إطار التحليل وحالة مثال

منظور المحلل: تفكيك من أربع خطوات

الفكرة الأساسية: الاختراق الأساسي للورقة البحثية ليس خوارزمية جديدة فاخرة، ولكن تحول حاسم في المنظور: معاملة تطبيق الخدمات المصغرة بأكمله كنظام واحد يجب تحسينه، وليس مجموعة من الأجزاء المستقلة. هذا مشابه للتحول في رؤية الكمبيوتر الذي أحدثته نماذج مثل CycleGAN (Zhu et al., 2017)، والتي تجاوزت ترجمة الصور المقترنة من خلال النظر في اتساق الدورة لمجال التحويل بأكمله. يطبق COLA مبدأ "الاتساق الشامل" المماثل على إدارة الموارد.

التدفق المنطقي: الحجة مقنعة وبسيطة: 1) الأمثلية المحلية (التوسع لكل خدمة) تتراكم لتشكل عدم كفاءة شاملة. 2) لذلك، استخدم هدفًا شاملًا (التكلفة) مع قيد شامل (زمن الاستجابة الشامل). 3) نظرًا لأن حل هذا أثناء التشغيل بطيء جدًا، قم بحله خارج الخط عبر البحث ونشر السياسة. تكمن الأناقة في استخدام مشكلة Bandit لجعل البحث عن التخصيص الأمثل للاختناق فعالاً، وهي تقنية مدعومة بأبحاث مكثفة في التعلم المعزز لتحسين الأنظمة (على سبيل المثال، أعمال من مختبر RISELab في جامعة كاليفورنيا، بيركلي).

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

رؤى قابلة للتنفيذ: لمهندسي السحابة، الرسالة واضحة: توقفوا عن ضبط عتبات وحدة المعالجة المركزية بشكل منعزل. استثمروا في بناء أو تبني قابلية مراقبة الأداء الشامل ومحرك قرار مركزي. ابدأوا بنهج هجين: استخدم فلسفة COLA لتحديد سلاسل الخدمات الحرجة وتطبيق التوسع الجماعي هناك، مع ترك الخدمات الأقل أهمية والمستقلة على HPA التقليدي. كما هو موضح، يمكن أن يكون عائد الاستثمار سريعًا. يجب على مزودي السحابة الانتباه؛ تحتاج أدوات مثل GKE Autopilot إلى مثل هذه الطبقات الذكية للتنسيق لتقديم وعد البنية التحتية "المدارة" حقًا.

7. آفاق التطبيق والاتجاهات المستقبلية

المبادئ الكامنة وراء COLA لها قابلية تطبيق واسعة تتجاوز التوسع الأساسي للآلات الافتراضية:

• التوسع متعدد الموارد وغير المتجانس: يمكن للإصدارات المستقبلية أن تقرر بشكل جماعي حجم الآلة الافتراضية (المحسنة للذاكرة مقابل المحسنة للحوسبة)، وتخصيص GPU، وحتى التنسيب عبر مناطق التوفر أو مزودي السحابة من أجل التكلفة والمرونة.
• التكامل مع شبكات الخدمة: سيوفر اقتران COLA مع شبكة خدمة (مثل Istio) قياسًا عن بعد أكثر ثراءً (تتبع مستوى الطلب، رسومات التبعية) ويمكن حتى من التحكم المباشر في توجيه حركة المرور وكسر الدائرة كجزء من التحسين.
• التكيف أثناء التشغيل والتعلم الفوقي: الحدود البحثية الرئيسية هي التغلب على القيد خارج الخط. يمكن لتقنيات التعلم الفوقي أن تسمح لـ COLA بتكييف سياسته بسرعة أثناء التشغيل بناءً على التغذية الراجعة في الوقت الفعلي، أو استكشاف تكوينات جديدة بأمان خلال فترات حركة المرور المنخفضة.
• أهداف الحوسبة الخضراء: يمكن توسيع هدف التحسين لتقليل البصمة الكربونية أو استهلاك الطاقة، بما يتماشى مع مبادرات الحوسبة المستدامة، من خلال دمج بيانات من مصادر مثل مشروع Cloud Carbon Footprint.
• سوق للسياسات: بالنسبة لأنماط التطبيقات الشائعة (مثل التجارة الإلكترونية، بث الوسائط)، يمكن مشاركة أو بيع سياسات COLA المحسنة مسبقًا، مما يقلل من الحاجة إلى عمليات تدريب فردية.

8. المراجع

1. Sachidananda, V., & Sivaraman, A. (2022). COLA: Collective Autoscaling for Cloud Microservices. arXiv preprint arXiv:2112.14845v3.
2. Zhu, J., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV).
3. Burns, B., Grant, B., Oppenheimer, D., Brewer, E., & Wilkes, J. (2016). Borg, Omega, and Kubernetes. Queue, 14(1), 70–93.
4. Hoffman, M., Shahriari, B., & Aslanides, J. (2020). Addressing Function Approximation Error in Actor-Critic Methods. Proceedings of the 37th International Conference on Machine Learning (ICML). (Example of advanced RL relevant for online adaptation).
5. Cloud Carbon Footprint. (n.d.). An open source tool to measure and visualize the carbon footprint of cloud usage. Retrieved from https://www.cloudcarbonfootprint.org/.
6. Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. Proceedings of the European Conference on Computer Systems (EuroSys).