تحديد الحجم المناسب لخوادم EC2 مع Compute Optimizer

ترث حساباً فيه 40 خادم ويب من نوع m5.2xlarge. كل الخوادم سليمة. ولم يُطلق أي تنبيه منذ ثمانية أشهر. ويعرض CloudWatch متوسط CPUUtilization عند 8% بذروات قرب 22%. وفاتورة الحوسبة الشهرية نحو 11,000 دولار، منها قرابة 8,000 تشتري سعة لا يستخدمها أحد.

لا شيء هنا معطّل، ولهذا بالضبط لا ينظر إليه أحد. تحديد الحجم المناسب هو الجزء من عمل CloudOps الذي لا حادثة مرتبطة به، ويختبره SOA-C03 لأن مهاراته هي نفسها التي تستعملها حين يقع عطل فعلي: قراءة مقاييس الاستخدام قراءة صحيحة، ومعرفة أي مقياس ناقص، ومعرفة أي أداة تجيب عن أي سؤال.

استخدام المعالج بُعد واحد من أربعة

CPUUtilization هو المقياس الذي يمدّ الجميع يده إليه، وهو وحده شبه عديم الفائدة في قرارات الحجم.

لكل خادم أربعة أبعاد سعة على الأقل قد ينفد أي منها مستقلاً عن غيره: المعالج، والذاكرة، والشبكة، وإدخال/إخراج التخزين. وينشر CloudWatch مقاييس ثلاثة منها جاهزةً. ولا ينشر الذاكرة، لأن المشرف الافتراضي لا يرى داخل النظام الضيف. فذاكرة نظام التشغيل لديك معتمة بالنسبة إلى AWS، ولا يبلّغ عن مقدار المستخدَم منها إلا وكيل يعمل داخل الخادم.

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

وتصيب هذه البقعة العمياء الأدوات المبنية فوق هذه المقاييس أيضاً. فـ Compute Optimizer لا يحلّل استخدام الذاكرة إلا للموارد التي ثُبّت عليها وكيل CloudWatch. وبدونه تحصل على نتائج مبنية على المعالج والشبكة والإدخال/الإخراج، وقد يوصي بخادم أصغر لحمل عمل مختنق في الذاكرة أصلاً.

ما الذي يفعله Compute Optimizer

يقرأ AWS Compute Optimizer إعدادات مواردك ومقاييس استخدامها في CloudWatch، ثم يعيد إعداداً موصى به مع الاستخدام المتوقّع لو تبنّيته.

وأربع حقائق عن طريقة عمله تصوغ معظم أسئلة الاختبار.

يجب تفعيله. لا يفعل شيئاً حتى تفعّله لحساب مستقل، أو حساب عضو، أو حساب الإدارة في مؤسسة. وسيناريو «لا يعرض Compute Optimizer أي توصيات» ينتهي عند هذا كثيراً.

النافذة الافتراضية 14 يوماً. يحلّل آخر 14 يوماً من المقاييس ويحدّث التوصيات يومياً. وتفعيل enhanced infrastructure metrics، وهو تفضيل توصيات مدفوع، يمدّ النافذة إلى 93 يوماً. وهذا هو الجواب كلما كان لحمل العمل إقفال شهري، أو دفعة ربع سنوية، أو أي ذروة لا تراها نافذة أسبوعين.

يحتاج إلى بيانات كافية. قد تستغرق التوصيات حتى 24 ساعة لتظهر بعد التفعيل، والمورد الذي لا يملك تاريخ مقاييس كافياً لا يحصل على نتيجة أصلاً.

يغطي ما هو أوسع من EC2 بكثير. خوادم EC2 ومجموعات Auto Scaling، وأحجام EBS، ودوال Lambda، وخدمات ECS على Fargate، وقواعد RDS وAurora، وDynamoDB، وElastiCache، وMemoryDB، وDocumentDB، وبوابات NAT، وWorkSpaces، وSageMaker، وتراخيص البرمجيات التجارية. فإن سأل سؤال عن خدمة واحدة تعطي توصيات حجم عبر الحوسبة والتخزين وقواعد البيانات، فهي هذه.

قراءة النتيجة

كل خادم مُحلَّل يقع في أحد ثلاثة تصنيفات:

يخبرك التصنيف بأن شيئاً ما خاطئ. ويخبرك سبب النتيجة بماذا، وهو محدّد: CPU over-provisioned، وMemory under-provisioned، وEBS throughput under-provisioned، وEBS IOPS over-provisioned، وNetwork bandwidth under-provisioned، وNetwork PPS under-provisioned، وDisk IOPS، وDisk throughput، ونظائرها لوحدات معالجة الرسوميات. وكل سبب يسمّي المقياس المشتق منه، فتستطيع الذهاب والتحقق بنفسك: أسباب EBS IOPS تأتي من VolumeReadOps وVolumeWriteOps، وعرض نطاق الشبكة من NetworkIn وNetworkOut، وحزم الشبكة من NetworkPacketsIn وNetworkPacketsOut.

