برنامه‌های "cloud-native" - قسمت اول Scalability

در این پست و چند پست آینده در مورد برنامه‌های “cloud-native” خواهم نوشت.

مقدمه

هنگامی که نرم‌افزار شما به منابع بیشتری نسبت به چیزی که در اختیار دارد نیاز داشته باشد، تاثیر بدی در تجربه‌ی کاربری خواهد گذاشت. دو روش برای بیشتر کردن منابع ِ مورد نیاز یک برنامه وجود دارد:

· روش افقی یا Horizontal.

· روش عمودی یا Vertical.

روش عمودی آسان‌تر است اما محدودیت‌های خاص خودش را دارد. روش افقی با اینکه پیچیده‌تر است، ولی می‌تواند منابع شما را نسبت به روش عمودی بسیار بیشتر گسترش دهد. راهکار “cloud-native” برای بیشتر کردن منابع، روش افقی یا “Horizontal scaling” است.

مفهوم Scalability به چه معناست؟

مفهوم scalability را شاید بتوان به این ترتیب تعریف کرد که scalability یک نرم‌افزار، مقیاسِ تعداد کاربرانی است که می‌تواند به صورت همزمان پشتیبانی کند. آن نقطه‌ای که نرم‌افزار دیگر نتواند کاربران اضافه‌تری را پشتیبانی کند، محدوده‌ی scalability آن نرم‌افزار است. scalability زمانی به حد آستانه می‌رسد که یکی از منابع سخت‌افزاری حیاتیِ نرم‌افزار تمام شود. بنابراین، در برخی اوقات می‌توان با تامین سخت‌افزار اضافه این حد آستانه را توسعه داد. منابع سخت‌افزاری که معمولا توسط یک نرم‌افزار مورد نیاز هستند عبارتند از CPU، حافظه‌، دیسک و پهنای‌باند شبکه. اما تنها هنگامی می‌توان یک نرم‌افزار را با تامین سخت‌افزار اضافه scale کرد، که نرم‌افزار بتواند به صورت کارامد از این سخت‌افزار استفاده کند. حالتِ اضافه شدنِ سخت‌افزارِ بیشتر به سیستم، روش scale شدن نرم‌افزار را معین می‌کند:

• روش عمودی: ظرفیت سخت‌افزاری که نرم‌افزار روی آن قرار دارد افزایش پیدا می‌کند.
• روش افقی: ظرفیت با اضافه شدن سخت‌افزار (یا نودهای دیگری) به سیستم افزایش پیدا می‌کند.

هر ترکیبی از این دو روش (۴ ترکیب مختلف) در نرم‌افزارهای متفاوت ممکن است قابل پیاده‌سازی باشد.

به عنوان مثال، اگر بخواهیم ظرفیت جاده‌ی تهران-شمال را افزایش دهیم، دو راه داریم:

• افزایش کیفیت راه‌ها، مثلا تبدیل جاده‌های خاکی مسیر به آسفالت. در این حالت سرعت حرکت ماشین‌ها بیشتر خواهد شد – روش عمودی.
• افزایش تعداد جاده‌ها یا عریض‌تر کردن آنها. در این حالت ماشین‌های بیشتری می‌توانند به صورت همزمان حرکت کنند – روش افقی.

روش عمودی

به روش عمودی یا “Vertical scaling”، “Scaling up” نیز گفته می‌شود. ایده‌ی اصلی در اینجا افزایش دادن ظرفیت نودها با بهتر کردن سخت‌افزار آن‌هاست. این امر ممکن است افرایش دادن حافظه‌ی RAM، بیشتر کردن تعداد هسته‌های CPU، افزایش پهنای‌باند یا هر روش دیگری باشد که می‌توان روی یک نود اعمال کرد.

به صورت سنتی این روش بنا به دلایل زیر، معمول‌ترین راه برای scaling بوده است:

• پیاده‌سازی آسان.
• ریسک کمتر.
• ارزان‌تر بودن سخت‌افزار اضافه نسبت به بهبودهای الگوریتمیک.

اما این روش چند محدویت اساسی دارد:

• هیچ تضمینی وجود ندارد که بتوانیم سخت‌افزار مورد نیاز را برای نودها تامین کنیم.
• حتا اگر بتوانیم سخت‌افزار مورد نیاز را تامین کنیم، هیچ تضمینی وجود ندارد که نرم‌افزار بتواند از تمام آن استفاده کند.
• چون بحث ارتقای سخت‌افزار مطرح است، این روش معمولا منجر به “downtime” خواهد شد.

