رایانش ابری(Cloud Computing) نحوه ارائه خدمات را متحول کرده است، کسب و کارها و افراد می توانند با استفاده از خدمات ابری متفاوتی که ارائه دهندگان ابر فراهم می کنند متناسب با تقاضا خودشان به منابع دسترسی داشته باشند. این امر سبب شده تا معماری هایی انعطاف پذیر و مقیاس پذیر برای ارائه بهینه خدمات به مشتریان طراحی شوند. در این پژوهش سعی در بررسی معماریهای مبتنی بر ابر از دید معمار نرم افزار را داریم.
تا کنون تعریف و طبقه بندی های مختلفی برای سرویس های ابری ارائه شده است. معروف ترین آن ها(NIST)، سه مدل سرویس ابری (Service models)و چهار مدل استقرار برای این سرویس های ابری(Deployment models) معرفی می کند.
مدل های سرویس های ابری می توانند:
مدل Infrastructure as a Service(IaaS) باشند که بصورت خام منابع ابری را به عنوان سرویس ارائه می دهند (مانند ماشینهای مجازی و حافظه ای که Amazon EC2 و Amazon S3 ارائه میدهند).
مدل Platform as a Service(PaaS) باشند که ابزارهایی برای توسعه و پیادهسازی نرمافزارها به کاربران عرضه میکند (مانند قابلیتهایی که Google App Engine ارائه میدهد).
تفاوت اصلی این مدل با IaaS در مدیریت زیر ساخت است که در این مدل کاملا بر عهده ارائه دهنده ابر می باشد.
مدل Software as a Service(SaaS) باشند که یک محصول نهایی را در اختیار کاربران میگذارد (مانند Gmail).
علاوه بر این سه مدل، Function as a Service(FaaS) را نیز می توان یک مدل سرویس نسبتا جدید دانست که مفصل تر به آن خواهیم پرداخت (مانند AWS Lambda).
چهار مدل مختلف برای استقرار این سرویس ها معرفی شده:
مدل Private Cloud که برای استفاده شخصی مستقر می شود. Community Cloud که می تواند برای یک سازمان و افرادی با اهداف مشترک مستقر شود. Public Cloud که در دسترس همه قرار دارد و با خریداری اشتراک هر فرد می تواند از خدمات سرویس مورد نظرش استفاده کند. Hybrid Cloud که ممکن است ترکیبی از سه مدل قبل می باشد.
همچنین، شاخصه های اصلی سرویس های ابری :
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service
در طول زمان نحوه پیاده سازی سرویسهای ابری مورد تغییر قرار گرفته، ماشینهای مجازی برای مدیریت و بهرهبری بهتر از منابع مورداستفاده قرار گرفتند، سبک بودن image ها در containerization و آسانتر بودن نگهداری و استقرار آنها باعث شد تا معماریهای مبتنی بر ابر به سمت containerization سوق پیدا کنند. با پیاده سازی برخی منطق های کسب و کار در قالب توابع و فراخوانی آن ها نیز معماری serverless معرفی شده که امروزه مورد استقبال ارائه دهندگان ابر قرار گرفته است.
یک Container در واقع بستهای از کدها و وابستگیهای یک سرویس یا میکروسرویس است که توانایی اجرا بر روی دستگاههای مختلف را دارد، Container ها زیربنا معماری ابری container-based و microservice ها هستند. درحالیکه Virtual Machine می توان یک کپی از سیستمعامل دانست که بر روی سرور اجرا میشود.
در مقاله(3) مقایسه ای در رابطه با عملکرد مجازی سازی و containerization انجام شده که در جدول زیر آمده:
همانطور که در حالت سنتی(non-cloud)، وقتی در رابطه با طراحی و توسعه محصولی که قرار است در اختیار مشتریان قرار گیرد تصمیم گیری می شود،در توسعه محصولات ابری نیز به عنوان معمار نرم افزار باید به یکسری ویژگی های کیفی(Quality attributes) و نیازمندی های غیر کارکردی(non-functional) توجه کرد که برای آن ها می بایست سناریو مشخص کرد و از الگو ها و تاکتیک ها استفاده کرد. باید مطمئن شد که ویژگی های کیفی مدنظر در QoS نرم افزار تعریف شده است، به عنوان مثال،security، scalability، maintainability و غیره. معمار نرم افزار باید اطمینان حاصل کند که برنامه طراحی شده میتواند سطوح خاصی از این ویژگیهای کیفی را برآورده کند، توانایی معمار نرم افزار برای ارضای سطح مورد نظر برای ویژگیهای کیفی در نرمافزار بستگی به نحوه و مهارت استفاده از این الگو ها و تاکتیک ها دارد.
یکی از شاخصه های اصلی توسعه نرم افزار ها در محیط ابری، انتزاع نرم افزار از منابع سخت افزاری(Software abstraction of hardware resources) است. در واقع مجازی سازی باعث شد تا این ویژگی مهم در محیط ابری ایجاد شود که در نتیجه سطح scalability و maintainability بسیار بالا رفت.
عملکرد سرور ها را معمولا در جنبه های زیر اندازه گیری می کنند:
Resource Utilization(در محیط ابری این معیار هر چه بالاتر باشد، بهتر است.)
Response time(هرچه کمتر، بهتر)
Latency(هرچه کمتر، بهتر)
Throughput(هرچه بیشتر، بهتر)
از اصول مربوط به توسعه نرم افزاری که در محیط غیر ابری برای رسیدن به عملکرد بهتر استفاده می کنیم، در توسعه محصولات ابری نیز می توان استفاده کرد(مانند parallelism، pooling shared resources و ...)
در محیط ابر با توجه این شاخصه که ارائه دهندگان ابر می خواهند ارائه سریع بر حسب تقاضا داشته باشند، باید سیستم ها طوری طراحی شوند که از elasticity سریع پشتیبانی کنند. (scale up و scale down سریع)
برای بررسی این موضوع تئوری CAP(مخفف Consistency, Availability, Partitionability) را مورد بررسی قرار می دهیم. تئوری CAP بیان این مسأله در سیستمهای پردازشی است؛ نمیتوان سیستمی داشت که همزمان سه ویژگی Consistency (پایداری)، Availability (دسترسپذیری) و Partitionability(تحمل پذیری دربرابر جداسازی) را داشته باشد.
ناحیه AP: در این ناحیه که Availability و Partitionability مطلوب است سیستم در مقابل خرابی شبکه مقاوم است.
ناحیه AC: در این ناحیه که Availability و Consistency مطلوب است هر درخواست یک پاسخ معتبر مربوطش را دریافت می کند.
ناحیه CP: در این ناحیه که Consistency و Partitionability مطلوب است در هر درخواست خواندن، آخرین نسخه از داده ها را دریافت می کنیم.
محاسبات بدون سرور(serverless) یک روش جدید است که در آن منطق برنامه بر حسب تقاضا و در پاسخ به رویدادها، بدون نیاز به مدیریت سرورها، اجرا میشود. با محاسبات بدون سرور، توسعهدهندگان توابعی را تعریف میکنند که میتوانند توسط رویدادهایی مانند درخواستهای HTTP، تغییرات پایگاه داده و آپلود فایل فعال شوند. پلتفرم های محبوب بدون سرور عبارتند از AWS Lambda، Google Cloud Functions و Microsoft Azure Functions.
برای پیاده سازی منطق بدون سرور با استفاده از سرویس های آمازون، از معماری آمازون ارائه می دهد استفاده می کنیم. این معماری از 5 لایه تشکیل شده:
لایه Compute: این لایه درخواستهای سیستمهای خارجی را مدیریت میکند، دسترسی را کنترل میکند و تأیید میکند که درخواستها مجاز هستند یا خیر. منطق کسب و کار توسط محیط زمان اجرا آن، پیاده می شود. در این لایه AWS Lambda، این امکان را میدهد برنامههای بدون سرور را روی یک پلتفرم مدیریت شده اجرا کنید که از معماریهای میکروسرویس و اجرا در لایه تابع پشتیبانی میکند. با آمازون API Gateway، میتوان یک REST API کاملاً مدیریتشده را اجرا کنید که با Lambda برای اعمال منطق کسبوکار شما ادغام میشود و شامل مدیریت ترافیک، authorization و کنترل دسترسی، نظارت API versioning است. در این لایه AWS Step Function ها، workload های بدون سروری که در محدوده اجرا AWS Lambda پشتیبانی نمی شوند(state، function chaining) را با شکستن به چند مرحله یا با فراخوانی worker ها که روی Amazon EC2 ها اجرا میشوند، مدیریت می کند.
لایه Data: این لایه ذخیره سازی دائمی را از داخل یک سیستم مدیریت می کند. همچنین یک مکانیسم امن برای ذخیره state هایی که منطق کسب و کار به آن نیاز دارد، فراهم می کند. همچنین مکانیزمی برای ایجاد event ها در پاسخ به تغییرات داده ها نیز فراهم می کند.
سرویس های آمازونی که در این لایه استفاده می شوند: Amazon DynamoDB، Amazon Simple Storage Service (Amazon S3)
لایه Messaging and streaming: لایه Messaging ارتباط بین بخش های مختلف را مدیریت می کند و لایه Streaming تحلیل و پردازش real-time داده های در جریان را مدیریت می کند.
سرویس های آمازونی که در این لایه استفاده می شوند: Amazon Simple Notification Service (Amazon SNS)، Amazon Kinesis
لایه User management and identity: این لایه احراز هویت و authorization را برای مشتریان خارجی و داخلی فراهم می کند.
سرویس آمازونی که در این لایه استفاده می شود: Amazon Cognito
لایه Edge: این لایه ارائه و اتصال به مشتریان خارجی را مدیریت می کند.
سرویس آمازونی که در این لایه استفاده می شود: Amazon CloudFront
روش های deployment که آمازون برای این معماری ارائه می دهد به شرح زیر است:
هنگام ساخت یک میکروسرویس بدون سرور، به این فکر کنید که چگونه یک منطق کسب و کار می تواند به عنوان یک سرویس قابل استفاده مجدد برای مشتریان ارائه شود. ساخت میکروسرویسهای بدون سرور در AWS شما راباعث می شود علاوه بر استفاده از خود قابلیتهای بدون سرور، بلکه از سایر خدمات و ویژگیهای AWS و همچنین ابزارهای AWS و AWS Partner Network (APN) استفاده کنید. فناوریهای بدون سرور بر روی زیرساختهای مقاوم در برابر خطا ساخته شدهاند و می توان خدمات قابل اعتمادی را برای workload ها ساخت. اکوسیستم ابزارسازی آمازون این امکان را میدهد که ساخت شود، وظایف خودکار شوند، وابستگیها هماهنگ شوند. در نهایت، ابزارهای بدون سرور AWS به کسب و کار ها اجازه می دهد تا بر روی منطق کاریشان تمرکز کنند و همچنین هزینههای خود را در مراحل ورود و زمانهای غیر اوج مصرف پایین نگه دارند.
در مقاله(4) این فریم ورک معرفی می شود. SCAR اجازه می دهد تا با ترکیب توابعی که روی AWS Batch یا AWS Lambda اجرا می شوند، workflow های بدون سرور ایجاد کنید،که فایل های خروجی را تولید می کند و اجرای توابعی را آغاز می کند که مجدداً روی AWS Batch یا AWS Lambda اجرا می شوند، با استفاده از همان تصاویر Docker. در نتیجه ایجاد گردشهای کاری بدون سرور با سرویسهای مقیاسپذیر را می توان با این framework انجام داد.
معماری ارائه شده SCAR به شکل زیر است:
«این مطلب، بخشی از تمرینهای درس معماری نرمافزار در دانشگاه شهیدبهشتی است»
1. Mell, P. and Grance, T. (2011), The NIST Definition of Cloud Computing, Special Publication (NIST SP), National Institute of Standards and Technology, Gaithersburg, MD, [online], https://doi.org/10.6028/NIST.SP.800-145 (Accessed January 31, 2024)
2. Kratzke, Nane. 2018. "A Brief History of Cloud Application Architectures" Applied Sciences 8, no. 8: 1368. https://doi.org/10.3390/app8081368
3. R. K. Barik, R. K. Lenka, K. R. Rao and D. Ghose, "Performance analysis of virtual machines and containers in cloud computing," 2016 International Conference on Computing, Communication and Automation (ICCCA), Greater Noida, India, 2016, pp. 1204-1210, doi: 10.1109/CCAA.2016.7813925.
4. Alfonso Pérez, Germán Moltó, Miguel Caballer, Amanda Calatrava, Serverless computing for container-based architectures, Future Generation Computer Systems, https://doi.org/10.1016/j.future.2018.01.022.
5. https://derak.cloud/blog/tech/%D8%AA%D8%A6%D9%88%D8%B1%DB%8C-cap/
6. https://docs.aws.amazon.com/wellarchitected/latest/framework
7. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/definitions.html
8. D. Gannon, R. Barga and N. Sundaresan, "Cloud-Native Applications," in IEEE Cloud Computing, vol. 4, no. 5, pp. 16-21, September/October 2017, doi: 10.1109/MCC.2017.4250939.
9. I. Odun-Ayo, M. Ananya, F. Agono and R. Goddy-Worlu, "Cloud Computing Architecture: A Critical Analysis," 2018 18th International Conference on Computational Science and Applications (ICCSA), Melbourne, VIC, Australia, 2018, pp. 1-7, doi:10.1109/ICCSA.2018.8439638.