قررت مؤخرًا تجربة واجهة برمجة التطبيقات على موقع CardGames.io الخاص بنا وتجربة إطار عمل Serverless . على مدار السنوات القليلة الماضية ، أصبح موضوعًا ساخنًا في عالم التكنولوجيا ، ولقد قمت بمماطلة أنني أردت الاحتفاظ بمهاراتي التقنية محدثة وتجربة شيء جديد. لذلك ، قررت قضاء عدة ساعات في دراسة Serverless ومعرفة ما إذا كان هناك أي معنى في موضع API هذا.

التكوين الحالي

يعمل CardGames.io على AWS. يتم تخزين جميع صفحات HTML و CSS و JavaScript والصور في S3. لدينا واجهة برمجة تطبيقات C # مستضافة على تطبيق Beanstalk المرن ، وهو يعمل على خوادم Linux التي تستخدم .NET Core مع Docker. أخيرًا ، نستخدم CloudFront CDN قبل الإحصائيات على S3 و API. فيما يلي نتيجة EC2 لشهر أغسطس 2019. لدينا العديد من الحالات الأخرى ، لكن واجهات برمجة التطبيقات تعمل على m1.small (نعم ، ربما يعمل t2.small بشكل أفضل) مع موازنة التحميل الكلاسيكية. إذا قمت بتلخيص ما تم تمييزه باللون الأحمر ، عندئذٍ يخرج 164.21 دولار شهريًا وليس سيئًا. لقد أدرجت EBS هناك ، لأنني لست متأكدًا من كيفية كسر هذه النفقات ، لدينا العديد من المشاريع في EC2.


حساب AWS لشجرة الفاصولياء المرنة

لدينا بيئتان مع 1-3 مثيلات في كل: نشط وغير نشط ، لأن نشر .NET Core في Docker على AWS يستغرق عدة دقائق ، لذلك نحن نفعل ذلك في بيئة غير نشطة ، ثم نحول سجلات CNAME إلى واحدة تم نشرها مؤخرًا. كان النشر البطيء أحد الأسباب التي جعلتني أرغب في تجربة شيء جديد. لدينا العديد من الخوادم التي تحتوي على تطبيقات node.js على Beanstalk - ويتم نشرها في ثوانٍ. أردت أن تكون هي نفسها لواجهة برمجة التطبيقات.

التحول إلى Serverless

لقد درست تعليميًا جيدًا لاستضافة ASP.NET Web API باستخدام إطار عمل Serverless ووجدت أنك تحتاج فقط إلى إضافة ملف تكوين بسيط ، تبعية واحدة وفئة بدء تشغيل صغيرة إلى مشروع API موجود. استغرق نشر حوالي عشرين ثانية - أفضل بكثير مما كانت عليه في شجرة الفاصولياء. أعتقد بفضل الدعم المضمن لبرنامج .NET Core في Lambda (على الرغم من ذلك ، 2.2) فقط ، بينما في Beanstalk يتم دعمه فقط إذا كنت تستخدم عامل إرساء مستقل. على أي حال ، كنت سعيدًا دون التفكير في مجموعات التحجيم التلقائي ومثيلات الحد الأقصى وما شابه ذلك.

اختبار الأداء

Serverless on AWS هو Lambda ، الذي يستضيف بالفعل ميزاتك ، وواجهة البوابة الأمامية API ، التي تتيح لك إضافة أشياء مثل حدود السرعة ، ومفاتيح API ، وأكثر من ذلك. قمت باستضافة ميزات Lambda في منطقة غرب الولايات المتحدة ، حيث توجد خوادم Beanstalk. ثم قمت بتكوين مثيل CloudFront لتوجيه الطلبات من إحدى ألعابنا إلى التكوين الجديد بدون خادم ، والآخر إلى تكوين Beanstalk القديم. ثم أطلق اختبارًا بسيطًا على عنوانين URL: واحد Serverless والآخر شجرة الفاصولياء. تم استدعاء كل من عناوين URL الخاصة بواجهة برمجة التطبيقات نفسها ، لتخزين نفس الحدث في قاعدة البيانات. قمت بتشغيل 100 استفسار لكل منها ، وهنا النتائج:


