Cloud Design Patterns - Compute Resource Consolidation

چندین کار یا عملیات را در یک واحد محاسباتی ادغام کنید. این کار می تواند استفاده از منابع محاسباتی را افزایش دهد و هزینه ها و سربار مدیریت مربوط به انجام پردازش محاسباتی در برنامه های کاربردی cloud-hosted را کاهش دهد.

طرح صورت مسئله:

یک برنامه ابری اغلب عملیات های مختلفی را پیاده سازی می کند. در برخی راه‌حل‌ها، منطقی است که در ابتدا از اصل طراحی جداسازی نگرانی‌ها (separation of concerns) پیروی کنیم و این عملیات را به واحدهای محاسباتی جداگانه تقسیم کنیم که به صورت جداگانه میزبانی و deploy می‌شوند (مثلاً به عنوان برنامه‌های وب سرویس App جداگانه یا ماشین‌های مجازی جداگانه). با این حال، اگرچه این استراتژی می تواند به ساده سازی طراحی منطقی راه حل کمک کند، استقرار تعداد زیادی از واحدهای محاسباتی به عنوان بخشی از همان برنامه می تواند هزینه های میزبانی زمان اجرا را افزایش دهد و مدیریت سیستم را پیچیده تر کند.

به عنوان مثال، شکل زیر ساختار ساده شده یک cloud-hosted را نشان می دهد که با استفاده از بیش از یک واحد محاسباتی پیاده سازی شده است. هر واحد محاسباتی در محیط مجازی خود اجرا می شود. هر تابع به عنوان یک وظیفه مجزا (با برچسب وظیفه A تا Task E) در واحد محاسباتی خود اجرا شده است.

هر واحد محاسباتی منابع chargeable را مصرف می‌کند، حتی زمانی که بی‌حرکت باشد یا کم استفاده شود. بنابراین، این همیشه مقرون به صرفه ترین راه حل نیست.

در در بیشتر سامانه‌های ارايه دهنده خدمات ابری مثل azure این نگرانی در مورد App Services و Container Apps و ماشین های مجازی وجود دارد. این موارد در محیط خودشان اجرا می شوند. اجرای مجموعه‌ای از وب‌سایت‌ها، میکروسرویس‌ها یا ماشین‌های مجازی مجزا که برای انجام مجموعه‌ای از عملیات به‌خوبی تعریف شده طراحی شده‌اند، اما نیاز به ارتباط و همکاری به عنوان بخشی از یک راه‌حل واحد دارند و اختلال در این مورد می‌تواند باعث استفاده ناکارآمد از منابع شود.

راه حل:

برای کمک به کاهش هزینه ها، افزایش استفاده، بهبود سرعت ارتباط و کاهش مدیریت، می توان چندین کار یا عملیات را در یک واحد محاسباتی ادغام کرد.

وظایف را می توان بر اساس معیارهایی بر اساس ویژگی های ارائه شده توسط environment و هزینه های مرتبط با این ویژگی ها گروه بندی کرد. یک رویکرد متداول این است که به دنبال کارهایی بگردید که مشخصات مشابهی در مورد lifetime و scalability و processing requirements دارند. گروه بندی اینها با هم به آنها اجازه می دهد تا به عنوان یک واحد معین مقیاس یا متریک شوند. خاصیت elasticity ارائه شده توسط بسیاری از محیط های ابری باعث می شود که نمونه های اضافی از یک واحد محاسباتی بر اساس حجم کار شروع و متوقف شوند. برای مثال، Azure مقیاس خودکار را ارائه می‌کند که می‌توانید آن را برای سرویس‌های برنامه و مجموعه‌های مقیاس ماشین مجازی اعمال کنید. برای اطلاعات بیشتر، به راهنمای Autoscaling Guidance مراجعه کنید.

به عنوان مثالی متقابل برای نشان دادن اینکه چگونه می توان از مقیاس پذیری برای تعیین اینکه کدام عملیات نباید با هم گروه بندی شوند استفاده کرد، دو وظیفه زیر را در نظر بگیرید:

• وظیفه 1 - استفاده از polls برای پیام های نادر(infrequent) و حساس به زمان ارسال شده به یک صف.
• وظیفه 2 - بررسی کردن حجم درخواست های بسیار بالا در ترافیک شبکه.

وظیفه دوم نیاز به elasticity دارد که می تواند شامل شروع و توقف تعداد زیادی از نمونه های واحد محاسباتی باشد. استفاده از همان scaling برای اولین کار به سادگی منجر به وظایف بیشتری برای listening به پیام های نادر(infrequent) در همان queue می شود و این کار برابر با اتلاف منابع است.

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

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

مسائل و ملاحظات:

در اجرای این الگو به نکات زیر توجه کنید:

مورد اول- Scalability and elasticity: بسیاری از راه حل های ابری scalability و elasticity را در سطح واحد محاسباتی با شروع و توقف instanceهای واحدها پیاده سازی می کنند. از گروه بندی task های که دارای الزامات مقیاس پذیری متناقض هستند در یک واحد محاسباتی خودداری کنید.

مورد دوم - Lifetime :

