فهم نماذج T3 القابلة للتوسع: ما معنى 'أرصدة المعالج' ولماذا يتباطأ الخادم فجأة؟

وصلني تذكرة دعم في منتصف الليل: 'الخادم أصبح بطيئاً جداً فجأة بعد ساعات من الأداء الجيد.' بعد التحقيق، اتضح أن الفريق اختار نموذج T3 لأنه 'أرخص'، دون أن يفهم آلية أرصدة المعالج التي تتحكم في أداء هذه النماذج بشكل جذري.

ملخص سريع (TL;DR): أرصدة المعالج في نماذج T3

المفهوم	الشرح المختصر
رصيد المعالج (CPU Credit)	وحدة قياس تمثل دقيقة واحدة من استخدام معالج واحد بنسبة 100%
معدل تراكم الأرصدة	يختلف حسب حجم النموذج، يُحدد بعدد الأرصدة المكتسبة في الساعة
الحد الأساسي (Baseline)	نسبة المعالج المضمونة دون استهلاك أرصدة
وضع Unlimited	يسمح بتجاوز الأرصدة مقابل تكلفة إضافية
سبب التباطؤ المفاجئ	نفاد الأرصدة يُقيّد المعالج عند الحد الأساسي فقط

كيف تعمل نماذج T3: آلية أرصدة المعالج

نماذج T3 هي نماذج قابلة للتوسع (Burstable Performance)، وهي مختلفة جوهرياً عن نماذج M5 أو C5. الفكرة الأساسية: النموذج يعمل عادةً عند نسبة معالج منخفضة (الحد الأساسي)، ويجمع أرصدة خلال فترات الخمول، ثم يستخدم هذه الأرصدة للوصول إلى 100% من المعالج عند الحاجة.

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

مكونات النظام

• الحد الأساسي (Baseline Utilization): نسبة المعالج المضمونة دائماً دون استهلاك أرصدة. مثلاً، t3.micro له حد أساسي 10% لكل vCPU.
• معدل تراكم الأرصدة: عدد الأرصدة التي يكسبها النموذج في الساعة. يتناسب مع حجم النموذج.
• الحد الأقصى للأرصدة المخزنة: سقف الأرصدة التي يمكن تجميعها. بعد الوصول إليه، تتوقف إضافة أرصدة جديدة.
• استهلاك الأرصدة: كل دقيقة يعمل فيها المعالج بنسبة أعلى من الحد الأساسي تستهلك أرصدة بنسبة الفرق.

