الكفاءة على نطاق واسع: قصة تحسين تكلفة AWS

لقد أطلقت مؤخرًا نظامًا أساسيًا لتحليل العملات المشفرة ، متوقعًا عددًا صغيرًا من المستخدمين يوميًا. ومع ذلك ، عندما وجد بعض مستخدمي YouTube المشهورين أن الموقع مفيد ونشروا مراجعة ، نمت حركة المرور بسرعة كبيرة لدرجة أنها أثقلت الحمل على الخادم ، وأصبح الوصول إلى النظام الأساسي (Scalper.AI) غير ممكن. احتاجت بيئة AWS EC2 الأصلية إلى دعم إضافي. بعد التفكير في حلول متعددة ، قررت استخدام AWS Elastic Beanstalk لتوسيع نطاق طلبي. كانت الأمور تبدو جيدة وتعمل بسلاسة ، لكنني فوجئت بالتكاليف في لوحة معلومات الفوترة.

هذه ليست قضية غير شائعة. وجدت دراسة استقصائية من عام 2021 أن 82٪ من صناع القرار في تكنولوجيا المعلومات والسحابة قد تكبدوا تكاليف سحابية غير ضرورية ، و 86٪ لا يشعرون أنه يمكنهم الحصول على عرض شامل لجميع إنفاقهم على السحابة. على الرغم من أن أمازون تقدم نظرة عامة مفصلة عن النفقات الإضافية في وثائقها ، إلا أن نموذج التسعير معقد بالنسبة لمشروع متنامٍ. لتسهيل فهم الأمور ، سأقوم بتفصيل بعض التحسينات ذات الصلة لتقليل تكاليف السحابة الخاصة بك.

لماذا اخترت AWS

الهدف من Scalper.AI هو جمع معلومات حول أزواج العملات المشفرة (الأصول التي يتم تبادلها عند التداول في البورصة) ، وإجراء تحليلات إحصائية ، وتزويد متداولي العملات المشفرة برؤى حول حالة السوق. يتكون الهيكل الفني للمنصة من ثلاثة أجزاء:

• البرامج النصية لاستيعاب البيانات
• خادم الويب
• قاعدة البيانات

تقوم نصوص العرض بجمع البيانات من مصادر مختلفة وتحميلها إلى قاعدة البيانات. كانت لدي خبرة في العمل مع خدمات AWS ، لذلك قررت نشر هذه البرامج النصية من خلال إعداد مثيلات EC2. تقدم EC2 العديد من أنواع المثيلات وتتيح لك اختيار معالج المثيل والتخزين والشبكة ونظام التشغيل.

اخترت Elastic Beanstalk للوظائف المتبقية لأنها وعدت بإدارة سلسة للتطبيق. قام موازن التحميل بتوزيع العبء بشكل صحيح بين مثيلات الخادم الخاص بي ، بينما عالجت ميزة القياس التلقائي إضافة مثيلات جديدة لزيادة الحمل. أصبح نشر التحديثات أمرًا سهلاً للغاية ، حيث لم يستغرق الأمر سوى بضع دقائق.

Scalper.AI يعمل بثبات ، ولم يعد المستخدمون يواجهون فترات توقف. بالطبع ، كنت أتوقع زيادة في الإنفاق منذ أن أضفت خدمات إضافية ، لكن الأرقام كانت أكبر بكثير مما توقعت.

كيف يمكنني تقليل تكاليف السحابة

بالنظر إلى الوراء ، كان هناك العديد من مجالات التعقيد في استخدام مشروعي لخدمات AWS. سنقوم بفحص تحسينات الميزانية التي اكتشفتها أثناء العمل مع ميزات AWS EC2 الشائعة: حالات الأداء القابلة للانفجار ، وعمليات نقل البيانات الصادرة ، وعناوين IP المرنة ، وحالات الإنهاء والإيقاف.

مثيلات الأداء المتفجرة

كان التحدي الأول الذي واجهته هو دعم استهلاك طاقة وحدة المعالجة المركزية لمشروعي المتنامي. توفر البرامج النصية لاستيعاب البيانات الخاصة بـ Scalper.AI للمستخدمين تحليلًا للمعلومات في الوقت الفعلي ؛ يتم تشغيل البرامج النصية كل بضع ثوانٍ وتغذي النظام الأساسي بآخر التحديثات من عمليات تبادل العملات المشفرة. ينتج عن كل تكرار لهذه العملية مئات الوظائف غير المتزامنة ، لذا فقد تطلبت حركة المرور المتزايدة للموقع مزيدًا من طاقة وحدة المعالجة المركزية لتقليل وقت المعالجة.

أرخص مثيل يقدمه AWS مع أربعة وحدات معالجة افتراضية ، a1.xlarge ، كان سيكلفني حوالي 75 دولارًا شهريًا في ذلك الوقت. بدلاً من ذلك ، قررت توزيع الحمل بين مثيلين t3.micro مع وحدتي vCPU و 1 جيجابايت من ذاكرة الوصول العشوائي لكل منهما. قدمت مثيلات t3.micro سرعة وذاكرة كافيتين للوظيفة التي أحتاجها بخمس تكلفة a1.xlarge. ومع ذلك ، كانت فاتورتي أكبر مما كنت أتوقعه في نهاية الشهر.

