الخلاصة

  • يشغّل Cloud Run الحد الأدنى لمثيلات النسخة عندما تدخل في تقسيم الزيارات أو تحمل علامة مرور. وتوضح Google أن النسخة الموسومة قد تظل نشطة ومدفوعة حتى في غياب الطلبات.
  • يُوزَّع الحد الأدنى للخدمة بحسب نسب الزيارات؛ أما الحد الخاص بنسخة واحدة فقد يجعل مجموع المثيلات الجاهزة أكبر من الرقم المحدد للخدمة.

باب المعاينة الخالي يستهلك مقعدًا

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

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

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

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

المصادر