نستكمل الـ Scalability Capsules و هنتكلم بشكل مختصر عن الـ Load Balancer و ازاي نقدر نخدم اي عدد من الترافيك او الطلبات (requests) علي الابلكيشن ونستحمل اي ترافيك اي وقت
#scalability_capsule
#scalability_capsule
١ - تخيل كدا انك عملت موقع و في خلال اول شهر الموقع كان شغال تمام و عليه ١٠٠ زيارة في الدقيقة. وبعد شهرين الزيارات بدأت تزيد ل ٣٠٠ في الدقيقة و العميل اتصل بيك و قالك الموقع بقى بطئ شويه ف انت قررت تزود حجم وامكانيات السيرفر شويه و حليت المشكله.
٢ - بعدها حصل تريند و الزيارات زادت ل ٧٠٠ في الدقيقة و العميل اتصل بيك و بيقولك مره الموقع يشتغل معايا و مره تاني يقولي 502 Bad Gateway و مش بيشتغل. وانك تزود السيرفر مش مقبول لأنك يا اما هتدفع سعر غالي جدا يا اما انت وصلت لأعلى سيرفر في شركة الاستضافة (Hosting) زي Digital Ocean
٣ -انك تزود امكانيات السيرفر مقبول في بعض الحالات والطريقه دي اسمها Vertical Scaling ودي مثلا ممكن تستخدمها مع سيرفر قاعدة بيانات انت عارف ان الترافيك متوسط ولكنه يحتاج مساحة تخزينية كبيرة و معالج أسرع علشان يقدر يخدم البيانات في وقت مظبوط. وفيه امثله تانية ممكن تبحث عنها.
٤ - طيب ليه لما ازود امكانيات السيرفر ممكن يظهر errors في بعض الاحيان؟ السبب ان فيه عوامل كتير لكن سيرفر بحجم كبير و عليه ترافيك كتير طريقه معالجه الprocessor و الthreads لطلبات كتيره في نفس الوقت هيحصل تاخير في بعض الطلبات لان فيه طلبات تاني بيتم خدمتها
٥ - تخيل ان مطعم فيه خادم واحد يوصل الاكل للزبائن. ومعه حامل بيشيل طبقين و المطعم به ١٠ زبائن. وقمنا باستبدال الحامل بآخر اكبر يحمل ٤ اطباق. ما زال هناك مشكله لان الخادم يحتاج يوصل ل٤ زبائن و يرجع للمطبخ يجيب ٤ اطباق كمان يخدم ٤ اخريين و احيانا زبون يطلب ٤ اطباق بدل من طبق واحد
٦ - لكن بدلا من زياده حجم الحامل فقط، وظفت خادم اخر. اصبح الان كل واحد منهم يستطيع ان يخدم ٤ زبائن في نفس الوقت. واذا كان هناك ضغط سيتم تقسيمه عليهم بدل ما كان الضغط علي خادم واحد فقط. و دي اسمها Horizontal Scaling
٧ - الـHorizontal Scale: اننا نزود سيرفرات بحجم صغير بدل من سيرفر واحد ضخم. وقتها توزيع الترافيك مش هيستهلك موارد كتير من كل سيرفر منهم. و بسهوله تقدر تزود سيرفرات في وقت الذروة و تقلل السيرفرات في وقت غياب الزيارات.
٨ - ازاي تطبق الـHorizontal Scaling. اولا هي مهمة الويب سيرفر انه يستقبل الطلبات و يبعتها للكود بتاعك. و بدلا من ان يكون فيه سيرفر واحد بنقوله ان فيه ٥ او ٦ او ١٠ سيرفرات جاهزين لخدمه اي طلب. ف زي ما انت عملت deploy للكود علي سيرفر هتعمل نفس العمليه علي عدد السيرفرات اللي عندك
٩ - فلو انا استخدمت اي server ip منهم المفروض الاقي نفس المحتوي اللي المفروض يرجع من الابلكيشن. ومن هنا نقدر نقول للويب سيرفر NGINX ان دول الips للسيرفرات اللي جاهزه و من فضلك اي ريكوست يجيلك ابعته لاي واحد منهم.
١٠ - ف كدا انت عندك سيرفر عليه nginx as loadbalancer و عدد x من السيرفرات كل واحد منهم عليه nginx + الكود بتاعك سواء هو php او nodeJS او rails
١١ - طيب هل التوزيع بيتم بشكل عشوائي كدا و خلاص. بما اننا بنتكلم علي nginx ف هو بيوفر كذا algorithm او طريقه لتوزيع الترافيك.
يوجد ٦ انواع مدعومين من Nginx هم
Round Robin
Least Connections
IP Hash
Generic Hash
Least Time
Random
يوجد ٦ انواع مدعومين من Nginx هم
Round Robin
Least Connections
IP Hash
Generic Hash
Least Time
Random
١٢ - الـ Round Robin وهي الافتراضيه و مش بتحتاج تعرف ليها اي حاجه و فيها بيتم توزيع الطلبات بالتساوي علي السيرفرات مع اعتبار الserver weight اللي بتعرفه لو عندك احجام مختلفه من السيرفرات اللي بتخدم نفس الـ api
١٣ - الـ Least Connections بيتم فيها ارسال الطلبات الي السيرفر الذي يخدم اقل عدد من الطلبات في وقت ارسال الطلب
- الـ IP Hash بيتم ارسال الطلبات الي السيرفر حسب first three octets من الـIP و ده بيضمن ان الطلبات من مكان معين بيتم ارسالهم الي نفس السيرفر
- الـ IP Hash بيتم ارسال الطلبات الي السيرفر حسب first three octets من الـIP و ده بيضمن ان الطلبات من مكان معين بيتم ارسالهم الي نفس السيرفر
١٤ - الـGeneric Hash و بيتم ارسال الطلبات حسب متغير تقدر تعرفه زي مثلا رابط معين او cookie معينه و مثلا ممكن يكون ip + port معين
- الـLeast Time (NGINX Plus only) وهنا بيتم ارسال الطلبات الي سيرفر باقل latency وبعض المتغيرات الاخري
- الـLeast Time (NGINX Plus only) وهنا بيتم ارسال الطلبات الي سيرفر باقل latency وبعض المتغيرات الاخري
١٥ - اخيراً الـ Random : و هنا بيتم توزيع الطلبات بشكل عشوائي بناء علي عده متغيرات. وتذكر انه لا يمكنك الاعتماد علي لوغاريتم بشكل عشوائي تماماً لانه ممكن يرسل اغلب الطلبات الي سيرفرات معينه فقط دون الاخري و وقتها هيسبب ضغط علي نظام من المفروض انه يقدر يخدم الطلبات بشكل كافي تماما
١٦ - كفانا حديث اكاديمي و خلينا نشوف ازاي نطبق ده علي الكود ;). المثال بسيط جدا. عرفنا upstream باسم app_nodes و به مجموعه سيرفرات و في location / يتم ارسال كل الطلبات الي احد السيرفرات باستخدام لوغاريتم Round Robin
١٧ - لنقول اننا نريد ارسال كل الطلبات علي /api الي سيرفرات اخري باستخدام لوغاريتم اخر سنقوم بعمل الاتي بكل بساطه. قمنا بعمل upstream جديد و استخدمنا لوغاريتم IP HASH. بشكل مبسط ;)
١٨ - اختتم كلامي بانك محتاج تتاكد ان كل السيرفرات اللي هتشارك الطلبات في الload balancer انها بتشارك قاعدة البيانات و ال session driver ولو بتستخدم centralized cache مثلا Redis.
اتمني ان الثريد كان مفيد ولو فيه اي سؤال و استفسار هكون سعيد اني اجاوبك :)
اتمني ان الثريد كان مفيد ولو فيه اي سؤال و استفسار هكون سعيد اني اجاوبك :)
جاري تحميل الاقتراحات...