في محاولة لفهم السبب ، بحثت في وثائق Amazon ووجدت الإجابة: عندما ينخفض ​​استخدام وحدة المعالجة المركزية للمثيل عن خط الأساس المحدد ، فإنه يجمع أرصدة ، ولكن عندما يتجاوز المثيل استخدام خط الأساس ، فإنه يستهلك الأرصدة المكتسبة مسبقًا. إذا لم تكن هناك أرصدة متاحة ، فإن المثيل ينفق "الأرصدة الفائضة" التي توفرها أمازون. تؤدي هذه القدرة على كسب الائتمانات وإنفاقها إلى جعل Amazon EC2 متوسط ​​استخدام وحدة المعالجة المركزية للمثيل على مدار 24 ساعة. إذا تجاوز متوسط ​​الاستخدام خط الأساس ، فسيتم إصدار فاتورة للمثيل بسعر موحد لكل ساعة vCPU.

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

لقد قمت في البداية بتحليل استخدام وحدة المعالجة المركزية لعدد قليل من أزواج التشفير ؛ كان الحمل صغيرًا ، لذلك اعتقدت أن لدي مساحة كبيرة للنمو. (لقد استخدمت مثيلًا صغيرًا واحدًا فقط لاستيعاب البيانات نظرًا لأن عددًا أقل من أزواج التشفير لا يتطلب قدرًا كبيرًا من طاقة وحدة المعالجة المركزية.) ومع ذلك ، أدركت قيود تحليلي الأصلي بمجرد أن قررت جعل رؤيتي أكثر شمولاً ودعم استيعاب البيانات لمئات من أزواج العملات المشفرة - لا يعني تحليل الخدمة السحابية شيئًا ما لم يتم إجراؤه بالمقياس الصحيح.

عمليات نقل البيانات الصادرة

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

كان التأثير هائلاً. أدى الخطأ الذي أصابني إلى تنزيلات صوتية من خوادم الويب ، مما تسبب في عمليات نقل إضافية للبيانات الصادرة. أدى خطأ بسيط في الكود الخاص بي إلى فاتورة أكبر بخمس مرات من الفاتورة السابقة. (لم تكن هذه النتيجة الوحيدة: فقد يتسبب الخطأ في حدوث تسرب للذاكرة في كمبيوتر المستخدم ، لذلك توقف العديد من المستخدمين عن العودة.)

يمكن أن تمثل تكاليف نقل البيانات ما يصل إلى 30٪ من زيادات أسعار AWS. النقل الداخلي EC2 مجاني ، ولكن يتم احتساب رسوم التحويل الصادرة لكل جيجابايت (0.09 دولار لكل جيجابايت عندما أنشأت Scalper.AI). كما تعلمت بالطريقة الصعبة ، من المهم توخي الحذر مع التعليمات البرمجية التي تؤثر على البيانات الصادرة ؛ سيؤدي تقليل التنزيلات أو تحميل الملفات حيثما أمكن (أو المراقبة الدقيقة لهذه المناطق) إلى حمايتك من رسوم أعلى. تتراكم هذه البنسات بسرعة نظرًا لأن رسوم نقل البيانات من EC2 إلى الإنترنت تعتمد على عبء العمل والمعدلات الخاصة بمنطقة AWS. تحذير أخير غير معروف للعديد من عملاء AWS الجدد: يصبح نقل البيانات أكثر تكلفة بين المواقع المختلفة. ومع ذلك ، يمكن أن يؤدي استخدام عناوين IP الخاصة إلى منع تكاليف نقل البيانات الإضافية بين مناطق التوفر المختلفة في نفس المنطقة.

عناوين IP المرنة

حتى عند استخدام عناوين عامة مثل عناوين IP المرنة (EIPs) ، فمن الممكن خفض تكاليف EC2. EIPs هي عناوين IPv4 ثابتة تستخدم للحوسبة السحابية الديناميكية. الجزء "المرن" يعني أنه يمكنك تعيين EIP لأي مثيل EC2 واستخدامه حتى تختار التوقف. تتيح لك هذه العناوين تبديل الحالات غير الصحية بأخرى سليمة بسلاسة عن طريق إعادة تعيين العنوان إلى مثيل مختلف في حسابك. يمكنك أيضًا استخدام EIPs لتحديد سجل DNS لمجال بحيث يشير إلى مثيل EC2.

توفر AWS خمسة برامج EIP فقط لكل حساب لكل منطقة ، مما يجعلها موردًا محدودًا ومكلفًا مع الاستخدام غير الفعال. تتقاضى AWS أجرًا منخفضًا بالساعة لكل EIP إضافي وفواتير إضافية إذا قمت بإعادة تعيين EIP أكثر من 100 مرة في الشهر ؛ سيؤدي البقاء تحت هذه الحدود إلى خفض التكاليف.

