الاختيار بين EBS gp2 و gp3: أيهما يتيح ضبط IOPS باستقلالية وأيهما أوفر؟

عند إنشاء وحدة تخزين EBS جديدة، يظهر خياران متشابهان في الاسم لكنهما مختلفان جوهرياً في الآلية: gp2 وgp3. المشكلة الشائعة في الإنتاج هي أن فريقاً يرفع حجم التخزين من 100 جيجابايت إلى 500 جيجابايت بهدف الحصول على IOPS أعلى — وهذا منطقي مع gp2 لكنه إهدار مباشر للمال مع gp3.

ملخص سريع: gp2 مقابل gp3 لأحجام EBS العامة

الخاصية	gp2	gp3
ضبط IOPS باستقلالية عن الحجم	❌ غير مدعوم	✅ مدعوم
الحد الأقصى لـ IOPS	16,000	16,000
IOPS الافتراضية	مرتبطة بالحجم (3 IOPS/GB)	3,000 ثابتة بغض النظر عن الحجم
الحد الأقصى للإنتاجية	250 MiB/s	1,000 MiB/s
ضبط الإنتاجية باستقلالية	❌	✅
التكلفة النسبية	أعلى في معظم السيناريوهات	أقل تكلفة عموماً
آلية Burst	✅ نعم (credit-based)	❌ لا يوجد burst — أداء ثابت

التسعير والحدود الدقيقة تتغير — راجع دائماً صفحة تسعير EBS الرسمية.

كيف يعمل كل نوع: الآلية الداخلية

قبل اتخاذ القرار، يجب فهم لماذا يتصرف كل نوع بهذه الطريقة — وليس فقط ما هي الأرقام.

gp2: الأداء مقيّد بالحجم

في gp2، تُحسب IOPS الأساسية بمعدل 3 IOPS لكل جيجابايت من الحجم المُخصص، بحد أدنى 100 IOPS وحد أقصى 16,000 IOPS. هذا يعني أن الوصول إلى 16,000 IOPS يستلزم حجماً لا يقل عن 5,334 جيجابايت — حتى لو كانت البيانات الفعلية أقل بكثير.

يمتلك gp2 أيضاً آلية burst قائمة على رصيد (I/O credit bucket). الأحجام الأصغر من 1 تيرابايت تتراكم رصيداً عندما يكون الاستخدام أقل من الأساسي، وتستهلكه عند الحاجة للوصول إلى 3,000 IOPS مؤقتاً. الأحجام التي تتجاوز 1 تيرابايت تحصل على IOPS أساسية تفوق 3,000 فلا تحتاج إلى burst.

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

gp3: الأداء مستقل عن الحجم

gp3 يكسر هذا الارتباط كلياً. كل وحدة gp3 تحصل على 3,000 IOPS و125 MiB/s إنتاجية بشكل افتراضي — بغض النظر عن الحجم، حتى لو كان 1 جيجابايت. يمكن رفع IOPS حتى 16,000 وإنتاجية حتى 1,000 MiB/s بشكل مستقل تماماً عن الحجم، مقابل تكلفة إضافية لكل وحدة IOPS أو MiB/s فوق الافتراضي.

لا يوجد burst في gp3 — الأداء ثابت ومضمون. هذا يجعل التخطيط للسعة أكثر قابلية للتنبؤ في بيئات الإنتاج.

graph TD subgraph gp2_model ["gp2: الأداء مرتبط بالحجم"] A2["الحجم المُخصص (GB)"] -->|"3 IOPS لكل GB"| B2["IOPS الأساسية"] B2 -->|"أقل من 1 TB"| C2["Burst حتى 3,000 IOPS"] B2 -->|"أكثر من 1 TB"| D2["IOPS أساسية فوق 3,000"] end subgraph gp3_model ["gp3: الأداء مستقل عن الحجم"] A3["الحجم المُخصص (GB)"] --> E3["3,000 IOPS افتراضية ثابتة"] F3["ضبط IOPS مستقل (حتى 16,000)"] --> G3["أداء مضمون ثابت"] H3["ضبط الإنتاجية مستقل (حتى 1,000 MiB/s)"] --> G3 end style gp2_model fill:#fff3cd,stroke:#ffc107 style gp3_model fill:#d4edda,stroke:#28a745

