چند وقت پیش درگیر پیاده سازی و اجرای MVP یک محصول استارتاپی دیجیتال بودیم که یکی از میکروسرویس‌‍‌های اون از نظر اجرا، نیاز به منابع زیرساختی نسبتا زیادی داشت. از اونجایی که بودجه محدودی برای زیرساخت این محصول در نظر گرفته بودیم، باید راهکاری انتخاب می‌کردیم تا ضمن پایین نگه داشتن هزینه‌های زیرساخت، بتونه محصول رو به حجم مشخص و محدودی از مشتریان اولیه تحویل بده.
در این نوشته می‌خوام شیوه‌ای که برای اجرا انتخاب کردیم و اعتقاد داریم از نظر هزینه برامون به صرفه بود رو توضیح بدم و با حالت‌های دیگه مقایسه کنم.
اما قبل از اون، بهتره که به صورت کلی تصویری از رفتار این سرویس و تاثیرش روی مصرف منابع بدم تا اصل قضیه کمی قابل درک‌تر باشه:
این سرویس وظیفه داره در طول جلسات مجازی کاربران (به عنوان مثال جلسات مجازی پلتفرم Zoom)، عملیاتی رو در طول برگزاری اون میتینگ انجام بده، میانگین زمان هر میتینگ رو هم می‌تونیم 45 دقیقه در نظر بگیریم. از طرفی منابع مورد نیاز برنامه به ازای هر میتینگ در حین برگزاری، چیزی حدود 1 هسته سی پی یو و 1 گیگابایت رم هست. همچنین احتمال همزمانی میتینگ‌ها کاملا وجود داره، ولی این همزمانی‌ها پراکندگی یکنواختی نداره و در یک لحظه ممکنه تعداد جلسات همزمان 10 تا و در زمان دیگه ای فقط یکی باشه.
مساله دقیقا همینجا بود. اینکه مثلا اگر سروری بگیریم که توان پاسخگویی همزمان به 15 کاربر رو داشته باشه، باید یک سرور مجازی با 16 هسته سی پی یو و 16 گیگ رم (که البته در کانفیگ‌ها معمولا 32 گیگ هستند) با قرارداد ماهانه و با قیمت حدودی 70 دلار اجاره می‌کردیم. با توجه به اینکه رسیدن به 10 یا حتی 15 میتینگ همزمان فقط در بعضی شرایط خاص ممکن بود رخ بده و 60 درصد مواقع نرخ میتینگ‌های در حال برگزاری عدد پایین‌تری بود، این حجم زیاد منابع بیهوده هدر می‌رفت.
گذشته از این، اگر حتی قرار بود 1 میتینگ دیگه به حجم ماکزیمم زیرساخت موجود اضافه بشه، امکانش وجود نداشت و مستلزم تهیه سرور دوم و اسکیل‌آپ کردن این مدلی زیرساخت بودیم و طبیعتا این هدر رفت منابع باز هم در سرور دوم تشدید می‌شد. بنابراین راه واقعا خوبی نبود.
کل سیستم‌ها روی داکر بودند و از قضا این قسمت سیستم که کارش مربوط به میتینگ‌ها می‌شد Stateless پیاده شده بود، طبیعتا یه گزینه مطرح این بود که روی سرویس‌های کلاود کانتینر Pay as you Go برای هر میتینگی یک اینستنس کانتینر با 1 هسته سی پی یو و 1 گیگ رم بسازیم و برنامه رو روش اجرا کنیم و بعد از اتمام میتینگ هم اون اینستنس رو از بین ببریم. اینطوری پول زیرساخت رو هم به ازای هر اینستنسی که می‌ساختیم به صورت ساعتی پرداخت می‌کردیم. از اون گذشته، امکان اسکیل آپ کردن سرویس تا حجم خیلی بالاتری هم در این روش وجود داشت و به راحتی می‌شد سقف تعداد میتینگ‌های همزمان رو هم گسترش داد.
این سرویس‌های کانتینر کلاود از اجاره سرور به صورت ماهانه قطعا گرون‌تر هستند. به عنوان نمونه، اینستنس 1 گیگابایت رم و 1 هسته سی پی یو با این مدل در AWS یا Azure درمیاد چیزی حدود 0.04 دلار به ازای هر ساعت. این روش نسبت به حالت قبلی خیلی گرون‌تره، اما حداقل برعکس روش اجاره سرور ماهانه، مشکل گسترش سقف میتینگ رو نداره.
بنابراین با توجه به دیتای فرضی مصرف سرویس ما، اگر قرار بود از روش کلاود کانتینر استفاده کنیم، هزینه ماهانه‌مون برابر می‌شد با عددی حدود 140 دلار که به نسبت حالت اجاره سرور 70 دلاری خیلی تفاوت داشت.
اما راه مطلوب برای این شرایط ما، استفاده ترکیبی (Hybrid) از این دو شیوه است. یعنی راهی که هم از قیمت پایین‌تر سرورهای قرارداد ماهانه استفاده کنیم و هم از توسعه پذیری کلاودها بهره‌مند بشیم ولی هزینه بالایی هم بابت اونها ندیم.
بنابراین ما باید یک کف ثابتی رو از ماکزیمم مورد نظر میتینگ‌های همزمان در هر فازی از کسب‌وکار رو مشخص کنیم که در اون کف ثابت، اتلاف منابع به حداقل برسه. یعنی مثلا در نمودار پیش‌بینی مصرف سرویس، یک تعدادی میتینگ همزمان رو درنظر بگیریم که بخش زیر این خط به نسبت فضای خالی کمی داشته باشه.
همونطور که مشخصه، بخش زیر خط نارنجی رنگ در تصویر بالا، فضای خالی به نسبت کمی داره و این یعنی اتلاف منابع در اون قسمت به حداقل می‌رسه.
در اینجا ما یک سروری با ظرفیت پشتیبانی از 7 میتینگ همزمان رو به صورت قرارداد ماهانه به عنوان زیرساخت ثابت و پایه اجاره می‌کنیم، و در کنارش اگر در زمان‌های خاصی نیاز به میتینگ‌های بالاتر از 7 داشتیم، این باقی‌مانده رو از سرویس‌های کلاود و به صورت ساعتی سرویس می‌گیریم.
هزینه محاسبه شده در این روش ترکیبی برای این مساله فرضی، چیزی معادل 41 دلار در ماه میشه. این عدد در مقایسه با هزینه 70 دلاری یک سرور بزرگ، و یا استفاده تنها از زیرساخت کلاود با هزینه ماهانه 140 دلار، عدد بسیار مطلوب‌تری هست.
علاوه بر هزینه کمتر و در مقایسه با سرور بزرگ، محدودیتی در گسترش تعداد میتینگ‌های همزمان وجود نداره و میشه مازاد بخش ثابت رو از سرویس کلاود درخواست کرد. طبیعتا بسته به رشد کاربران سرویس، میشه عدد کف ثابت رو هم تغییر داد تا در هر دوره زمانی متناسب با شرایط کسب‌وکار، این عدد در بهینه‌ترین مقدار خودش باشه.
