چندین task یا عملیات را در یک واحد محاسباتی ادغام کنید. این کار می‌تواند استفاده از منابع محاسباتی را افزایش دهد و هزینه‌ها و سربار مدیریت مربوط به انجام پردازش محاسباتی در cloud-hosted application را کاهش دهد.
یک برنامه ابری اغلب عملیات مختلفی را پیاده‌سازی می‌کند. در برخی راه‌حل‌ها، منطقی است که در ابتدا از اصل طراحی جداسازی نگرانی‌ها(separation of concerns) پیروی کنیم و این عملیات را به واحدهای محاسباتی جداگانه تقسیم کنیم که به‌صورت جداگانه host و deploy می‌شوند (مثلاً به‌عنوان برنامههای وب‌سرویس App جداگانه یا ماشینهای مجازی جداگانه). بااین‌حال، اگرچه این راهبُرد می‌تواند به ساده‌سازی طراحی‌ها کمک کند، deploy کردن تعداد زیادی از واحدهای محاسباتی به‌عنوان بخشی از همان برنامه می‌تواند هزینههای hosting را افزایش دهد و مدیریت سیستم را پیچیده‌تر کند.
به‌عنوان‌مثال، شکل ساختاریافته و ساده شده یک راه‌حل cloud-host را نشان می‌دهد که با استفاده از بیش از یک واحد محاسباتی پیاده‌سازی شده است. هر واحد محاسباتی در محیط مجازی خود اجرا می‌شود. هر تابع به‌عنوان یک تسک مجزا (با برچسب تسک A تا تسک E) در واحد محاسباتی خود اجرا شده است.
هر واحد محاسباتی منابع هزینه‌بری را مصرف می‌کند، حتی زمانی که کاری انجام نمی‌دهند یا کم استفاده باشند؛ بنابراین، این همیشه مقرون‌به‌صرفه‌ترین راه‌حل نیست.
در Azure، این نگرانی در مورد App Serviceها ، Container Appها و ماشینهای مجازی اعمال می‌شود. این موارد در محیط خودشان اجرا می‌شوند. اجرای مجموعه‌ای از وبگاه‌ها، میکروسرویس‌ها یا ماشینهای مجازی مجزا که برای انجام مجموعه‌ای از عملیات به‌خوبی تعریف شده طراحی شده‌اند، اما نیاز به ارتباط و همکاری به‌عنوان بخشی از یک راه‌حل واحد دارند که درنهایت می‌تواند باعث استفاده ناکارآمد از منابع شود.
برای کمک به کاهش هزینه‌ها، افزایش استفاده، بهبود سرعت ارتباطی و کاهش نظارت‌ها روی برنامه، می‌توان چندین تسک یا عملیات را در یک واحد محاسباتی ادغام کرد.
تسک‌ها را می‌توان بر اساس معیارهایی بر اساس ویژگی‌های ارائه شده توسط محیط اجرایی و هزینههای مرتبط با این ویژگی‌ها گروه‌بندی کرد. یک رویکرد متداول این است که به دنبال کارهایی بگردید که مشخصات مشابهی در مورد scalability و lifetime و نیازمندی‌های پردازشی دارند. گروه‌بندی اینها با هم به آنها اجازه می‌دهد تا به‌عنوان یک واحد scale شوند. خاصیت ارتجاعی (elasticity) ارائه شده توسط بسیاری از محیطهای ابری باعث می‌شود که نمونههای اضافی از یک واحد محاسباتی بر اساس حجم کار (workload) آن شروع و متوقف شوند. برای مثال، Azure autoscaling راه‌حلی ارائه می‌کند که می‌توانید آن را برای App Serviceها و دسته‌هایی از ماشین مجازی Scale شده اعمال کنید. برای اطلاعات بیشتر، به Autoscaling Guidance مراجعه کنید.
به‌عنوان مثالی متقابل برای نشان‌دادن اینکه چگونه می‌توان از مقیاس‌پذیری (scalability) برای تعیین اینکه کدام عملیات نباید با هم گروه‌بندی شوند استفاده کرد، دو تسک زیر را در نظر بگیرید:
* تسک ۱ - برای پیام‌های نادر و حساس به زمان ارسال شده به یک صف. * تسک ۲ - که حجم بالای ترافیک شبکه را کنترل می‌کند. تسک دوم نیاز به کشسانی (elasticity) دارد که می‌تواند شامل شروع و متوقف کردن تعداد زیادی از نمونههای واحد محاسباتی باشد. اعمال scaling یکسان برای تسک اول به‌سادگی منجر به tasks listening بیشتر برای پیام‌های انگشت‌شمار در همان صف می‌شود که به‌نوعی اتلاف منابع است.
در بسیاری از محیطهای ابری، می‌توان منابع موجود برای یک واحد محاسباتی را از نظر تعداد هسته‌های CPU، حافظه، فضای دیسک و غیره مشخص کرد. به‌طورکلی، هر چه منابع بیشتر تعیین شود در نتیجه هزینههای آن نیز بیشتر می‌شود. برای صرفه‌جویی در هزینه، مهم است که کارهای یک واحد محاسباتی گران‌قیمت را به حداکثر برسانید و اجازه ندهید برای مدت طولانی غیرفعال شود.
اگر تسک‌هایی وجود دارد که به مقدار زیادی توان CPU در فواصل کوتاه نیاز دارند، این تسک‌ها را در یک واحد محاسباتی ادغام کنید که توان لازم را فراهم کند. بااین‌حال، متعادل‌کردن این نیاز برای مشغول نگه‌داشتن منابع گران‌قیمت در برابر مشکلاتی که در صورت فشارهای بیش از حد ممکن است رخ دهد، بسیار مهم است. برای مثال، کارهای طولانی‌مدت و فشرده نباید واحد محاسباتی یکسانی را به اشتراک بگذارند.
در اجرای این الگو به نکات زیر توجه کنید: Scalability و elasticity. بسیاری از راه‌حل‌های مورداستفاده در فضای ابری مقیاس‌پذیری (scalability) و کشسانی (elasticity) را در سطح واحد محاسباتی با start و stop نمونههای اجرایی قسمت‌های مختلف پیاده‌سازی می‌کنند. از گروه‌بندی تسک‌هایی که دارای الزامات scalability خاص یا متناقض و دارای تداخل هستند در یک واحد محاسباتی خودداری کنید. طول عمر -Lifetime. یک زیرساخت ابری(cloud infrastructure) به‌صورت دوره‌ای virtual environment مربوط به host یک واحد محاسباتی را بازیابی می‌کند. هنگامی که تسک‌هایی در حال اجرا به‌صورت طولانی‌مدت در داخل یک واحد محاسباتی وجود دارد، شاید لازم باشد که واحد محاسباتی را دوباره پیکربندی و تنظیم کنید که از بازیابی آن جلوگیری شود تا زمانی که این تسک‌ها به پایان برسد. روش دیگر، طراحی تسک‌هایی با استفاده از یک رویکرد check-point است که آنها را قادر می‌سازد به طرز خوبی stop شوند و در نقطه‌ای که با راه‌اندازی مجدد واحد محاسباتی قطع شده‌اند، از همان نقطه ادامه دهند. آزادسازی وزنه -Release cadence. اگر پیاده‌سازی یا پیکربندی یک تسک به طور مکرر تغییر می‌کند، شاید لازم باشد واحد محاسباتی host مربوط به کدی که دایم در حال به‌روزرسانی است متوقف شود، برای این کار باید واحد را مجدداً پیکربندی و deploy کنید و سپس آن را مجدداً راه‌اندازی کنید. این فرایند همچنین مستلزم آن است که سایر تسک‌ها در همان واحد محاسباتی متوقف شوند، مجدداً deploy شوند و در ادامه مجدداً راه‌اندازی یا restart شوند. امنیت. تسک‌ها در یک واحد محاسباتی ممکن است زمینه امنیتی یکسانی داشته باشند و بتوانند به منابع مشابهی دسترسی داشته باشند. بین تسک‌ها باید درجه بالایی از اطمینان وجود داشته باشد و اطمینان حاصل شود که یک کار باعث خرابی و تداخل یا تأثیر نامطلوب در تسک دیگر نمی‌شود. علاوه بر این، افزایش تعداد تسک‌ها در حال اجرا در یک واحد محاسباتی سطح حمله(attack surface) واحد را افزایش می‌دهد. هر تسک فقط به همان اندازه که بیشترین آسیب‌پذیری را دارد، ایمن است. تحمل خطا -Fault tolerance. اگر یک تسک در یک واحد محاسباتی با شکست مواجه شود یا رفتار غیرعادی داشته باشد، می‌تواند بر سایر تسک‌ها در حال اجرا در همان واحد تأثیر بگذارد. برای مثال، اگر یک کار به‌درستی شروع نشود، می‌تواند باعث شود کل منطق راه‌اندازی واحد محاسباتی با شکست مواجه شود و از اجرای سایر تسک‌ها در همان واحد جلوگیری کند. درگیری -Contention از ایجاد درگیری بین تسک‌هایی که برای استفاده از منابع در یک واحد محاسباتی با هم رقابت می‌کنند، خودداری کنید. در حالت ایده‌آل، تسک که واحد محاسباتی یکسانی دارند باید ویژگی‌های استفاده از منابع متفاوتی را نشان دهند. به‌عنوان‌مثال، دو تسک‌ای که عملیات فشرده محاسباتی را انجام می‌دهند یا مقدار زیادی از حافظه را مصرف می‌کنند، نباید در یک واحد محاسباتی قرار داشته باشند. بااین‌حال، اختلاط یک عملیات محاسباتی فشرده با تسک‌هایی که به مقدار زیادی حافظه نیاز دارد، ترکیبی قابل‌اجرا است.
توجه داشته باشید
منابع محاسباتی را فقط برای سیستمی در نظر بگیرید که برای یک دوره زمانی در حالت production بوده است تا اپراتورها و توسعه‌دهندگان بتوانند سیستم را نظارت کنند و یک نقشه حرارتی(_heat map_) ایجاد کنند که مشخص می‌کند هر کار چگونه از منابع مختلف استفاده می‌کند. از این نقشه می‌توان برای تعیین اینکه کدام تسک‌ها کاندیدهای خوبی برای اشتراک منابع محاسباتی هستند استفاده کرد.
پیچیدگی. ترکیب چندین تسک در یک واحد محاسباتی به کدها و برنامههای موجود در واحد محاسباتی پیچیدگی زیادی را می‌افزاید و احتمالاً تست و اشکال‌زدایی و نگهداری آن را دشوارتر می‌کند. معماری منطقی پایدار. کد یا برنامه را مخصوص هر تسک طراحی و پیاده‌سازی کنید تا نیازی به تغییر نداشته باشد، حتی اگر محیط فیزیکی که تسک در آن فعالیت می‌کند، تغییر کند. راهبُردهای دیگر. ادغام منابع محاسباتی تنها یکی از راه‌های کمک به کاهش هزینههای مرتبط با اجرای چندین تسک به طور هم‌زمان است. این کار نیاز به برنامه‌ریزی و نظارت دقیق دارد تا اطمینان حاصل شود که یک رویکرد مؤثر باقی می‌ماند. بسته به ماهیت کار و محل قرارگیری کاربرانی که از این تسک‌ها در حال استفاده هستند کجا قرار دارد، راهبُردهای مختلفی شاید برای اجرا پیشرو باشند. به‌عنوان‌مثال، تجزیه عملکردی workload (همان‌طور که توسط Compute Partitioning Guidance توضیح داده شده است) ممکن است گزینه بهتری باشد.
از این الگو برای کارهایی استفاده کنید که اگر در واحدهای محاسباتی خودشان اجرا شوند مقرون‌به‌صرفه نیستند. اگر یک تسک بیشتر زمان خود را بیکار می‌گذراند، اجرای این کار در یک واحد اختصاصی می‌تواند گران باشد. این الگو ممکن است برای کارهایی که عملیات حساس تحمل‌پذیر خطا(critical fault-tolerant) را انجام می‌دهند، یا کارهایی که داده‌های بسیار حساس یا خصوصی را پردازش می‌کنند و به زمینه امنیتی خاص خود نیاز دارند، مناسب نباشد. این تسک‌ها باید در محیط ایزوله خود، در یک واحد محاسباتی جداگانه اجرا شوند.
| چگونه این الگو از اهداف حمایت می‌کند | اهداف |
|---|---|
| این الگو استفاده از منابع محاسباتی را با اجتناب از ظرفیت تدارکاتی استفاده نشده از طریق تجمیع اجزا یا حتی بار‌های کاری کل در یک زیرساخت تلفیقی، به حداکثر می‌رساند. | بهینه سازی هزینه (Cost Optimization) بر حفظ و بهبود بازده سرمایه گذاری حجم کاری شما متمرکز است. |
| ادغام می‌تواند به یک پلت فرم محاسباتی همگن تر منجر شود، که می‌تواند مدیریت و مشاهده پذیری را ساده کند، رویکرد‌های متفاوت به وظایف عملیاتی را کاهش دهد، و میزان ابزار مورد نیاز را کاهش دهد. - OE:07 Monitoring system - OE:10 Automation design | تعالی عملیاتی (Operational Excellence)به ارائه کیفیت بار کاری از طریق فرآیند‌های استاندارد و انسجام تیم کمک می‌کند. |
| ادغام، استفاده از منابع محاسباتی را با استفاده از ظرفیت گره اضافی و کاهش نیاز به تامین بیش از حد، به حداکثر می‌رساند. نمونههای محاسباتی بزرگ (مقیاس عمودی) اغلب در مجموعه منابع برای این زیرساخت‌ها استفاده می‌شوند. - PE:02 Capacity planning - PE:03 Selecting services | کارایی موثر (Performance Efficiency) به حجم کاری شما کمک می‌کند تا از طریق بهینه‌سازی در مقیاس‌بندی، داده‌ها و کد، خواسته‌ها را به طور موثر برآورده کند. |
بسته به سرویس محاسباتی که استفاده می‌کنید، می‌توان این الگو را به روش‌های مختلفی به دست آورد. نمونه سرویس‌‌های زیر را ببینید: *در Azure App Service و Azure Functions**: برنامههای مشترک App Service را که نشان‌دهنده زیرساخت سرور میزبانی است، اجرا کنید. یک یا چند برنامه را می‌توان پیکربندی کرد تا بر روی همان منابع محاسباتی (یا در همان App Service) اجرا شوند.
Azure Container Apps*: برنامههای Container ای را در همان محیطهای مشترک Deploy کنید. به‌خصوص در شرایطی که نیاز به مدیریت سرویس‌‌های مرتبط دارید یا نیاز به Deploy برنامههای مختلف در یک شبکه مجازی دارید.
Azure Kubernetes Service (AKS)* یک زیرساخت میزبانی مبتنی بر کانتینر است که در آن اپلیکیشن‌ها یا مؤلفه‌‌های برنامه را می‌توان پیکربندی کرد تا در منابع محاسباتی (nodes) به‌صورت مشترک اجرا شوند که بر اساس نیازهای محاسباتی مانند نیازهای CPU یا حافظه، گروه‌بندی می‌شوند. (node pools).
ماشینهای مجازی*: مجموعه‌ای از ماشینهای مجازی را برای استفاده همه tenantها Deploy کنید، به‌این‌ترتیب هزینههای مدیریت در بین tenantها تقسیم می‌شود. Virtual Machine Scale Sets یک ویژگی است که از مدیریت منابع مشترک، توزیع بار(load-balancing) و مقیاس‌پذیری افقی(horizontal scaling) ماشینهای مجازی پشتیبانی می‌کند.
الگوها و راهنمایی‌‌های زیر نیز ممکن است هنگام اجرای این الگو مرتبط باشند: * راهنمای مقیاس‌دهی خودکار(Autoscaling Guidance). مقیاس‌دهی خودکار(Autoscaling) بسته به تقاضای پیش‌بینی‌شده برای پردازش، می‌تواند برای start و stop نمونه‌‌هایی از منابع محاسباتی service host استفاده شود. راهنمای پارتیشن‌بندی(Compute Partitioning Guidance). نحوه تخصیص سرویس‌ها و مؤلفه‌ها در یک سرویس ابری را به‌گونه‌ای توضیح می‌دهد که به‌حداقل‌رساندن هزینههای جاری و حفظ مقیاس‌پذیری، performance، availability و امنیت سرویس کمک می‌کند. Architectural approaches for compute in multitenant solutions. این مورد ملاحظات و الزامات ضروری برای ارائه راه‌حل‌هایی برای معماری مناسب برنامه در زمانی که در حال برنامه‌ریزی سرویس‌‌های محاسباتی یک راه‌حل multi-tenant هستیم را ارائه می‌دهد.