التوسيع التلقائي

ماذا يفعل

يراقب التوسيع التلقائي (Autoscaling) متوسط استهلاك المعالج والذاكرة في تطبيقك، ويغيّر عدد النسخ (instances) العاملة بين حدّ أدنى وحدّ أقصى تختارهما أنت. عندما يبقى الاستهلاك فوق الهدف تُضاف نسخ؛ وعندما يعود للانخفاض تُزال النسخ، تدريجياً لا فجأة. تضبطه لكل تطبيق من قسم التوسيع في صفحة التطبيق بالبوابة، أو عبر الـ API.

ينطبق التوسيع التلقائي على التطبيقات فقط. أمّا قواعد البيانات المُدارة فتعمل بعدد نسخ ثابت في هذا الإصدار الأول. اقرأ الملاحظة الصريحة في الأسفل.

السياسة

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

مهلة الاستقرار قبل التقليص

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

إيقاف التطبيق يتقدّم على السياسة

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

التعديل اليدوي لعدد النسخ مقفل

ما دامت السياسة فعّالة، فالتوسيع التلقائي هو مالك عدد النسخ. يُعطَّل حقل النسخ في نافذة تعديل التطبيق مع إشارة إلى سياسة التوسيع، ويُرفض أي طلب API يحاول تغييره مباشرة بالرمز 409 AUTOSCALING_OWNS_REPLICAS. لتثبيت عدد يدوي من جديد، أوقف السياسة أولاً: يستمر تطبيقك حينها بآخر عدد نسخ وصل إليه التوسيع، ويعود الحقل للعمل.

سقف المشروع

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

شرط الرصيد

التوسّع يكلّف مالاً، لذا يتطلّب تفعيل السياسة، أو رفع حدّها الأقصى، أن يغطّي رصيدك الحالي تكلفة 48 ساعة من التشغيل عند الحدّ الأقصى:

الرصيد المطلوب = التكلفة بالساعة عند الحدّ الأقصى × 48 ساعة

ولماذا 48 ساعة؟ لأنها فترة السماح في المنصّة. هذا الشرط يضمن ألا يدفع توسّعٌ طلبتَه أنت رصيدَك إلى الدَّين لحظة وصول الزوّار.

مثال محسوب. تطبيق يحجز 0.25 vCPU و512 MB تكلّف نسخته الواحدة نحو $0.0041 في الساعة (قرابة $3 شهرياً). بحدّ أقصى 4 نسخ:

التكلفة بالساعة عند الحدّ الأقصى = 4 × $0.0041  ≈ $0.0165
الرصيد المطلوب                  = $0.0165 × 48 ≈ $0.79

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

وإذا نفد رصيدك لاحقاً والتطبيق متوسّع، تنطبق آلية التعليق المعتادة بعد فترة السماح: يُعلَّق التطبيق ويُصفَّر عدد نسخه كأي خدمة غير مدفوعة.

قواعد البيانات المُدارة لا تتوسّع (بعد)

في هذا الإصدار الأول، التوسيع التلقائي للتطبيقات فقط. وأي محاولة لربط سياسة بخدمة Postgres أو MySQL أو Redis مُدارة تُرفض بالرمز 409 UNSUPPORTED_SERVICE_TYPE. والسبب بصراحة: توسيع عدد نسخ قاعدة بيانات بأمان يتطلّب آليات نسخ متماثل وتوسعة تخزين لم تنضج بعد، ولن نطلق مفتاحاً يعرّض بياناتك للخطر.

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

كل تغيير يُسجَّل

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