إنهاء وإيقاف الدول

توفر AWS خيارين لإدارة حالة تشغيل مثيلات EC2: إنهاء أو إيقاف. سيؤدي الإنهاء إلى إيقاف تشغيل المثيل ، ولن يعد الجهاز الظاهري المزود له متاحًا. سيتم فصل أي وحدات تخزين Elastic Block Store (EBS) المرفقة وحذفها ، وستفقد جميع البيانات المخزنة محليًا في المثيل. لن يتم تحصيل رسوم منك للمثيل بعد الآن.

إيقاف مثيل مماثل ، مع اختلاف بسيط واحد. لا يتم حذف وحدات تخزين EBS المرفقة ، لذلك يتم الاحتفاظ ببياناتها ، ويمكنك إعادة تشغيل المثيل في أي وقت. في كلتا الحالتين ، لم تعد Amazon تفرض رسومًا على استخدام المثيل ، ولكن إذا اخترت التوقف بدلاً من الإنهاء ، فإن وحدات تخزين EBS ستولد تكلفة طالما كانت موجودة. توصي AWS بإيقاف مثيل فقط إذا كنت تتوقع إعادة تنشيطه قريبًا.

ولكن هناك ميزة يمكنها زيادة فاتورة AWS الخاصة بك في نهاية الشهر حتى إذا قمت بإنهاء مثيل بدلاً من إيقافه: لقطات EBS. هذه نسخ احتياطية تدريجية لوحدات تخزين EBS المخزنة في Amazon's Simple Storage Service (S3). تحتوي كل لقطة على المعلومات التي تحتاجها لإنشاء وحدة تخزين EBS جديدة ببياناتك السابقة. إذا قمت بإنهاء مثيل ، فسيتم حذف وحدات تخزين EBS المرتبطة به تلقائيًا ، ولكن ستبقى لقطاته. نظرًا لأن S3 تتقاضى رسومًا من حجم البيانات المخزنة ، فإنني أوصيك بحذف هذه اللقطات إذا لم تستخدمها قريبًا. تتميز AWS بالقدرة على مراقبة نشاط التخزين لكل حجم باستخدام خدمة CloudWatch:

1. أثناء تسجيل الدخول إلى AWS Console ، من قائمة الخدمات العلوية اليسرى ، ابحث عن خدمة CloudWatch وافتحها.
2. على الجانب الأيسر من الصفحة ، ضمن قائمة المقاييس القابلة للطي ، انقر فوق جميع المقاييس .
3. تعرض الصفحة قائمة بالخدمات ذات المقاييس المتاحة ، بما في ذلك EBS و EC2 و S3 والمزيد. انقر فوق EBS ثم على مقاييس الحجم . (ملاحظة: سيكون خيار EBS مرئيًا فقط إذا كان لديك وحدات تخزين EBS تم تكوينها على حسابك.)
4. انقر فوق علامة التبويب الاستعلام . في طريقة عرض المحرر ، انسخ والصق الأمر SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId ثم انقر فوق تشغيل . (ملاحظة: يستخدم CloudWatch لهجة SQL مع بناء جملة فريد.)

تقدم CloudWatch مجموعة متنوعة من تنسيقات المرئيات لتحليل نشاط التخزين ، مثل المخططات الدائرية والخطوط والأشرطة والمخططات المساحية المكدسة والأرقام. يعد استخدام CloudWatch لتحديد أحجام ولقطات EBS غير النشطة خطوة سهلة نحو تحسين تكاليف السحابة.

أموال إضافية في جيبك

على الرغم من أن أدوات AWS مثل CloudWatch تقدم حلولًا مناسبة لمراقبة تكلفة السحابة ، تتكامل العديد من المنصات الخارجية مع AWS لتحليل أكثر شمولاً. على سبيل المثال ، تُظهر منصات إدارة السحابة مثل CloudHealth من VMWare تحليلًا تفصيليًا لأهم مجالات الإنفاق التي يمكن استخدامها لتحليل الاتجاه ، واكتشاف الانحرافات ، ومراقبة التكلفة والأداء. أوصي أيضًا بإعداد منبه الفوترة CloudWatch لاكتشاف أي زيادات في الرسوم قبل أن تصبح مفرطة.

توفر Amazon العديد من الخدمات السحابية الرائعة التي يمكن أن تساعدك في تفويض أعمال الصيانة للخوادم وقواعد البيانات والأجهزة إلى فريق AWS. على الرغم من أن تكاليف النظام الأساسي السحابي يمكن أن تنمو بسهولة بسبب الأخطاء أو أخطاء المستخدم ، فإن أدوات المراقبة في AWS تزود المطورين بالمعرفة لحماية أنفسهم من النفقات الإضافية.

مع وضع تحسينات التكلفة هذه في الاعتبار ، فأنت على استعداد لبدء مشروعك - وتوفير مئات الدولارات في هذه العملية.