مقارنة الأداء

في عمليات التشغيل المتعددة ، كان التكوين Serverless أبطأ بنسبة 15٪ (إذا كان هناك أي شيء ، فقد قمت بتشغيله من أيسلندا ، ومن ثم بينغ الكبير). كانت السرعة مخيبة للآمال ، لكنها ظلت عالية جدًا - أدركت أن هناك بعض الحملات الأمامية لواجهة بوابة API أمام واجهة برمجة التطبيقات لدينا: هناك العديد من الوظائف ، حتى لو لم نستخدمها. لذلك ، حزينة ، ولكن ليست حاسمة!

أسعار

بصراحة ، في البداية لم أفكر في الأسعار. قررت للتو أن الدفع مقابل الاستخدام الفعلي قد يكون أرخص من دفع ثمن الحالات 24/7. لذلك ، سمح للتثبيت بدون خادم الجديد بالعمل لعدة أيام ، ثم بدأ التحقق من الحسابات. عفوا! تجاوزت فاتورة Lambda + API Gateway بالفعل مائة دولار! في البداية بدأت العبث بإعداد Lambda ، حيث خصصت ذاكرة أقل لحفظه ، لكن عندما نظرت إلى ما كان يحدث بشكل جيد ، أصبح من الواضح أن المشكلة كانت في البوابة. فيما يلي أسعار API Gateway:


أسعار بوابة API

تقبل API الخاصة بنا حوالي 10 مليون طلب يوميًا. هذا هو حوالي 35 دولار لكل بوابة فقط كل يوم . بالإضافة إلى ذلك ، يكلف Lambda حوالي 10 دولارات في اليوم ، على الرغم من أنه يمكن تخفيض ذلك عن طريق تخصيص ذاكرة أقل. وتبين معًا حوالي 45 دولارًا في اليوم ، أو 1350 دولارًا في الشهر ، مقابل 164 دولارًا في الشهر على مرمر شجرة الفاصولياء. ثماني مرات أكثر تكلفة ! أنا أحب التقنيات الجديدة والانتشار السريع ، لكنني لن أدفع 1200 دولار شهريًا مقابل ذلك. العودة إلى شجرة الفاصولياء!

استنتاج

ربما ، كان ينبغي عليّ أن أتعرف على الأسعار مقدماً وأجري بعض الحسابات الرياضية! لكن بالطبع ، يجب أن أقوم بعمل حقيقي ، وأن لا أتعلم مهارات فنية قيمة! أنا متأكد من أنه في بعض الحالات ، تكون واجهات برمجة تطبيقات Gateway و Lambda أفضل من تطبيق Beanstalk المرن. إنها ليست حالتنا. ربما إذا كنت تستخدم مفاتيح API وحدود السرعة وميزات بوابة API الأخرى ، فمن المنطقي دفع 3.50 دولار لكل مليون طلب. من الأفضل أن نضع موازن التحميل الطبيعي أمام Lambda. حسب علمي ، هذا غير ممكن ؛ بوابة API مطلوبة للوصول http إلى Lambda.

لكن حتى لو دفعنا للتو مقابل Lambda ، فقد بلغت 300 دولار في اليوم مقابل 300 دولار في اليوم بدلاً من 164 دولار. لدينا العديد من الاستعلامات ، لكن كل استعلام يقوم بالقليل: في الأساس ، مكالمة DB واحدة لكل استعلام. ربما تكون الاستعلامات الأثقل التي تستخدم وقتًا أكبر للحوسبة أكثر ملاءمة لـ Lambda ، حيث تدفع مقابل 100 مللي ثانية من وقت الحوسبة. أدناه هو تقرير لطلب واحد. كما ترون ، نستخدم 3.50 مللي ثانية من وقت الحوسبة ، لكن الفاتورة محددة بـ 100 مللي ثانية ، وهذا ليس تقريبًا ضعيفًا.


تقرير لامدا لطلب واحد

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