توسعه دهنده نرم افزار
Scalability and Costs
بیایید با یه مثال ساده فرضی رابطهی بین مقیاسپذیری و هزینه رو بررسی کنیم. فرض کنید یه سیستم مبتنی بر وب داریم که میتونه از پس ۱۰۰ درخواست همزمان با میانگین زمان پاسخ ۱ ثانیه بربیاد. حالا یه نیازمندی کسبوکاری داریم که این سیستم رو برای هندل کردن ۱۰۰۰ درخواست همزمان با همون زمان پاسخ، ارتقا بدیم. بدون هیچ تغییری، یه تست بار ساده روی این سیستم نشون میده که عملکردش مثل شکل زیر میشه. همزمان با افزایش بار درخواست، میبینیم که میانگین زمان پاسخ به طور پیوسته تا ۱۰ ثانیه با بار پیشبینیشده بالا میره. واضحه که این وضعیت تو پیکربندی استقرار فعلی، نیازمندیهای ما رو برآورده نمیکنه. سیستم به خوبی مقیاسپذیر نیست.
البته برای رسیدن به عملکرد مورد نیاز، یه سری تلاش مهندسی لازم داریم شکل زیر عملکرد سیستم رو بعد از این تغییرات نشون میده. حالا با ۱۰۰۰ درخواست همزمان، زمان پاسخ دهی مطلوب رو داره. پس موفق شدیم سیستم رو مقیاس کنیم. هورااا! ولی یه سوال مهم باقی میمونه. چقدر تلاش و منابع برای رسیدن به این عملکرد لازم بوده؟ شاید فقط لازم بوده سرور وب رو روی یه ماشین مجازی (یا فیزیکی) قویتر اجرا کنیم. این کار تو یه کلود نهایتا نیم ساعت طول میکشه. یه راه دیگه، پیکر بندی مجدد سیستم برای اجرای چندتا instance از سرور وب برای افزایش ظرفیتشه. اینم باید یه تغییر پیکربندی ساده و کمهزینه برای اپلیکیشن باشه، بدون نیاز به تغییر کد. اینا سناریوهای ایدهآلی هستن.
ولی خب، مقیاسپذیر کردن یه سیستم همیشه به این سادگی نیست. دلایل زیادی داره و ممکنه با هم فرق داشته باشن، اما بذار چندتا حالت رو بررسی کنیم:
- با ۱۰۰۰ تا درخواست در ثانیه، دیتابیس کند میشه و لازمه ارتقا پیدا کنه به یه ماشین جدید لازمه ارتقا پیدا کنه
- سرور وب خیلی از محتوا رو به صورت پویا تولید میکنه و این باعث کاهش زمان پاسخ تحت بار میشه. یه راه حل احتمالی، تغییر کد برای تولید محتوا با کارایی بیشتره که باعث کاهش زمان پردازش برای هر درخواست میشه.
- بار درخواست، نقاط (hotspots) تو دیتابیس ایجاد میکنه، زمانی که درخواستهای زیادی به طور همزمان سعی میکنن به رکوردهای مشابه دسترسی پیدا کنن و اونارو آپدیت کنن. این نیازمند یه بازطراحی اسکیما در دیتابیس، و همچنین تغییرات کد تو لایه دسترسی به دادههاست.
- فریمورک سرور وب که انتخاب شده، بیشتر روی راحتی توسعه به جای مقیاسپذیری تمرکز داشته. مدلی که اجرا میکنه یعنی کد به سادگی نمیتونه برای رسیدن به نیازمندیهای بار درخواستی، مقیاس بشه و نیاز به یه بازنویسی کامل داره.
حالا فرض کنیم گزینه (۱)، ارتقای سرور دیتابیس، به ۱۵ ساعت کار و ماهیانه هزار دلار هزینه اضافی کلود برای یه سرور قویتر نیاز داشته باشه. این خیلی گرون در نمیاد.
فرض کنیم گزینه (۴)، یه بازنویسی کامل لایه وب اپلیکیشن، به خاطر پیادهسازی یه زبان جدید (مثلا جاوا به جای Ruby) به ۱۰ هزار ساعت توسعه نیاز داشته باشه.
گزینههای (۲) و (۳) یه جایی بین گزینههای (۱) و (۴) قرار میگیرن. هزینه ۱۰ هزار ساعت توسعه، واقعا قابل توجهه.تا زمانی که توسعه در حال انجامه، ممکنه اپلیکیشن به خاطر اینکه نمیتونه بار درخواستهای مشتری رو تامین کنه، در حال از دست دادن سهم بازار و در نتیجه پول باشه. اینجور موقعیتها میتونن باعث شکست سیستمها و کسبوکارها بشن. این سناریوی ساده نشون میده که چطور ابعاد هزینه منابع و تلاش، به طور جداییناپذیری به مقیاسپذیری وصل هستن. اگه یه سیستم ذاتا برای مقیاسپذیری طراحی نشده باشه، پس هزینهها و منابع بعدی برای افزایش ظرفیتش جهت برآورده کردن نیازمندیها، ممکنه خیلی زیاد باشن.
هیچ وقت انتظار نداریم کسی بخواد ظرفیت یه خونه حومهشهری رو برای تبدیل شدن به یه برج اداری ۵۰ طبقه بالا ببره. این خونه، نه از نظر معماری، نه مصالح و نه فونداسیون، هیچکدوم رو نداره که حتی بتونه به عنوان یک احتمال هم باشه، مگه اینکه کلش رو خراب کنیم و از نو بسازیم. به همین شکل، نباید انتظار داشته باشیم که سیستمهای نرمافزاری که از معماری، مکانیزمها و تکنولوژیهای مقیاسپذیر استفاده نمیکنن، بتونن به سرعت برای برآورده کردن نیازهای ظرفیت بالاتر، تغییر کنن. پایههای مقیاسپذیری لازمه که از همون اول ساخته بشه، با این درک که اجزا به مرور زمان تکامل پیدا میکنن. با به کار بردن اصول طراحی و توسعهای که باعث ارتقاء مقیاسپذیری میشن، میتونیم سیستمها رو با سرعت و هزینه کمتری برای پاسخ به تقاضای رو به رشد، ارتقا بدیم.
سیستمهای نرمافزاری که میتونن به صورت تصاعدی مقیاس بشن، در حالی که هزینهها به صورت خطی افزایش پیدا میکنن، به عنوان سیستمهای Hyper scalable شناخته میشن، سیستمهای Hyper scalable رشد تصاعدی در توان محاسباتی و ظرفیت ذخیرهسازی رو نشون میدن، در حالی که نرخ رشد خطی در هزینههای منابع مورد نیاز برای ساخت، اجرا، پشتیبانی و توسعه منابع نرمافزاری و سختافزاری مورد نیاز رو دارن.
مطلبی دیگر از این انتشارات
مدل های Communication در معماری میکروسرویس (قسمت اول)
مطلبی دیگر از این انتشارات
API Gateway به زبان ساده (قسمت آخر)
مطلبی دیگر از این انتشارات
مدل های Communication در معماری میکروسرویس (قسمت دوم)