الان مقیاس بندی کنیم یا بعداً (Scale Now or Scale Later)
نکات کلیدی
-
مقیاسپذیر کردن یک سیستم، مسئلهای سخت برای حل کردن است. کمسرمایهگذاری روی مقیاسپذیری باعث کوتاهشدن عمر سیستم میشود، اما سرمایهگذاری بیش از حد میتواند توجیه تجاری MVP را بهخاطر هزینه از بین ببرد.
-
تیمها اغلب در مورد نیازهای مقیاسپذیری حدس میزنند، چون حامیان تجاری بهسختی میتوانند رشد استفاده از سیستم را در آینده تصور کنند.
-
واقعاً الزامهای مقیاسپذیری وجود دارند، فقط دیدن آنها سخت است. هر سیستم یک توجیه تجاری دارد و آن توجیه تجاری، الزامهای ضمنی مقیاسپذیری در خود پنهان کرده است.
-
رسیدن به مقیاسپذیری با هزینه قابلقبول، شامل موازنههای ظریف است. اغلب مشکلات مقیاس، حاصل یک گلوگاه حیاتی در سیستم هستند که معمولاً بهخاطر دسترسی به یک منبع مشترک ایجاد میشود.
-
آزمون و خطای معماری (Architectural experimentation) یک پادزهر خوب در برابر بیشساختن (Overbuilding) برای مقیاسپذیری است.
مقدمه
هر محصول حداقلی (MVP) یک فرضیه ضمنی درباره مقیاسپذیری در دل خود پنهان دارد. محصول یک توجیه تجاری دارد که تقریباً همیشه (اگر نگوییم همیشه) برای موفقیت خود به درجهای از مقیاسپذیری وابسته است. در دنیای امروز، هر ایده تجاری موفق باید به تعداد زیادی از افراد برسد تا به اهداف مالی خود دست پیدا کند. در نتیجه، هر سیستم نرمافزاری یک نگرانی حیاتی درباره مقیاسپذیری دارد. مهم نیست یک ایده چقدر خوب باشد، اگر نتواند به تعداد زیادی از افراد سرویس بدهد. بنابراین، جالبترین و شاید سختترین تصمیمهای معماری، تصمیمهایی هستند که به مقیاسپذیری مربوط میشوند.
«Scalability (مقیاسپذیری) گاهی با Performance (کارایی/عملکرد) اشتباه گرفته میشود؛ در حالی که بر خلاف مقیاسپذیری، کارایی درباره توانایی سیستم نرمافزاری برای برآورده کردن الزامهای زمانی آن است و تست کردن آن نسبت به مقیاسپذیری آسانتر است. اگر کارایی سیستم در نسخه اولیه کافی باشد، تیم ممکن است فرض کند که سیستم قادر خواهد بود با بارهای کاری بیشتر در آینده کنار بیاید. متأسفانه، اگر مقیاسپذیری در زمان طراحی معماری به عنوان یکی از QARهای اصلی (Quality Attribute Requirements) در نظر گرفته نشده باشد، بهندرت این فرض درست از آب درمیآید.»
حداقل الزام مقیاسپذیری برای یک سیستم، سطح استفادهای است که برای برآوردهشدن توجیه تجاری لازم است. مقادیر بیشتر شاید جذاب باشند، اما اگر توجیه تجاری محقق نشود، ساختن سیستم اصلاً ارزش ندارد. بنابراین، تیم توسعه باید معماری سیستم خود را ارزیابی کند تا مطمئن شود این سطح حداقلی قابل دستیابی است.
یک تیم عاقل اطمینان حاصل میکند که ظرفیت کافی برای پیشبینی رشد آتی استفاده دارد، بدون این که آنقدر بیشازحد سرمایهگذاری کند که بودجه ابتکار عمل خود را رد کند یا از آن فراتر برود. تصمیمگیری درباره این که چقدر رشد باید پیشبینی شود، هنر معماری است، اما نیازمند در نظر گرفتن اندازه بازار و پتانسیل رشد برای راهحلی است که سیستم از آن پشتیبانی میکند.
تیمها اغلب درباره نیازهای مقیاسپذیری حدس میزنند
تیمها معمولاً الزامهای مشخص و دقیقی درباره مقیاسپذیری ندارند. کسبوکار ممکن است منبع قابل اتکایی برای این اطلاعات نباشد، اما همانطور که بالاتر اشاره کردیم، یک توجیه تجاری دارد که نیازهای ضمنی مقیاسپذیری در خود دارد. برای تیمها آسان است که در مراحل اولیه روی نیازهای عملکردی تمرکز کنند و این الزامهای ضمنی مقیاس را نادیده بگیرند. آنها ممکن است امیدوار باشند که مقیاسپذیری مشکلساز نشود یا بتوانند با پرتاب منابع محاسباتی بیشتر به سمت مسئله، مشکل را حل کنند. نگرانی آنها درباره بیشساختن و افزایش هزینهها مشروع است، اما امیدوار بودن به این که مشکل مقیاسپذیری پیش نمیآید، استراتژی خوبی برای مقیاسپذیری نیست. تیمها باید از همان ابتدا مقیاسپذیری را در نظر بگیرند.
«[The MVA] از یک مجموعه حداقلی از تصمیمهای فنی تشکیل شده که با استفاده از تجربهگرایی در طول زمان تست و تکامل داده میشوند. این تصمیمها با یک مجموعه حداقلی از رویههای معماری تکمیل میشوند که به تیم کمک میکنند محصول را در حین توسعه، از نظر معماری، قابل دوام نگه دارد.»
بازخورد مشتری اغلب تنها منبع قابل اعتماد اطلاعات درباره قابلیت زیست MVP است، اما نمیتوان این بازخورد را جمعآوری کرد تا زمانی که چیزی ساخته شود، و آن چیز ممکن است مقیاسپذیر نباشد. در نتیجه، معماری برای مقیاسپذیری باید فرآیندی تکرارشونده و آزمایشمحور (Experiment-driven) باشد. متأسفانه، تیمهای توسعه گاهی در مراحل اولیه نسبت به تمرکز روی مقیاسپذیری مقاومت نشان میدهند، چون میخواهند ابتدا ببینند MVP موفق میشود یا نه، و بعد نگران این بشوند که آیا راهحل آنها مقیاس میگیرد یا نه. این طرز فکر، تا حدی منطقی است، اما مشکل اینجاست که خود MVP برای این که موفق شود باید مقیاسپذیر باشد.
رسیدن به مقیاسپذیری با هزینه قابل قبول، شامل موازنههای ظریف است
عدم قطعیت درباره نیازهای مقیاسپذیری یک دوراهی ایجاد میکند: اگر راهحل شما به اندازه کافی مقیاسپذیر نباشد، در بازار (یا نزد کاربران) شکست میخورد؛ اما اگر راهحلی بسازید که بیش از نیازتان مقیاسپذیر باشد و روی مقیاسپذیری بیشازحد سرمایهگذاری کنید، ممکن است از نظر مالی شکست بخورید.
تیمها اغلب نیاز محصول خود به مقیاسپذیری را دستکم میگیرند، مثلاً:
-
آنها میتوانند نسبت به این که سیستمشان چقدر خوب مقیاس میگیرد بیش از حد خوشبین باشند، چون فرضیات خود را تست نمیکنند.
-
فرض میکنند تکنولوژی (مثلاً Cloud) هر مشکلی را که با آن روبهرو شوند حل میکند. این بهندرت درست است، چون موانع مقیاسپذیری معمولاً ناشی از تصمیمهایی هستند که گلوگاه ایجاد میکنند، نه صرفاً «موتور کافی بزرگ یا کافی سریع نیست».
-
آنها آنقدر نگران این هستند که نسخه اولیه محصول را به دست مشتریان برسانند که مقیاسپذیری را یک «خوب است داشته باشیم» (Nice-to-have) و یک فکرِ بعد از انجام کار میبینند.
با این حال، بیشسرمایهگذاری روی مقیاسپذیری نیز یک مشکل است، چون میتواند منجر به اضافههزینه و تأخیر در زمانبندی، و همچنین کد متورم و کمکارا شود. به عبارت دیگر، مقیاسپذیری ناکافی میتواند MVP را ناکام کند، اما سرمایهگذاری بیشازحد ممکن است خیلی زود بیشسرمایهگذاری باشد و منابع محدود مالی را برای حل مسئلهای مصرف کند که هنوز (و شاید هرگز) به آن نرسیدهاید. بیشسرمایهگذاری حتی ممکن است باعث لغو پروژه به دلیل «شوک قیمتی» (Sticker shock) شود، بنابراین تیمها ممکن است احساس راحتی بیشتری در این داشته باشند که در سمت دستکم گرفتن خطر کنند تا سمت بیشبرآورد کردن.
الزامهای مقیاسپذیری واقعاً وجود دارند، فقط دیدنشان سخت است
MVP اغلب الزامهای ضمنی مقیاسپذیری دارد، مثل این جمله که: «برای این که این ایده موفق شود، باید ده هزار مشتری جدید جذب کنیم.» پرسیدن سوالهای درست و ورود به گفتوگوی مشارکتی، اغلب میتواند این الزامها را آشکار کند. این موارد غالباً به معیارهای موفقیت برای آزمایش MVP مرتبط هستند.
برای مثال، توجیه تجاری را در نظر بگیرید: برای دریافت بودجه برای یک ایده، حامیان تجاری غالباً فرضیاتی درباره پذیرش دارند. حداقل فرضیاتی که باید برآورده شوند تا توجیه تجاری «موفق» تلقی شود، حداقل الزامهای مقیاسپذیری برای سیستم را نشان میدهند. این فرضیات ممکن است برای گرفتن تأیید توجیه تجاری خوشبینانه تنظیم شده باشند و هنوز لازم باشد از طریق آزمایشهای MVP اعتبارسنجی شوند، اما نقطه شروعی برای در نظر گرفتن موازنههای معماری فراهم میکنند.
گاهی مقیاسپذیریای که توجیه تجاری فرض میکند، با هزینه قابل قبول (یا با هزینهای که در توجیه تجاری ذکر شده) قابل دستیابی نیست. کشف سریع این موضوع ارزشمند است، چون میتواند منجر به این شود که یک ایده بد زودتر لغو شود تا منابع مالی آزاد شوند و روی ایدههای باارزشتر صرف شوند. در نتیجه، تیمها باید آزمایشهای اولیهای اجرا کنند تا تست کنند آیا این مقیاسپذیری فرضشده قابل دستیابی است یا نه.
موازنههایی که میتوانند باعث مشکلات مقیاسپذیری شوند
اغلب مشکلات مقیاس از یک گلوگاه حیاتی در سیستم ناشی میشوند که معمولاً به خاطر دسترسی به یک منبع مشترک ایجاد شده است. برخی از مهمترین مسائلی که ما با آنها روبهرو شدهایم («تجربه شما ممکن است متفاوت باشد / YMMV») شامل موارد زیر است:
-
دقیقاً مثل املاک، موقعیت مهم است. درک اثر توزیعکردن پردازشها و دادهها به تیمها کمک میکند تصمیمهای مقیاسپذیری بهتری بگیرند، بدون این که بیش از حد روی قابلیتهایی سرمایهگذاری کنند که هنوز به آنها نیاز ندارند.
-
دسترسی مدیریتنشده به منابع مشترک، که گاهی تا حد یک تولیدکننده شماره ترتیبی ساده (Sequence Number Generator)، که از تولید شماره سفارش گرفته تا شماره مشتری و شماره محصول استفاده میشود. منابع مشترک شامل انواع دیگری از سرویسهای مشترک هستند که توسط بسیاری از اپلیکیشنها استفاده میشوند، مثل سرویسهای ایمیل، تولیدکنندههای توکن امنیتی، سرویسهای رمزنگاری، سرویسهای Cache و حتی سرویسهایی که با اجزای هوش مصنوعی مثل LLMها در تعاملاند. چالشهای طراحی مرتبط با دسترسی به منابع مشترک شامل مدیریت Lock و کنترل همزمانی (Concurrency Control) میشوند.
-
تصمیمگیری برای استفاده از یک فریمورک یا پکیج (بهویژه Open-Source) که تصمیمهای زیرساختی مرتبط با منابع مشترک را پنهان میکند: همانطور که در یک مقاله قبلی اشاره کردیم، فریمورکها و پکیجها بهرهوری تیم را به شدت افزایش میدهند، اما خود فریمورک/پکیج اغلب گلوگاههای مقیاسپذیری ناشناخته یا کمتر درکشدهای دارد. در غیاب این اطلاعات، تیمها باید آزمایشهایی انجام دهند تا کشف کنند فریمورک/پکیج در چه نقطهای و تحت چه باری از کارایی میافتد.
-
واگذاری حل مسائل بالقوه مقیاسپذیری به فروشنده Cloud. دوراهی مقیاسپذیری Cloud: اگر اپلیکیشن شما از ابتدا مقیاسپذیر نباشد، هیچ مقدار «تکنولوژی Cloud» نمیتواند آن مشکل را حل کند. برای لحظهای فکر کنید «Cloud» چیست. این فقط یک راه آسان برای تأمین محیطهای محاسباتی مجازی است. این که اپلیکیشن شما بتواند از چند محیط برای مقیاسپذیری استفاده کند، به تصمیمهایی که تیم توسعه اتخاذ میکند بستگی دارد. اگر گلوگاههای حیاتی در طراحی وجود داشته باشد، یک محیط بینهایت مقیاسپذیر هم کمکی نخواهد کرد. علاوه بر این، اتکای بیشازحد به راهحلهای «آماده» (Canned Solutions) ارائهشده توسط فروشنده Cloud، مثل ماشینهای مجازی، Containerها و Serverless Functions ممکن است این توهم را به تیم بدهد که MVA (معماری حداقلی قابل قبول) آنها در آینده قادر خواهد بود بهقدر کافی مقیاس بگیرد، حتی اگر طراحی ضعیفی برای این کار داشته باشد.
در سطحی بنیادیتر، این سوال مطرح است که آیا «انتقال به Cloud» یک تصمیم معماری است؟ شاید؛ اما اگر اپلیکیشن تغییر نکند تا از قابلیتهای منحصربهفرد Cloud استفاده کند، و اگر تصمیم شما برای حل یک مسئله معماری اتخاذ نشده باشد، آنوقت این تصمیم، تصمیم معماری نیست؛ فقط یک راه راحتتر برای میزبانی سیستم است.
استراتژیهای نامناسب پردازش همزمان (Synchronous) و ناهمزمان (Asynchronous)
برخی افراد ارتباط ناهمزمان (Asynchronous Communication) را یک نوشداروی دیگر برای مقیاسپذیری میبینند، چون اجازه میدهد کار مستقل از تسکی که آن را آغاز کرده، ادامه پیدا کند. منطق این است که تسک اصلی میتواند کارهای دیگری انجام دهد، در حالی که کار در پسزمینه در حال انجام است.
تا زمانی که تسک آغازگر، در نقطهای برای ادامه کار، نیاز به نتایج تسک ناهمزمان نداشته باشد (یک مثال ساده، ارسال یک Job به چاپگر یا ثبت (Logging) یک رویداد است)، پردازش ناهمزمان میتواند به مقیاسپذیری سیستم کمک کند. اما ممکن است مسئلهای در توالی ایجاد شود. اگر تسک آغازگر برای ادامه کار نیاز داشته باشد پاسخی از تسک ناهمزمان دریافت کند، ممکن است در انتظار بماند. اگر تسک آغازگر به تعداد زیادی تسک ناهمزمان متکی باشد، ممکن است مجبور شود نتایج خود را به ترتیبی خاص تجمیع کند. تأخیر در تسکهای ناهمزمان میتواند به راحتی سرعت سیستم را آنقدر کم کند که عملاً بخزد.
استفاده افراطی از LLMها یا سازندههای اپلیکیشن «بدونکدنویسی» برای توسعه MVP
استفاده از LLMها یا سازندههای اپلیکیشن No-Code میتواند سرعت ساخت (یعنی کدنویسی) MVP را افزایش دهد. با این حال، در این رویکرد ریسکهایی وجود دارد. همانطور که Mirza Masfiqur Rahman و Ashish Kundu در «Code Hallucination» اشاره کردهاند:
«مدلهای مولد مثل مدلهای زبانی بزرگ (LLMها) به طور گسترده به عنوان Copilotهای کد و برای تولید برنامه کامل استفاده میشوند. با این حال، برنامههایی که تولید میکنند اغلب از نظر صحت، اصالت و قابلیت اطمینان در سطح یکپارچگی محل تردید هستند، چون ممکن است از نیازهای کاربر تبعیت نکنند، خروجیهای غلط و/یا بیمعنی ارائه دهند، یا حتی شامل خطاهای معنایی/نحوی باشند؛ چیزی که در مجموع به عنوان «توهم LLM» (LLM Hallucination) شناخته میشود.»
آیا تیم به طور کامل موازنههایی را که به صورت ضمنی انجام داده، و این که این موازنهها چگونه ممکن است روی مقیاسپذیری اثر بگذارند، درک میکند؟ آیا مهارتهای فنی آنها در طول زمان با واگذاری کارهای کدنویسی MVP به یک LLM یا یک App Builder بدونکد بدتر نخواهد شد؟
جمعبندی
در نقطهای که در حال گرفتن تصمیمی هستید که ممکن است بر مقیاسپذیری MVA شما تأثیر بگذارد، باید تصمیم بگیرید که آیا لازم است همین حالا آن مسئله را حل کنید یا میتواند منتظر بماند. اگر میزان کار اضافه (Rework) برای تغییر تصمیم مربوط به مقیاسپذیری در آینده «خیلی» زیاد باشد، باید مسئله را همین حالا حل کنید؛ در غیر این صورت باید تصمیم «بهاندازه کافی خوب» خود را مستند کنید، همراه با یادداشتی که میگوید در صورت نیاز، گزینه این را دارید که بعداً تصمیم دیگری درباره مقیاسپذیری بگیرید. به بیان دیگر، شما عمداً بدهی فنی ایجاد میکنید که ممکن است مجبور شوید در آینده آن را بازپرداخت کنید یا نه.
مقیاسپذیر کردن یک سیستم، مسئلهای سخت برای حل کردن است. کمسرمایهگذاری روی مقیاسپذیری، عمر سیستم را کوتاه میکند؛ اما بیشسرمایهگذاری میتواند توجیه تجاری MVP را به خاطر هزینه نابود کند. فکر کردن به مقیاسپذیری به صورت «گزینهها» مهم است؛ تا زمانی که میتوانید مسئله را بعداً بدون تغییر معماری حل کنید، میتوانید تصمیم را به تعویق بیندازید، در غیر این صورت باید همین حالا آن را حل کنید.
آزمون و خطای معماری (Architectural Experimentation) یک پادزهر خوب در برابر بیشساختن برای مقیاسپذیری است. لازم نیست سطح مقیاسپذیریِ موردنیاز را قبل از زمانی که واقعاً به آن احتیاج دارید بسازید، به شرطی که مطمئن باشید میتوانید سیستم را با هزینهای قابل پیشبینی تطبیق دهید تا هر وقت نیاز داشتید، مقیاسپذیری را افزایش دهید. اگر آزمایشهای شما نشان دهد که میتوان تصمیم مقیاسپذیری را به زمانی بعد موکول کرد، در آن صورت سرمایهگذاری روی مقیاسپذیری در حال حاضر نه ضروری است و نه مطلوب.
