Scalability Basic Design Principles

هدف اصلی از مقیاس کردن یه سیستم، افزایش ظرفیتش در یه بعد خاصه که بستگی به اون برنامه داره. یه بعد رایج، بالا بردن تعداد درخواست هایی هست که سیستم میتونه تو یه بازه زمانی مشخص پردازش کنه. به این توان عملیاتی یا Throughput سیستم میگن.

بذار با یه مثال دو تا اصل اساسی که برای مقیاس کردن سیستم ها و بالا بردن توان عملیاتی در دست داریم رو بررسی کنیم: تکثیر (Replication) و بهینه سازی (Optimization). سال ۱۹۳۲، یکی از عجایب مهندسی دنیا، پل بندرگاه سیدنی افتتاح شد. حالا فرض خیلی منطقی ایه که ترافیک تو سال ۲۰۲۱ خیلی بیشتر از ۱۹۳۲ باشه. تو ۳۰ سال اخیر تو ساعت شلوغی ظرفیت زیادی هر روز داره رد میشه. پس چطور میشه توان عملیاتی زیرساخت های فیزیکی مثل پل رو بالا برد؟ این موضوع تو دهه ۸۰ تو سیدنی خیلی مهم شد، وقتی که فهمیدن ظرفیت عبور از بندر باید بیشتر بشه. راه حل، تونل بندرگاه سیدنی بود که خب خیلی کمتر از پل معروفه، ولی تقریبا همون مسیر رو زیر آب دنبال میکنه. این تونل چهار تا خط ترافیک دیگه اضافه کرد و در نتیجه یه سوم به ظرفیت عبور از بندر اضافه کرد. تو اوکلند که خیلی هم دور نیست، پل بندر اونها هم مشکل ظرفیت داشت چون تو ۱۹۵۹ با فقط چهار خط ساخته شده بود. خلاصه اینکه، اونا هم تقریبا همون راه حل سیدنی رو برای افزایش ظرفیت انتخاب کردن. ولی بجای اینکه تونل بسازن، با یه نبوغ خاصی تعداد خط ها رو با اضافه کردن "گیره های نیپون" ( Nippon clip-ons) دو برابر کردن. این گیره ها باعث شدن عرض پل از دو طرف بیشتر بشه.

این مثال ها اولین استراتژی ای که برای افزایش ظرفیت تو سیستم های نرم افزاری داریم رو نشون میدن. ما اساسا منابع پردازش نرم افزار رو تکثیر می کنیم تا ظرفیت بیشتری برای مدیریت درخواست ها و در نتیجه بالا بردن توان عملیاتی داشته باشیم، همونطور که تو شکل زیر نشون داده شده، این منابع پردازش تکثیر شده مشابه خط های ترافیک رو پل ها هستن، که یه مسیر پردازش تقریبا مستقل برای جریان درخواست های ورودی فراهم می کنن. خوشبختانه تو سیستم های نرم افزاری ابری، تکثیر با یه کلیک روی ماوس قابل انجامه، و ما می تونیم به طور موثر منابع پردازش خودمون رو هزاران بار تکثیر کنیم. تو این زمینه خیلی راحت تر از پل سازها کارمون رو انجام میدیم. با این حال، باید دقت کنیم که منابع رو برای رفع گلوگاه های واقعی تکثیر کنیم. اضافه کردن ظرفیت به مسیرهای پردازشی که بیش از حد اشباع نیستن، هزینه های اضافی رو بدون اینکه فایده ای برای مقیاس پذیری داشته باشه تحمیل می کنه.

استراتژی دوم برای مقیاس پذیری رو هم میشه با مثال پل مون توضیح داد.

تو سیدنی، یه نفر باهوش فهمید که صبح ها خیلی بیشتر از جنوب به شمال از روی پل رد میشن، و بعد از ظهر این جریان برعکس میشه. پس یه راه حل خلاقانه در نظر گرفته شد - تو صبح، بیشتر خط ها رو به جهتی که تقاضای بیشتری داره اختصاص بدن، و بعد از ظهر این وضعیت رو برعکس کنن. این کار باعث شد تا ظرفیت پل به طور موثر بالا بره بدون اینکه منابع جدیدی اختصاص بدن - ما منابعی که قبلا داشتیم رو بهینه سازی کردیم.

ما می تونیم همین روش رو تو نرم افزار هم برای مقیاس کردن سیستم هامون دنبال کنیم. اگه بتونیم پردازش رو با استفاده از الگوریتم های کارآمدتر، اضافه کردن ایندکس های بیشتر به دیتابیس هامون برای سرعت بخشیدن به کوئری ها، یا حتی بازنویسی App server با یه زبان برنامه نویسی سریع تر بهینه سازی کنیم، می تونیم ظرفیتمون رو بدون اینکه منابعمون رو زیاد کنیم بالا ببریم. یه مثال خوب از این موضوع، ساخت HipHop برای PHP (که الان دیگه منسوخ شده) توسط فیسبوکه، که سرعت تولید صفحات وب فیسبوک رو تا شش برابر با کامپایل کردن کد PHP به C++ افزایش داد.

اتخاذ دو اصل طراحی - یعنی تکثیر و بهینه سازی - پیامدهای پیچیده زیادی داره، که از این واقعیت ناشی میشه که ما در حال ساختن سیستم های توزیع شده هستیم. سیستم های توزیع شده ویژگی هایی دارن که ساختن سیستم های مقیاس پذیر رو جالب میکنه، که تو این زمینه هم معنای مثبت و هم منفی داره.