1. gp2: الحجم يحدد IOPS الأساسية مباشرة — زيادة IOPS تعني زيادة الحجم إلزامياً.
2. gp3: الحجم والأداء (IOPS والإنتاجية) معاملات مستقلة يمكن ضبط كل منها على حدة.
3. في gp2، الأحجام الصغيرة تعتمد على burst لتجاوز الحد الأساسي المنخفض — وهذا غير مضمون تحت الضغط المستمر.
4. في gp3، الأداء الافتراضي (3,000 IOPS) متاح حتى للأحجام الصغيرة جداً دون أي رصيد أو burst.

لماذا gp3 أوفر في معظم الحالات

السيناريو الأكثر شيوعاً الذي يكشف الفارق: تطبيق يحتاج 6,000 IOPS على قاعدة بيانات بحجم 100 جيجابايت فعلي.

• مع gp2: 3 IOPS/GB تعني أنك تحتاج إلى 2,000 جيجابايت للحصول على 6,000 IOPS — تدفع مقابل 1,900 جيجابايت إضافية لا تستخدمها.
• مع gp3: تُخصص 100 جيجابايت وترفع IOPS إلى 6,000 بشكل مستقل — تدفع فقط مقابل ما تحتاجه.

هذا هو الفخ الكلاسيكي مع gp2: المهندس يعتقد أنه يحل مشكلة أداء بينما هو في الحقيقة يدفع مقابل مساحة تخزين فارغة.

متى يكون gp2 لا يزال مقبولاً

gp2 ليس خاطئاً دائماً. هناك حالات محددة:

• أحجام كبيرة جداً مع استخدام IOPS منخفض: إذا كان الحجم 5+ تيرابايت والتطبيق لا يحتاج IOPS عالية، قد تكون الفجوة السعرية أقل وضوحاً — لكن gp3 لا يزال الأفضل في معظم الحالات.
• أنظمة قديمة لم تُهاجر بعد: وحدات gp2 موجودة في الإنتاج منذ سنوات وتعمل بشكل مستقر — الترقية ممكنة في أي وقت دون توقف.
• تطبيقات تعتمد على burst قصير المدى: إذا كان النمط هو هدوء طويل ثم ذروة قصيرة، قد يكفي burst gp2 — لكن يجب مراقبة رصيد BurstBalance في CloudWatch.

الترقية من gp2 إلى gp3: الخطوات العملية

الترقية لا تتطلب إيقاف الـ instance ولا فصل الوحدة. يمكن تعديل نوع الوحدة مباشرة على وحدة متصلة وتعمل — وهذا ما يجعل القرار سهلاً: لا خسارة في التوفر.

الخطوة 1: فحص الوحدات الحالية وتحديد gp2

ابدأ بجرد الوحدات الحالية لتحديد أي منها لا يزال على gp2 — خاصة تلك ذات الأحجام الكبيرة مقارنة بالاستخدام الفعلي.

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,IOPS:Iops,State:State,AZ:AvailabilityZone}' \
  --output table \
  --region us-east-1

هذا الأمر يعرض جميع وحدات gp2 في المنطقة مع حجمها وحالتها — نقطة البداية لتقييم التوفير المحتمل.

الخطوة 2: فحص رصيد BurstBalance لوحدة gp2 نشطة

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

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --period 3600 \
  --statistics Average \
  --region us-east-1

مقياس BurstBalance موثق في AWS CloudWatch Metrics لـ EBS. قيمة تقترب من 0% باستمرار تعني أن الوحدة تعمل عند حدها الأساسي فقط.

الخطوة 3: تعديل الوحدة من gp2 إلى gp3

الترقية تتم بأمر واحد. يمكن في نفس الوقت تحديد IOPS والإنتاجية المطلوبة — أو تركها عند القيم الافتراضية (3,000 IOPS و125 MiB/s) إذا كانت كافية.

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 250 \
  --region us-east-1

التعديل يبدأ فوراً والوحدة تبقى متاحة طوال العملية. الأداء الجديد يصبح فعالاً بعد اكتمال تحسين الوحدة.

الخطوة 4: مراقبة حالة التعديل

التعديل ليس فورياً — قد يستغرق وقتاً حسب حجم الوحدة. تتبع الحالة للتأكد من اكتمال العملية قبل إجراء أي تعديلات أخرى.

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,State:ModificationState,Progress:Progress,TargetType:TargetVolumeType,TargetIOPS:TargetIops}' \
  --output table \
  --region us-east-1

حالة completed تعني أن الوحدة تعمل الآن بالمواصفات الجديدة بالكامل.

