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

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

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

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

هناك عدد من الحلول في الصناعة لحل هذه المشكلة: تطبيقات الويب المُدارة (Beanstalk ، AppEngine ، وما إلى ذلك) ، وإدارة الحاويات (Kubernetes ، ECS ، وما إلى ذلك) وغيرها الكثير. إنهم يعملون بشكل جيد خارج الصندوق ويمكنهم حل المشكلة بشكل مثالي. ولكن هذا التعقيد غير ضروري عند إطلاق تطبيق ويب ، وعادة ما تكون هذه الحلول "تعمل فقط".

لسوء الحظ ، فإنهم لا يعملون دائمًا "فقط". إذا كان هناك أي فارق بسيط ، فأنا أريد أن أعرف المزيد عن هذا الصندوق الأسود الشرير.

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

ابدأ

تخيل ميزانيتك للاستضافة 500 دولار في السنة ، لذلك قررت استئجار خادم t2.medium واحد على Amazon AWS. في وقت كتابة هذا التقرير ، كان هذا حوالي 400 دولار في السنة.

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


التين. 1

هذا يكفي الآن. في الواقع ، يمكن أن يعمل مثل هذا النظام لبعض الوقت. الخدمة صغيرة ، أقل من 10 زيارات في اليوم. ربما كان المثال الصغير كافيًا ، لكننا متفائلون بشأن نمو الشركة ، لذلك أخذنا بحذر t2.medium.

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

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

الآن يبدو النظام شيئًا مثل هذا:


التين. 2

لقد قمت بزيادة موثوقية قاعدة البيانات ، وحان الوقت للتحضير لـ "تأثير العطب" عن طريق تشغيل اختبار تحميل على الخادم. كل شيء يسير على ما يرام حتى ظهور 500 خطأ ، ثم تدفق خطأ 404 ، لذلك أنت تحقق في ما حدث.

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

يمكنك إصلاح المشكلة من خلال إعادة التشغيل التلقائي عن طريق إنشاء خدمة systemd ، وبدء تشغيل خادم الويب ، والذي يحل في نفس الوقت مشكلة التسجيل. ثم قم بإجراء اختبار تحميل آخر للتحقق.

ومرة أخرى نرى أخطاء 500 (لحسن الحظ ، بدون 404). تحقق من السجلات. تم الكشف عن أن تجمع اتصال قاعدة البيانات ممتلئ لأنه تم تعيين حد صغير من 10 اتصالات. قم بتحديث التقييد وأعد تشغيل قاعدة البيانات وقم بتشغيل اختبار الحمل مرة أخرى. كل شيء يسير على ما يرام ، لذلك قررت التحدث عن موقعك على حبري.

يوم الإطلاق

أم الله! أصبحت خدمتكم على الفور ضربة. لقد وصلت إلى الصفحة الرئيسية وحصلت على 5000 مشاهدة في الدقائق الثلاثين الأولى - وسترى التعليقات. ماذا يكتبون هناك؟

لدي خطأ 404 ، لذلك كان علي فتح نسخة مخبأة من الصفحة. هذا هو الرابط ، إذا كان أي شخص يحتاج إليه: ...

...

لا شيء يفتح. أيضا ، لقد تم تعطيل Javascript. لماذا يعتقد الناس أنني أريد تحميل جافا سكريبت 2 ميغابايت ...

...

يستغرق تنزيل الصفحة الرئيسية 4 ثوانٍ. يُظهر Traceroute من أستراليا أن الخادم موجود في مكان ما في تكساس. أيضا ، لماذا تقوم الصفحة الأولى بتحميل 2 ميغابايت من جافا سكريبت؟

في اندفاع مجنون ، يمكنك تكوين Nginx كخادم وكيل عكسي للتطبيق الخاص بك وتكوين صفحة 404 ثابتة هناك. يمكنك أيضًا تغيير إجراء النشر لإرسال ملفات ثابتة إلى S3: هذا ضروري لكي يعمل CloudFront CDN لتقليل وقت التحميل في أستراليا.


التين. 3

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

قضايا الأداء

تمر الأشهر. الجمهور ينمو. يبدأ الموقع في التباطؤ. لقد لاحظت في مراقبة CloudWatch أن هذا يحدث فقط بين 00:00 و 12:00 UTC. نظرًا لنفس أوقات التأخير والانتهاء ، تدرك أن هذا يرجع إلى مهمة مجدولة على الخادم. تحقق من crontab وندرك أنه من المقرر وظيفة واحدة في منتصف الليل: النسخ الاحتياطي. بالطبع ، يستغرق النسخ الاحتياطي اثنتي عشرة ساعة ويؤدي إلى زيادة تحميل قاعدة البيانات ، مما يتسبب في حدوث تباطؤ كبير في الموقع.

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


التين. 4

نمو الفريق

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

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

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


التين. 5

واثقًا من أنك ستتعامل مع الحمل ، تذكر مرة أخرى موقعك على حبري. يا معجزة ، يمكن أن تصمد أمام حركة المرور. نجاح عظيم!

يبدو أن كل شيء يسير على ما يرام حتى تذهب للتحقق من السجلات. استغرق الأمر ساعة لاختبار 12 خادمًا (أربعة خوادم في كل بيئة). متاعب حقيقية. لحسن الحظ ، هناك ما يكفي من المال لشراء مكدس ELK (ElasticSearch ، LogStash ، Kibana). يمكنك نشره وتوجيه خوادم هناك من جميع البيئات.


التين. 6

الآن ، يمكنك الرجوع إلى السجلات مرة أخرى ، والنظر إليها - وملاحظة شيء غريب. إنها مليئة بهذه الإدخالات:

 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 

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


التين. 7

تحقق من السجلات مرة أخرى. استمرت محاولات القرصنة ، لكنها الآن تقتصر على المنفذ 80 على موازن التحميل ، وهو أمر مريح قليلاً ، لأن خوادم التطبيقات وخوادم قواعد البيانات ومكدس ELK لم تعد في المجال العام.

على الرغم من السجلات المركزية ، فقد سئمت من البحث عن أوقات التوقف عن العمل ، والتحقق من السجلات يدويًا. من خلال Amazon CloudWatch ، يمكنك إعداد تنبيهات البريد الإلكتروني عندما يصل استخدام محرك الأقراص ووحدة المعالجة المركزية والشبكة إلى 80٪. عظيم!

عملية سلسة

أمزح فقط! لا يوجد شيء مثل التشغيل السلس في البرنامج. سوف ينكسر شيء بالتأكيد. لحسن الحظ ، لديك الآن العديد من الأدوات للتعامل مع الموقف.

لقد أنشأنا تطبيق ويب قابل للتطوير مع النسخ الاحتياطية ، والعودة (باستخدام عمليات النشر الزرقاء / الخضراء بين الإنتاج والمرحلة المتوسطة) ، والسجلات المركزية ، والرصد والإخطار. يعتمد التوسع الإضافي ، كقاعدة ، على الاحتياجات المحددة للتطبيق.

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

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

الخلاصة

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

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

هذا كل شيء الآن.

شكرا للقراءة والتشفير الجيد!

ملاحظة: لا تأخذ حرفيا التسلسل من هذه المقالة التوضيحية. بشكل منفصل ، حدثت لي كل هذه الأحداث حقًا ، ولكن في أوقات مختلفة ، في بيئات مختلفة تمامًا وفي مهام مختلفة.