ولاحظ الانقسام الذي يوقع الناس: أسباب Disk تشير إلى أحجام instance store (DiskReadOps، وDiskWriteBytes)، وأسباب EBS تشير إلى أحجام EBS المرتبطة. عتاد مختلف وإصلاح مختلف. فنتيجة Disk تُحلّ بتغيير نوع الخادم، ونتيجة EBS تُحلّ غالباً بتعديل الحجم، وهو ما يغطيه الدرس الثالث من هذا الموضوع بالتفصيل.

وتحمل كل توصية كذلك مخاطرة أداء (performance risk) من very low إلى very high (0 إلى 4 في الـ API). وهي أعلى درجة مخاطرة عبر كل المواصفات المحلَّلة، وتجيب عن سؤال «ما احتمال أن يخيّب هذا النوع الأصغر ظنّي؟». فـ very low تعني أن النوع متوقّع أن تكفي قدرته دائماً. وأي درجة أعلى دعوة إلى الاختبار تحت حمل حقيقي أولاً.

خوادم burstable تلعب بقواعد أخرى

كل ما سبق يفترض أن الخادم يستطيع استخدام 100% من معالجه متى شاء. وخوادم عائلة T لا تستطيع، وهذه أكثر معلومة في تحجيم EC2 تكراراً في الاختبار.

يُباع الخادم burstable بمستوى خط أساس (baseline) من المعالج يستطيع الصمود عنده إلى الأبد، ومعه دلو من أرصدة المعالج (CPU credits) تتيح له العمل فوق خط الأساس مدةً. والرصيد الواحد يساوي vCPU واحداً يعمل عند 100% لدقيقة واحدة. فتحت خط الأساس يكسب أكثر مما ينفق فيمتلئ الدلو. وفوقه ينفق أكثر مما يكسب فيفرغ.

خذ t3.large، وله 2 vCPU، ويكسب 36 رصيداً في الساعة، وخط أساسه 30%، ويستطيع تراكم 864 رصيداً (يوم كامل من الكسب):

• يرتفع الطلب إلى 55% معالج بثبات.
• الأرصدة المنفقة في الدقيقة = عدد الـ vCPU × نسبة الاستخدام = 2 × 0.55 = 1.1، أي 66 في الساعة.
• الأرصدة المكتسبة في الساعة = 36.
• الاستنزاف الصافي = 30 رصيداً في الساعة. وانطلاقاً من 864 ممتلئة، يبلغ الرصيد صفراً بعد نحو 29 ساعة.

وما يحدث عند الصفر يتوقف على وضع ضبط الأرصدة:

• الوضع standard: يُنزَل الخادم إلى خط أساسه. فيُقيَّد المعالج عند 30% ويبطؤ التطبيق، بلا خطأ، وبلا تنبيه، وبلا سبب ظاهر. وهذا هو الافتراضي لـ T2 ولـ T3 على Dedicated Host.
• الوضع unlimited: يواصل الخادم العمل فوق خط الأساس بإنفاق أرصدة فائضة (surplus credits). فإن بقي متوسط معالجه خلال 24 ساعة متجدّدة عند خط الأساس أو تحته، غطّى السعر الساعي المعتاد الفائض. وإن لم يبقَ، دفعت سعراً إضافياً ثابتاً لكل vCPU في الساعة. وهذا هو الافتراضي لـ T3 وT3a وT4g.

والفهم الخاطئ الذي يستحق التسمية: يقرأ الناس كلمة burstable على أنها مكافأة، فيفترضون أن الخادم يستطيع الثبات عند معالج عالٍ إلى ما لا نهاية. وهو لا يستطيع، في أي من الوضعين، بلا ثمن. ففي الوضع standard الثمن هبوط أداء بعد يوم تقريباً من ارتفاع الحمل. وفي الوضع unlimited الثمن بند في الفاتورة لم يتوقّعه أحد. والمقياس الذي يتنبأ بالحالتين هو CPUCreditBalance لا CPUUtilization، فأي أسطول من عائلة T يحتاج إلى تنبيه على اتجاه رصيد الأرصدة نحو الصفر. وCPUSurplusCreditsCharged هو الذي تراقبه للجانب المالي.

وحقائق أخرى عن الأرصدة تستحق الحفظ:

