هندسة السحابة - متقدّم
هندسة السحابة - متقدّم
سيغطّي هذا القسم مواضيع هندسة السحابة المتقدّمة مثل السحابة المتعدّدة (Multi Cloud)، والحياد السحابي (Cloud Agnosticism)، والحوسبة الطرفية (Edge Computing).
ملاحظة
قيد الإنجاز.
FinOps
FinOps هو نهج لتحسين تكاليف السحابة، يضمن المساءلة المالية والكفاءة وإدارة الموارد. ويستند إلى فهم المبادئ المالية ذات الصلة بالحوسبة السحابية، مثل وضع الميزانية والتنبؤ وتوزيع التكاليف والفوترة.
وفقًا لـGartner:
يطبّق FinOps مفاهيم DevOps التقليدية المتمثّلة في الرشاقة والتكامل والنشر المستمر وتغذية المستخدم النهائي الراجعة على الحوكمة المالية ووضع الميزانية وجهود تحسين التكاليف. ويؤتمت FinOps المعزّز (Augmented FinOps) هذه العملية بتطبيق ممارسات الذكاء الاصطناعي (AI) والتعلّم الآلي (ML) — بشكل أساسي في السحابة — لتمكين بيئات تُحسّن التكلفة تلقائيًا استنادًا إلى أهداف أعمال محدّدة معبّر عنها باللغة الطبيعية.
لكل مزوّد سحابي خدمات مدمجة لـ FinOps مثل:
- AWS: Cost Explorer و AWS Budgets
- Azure: Cost Management
- Google: Cloud Billing
FinOps - AWS
ما الذي تحتاج إلى معرفته
فيما يلي بعض الاستراتيجيات لتحسين تكاليف سحابة AWS.
الشبكات:
- إدارة تكاليف نقل البيانات: تتحمّل بوّابات NAT تكاليف؛ وفي معظم الحالات تكفي شبكتان فرعيتان (subnets) بتوفّر 99.9٪. ولموفّرية 99.99٪ استخدم ثلاث شبكات فرعية مع ثلاث بوّابات NAT. واكتفِ عمومًا بشبكتين فرعيتين في معظم السيناريوهات.
- أزل عناوين IPv4 غير الضرورية أو المرتبطة ببطاقة واجهة الشبكة (NIC).
- لتقليل التكاليف، استخدم نقاط نهاية VPC (VPC endpoints) للاتصال الخاص بخدمات AWS المدعومة وخدمات نقاط نهاية VPC بدلًا من الاعتماد على بوّابات NAT. بالإضافة إلى ذلك، غالبًا ما يكون AWS PrivateLink مطلوبًا لأغراض أخرى مثل الامتثال، بصرف النظر عن اعتبارات التكلفة.
الحوسبة:
- تنفيذ التوسّع التلقائي للنسخ (Instance Autoscaling): اضبط التوسّع التلقائي باستخدام نسخ Spot لعُقد العمل عبر Karpenter لضبط الموارد ديناميكيًا وفق الطلب.
- استخدام النسخ المحجوزة (Reserved Instances) وخطط التوفير (Savings Plans): حسّن لمعظم التطبيقات نحو نوع عقدة واحد، مثل
m5a.largeأوm5a.xlarge، لتحقيق وفورات في التكلفة عبر السعة المحجوزة. - ضبط حجم الموارد (Rightsize Resources): أعِد تقييم التطبيقات والعُقد بانتظام لتقييم الاستخدام وضبط حجم الموارد من أجل أداء وتكلفة مثاليين.
- استخدم الإجراءات المجدولة (scheduled actions) في مجموعة التوسّع التلقائي (Auto Scaling group) لبيئات الاختبار والتطوير لإيقاف النسخ تلقائيًا في أوقات محدّدة حين لا تكون عُقد الحوسبة قيد الاستخدام، وتشغيلها عند الحاجة.
- نوع المعالج (CPU Type): معالجات ARM (مثل AWS Graviton) أكثر فعالية من حيث التكلفة لكن قد تواجه مشكلات توافق مع تطبيقات معيّنة. وينبغي للمطوّرين ضمان توافق التطبيق لدعم أنواع متعدّدة من المعالجات.
- الترقيات (Upgrades): قد يفرض مزوّدو السحابة رسومًا على العناقيد غير المرقّاة إلى إصدار مدعوم. وفي EKS، يتطلّب استخدام عنقود Kubernetes قديم الدعم الموسّع (Extended Support)، ما يؤدّي إلى نفقات إضافية.
التخزين:
- S3: اضبط سياسات دورة الحياة، خصوصًا عند استخدام الإصدارات (versioning)، واختر فئة التخزين المناسبة (مثل Standard أو Infrequent Access). وفكّر في S3 Intelligent-Tiering لإدارة تخزين مؤتمتة وفعّالة من حيث التكلفة.
- EBS: تأكّد من ضبط أحجام EBS لاستخدام نوع التخزين GP3، وهو أكثر فعالية من حيث التكلفة بنسبة 20٪ من GP2.
- EBS: احذف أحجام EBS واللقطات (snapshots) غير المستخدمة والتي لم تعد تُستعمل.
قاعدة البيانات (Database):
- بالنسبة لـ RDS، فكّر في ضبط الحجم، واستخدام نسخ قائمة على Graviton، وإجراء ترقيات جماعية لإصدار المحرّك إن كانت التطبيقات تدعم الإصدار الجديد.
- يؤدي الانتقال إلى Amazon Aurora I/O-Optimized إلى زيادة تكاليف النسخ بنحو 25٪، بما يشمل عمليات الإدخال/الإخراج (I/O)، ما يجعله خيارًا مثاليًا لأحمال العمل ذات الإدخال/الإخراج المرتفع. ويوفّر هذا الخيار قابلية أفضل للتنبؤ بالتكلفة ويمكن أن يقلّل التكاليف الإجمالية حين يكون الطلب على الإدخال/الإخراج كبيرًا.
- قد يفرض مزوّدو السحابة رسومًا على العناقيد غير المرقّاة إلى إصدار مدعوم. وبالنسبة لـ RDS، قد يتطلّب استخدام محرّكات قواعد بيانات قديمة الدعم الموسّع (Extended Support)، ما يؤدّي إلى نفقات إضافية.