graph TD A["النموذج يعمل
أقل من الحد الأساسي"] -->|"تراكم الأرصدة"| B["مخزن الأرصدة
CPUCreditBalance"] B -->|"حمل مرتفع"| C["وضع التوسع (Burst)
حتى 100% معالج"] C -->|"استهلاك الأرصدة"| D{"هل الأرصدة
نفدت؟"} D -->|"لا"| C D -->|"نعم - وضع Standard"| E["تقييد المعالج
عند الحد الأساسي فقط"] D -->|"نعم - وضع Unlimited"| F["استمرار التوسع
مع رسوم إضافية"] E -->|"فترة خمول"| A F -->|"فترة خمول"| A

1. مرحلة التراكم: عندما يكون استخدام المعالج أقل من الحد الأساسي، تتراكم الأرصدة تدريجياً حتى الحد الأقصى.
2. مرحلة التوسع (Burst): عند الحاجة لمعالجة مكثفة، يستخدم النموذج الأرصدة المخزنة للوصول إلى 100% من طاقة المعالج.
3. مرحلة النفاد: حين تنتهي الأرصدة، يُقيَّد المعالج عند الحد الأساسي فقط — هنا يحدث التباطؤ المفاجئ.
4. وضع Unlimited: إذا كان مفعّلاً، يستمر النموذج في العمل فوق الحد الأساسي مقابل رسوم إضافية لكل vCPU-hour.

صيغة استهلاك الأرصدة

الأرصدة المستهلكة في الدقيقة = (نسبة استخدام المعالج الفعلية − الحد الأساسي) × عدد vCPUs × (1/100)

مثال عملي: نموذج t3.micro (vCPU واحد، حد أساسي 10%) يعمل بنسبة 60% لمدة دقيقة واحدة يستهلك: (60 − 10) × 1 × 0.01 = 0.5 رصيد.

مقارنة أحجام نماذج T3 الشائعة

القيم التالية مستمدة من توثيق AWS الرسمي — تحقق دائماً من صفحة التوثيق الرسمية لأن هذه القيم قابلة للتغيير.

النموذج	vCPUs	الحد الأساسي لكل vCPU	أرصدة مكتسبة/ساعة	الحد الأقصى للأرصدة
t3.nano	2	5%	6	144
t3.micro	2	10%	12	288
t3.small	2	20%	24	576
t3.medium	2	20%	24	576
t3.large	2	30%	36	864
t3.xlarge	4	40%	96	2304

تشخيص مشكلة التباطؤ المفاجئ: الأعراض والأسباب والحل

الأعراض الشائعة

• استجابة الخادم تتدهور فجأة بعد فترة من الأداء الجيد
• مقاييس CloudWatch تُظهر استخدام المعالج ثابتاً عند نسبة منخفضة بشكل مريب
• لا توجد أخطاء في سجلات التطبيق — المشكلة على مستوى البنية التحتية
• التباطؤ يختفي بعد فترة من الخمول ثم يعود عند الضغط

التشخيص الخاطئ الشائع والسبب الحقيقي

الفريق يرى استخدام المعالج عند 10% في CloudWatch ويستنتج: 'المعالج ليس مشكلة، المشكلة في قاعدة البيانات أو الشبكة.' يقضون ساعات في تحليل استعلامات SQL وتتبع حزم الشبكة. الحقيقة: النموذج نفد من أرصدته وقُيِّد عند الحد الأساسي 10% — وهذا بالضبط ما تراه في CloudWatch. المعالج لا يستطيع الصعود أعلى من ذلك حتى لو كان التطبيق يطلب المزيد.

المقياس الذي يكشف الحقيقة هو CPUCreditBalance — وليس CPUUtilization.

graph LR A["ارتفاع مفاجئ
في وقت الاستجابة"] --> B{"ما الذي
تراه في CloudWatch؟"} B -->|"CPUUtilization ثابت
عند نسبة منخفضة"| C["تشخيص خاطئ شائع:
'المعالج ليس المشكلة'"] C --> D["البحث في قاعدة البيانات
والشبكة... بلا نتيجة"] B -->|"CPUCreditBalance
قريب من الصفر"| E["السبب الحقيقي:
نفاد الأرصدة"] E --> F["المعالج مقيّد
عند الحد الأساسي"] F --> G["الحل: تغيير وضع الأرصدة
أو ترقية النموذج"]

خطوات التشخيص العملي

الخطوة 1: التحقق من رصيد الأرصدة الحالي

أول خطوة هي قراءة مقياس CPUCreditBalance مباشرة. إذا كان قريباً من الصفر أو عند الصفر خلال فترة التباطؤ، فأنت أمام مشكلة نفاد الأرصدة — وليس مشكلة تطبيق.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T12:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

الخطوة 2: مقارنة استهلاك الأرصدة مع الأرصدة المكتسبة

رؤية الرصيد وحده لا تكفي — تحتاج لفهم معدل الاستهلاك مقارنةً بمعدل التراكم. إذا كان CPUCreditUsage يتجاوز باستمرار معدل الاكتساب، فالنموذج يسير نحو النفاد حتماً.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T12:00:00Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

الخطوة 3: التحقق من وضع Unlimited

نماذج T3 تأتي مع وضع unlimited مفعّلاً افتراضياً — لكن هذا لا يعني أن المشكلة لن تظهر. يعني فقط أن النموذج سيستمر في العمل مقابل تكلفة إضافية. تحقق من الإعداد الحالي لتعرف هل أنت تدفع رسوماً إضافية دون أن تعلم.

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1

الخطوة 4: التحقق من مقياس الأرصدة الفائضة (في وضع Unlimited)

إذا كان وضع unlimited مفعّلاً، يُظهر مقياس CPUSurplusCreditBalance الأرصدة التي اقترضها النموذج فوق ما اكتسبه. هذا الرقم يُترجم مباشرة إلى تكلفة إضافية في فاتورتك.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T12:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

الخطوة 5: إنشاء تنبيه على CloudWatch لرصيد الأرصدة

التشخيص التفاعلي لا يكفي في بيئة الإنتاج. ضع تنبيهاً يُطلق إنذاراً قبل نفاد الأرصدة بوقت كافٍ للتدخل — سواء بتغيير النموذج أو تفعيل وضع Unlimited.

aws cloudwatch put-metric-alarm \
  --alarm-name 'T3-CPUCreditBalance-Low' \
  --alarm-description 'CPU Credit Balance dropping low on T3 instance' \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 50 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1

وضع Standard مقابل وضع Unlimited: متى تختار كلاً منهما

graph TD A["وضع Standard"] --> A1["عند نفاد الأرصدة:
تقييد المعالج"] A --> A2["لا تكاليف إضافية"] A --> A3["مناسب: أحمال متقطعة"] B["وضع Unlimited"] --> B1["عند نفاد الأرصدة:
استمرار التوسع"] B --> B2["رسوم إضافية
لكل vCPU-hour فائض"] B --> B3["مفعّل افتراضياً
على T3"] B --> B4["خطر: تكلفة غير متوقعة
عند الحمل المستمر"]

وضع Standard

• عند نفاد الأرصدة، يُقيَّد المعالج عند الحد الأساسي.
• لا توجد تكاليف إضافية فوق سعر النموذج الأساسي.
• مناسب للأحمال المتقطعة التي تحتاج توسعاً قصيراً ثم تعود للخمول.

وضع Unlimited

• النموذج يستمر في التوسع حتى بعد نفاد الأرصدة.
• يُفرض رسم إضافي لكل vCPU-hour من الاستخدام الفائض — راجع صفحة أسعار EC2 للقيم الحالية.
• مفعّل افتراضياً على نماذج T3 عند الإطلاق.
• خطر: إذا كان الحمل مرتفعاً باستمرار، قد تتجاوز التكلفة سعر نموذج ثابت الأداء مثل m5.

تغيير وضع الأرصدة

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1

لتفعيل وضع unlimited، استبدل standard بـ unlimited في الأمر أعلاه.

متى تتخلى عن T3 وتنتقل لنموذج آخر

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

• متوسط استخدام المعالج يتجاوز الحد الأساسي باستمرار لساعات طويلة.
• رصيد CPUSurplusCreditBalance يرتفع بشكل مستمر في وضع Unlimited.
• تكلفة الأرصدة الفائضة تقترب من أو تتجاوز الفرق في السعر بين T3 ونموذج ثابت الأداء.
• التطبيق حساس للكمون ولا يتحمل تقلبات الأداء.

نموذج T3 الذي يعمل بوضع Unlimited تحت حمل مستمر قد يكلفك أكثر من m5.large — مع أداء أقل استقراراً. احسب التكلفة الفعلية قبل أن تفترض أن 'الأرخص' هو الأوفر.

مسار قرار اختيار النموذج

graph TD START(["هل تحتاج EC2 للمعالجة؟"]) --> Q1{"هل متوسط استخدام
المعالج أقل من 40%؟"} Q1 -->|"نعم"| Q2{"هل الحمل متقطع
مع فترات خمول؟"} Q1 -->|"لا"| REC2["استخدم نموذجاً ثابتاً
مثل m5 أو c5"] Q2 -->|"نعم"| Q3{"هل التطبيق حساس
لتقلبات الأداء؟"} Q2 -->|"لا"| REC2 Q3 -->|"لا"| REC1["T3 مناسب
وضع Standard أو Unlimited"] Q3 -->|"نعم"| REC2

صلاحيات IAM المطلوبة لمراقبة أرصدة T3

للوصول إلى مقاييس CloudWatch الخاصة بأرصدة المعالج وتعديل إعدادات النموذج، تحتاج الصلاحيات التالية كحد أدنى:

🔽 عرض سياسة IAM المطلوبة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadCPUCreditMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DescribeInstanceCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifyInstanceCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
    }
  ]
}

ملاحظة: إجراءات Describe وList وGetMetricStatistics تتطلب عادةً "Resource": "*" لأنها لا تدعم تقييد الموارد على مستوى ARN — تحقق من مرجع تفويض الخدمة للتفاصيل.

الخلاصة والخطوات التالية: فهم أرصدة المعالج في T3

التباطؤ المفاجئ في نماذج T3 ليس خللاً — هو السلوك المتوقع عند نفاد أرصدة المعالج. الحل ليس دائماً تغيير النموذج؛ أحياناً يكفي فهم نمط الحمل وضبط وضع الأرصدة أو إضافة تنبيهات مناسبة. الخطوات الفورية الموصى بها:

1. راجع مقياس CPUCreditBalance لنماذج T3 الحالية في بيئة الإنتاج.
2. أضف تنبيه CloudWatch على هذا المقياس لكل نموذج T3 حرج.
3. قرر بوعي بين وضع Standard و Unlimited بناءً على نمط الحمل الفعلي.
4. إذا كان الحمل مرتفعاً باستمرار، قارن التكلفة الفعلية مع نماذج ثابتة الأداء.

للمزيد، راجع توثيق AWS الرسمي لنماذج Burstable Performance.

قاموس المصطلحات

المصطلح	التعريف
CPU Credit (رصيد المعالج)	وحدة قياس تمثل دقيقة واحدة من استخدام vCPU واحد بنسبة 100%
Baseline Utilization (الحد الأساسي)	نسبة المعالج المضمونة للنموذج دون استهلاك أرصدة
Burst (التوسع)	قدرة النموذج على تجاوز الحد الأساسي باستخدام الأرصدة المخزنة
CPUSurplusCreditBalance	الأرصدة التي اقترضها النموذج في وضع Unlimited فوق ما اكتسبه
Burstable Performance Instance	نموذج EC2 يعمل بأداء متغير مرتبط بنظام الأرصدة، مثل عائلة T3