زیرساخت ابری به صورت دوره ای محیط مجازی را که میزبان یک واحد محاسباتی است، بازرسی می کند. هنگامی که long-running tasks زیادی در داخل یک واحد محاسباتی وجود دارد، ممکن است لازم باشد که واحد را پیکربندی مجدد کنید تا از recycled آن جلوگیری شود تا زمانی که این tasks به پایان برسد. روش دیگر؛ طراحی tasks با استفاده از یک رویکرد check-pointing که آنها را قادر می سازد به طور مناسب متوقف شوند و در نقطه ای که هنگام راه اندازی مجدد واحد محاسباتیوارد وقفه شد، ادامه دهند.

مورد سوم - Fault tolerance :

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

مورد چهارم - Contention :

از ایجاد conflict بین task که برای منابع در یک واحد محاسباتی با هم رقابت می کنند خودداری کنید. در حالت ایده آل، وظایفی که واحد محاسباتی یکسانی دارند باید ویژگی های استفاده از منابع متفاوتی را نشان دهند. به عنوان مثال؛ دو کار فشرده محاسباتی احتمالاً نباید در یک واحد محاسباتی قرار داشته باشند، و همچنین نباید دو task که مقدار زیادی از حافظه را مصرف می‌کنند در یک واحد محاسباتی باشند. با این حال، اختلاط یک کار محاسباتی فشرده با یک کار که به مقدار زیادی حافظه نیاز دارد، ترکیبی قابل اجرا است.

مورد پنجم - Complexity:

ترکیب چند task در یک واحد محاسباتی به پیچیدگی کد موجود می‌افزاید و احتمالاً test و اشکال‌زدایی و نگهداری آن برنامه را دشوارتر می‌کند.

مورد ششم - Stable logical architecture:

برای هر task کد برنامه را ويژه و مناسب طراحی و پیاده سازی کنید به طوری که نیازی به تغییرات کد حتی در صورت تغییر محیط فیزکی اجرا نداشته باشد.

مورد هفتم - Other strategies:

ادغام منابع محاسباتی تنها یکی از راه‌های کمک به کاهش هزینه‌های مرتبط با اجرای چندین task به طور همزمان است. این نیاز به برنامه ریزی و نظارت دقیق دارد تا اطمینان حاصل شود که یک رویکرد موثر باقی می ماند. بسته به ماهیت کار و محل قرارگیری کاربرانی که این وظایف در حال اجرا هستند، استراتژی‌های دیگر ممکن است مناسب‌تر باشند. به عنوان مثال، تجزیه عملکردی حجم کاری (همانطور که توسط راهنمای پارتیشن بندی Compute Partitioning Guidance محاسبه شده است) ممکن است گزینه بهتری باشد.

چه زمانی از این الگو استفاده کنیم؟

از این الگو برای کارهایی استفاده کنید که اگر در واحدهای محاسباتی خودشان اجرا شوند مقرون به صرفه نیستند. اگر یک کار بیشتر زمان خود را بیکار می گذراند، اجرای این کار در یک واحد اختصاصی می تواند گران باشد.

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

انتخاب platform:

در این مورد گزینه های ارائه شده در Azure را بررسی می‌کنیم:

یک - Azure App Service و Azure Functions: برنامه های مشترک App Service را که نشان دهنده زیرساخت hosting server است را اجرا کنید. یک یا چند برنامه را می توان پیکربندی کرد تا بر روی همان منابع محاسباتی (یا در همان برنامه خدمات برنامه) اجرا شوند.

دو - برنامه‌های کانتینر Azure: برنامه‌های کانتینر را در همان محیط‌های مشترک مستقر کنید. به خصوص در شرایطی که نیاز به مدیریت خدمات مرتبط دارید یا نیاز به استقرار برنامه های مختلف در یک شبکه مجازی دارید.

سه - سرویس Azure Kubernetes (AKS): AKS یک زیرساخت میزبانی مبتنی بر کانتینر است که در آن برنامه‌های کاربردی یا مؤلفه‌های برنامه را می‌توان پیکربندی کرد تا در منابع محاسباتی (گره‌ها) به صورت مشترک اجرا شوند، که بر اساس نیازهای محاسباتی مانند نیازهای CPU یا حافظه گروه‌بندی می‌شوند ( استخرهای گره).

چهار - ماشین‌های مجازی: مجموعه‌ای از ماشین‌های مجازی را برای استفاده همه tenant ها مستقر کنید، به این ترتیب هزینه‌های مدیریت در بین tenant ها تقسیم می‌شود. Virtual Machine Scale Sets یک ویژگی است که از مدیریت منابع مشترک، load-balancing و horizontal scaling ماشین های مجازی پشتیبانی می کند.

مباحث مرتبط:

Autoscaling Guidance.

Compute Partitioning Guidance.

Architectural approaches for compute in multitenant solutions.

Edge Workload Configuration pattern - Cloud Design Patterns<br/> Geode pattern - Azure Architecture Center

Scheduler Agent Supervisor pattern - Azure Architecture Center<br/> External Configuration Store pattern - Azure Architecture Center<br/> Choreography pattern - Azure Architecture Center<br/> Leader Election pattern - Azure Architecture Center<br/> Valet Key pattern - Azure Architecture Center

Index Table pattern - Azure Architecture Cente