روش افقی

روش افقی یا “Horizontal scaling” که به آن “Scaling out” هم گفته می‌شود، با اضافه کردن نودهای کامل جدید به سیستم باعث افزایش ظرفیت نرم‌افزار می‌شود. معمولا، هر نود یک مقدار مساوی (مثلا یک مقدار مشخص حافظه یا CPU) به ظرفیت سیستم خواهد افزود.

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

توصیف Scalability

معمولا تعریفی که از مقیاس‌پذیری یک برنامه ارائه می‌شود، تعداد کاربرانی است که همزمان می‌توانند از آن استفاده کنند. برای مثال: این برنامه می‌تواند ۱۰۰ کاربر همزمان را پشتیبانی کند.

اما یک تعریف بهتر می‌تواند هم شامل تعداد کاربران همزمان، و هم مدت زمان پاسخ‌دهی باشد. مدت زمان پاسخ‌دهی یا “Response time” به مدت زمانی گفته می‌شود که کاربر درخواست را ارسال می‌کند، تا زمانی که پاسخ را دریافت کند. برای مثال: با ۱۰۰ کاربر همزمان مدت زمان پاسخ‌دهی در ۶۰ درصد مواقع زیر ۲ ثانیه، در ۳۸ درصد مواقع بین ۲ تا ۵ ثانیه، و در ۲ در مواقع بیشتر از ۵ ثانیه است.

برنامه‌های “Cloud-Native”

ویژگی‌های زیر که مربوط به پلتفورم‌های cloud است، امکان ایجاد برنامه‌های “cloud-native” را فراهم می‌کند:

• تعداد نامتناهی (به صورت عملی) از منابع با ظرفیت محدود. scaling در کلود به صورت افقی است.
• اجاره‌ی منابع به صورت کوتاه-مدت. اضافه یا حذف کردن منابع با سرعت بالا و به راحتی قابل انجام است.
• پرداخت هزینه‌ها با مدل “pay-as-you-go”، فقط به همان مقدار که مصرف کرده‌اید هزینه پرداخت می‌کنید.
• اضافه و حذف کردن منابع به صورت “selft-service”، “on-demand”، و “programmatic”، یعنی این فرآیند می‌تواند خودکار باشد.
• سرویس‌ها معمولا به صورت اشتراکی (multitenant) روی سخت‌افزارهای معمولی اجرا می‌شوند. برنامه‌های کلود برای هزینه‌ی کم بهینه شده‌اند نه قابلیت اعتماد. بنابراین به صورت روتین “failure” رخ می‌دهد، اما به ندرت منجر به “downtime” می‌شود.
• تعداد زیادی “Managed service” وجود دارد، یعنی این سرویس‌ها توسط کلود نگهداری می‌شوند، که در نتیجه‌ی آن توسعه‌ی برنامه‌های مبتنی بر کلود آسان‌تر خواهد شد.

تمام Cloud providerهای معروف مانند AWS یا Azure این ویژگی‌ها را دارند. بنابراین یک برنامه‌ی “cloud-native” به گونه‌ای طراحی می‌شود که بتواند از محیط‌های کلود بهترین استفاده را بکند. به این ترتیب، انتظار می‌رود یک برنامه‌ی “cloud-native” دارای ویژگی‌های زیر باشد:

• استفاده از محیط‌های ابری برای بهره‌مندی از زیرساختی scalable و reliable. یعنی نگهداری از زیرساخت توسط پلتفورم ابری انجام می‌شود.
• استفاده از ارتباط‌‌های “non-blocking asynchronous” و معماری‌ “loosely-coupled”.
• قابلیت scale شدن به صورت افقی.
• قابلیت scale شدن به گونه‌ای که تجربه‌ی کاربر متاثر نشود، و downtime رخ ندهد.
• قابلیت حل مشکلات و به طور کلی failureها به گونه‌ای که تجربه‌ی کاربری متاثر نشود.
• کنترل کردن failure در سطح نودها به گونه‌ای که downtime رخ ندهد.
• استفاده از نقاط جغرافیایی مختلف برای به حداقل رسانیدن تاخیر شبکه یا latency.
• توانایی upgrade شدن بدون downtime.
• توانایی scale شدن به صورت active یا proactive در شرایط مختلف و در برابر تغییرات.
• مانیتورینگ مستمر لاگ‌ها حتا هنگامی که نودها اضافه یا کم می‌شوند.

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

در بخش‌های بعدی، به هر کدام از موارد بیشتر خواهیم پرداخت.

لینک قسمت دوم: