حقيقة تشغيل تطبيق Node للإنتاج على AWS Elastic Beanstalk

الدروس المستفادة من عامين من تشغيل تطبيق Node للإنتاج على منصة ELB الخاصة بـ AWS

أمامي

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

التكلفة الحقيقية لتشغيل التطبيق

لقد كنت أدير تطبيق ويب عقدة على ELB منذ حوالي عامين حتى الآن. كانت السنة الأولى رائعة ، لقد قدموا لك كل شيء مجانًا (في الغالب)! بعد ذلك ، عليك أن تبدأ في الدفع مقابل أشياء ، مثل مثيلات EC2.

ستركز هذه المقالة على متطلبات تطبيقي المحددة ، وهو تطبيق سريع يعتمد على العقدة ويتم استضافته على Elastic Beanstalk.

للحصول على تفاصيل كاملة حول التصميم ، راجع مقالتي السابقة هنا.

انفصال

هذا ما أعمله حاليًا على AWS:

بيئة EBS واحدة (منطقة غرب الولايات المتحدة):

  • 1 موازن تحميل كلاسيكي
  • 1 t2.micro EC2 مثيل
  • دلو S3 يحمل صورًا (7 جيجابايت وقت كتابة هذا التقرير)
  • 1 طريق 53 منطقة مستضافة

18 دولارًا (موازن التحميل) + 5 دولارات (EC2 مع RI) + 0.50 دولار (الطريق 53) + 0.17 دولار (S3) + 0.21 دولار (نقل البيانات) = ما يقرب من 25 دولارًا في الشهر.

بالإضافة إلى ذلك ، أستضيف MongoDB في مكان آخر ، لذلك إذا كنت تخطط لاستضافة قاعدة بيانات على AWS ، فسيتكبد ذلك تكاليف إضافية. دعنا نقسم التكاليف المختلفة.

موازن التحميل

هذا هو أغلى جزء من المكدس. يكلف:

  • 0.025 دولار لكل ساعة موازن تحميل كلاسيكي (أو ساعة جزئية)
  • 0.008 دولار لكل جيجابايت من البيانات التي تتم معالجتها بواسطة Classic Load Balancer

هذا يعني أنه إذا قمت بتشغيل تطبيقك على مدار 24 ساعة في اليوم ، فسيتكلفك ما يقرب من 18 دولارًا + رسوم بيانات كل شهر.

مثيل EC2

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

S3

لدي دلاء S3. واحدة لصفحتي الرئيسية الثابتة ، وواحدة لحمل الصور والأخرى للاحتفاظ بإصدار التطبيق. على حد علمي ، تقوم ELB تلقائيًا بإنشاء الإصدار لإدارة إصدارات التطبيق.

يعتبر S3 رخيصًا جدًا ، لذلك لست قلقًا جدًا بشأن محاولة استخدام النيكل والدايم ، ولكن هناك طرقًا لتوفير المال عبر نظام Glacier الخاص بهم.

قاعدة البيانات

أستضيف برنامج MongoDB DB الخاص بي في mLab ، والذي سينتهي قريبًا. لذلك سوف أقوم بتحديث هذا عندما أحدد المبلغ الذي سيكلفني في الواقع بمجرد أن أجبر على الانتقال إلى نظام أطلس مونجو.

مثيلات EC2 المحجوزة

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

بعد الكثير من القراءة والتحدث مع خدمة عملاء AWS ، هذا ما توصلت إليه نوعًا ما.

أولاً ، توجد طريقتان مختلفتان يمكنك حجز مكان وجود RI: المنطقة الإقليمية ومنطقة توافر الخدمات. الوسائل الإقليمية ، وهي خاصة بإحدى المناطق الرئيسية ، على سبيل المثال. us-west-2 (أوريغون). منطقة الإتاحة (AZ) خاصة بمنطقة داخل تلك المنطقة ، على سبيل المثال us-west-2 a (Oregon).

لقد اشتريت RI داخل us-west-2 وتم تطبيقه تلقائيًا على المثيل الخاص بي الذي يعمل في تلك المنطقة. إذا اشتريت واحدًا داخل AZ ، فسيتم تطبيقه فقط على AZ المحدد ، على سبيل المثال us-west-2a ، لذلك إذا قام ELB بتدوير مثيل EC2 في us-west2b ، فلن يحالفك الحظ.

بالإضافة إلى ذلك ، هناك أنواع "قياسية" و "قابلة للتحويل" من RIs. لا أفهم ما يعنيه ذلك بنسبة 100٪ ، ولكن مما أفهمه أن التحويل أكثر مرونة فيما يتعلق بما يمكنك تبديله به ، ولكنه أكثر تكلفة.

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

لكل دعم AWS:

لا توجد مثيلات محجوزة مقدمًا (RIs) يمكن أن تشكل مخاطر فوترة كبيرة على الحسابات الجديدة ، حيث إنها التزام تعاقدي بالدفع شهريًا لكامل مدة RI. لهذا السبب ، لا يمكن للحسابات الجديدة والحسابات المستخدمة قليلاً الاشتراك في No Upfront RIs حتى يتم إنشاء سجل فوترة ناجح معنا.

قد تواجه هذا الخطأ إذا حاولت شراء لا مقدمًا.

خطأ: حصتك الحالية لا تسمح لك بشراء العدد المطلوب من المثيلات المحجوزة (الخدمة: AmazonEC2 ؛ رمز الحالة: 400 ؛ رمز الخطأ: ReservedInstancesLimitExceeded ؛)

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

نقاط الألم

هذه مجرد بعض الشكاوى البسيطة حول EBS بشكل عام ، والتي اعتقدت أنني سأدرجها كملحق لمقالتي الأصلية ، في حال كنت فضوليًا.

التحديثات التلقائية ليست تلقائية حقًا

إصدارات العقدة لا تصطف من إصدار إلى آخر.

راجع الخطوة أدناه حول كيفية إدارة تغيير إصدارات Linux عندما لا تعمل Node.

تشغيل أكثر من بيئة

من السهل وجود بيئة تطوير وتشغيل إنتاج في نفس الوقت ، لكنه مكلف. إنه يضاعفها ، في الواقع. لذلك ، عادةً ما أقوم بتدمير بيئة التطوير بمجرد انتهائي من ذلك.

التوثيق مروع

AWS كبير جدًا لمصلحته. هذا جزء من سبب كتابتي لهذا. كان من الصعب حقًا العثور على إجابات لاحتياجاتي الخاصة.

كيف أدير التحديثات

لدي حالتان منفصلتان من Git repo مثبتان على الكمبيوتر المحمول الخاص بي. لدي واحد للتطوير والآخر للإنتاج.

أنا أستخدم بيئة التطوير من أجل التطوير الجيد! واضحة ومباشرة جدا. أنا أستخدم مجلد الإنتاج فقط لغرض سحب التحديثات من فرع Git الرئيسي ، وتشغيل تكوين webpack الخاص بي ونشره على خادم الإنتاج.

السبب في انفصالهما هو أنني أستطيع الحفاظ على تكوينات منفصلة مرنة لساق الفاصولياء ولا داعي للقلق بشأن النشر في المكان الخطأ.

التحديثات لا تتطلب تغيير بيئة Linux

بالنسبة للتحديثات التي لا تتطلب أي تغييرات في بيئة نظام التشغيل Linux ، فهي بسيطة مثل التشغيل eb deployفي الجهاز. إنه أمر مذهل ويستغرق انتشاره حوالي 10 دقائق.

التحديثات التي تتطلب تغيير بيئة Linux

في بعض الأحيان ، سترغب في تحديث بيئة Linux ولكنك لن تتمكن أيضًا من ذلك لأن AWS غبية (أنا متأكد من أن هناك سببًا) ولا تسمح إلا بإصدارات معينة من Node على كل إصدار من Linux. لهذا ، الأمر أكثر تعقيدًا بعض الشيء ، لكن يمكن التحكم فيه.

  1. ادفع لتكوين الإنتاج في ظل بيئة جديدة. في المرة الأخيرة التي قمت فيها بذلك ، قمت للتو بإنشاء مثيل جديد عبر eb create prod-1. ستفعل ما تحتاج إليه وتنشر تطبيقك في بيئة جديدة.
  2. تأكد من أن جميع التحديثات الخاصة بك تعمل. يبدو واضحًا جدًا ، ولكن هذا هو الوقت المناسب للتأكد من عدم وجود أي عوائق في التصميم الجديد.
  3. تأكد من إعداد Vars الخاص بك بشكل صحيح. هذا جزء من الإصدار السابق ، لكن تأكد من أنك تسحب قاعدة البيانات الصحيحة ، أو أيًا كان.
  4. تأكد من أن موازن التحميل الخاص بك لديه نفس شهادة SSL (إن وجدت). حقيقة ممتعة ، إذا حاولت الوصول إلى مثيل ELB في https بدون شهادة ، فسوف يفشل!
  5. مبادلة المثيلات. أخيرًا ، بعد أن يبدو كل شيء جيدًا ، هناك زر في وحدة التحكم لمبادلة عناوين url الخاصة بالمثيل. سهل جدا. ليس عليك تغيير أي شيء في الطريق 53 ، فهو يفعل كل شيء من أجلك.

لذا ، ها أنت ذا. كيفية إدارة التحديثات الخاصة بك. سهل جدا.

افكار اخيرة

إذا كانت لديك أي اقتراحات لجعلها أرخص / أسهل ، فأنا أحب أن أسمعها. أحب النقاش حول الأدوات والخيارات تمامًا مثل المطور التالي!

مع ذلك ، سأغادر مع هذا: أتمنى لك برمجة سعيدة!