graph LR S1["فحص وحدات gp2
describe-volumes"] --> S2["مراقبة BurstBalance
CloudWatch"] S2 --> S3{"هل BurstBalance
قريب من 0%؟"} S3 -->|"نعم"| S4["أداء مقيّد فعلاً
الترقية أولوية عالية"] S3 -->|"لا"| S5["نمط burst كافٍ
قيّم التكلفة فقط"] S4 --> S6["modify-volume
إلى gp3 + ضبط IOPS"] S5 --> S6 S6 --> S7["describe-volumes-modifications
تتبع حالة التعديل"] S7 --> S8{"الحالة؟"} S8 -->|"completed"| S9["الوحدة تعمل بـ gp3"] S8 -->|"optimizing"| S7

1. فحص الوحدات الحالية يحدد أهداف الترقية ذات الأولوية.
2. مراقبة BurstBalance تكشف ما إذا كان التطبيق يعاني فعلاً من قيود الأداء.
3. أمر modify-volume يطبق التغيير مباشرة دون إيقاف الخدمة.
4. تتبع حالة التعديل ضروري قبل الاعتماد على الأداء الجديد في الإنتاج.

نمط الفشل الشائع: رفع الحجم بدلاً من ضبط IOPS

هذا ما يحدث في الواقع: تنبيه CloudWatch يُظهر ارتفاع VolumeQueueLength على قاعدة بيانات. المهندس يفتح وحدة التخزين ويرى 200 جيجابايت على gp2 — يحسب 600 IOPS أساسية ويقرر رفع الحجم إلى 1,000 جيجابايت للحصول على 3,000 IOPS.

التشخيص الخاطئ: المشكلة هي نوع الوحدة، ليس الحجم. الحل الصحيح: تحويل الوحدة إلى gp3 وضبط IOPS على 3,000 أو أكثر — بنفس الحجم الأصلي 200 جيجابايت. النتيجة: أداء أفضل وتكلفة أقل.

الدرس: في gp2، الحجم والأداء مرتبطان إجبارياً. في gp3، هما متغيران مستقلان.

IAM: الصلاحيات المطلوبة لتعديل وحدات EBS

تعديل نوع الوحدة يتطلب صلاحية ec2:ModifyVolume. فحص الحالة يتطلب ec2:DescribeVolumesModifications. فيما يلي سياسة بأقل الصلاحيات اللازمة:

🔽 عرض سياسة IAM للتعديل والمراقبة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEBSVolumeModification",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyVolume",
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowCloudWatchEBSMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

ملاحظة: ec2:DescribeVolumes وec2:DescribeVolumesModifications تتطلب "Resource": "*" لأنها لا تدعم تقييد الموارد على مستوى ARN وفقاً لـ AWS Service Authorization Reference.

الخلاصة والخطوات التالية: gp3 هو الاختيار الافتراضي الصحيح

إذا كنت تبدأ وحدة جديدة اليوم، اختر gp3 افتراضياً. إذا كان لديك وحدات gp2 في الإنتاج، قيّم الترقية — خاصة تلك التي رُفع حجمها في الماضي بهدف الحصول على IOPS أعلى.

القاعدة العملية: gp3 يمنحك التحكم الكامل في الأداء والتكلفة بشكل مستقل. gp2 يجبرك على ربط الاثنين معاً.

• راجع توثيق AWS لأنواع وحدات EBS للمواصفات الكاملة والمحدّثة.
• استخدم حاسبة تسعير EBS لمقارنة التكلفة الفعلية لسيناريو محدد.
• فعّل AWS Cost Explorer Rightsizing Recommendations لتحديد وحدات gp2 ذات الأولوية للترقية.

مسرد المصطلحات

المصطلح	التعريف
IOPS	عدد عمليات الإدخال/الإخراج في الثانية — مقياس أداء التخزين للعمليات العشوائية.
Throughput (الإنتاجية)	كمية البيانات المنقولة في الثانية (MiB/s) — مهمة للعمليات التسلسلية الكبيرة.
Burst Credit (رصيد الانفجار)	رصيد يتراكم في gp2 عند الاستخدام المنخفض ويُستهلك للوصول إلى أداء أعلى مؤقتاً.
BurstBalance	مقياس CloudWatch يعكس النسبة المئوية المتبقية من رصيد burst في وحدة gp2.
Elastic Volumes	ميزة EBS تتيح تعديل نوع الوحدة وحجمها وأداءها دون إيقاف الـ instance المتصلة.