• سقف التراكم دائماً هو ما يُكسب في 24 ساعة. فـ t3.micro يكسب 12 في الساعة ويتراكم عنده 288، وt3.2xlarge يكسب 192 في الساعة ويتراكم عنده 4,608.
• نسب خط الأساس لكل vCPU وتطابق ما يعرضه CloudWatch. فـ t3.large عند خط أساسه يُقرأ 30% في وحدة التحكم.
• في T3 وT3a وT4g تنجو الأرصدة المتراكمة من الإيقاف لمدة 7 أيام. وفي T2 تضيع لحظة إيقاف الخادم.
• أرصدة الإطلاق (launch credits) موجودة لـ T2 في الوضع standard فقط. أما T3 وما بعده فيُطلق في الوضع unlimited، فيستطيع الاندفاع فوراً بلا حاجة إليها.

وإن كان خادم T يعيش باستمرار فوق خط أساسه، فهو الخادم الخاطئ لحمل العمل. وهذه نتيجة تحجيم لا مشكلة ضبط، ويرسم Compute Optimizer خط الأساس على منحنى المعالج كي تراها.

تغيير حجم خادم يعمل

بعد أن تحصل على النتيجة، يصير التغيير نفسه آلياً، ويهتم الاختبار بالترتيب وبالآثار الجانبية.

في خادم مبني على EBS، يتطلب تغيير النوع أن يكون الخادم متوقفاً:

aws ec2 stop-instances --instance-ids i-0abc123def4567890
aws ec2 wait instance-stopped --instance-ids i-0abc123def4567890

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123def4567890 \
  --instance-type "{\"Value\": \"m5.xlarge\"}"

aws ec2 start-instances --instance-ids i-0abc123def4567890

يحتفظ الخادم بمعرّفه، وبأحجام EBS المرتبطة به، وبمجموعات الأمان، وبدور IAM. وثلاثة أشياء لا تنجو من الإيقاف والتشغيل:

• البيانات على أحجام instance store، لأن الخادم ينتقل إلى عتاد مضيف مختلف.
• عنوان IPv4 العام، ما لم يكن Elastic IP مرتبطاً به.
• رصيد أرصدة المعالج على خادم T2.

والوسوم (tags) تؤدي النصف التنظيمي من هذا العمل. فتحديد الحجم على مستوى الأسطول يعني القدرة على الإجابة عن «من يملك هذا الخادم وفي أي بيئة هو» قبل تغيير حجمه، ولهذا تسمّي المهارة 1.3.1 في دليل الاختبار وسوم الموارد إلى جانب مقاييس الأداء. ومجموعة وسوم متسقة من Environment وOwner وApplication هي ما يحوّل قائمة من 400 نتيجة إلى 12 محادثة.

أما الخوادم داخل مجموعة Auto Scaling فلا تغيّر أحجامها فرادى. حدّث قالب الإطلاق بالنوع الجديد وابدأ instance refresh، كي يدوم التغيير وتستبدل المجموعة خوادمها بصورة منضبطة.

أي أداة تجيب عن أي سؤال

ثلاث خدمات تنتج نصائح متشابهة الظاهر، وتُكتب الأسئلة للفصل بينها.

والإشارة: «أوصِ بنوع خادم بناءً على استخدام مقيس» هي Compute Optimizer. و«اعرض لي فرص التوفير إلى جانب فاتورتي» هي Cost Explorer. و«افحص حسابي مقابل قائمة أفضل الممارسات» هي Trusted Advisor.

نصائح للاختبار

• انخفاض المعالج مع بطء التطبيق يعني الذاكرة. والإجراء الذي يفتح الطريق هو تثبيت وكيل CloudWatch، لأن الذاكرة ليست مقياساً افتراضياً ولا يستطيع Compute Optimizer تحليلها بدونه.
• «مهمة دفعية شهرية»، أو «ذروة ربع سنوية»، أو «حمل موسمي» مع Compute Optimizer تشير إلى enhanced infrastructure metrics ونافذتها 93 يوماً. فنافذة 14 يوماً لن ترى الذروة أصلاً.
• خادم T يبطؤ بعد نحو يوم من حمل مرتفع هو سؤال نفاد أرصدة. والمقياس CPUCreditBalance، والحل إما الوضع unlimited مع قبول رسم الفائض وإما عائلة غير burstable.
• انتبه إلى الافتراضي الذي يفترضه السؤال. فـ T2 افتراضيه standard ويقيّد، وT3 وT3a وT4g افتراضيها unlimited وتفوتر بدلاً من ذلك.
• لا تخلط بين أسباب Disk (instance store) وأسباب EBS (الأحجام المرتبطة). فهما يقودان إلى معالجتين مختلفتين.
• تغيير نوع خادم يحتاج إلى إيقافه، وإيقافه يتلف بيانات instance store ويحرّر عنوان IP عام غير Elastic.

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