إن الاختيار بين Amazon Elastic Compute Cloud (Amazon EC2) وAmazon Elastic Container Service (Amazon ECS) وAmazon Elastic Kubernetes Service (Amazon EKS) وAWS Fargate وAWS Lambda وAWS Batch هو قرار يتعلق بمكان تشغيل الكود (الشيفرة البرمجية) والجهة المسؤولة عن المهام التشغيلية. في هذه الدورة، سنبني إطار عمل قابلاً للتكرار يربط متطلبات عبء العمل (workload) بسلوك التوسع (scaling)، وحدود الفشل، والمسؤولية التشغيلية، ومحركات التكلفة الإجمالية. سنتجنب أسلوب التفكير القائم على “كتالوج الخدمات” (service catalog)، وبدلاً من ذلك سنجعل كل خيار قابلاً للتبرير استناداً إلى القيود والأدلة.
لنحدد أولاً محور المسؤولية، لأنه يوضح معظم المقايضات والخيارات المتاحة. تشير المسؤولية التشغيلية إلى الجهة التي تتولى تطبيق التحديثات الأمنية (patches) على نظام التشغيل، وإدارة السعة، وتشغيل المجدوِل (scheduler) الذي يوزع المهام على موارد الحوسبة.
في Amazon EC2، نقوم بتشغيل أجهزة افتراضية (virtual machines)، لذا نختار صورة الجهاز (AMI)، واستراتيجية التحديثات الأمنية، وآلية التوسع. في Amazon ECS أو Amazon EKS، نقوم بتشغيل نظام تنسيق (orchestrator) لجدولة الحاويات (containers)، ومع ذلك نحتاج إلى تحديد المكون الذي يوفر السعة الأساسية لتشغيلها. في AWS Fargate، تتولى AWS إدارة طبقة سعة الحاويات، لذا نركز على تعريفات المهام (task definitions) وتوسيع نطاق الخدمة بدلاً من إدارة أساطيل العُقد (node fleets). في AWS Lambda، تتولى AWS تشغيل البنية التحتية للحوسبة وإدارة التوسع، بينما نركز نحن على كود الدالة (function code) ونموذج استدعائها. في خدمة AWS Batch، تتولى AWS إدارة عمليات وضع المهام في قوائم الانتظار وجدولتها لمعالجة الدفعات (batch work)، كما يمكنها توجيه هذه المهام للعمل على موارد ECS أو EKS أو Fargate أو EC2.
لنستعرض الآن -بشكل عام- كيفية تغير نطاق المسؤولية والملكية بين هذه الخيارات.
يمكننا الآن التعامل مع عملية اختيار موارد الحوسبة على أنها تمرين لمطابقة القيود، وليس مجرد نقاش حول التفضيلات. يشير نموذج التنفيذ إلى كيفية تشغيل العمل: هل يتم كخدمة مستمرة (طويلة الأمد)، أم كدالة تُستدعى عند وقوع حدث معين، أم كمهمة توضع في قائمة انتظار ولها نقطتا بداية ونهاية محددتان؟
غالباً ما يكون نمط حركة المرور (Traffic shape) هو القيد الأول الذي يفرض تحدياته. تميل حركة المرور المتقلبة (التي تشهد طفرات مفاجئة وفترات خمول طويلة) إلى تفضيل النماذج التي تعتمد على الدفع مقابل كل طلب (per-request models)، بينما تميل حركة المرور المستقرة إلى تفضيل السعة المتاحة دائماً (always-on capacity) حيث تظل معدلات الاستخدام مرتفعة.
تساهم عوامل المدة الزمنية والحالة (state) في حصر الخيارات المتاحة بسرعة. تفرض خدمة AWS Lambda حداً أقصى للمهلة الزمنية (timeout) يبلغ حالياً 900 ثانية؛ لذا فإن المهام التي تستغرق وقتاً أطول عادةً ما تُنقل للعمل بنظام الحاويات (containers) أو المعالجة الدفعية (batch processing). أما أحمال العمل التي تحتفظ بحالة محلية (stateful workloads) أو تتطلب ضبطاً خاصاً للمضيف (host tuning)، فغالباً ما تكون أكثر ملاءمة للعمل على Amazon EC2 أو داخل حاويات تعمل على سعة EC2.
كما أن الحساسية تجاه زمن الانتقال (latency) لها دلالات تشغيلية مهمة. في مسارات “الطلب والاستجابة” (request-response)، نولي اهتماماً لمخاطر “التشغيل البارد” (cold start)، وموقع الشبكة، وسرعة المنصة في إضافة سعة معالجة متوازية. وفي المسارات غير المتزامنة (async paths)، نركز على تزايد تراكم المهام (backlog growth)، وسلوك إعادة المحاولة، وكيفية عزل حالات الفشل وإعادة تنفيذ المهام المتعثرة.
لنستعرض معاً كيف ترتبط بطاقات المتطلبات هذه بقيود موارد الحوسبة.