(ثريد) بقالي فتره طويله بفكر ازاي ممكن اتكلم و اشارك الخبره اللي اكتسبتها في بناء سوفت وير ستارتب اعلانات قدر يخدم من 800 page view ل +2M page views في اليوم و اكتر.
هتكلم عن بعض مفاهيم الScalability اللي ساعدتني في بناء البروداكت و تساعدكم انتم كمان ان شاء الله
هتكلم عن بعض مفاهيم الScalability اللي ساعدتني في بناء البروداكت و تساعدكم انتم كمان ان شاء الله
١ - بناء تطبيق عليه زيارات كتير و عدد كبير مش محتاج انه يكون Microservice. حاول تبعد عنها في بناء البروداكت علشان يكون سهل عليك تعمل تعديلات و تطور في النظام و تتجنب المشاكل اللي بتحصل مع الـ Microservice الي ان تجد الحاجه اللي تجبرك انك تنقلها. وهوضحلك ده كمان كام تويته.
٢ - load tests / stress test. من المهم انك تقدر تعرف الكود بتاعك بيحتاج موارد قد ايه علشان يخدم عدد معين من المستخدمين وبناء عليه توفر عدد سيرفرات معين حسب الترافيك و هتبقي عامل حسابك ان كل ما الترافيك يزيد انت محتاج قد ايه سيرفرات متوفره علشان تخدم العدد ده.
٢.١ معانا ظهرت المشاكل من اول ٨٠٠ زياره في الدقيقه و اخدنا وقت علشان نحسن اداء الكود شويه و زودنا امكانيات السيرفر علشان يقدر يتحمل العدد ده من الترافيك. و النقطه الجايه هنشرح ازاي ممكن تخدم عدد كبير ب سيرفرات حجمها صغير و تكلفتها قليله
٣- Load balancing: بدل من استخدام سيرفر واحد ضخم و نزود حجمه كل ما الترافيك يكبر. احنا ممكن نستخدم اكتر من سيرفر صغير علشان نوزع عليهم الترافيك و هيبقي ادائهم احسن و افضل من مجرد سيرفر واحد ضخم. ده غير ان فقدان سيرفر منهم لاي سبب مش هياثر علي السيستم كله لوجود سيرفرات تانيه متاحه
٣.١ كل مره كنا بنزود حجم السيرفر لغايه ما وصلنا لاكبر سيرفر ب ٦٥٠ دولار . و ده مكانش كافي وكان مش بيقدر يستحمل بردو. بس لما عملنا ٣ سيرفرات كل سيرفر منهم تكلفته حوالي ٥٠ دولار و عملنا الload balancer الترافيك كان بيتوزع بشكل مرن جدا و قدرنا نخدم حوالي ٢٠٠٠ زياره ف الدقيقه.
٣.٢ ملاحظه بردو اننا في الوقت ده كان عندنا مشاكل في الكود لان خبرتنا كانت صغيره علي الترافيك ده كله. و بعد محاولات عديده و تحسين ف الكود قدرنا نخفض التكلفه و عدد السيرفرات
٤ - Centralization: من المهم ان البيانات تكون منفصله في سيرفر مركزي. مثلا الكاش مينفعش يبقي موجود كملف علي كل سيرفر لان ده معناه انك بتكرر نفس البيانات وده هيكلفك مساحه و فلوس. الحل ان يبقي عندك سيرفر منفصل عليه البيانات دي و الكود بيتصل بيه للكتابة و القراءة
٤.١ في الحاله بتاعتنا كنا بنعمل كاش active campaigns. ف استخدمنا Redis server علي سيرفر منفصل و كل الapps كانت بتتصل بيه علشان تقرا البيانات دي و بكدا مكناش قلقانين من اننا نزود سيرفرات و نقللها مع ال Load balancer
٥ - DB Distribution: من المهم جدا انك تكون فاهم ازاي هتسجل البيانات وتقرأها و لما تزيد هتتصرف ازاي. هنتكلم لاحقاً عن ال Replication & Sharding لكن خليني اقولك ان فيه طريقه اسمها Horizontal Scaling و دي اشبه للـ load balancer كدا. انك كل ما تحتاج مساحه تخزينيه اكتر هتزود سيرفرات
٥.١ الاول كنا معتمدين علي Single Server و كنا بنكتب و نقرا منه كل حاجه و بنبعت عليه كل الترافيك وده كان بيسبب مشاكل كتير و دايما السيرفر كان بيستخدم كل الـ resources.
٥.٢ لكن احنا اعتمدنا علي Horizontal Scaling لما كنا بنحتاج ٢٠ جيجا يوميا مع MongoDB لما كنا بنسجل ال analytics events. وكل ما حجم البيانات بيزيد. كل ما السيرفرات كانت بتزيد. و طبعا مع auto scale rules تقدر تخلي الموضوع اوتوماتيك و تريح نفسك من الصداع
٦ - CQRS: من الحاجات المهمه هي انك تتحكم في كيفية تسجيل البيانات. ومنها تقدر تتحكم في الترافيك علي قاعدة البيانات علشان تسجل البيانات دي. ف بدل من ارسال كل الevents في نفس الوقت وممكن تفقدها في حاله حدوث اي خطا. ممكن تخزنها في مكان مجرد object وبعدين ننقلها لقاعدة البيانات
٦.١ الخطا اللي عملناه اننا كنا بنبعت الريكوست لقاعدة البيانات علي طول علي امل ان قاعدة البيانات هتقدر تتعامل مع الترافيك ده ولكن اكتشفنا ان كل حاجه بتنهار مهما زودنا حجم السيرفر ومع اي خطا بنفقد الريكوست ده وده بروداكشن يخسرنا فلوس :)
٦.٢ الحل الامثل وقتها اننا استخدمنا Redis as a message broker. ف الكود بيتكلم مع redis فقط اثناء تسجيل الevents. وبعد ذلك x workers بيشتغلوا علشان يسجلوا البيانات دي في قاعدة البيانات. وفي حاله حدوث اخطاء بنقدر نرجع لـ Redis علشان نحاول نسجلهم مره تانيه بعد ما صلحنا الخطآ
٦.٣ ومن الميزه اننا بنقدر نتحكم في الترافيك اللي بنخزن بيه البيانات. ف ممكن في وقت الذروه نزود عدد الworkers ل 5 و باقي اليوم والاوقات يكونو 2 بس. وده بيخفض التكلفه جداً
٧ - Backup: من اهم الحاجات في اي سيتسم انه يكون فيه backup بشكل دوري سواء كل ساعه او كل يوم المهم انه يكون دايما فيه backup من البيانات وهنا كنا بنستخدم mysql-dump كل يوم الساعه ٣ الفجر لان الترافيك وقتها كان اقل ٢٠٠ في الدقيقه.
٨ - Availability: من المهم جدا ان السيرفرات يكون مكانها قريب من مكان المستخدمين. ف مثلاً لو انت بتخدم عملاء امريكا لازم يكون السيرفرات بتاعتك في امريكا او قريبه منهم. ولو انت ف مصر والشرق الاوسط لازم يكون في فرنسا او لندن علشان الresponse يكون اسرع ما يكون
٨.١ من الاخطاء اللي عملناها لما نقلنا علي AWS هي اننا استخدمنا US Zone وده كان عامل 200ms delay نظرا لان كل الزيارات كانت بتسافر لامريكا و ترجع تاني. ولما نقلنا ل London و Frankfurt الdelay قل ل 20ms تقريباً
٩. هكتفي بهذا القدر في الثريد ده و اكيد ان شاء الله هيكون فيه ثريدز تانيه نتكلم فيها بالتفصيل عن كل نقطة منهم و الاخطاء اللي حصلت و عالجناها ازاي و اتعلمنا ايه. لو الكلام ده كان مفيد ليك يا ريت تعمل ريتويت علشان يوصل لناس اكتر فضلا لا امرا :)
@botros__fadi الحل البديل من وجهه نظري هو event stream و كل action يحصل علي اي كامبين يسمع في كل الخدمات اللي بتحتاج بيانات الكامبين و منها تقدر تعدل في الكامبينز اللي تتعرض واللي تتلغي.
لكن فكره كل سيرفر من نفس الابلكيشن يعمل الكاش بنفسه مش عارف ليه تكون مفيده و احسن !
لكن فكره كل سيرفر من نفس الابلكيشن يعمل الكاش بنفسه مش عارف ليه تكون مفيده و احسن !
جاري تحميل الاقتراحات...