تقریبا ده سال از عمر آمازون EC2 می‌گذرد. این مسئله نشان می‌دهد که رایانش ابری کاملا واقعی بوده و توانسته هزاران سیستم را به اجرا درآورد.
چند مستاجری مفهومی است که از ابتدای فعالیت رایانش ابری با آن همراه بوده است به این صورت که مالک می‌تواند امکانات و تجهیزات را همزمان در فضای خود به اشتراک بگذارد. بهترین نمونه‌ای که برای توصیف آن وجود دارد، یک آپارتمان است که ضمن به اشتراک گذاشتن منابع مانند لوله‌کشی، فضاهای مشترک، امنیت، نگه‌داری و... فضای اختصاصی نیز در اختیار مستاجران قرار می‌گیرد تا هزینه اجاره نیز پرداخت شود. دقت داشته باشید که هزینه منابع اشتراکی مستاجران باید کمتر از هزینه در اختیار داشتن منابع اختصاصی آنها باشد.
یک برنامه چند مستاجری در رایانش ابری به طور معمول می‌تواند سه نوع منبع را مدیریت نماید: اجرای OLTP، ذخیره داده‌ها و اجراهای دسته‌ای OLAP (تجزیه و تحلیل). به عنوان مثال: به برنامه‌ای فکر کنید که دارای یک نرم‌افزار وب یا نرم‌افزار تلفن هوشمند باشد. این برنامه مجموعه‌ای از خدمات را ارائه می‌دهد که پس زمینه برنامه‌های پایگاه داده و سیستمی را برای پردازش آنالیز خود فراهم می‌کند. از آنجا که وضعیت معماری‌های امروزه با استفاده از سرورهای بدون حالت، بانک‌های اطلاعاتی جداگانه و سیستم‌های تجزیه و تحلیل جداگانه ساخته شده است، می‌توانیم با کمک گرفتن از چند مستاجری به صورت جداگانه به اجرا درآوردن و حتی تجربه و تحلیل داده‌های جانبی بپردازیم.
اجرای برنامه چند مستاجری
رایانش ابری می‌تواند اشتراک‌گذاری را در سطوح مختلف پیاده‌سازی نماید.
اگر نگاهی به لیست بیاندازید متوجه خواهید شد که هر کدام از آنها منابع بیشتری را به اشتراک گذاشته‌اند، اما از امنیت کمتری برخوردارند. زیرساخت‌هایی که با عنوان سرویس IaaS شناخته می‌شوند توانسته‌اند سطح دو را در لیست فوق به خود اختصاص دهند. ارائه‌دهندگان PaaS و SaaS نیز باید سطوح 2 و 3 را انتخاب نمایند.
اگر این کار به درستی انجام شود یکی از مهم‌ترین ویژگی‌ها و مزایای رایانش ابری «یعنی پرداخت برای آن چیزی که استفاده کرده‌اید» برای شما به اجرا درآمده است. در واقع نباید هیچ هزینه‌ای برای در دسترس بودن به شما اعطا شود. بلکه شما فقط در صورت استفاده از منابع باید به‌ازای آن مبلغی را پرداخت نمائید. برای مثال IaaS مانند AWS، تقریبا رایگان است زیرا سخت‌افزار را از طریق VMs در میان کاربران به اشتراک گذاشته می‌شود.
نکته اینجاست که "پرداخت به خاطر آن چیزی که استفاده می‌کنید" برای PaaS و SaaS رایگان نیست. شما باید یک ارائه‌دهنده رایانش ابری با عنوان XCloud" را فرض کنید که یک میلیون کاربر در اختیار دارد و برنامه‌های PaaS/SaaS را در XCloud مستقر کرده است. مطمئنا به این مسئله پی خواهید برد که تنها چند هزار نفر از این برنامه‌ها فعال خواهد بود به این صورت که تشخیص آن امکان‌پذیر نیست. بنابراین زمانی که یک کاربر برای AppY به XCloud می‌رود ، نیاز است که سروری را در اختیارش بگذاریم. در واقع دو انتخاب پیش‌رو داریم:
هر چند که به عقیده بسیاری از افراد، استفاده از گزینه اول کاملا بی‌فایده است. در واقع شما باید تصور کنید که AppY همان Gmail است، مطمئنا گوگل تمایلی به اجرا درآوردن یک VM برای هر حساب Gmail ندارد. اگر آنها تنها یک‌بار برای هر کاربر آن را به اجرا درآورند مطمئنا برای‌شان سخت خواهد بود که تنها در مواقع استفاده از برنامه مبلغی را دریافت نمایند.
این تفاوت میان VMها در برابر فرآیند چند مستاجری است. VMها چند ثانیه برای بوت شدن به زمان نیاز دارند و اگر برنامه آنها واقعا ساده نباشد هیچ راهی وجود ندارد که بتوانند آن را در سریع‌ترین زمان ممکن به‌کار گیرند تا در خدمت کاربرانی باشند که تازه به جمع مشتریان اضافه شده‌اند. به طور معمول برنامه باید در کمتر از ده ثانیه به کاربر برگردد.
برنامه‌هایی مانند Docker به راحتی می‌توانند این مشکل را برطرف نمایند. آنها VMهای سبک وزنی هستند که در کسری از ثانیه تقویت شده و به انجام فعالیت خود می‌پردازند. اگر کمی به مثال Gmail توجه کنید متوجه خواهید شد که جای هیچ تعجبی نیست اگر برنامه‌های موجود از طریق گوگل وارد شوند. نکته قابل توجه اینجاست که استفاده از Docker به هیچ عنوان نمی‌تواند تضمینی برای سرعت بخشیدن به برنامه‌های شما باشد زیرا امکان اشتباه گرفتن آن با کدهای سایر برنامه‌ها وجود دارد. با این‌حال، در صورت رمز‌گذاری‌های دقیق می‌توانید برنامه‌اهای اضافی را حذف نمائید.
نکته جالب دیگر این است که همین مسئله مهم‌ترین دلیل علاقمندی به میکروسرویس‌ها و سیستم‌های مبتنی بر Docker از همان ابتدا است. در واقع اگر سیستم‌ها بتوانند سرعت خدمات‌رسانی به کاربران را افزایش دهند، هزینه‌های اصلی آنها تا حدود زیادی کاهش پیدا می‌کند زیرا نیاز نگه‌داشتن یک نمونه برای تمام مدت در هر برنامه از بین می‌رود. علاوه براین، الگوریتم‌های مقیاس پذیری خودکار به‌طور قابل توجهی ساده می‌شوند زیرا الگوریتم دیگر نیازی به پیش‌بینی بار و نگه‌داشتن نمونه‌ها برای مقابله با زمان راه‌اندازی ندارد.
اگر به مقایسه ظرفیت موجود در مقابل فرآیند چند مستاجری بپردازید ( سطح 4 لیست) متوجه خواهید شد که دومی می‌تواند کارآیی بیشتری از خود نشان دهند. مسلما در یک سیستم فعالیت‌های بسیار زیادی صورت می‌گیرد، که اشتراک‌گذاشتن یک فرآیند به صورت گذشته‌نگر ترسناک به نظر می‌آید زیرا باید به برنامه‌نویس پلتفرم، برای عدم خطا اعتماد کنید. از طرفی، جداسازی عملکردها از راهکارهای مهم برنامه نویسی برای افزایش اعتماد‌پذیری به برنامه محسوب می‌شود و استفاده از آن به پایداری برنامه کمک می‌کند.
این‌گونه به نظر می‌آید که رایانش ابری برای به اجرا درآوردن برنامه‌های چند مستاجری مبتنی بر سیستم استقرار پیدا کرده است و درواقع سیستم‌ها اغلب عملکرد قابل قبولی از خود ارائه می‌دهند. با نگاهی به گذشته می‌توان درک کرد که این یک انتخاب معقول به حساب می‌آید.
سرانجام یک راه‌حل بسیار ساده‌تر وجود دارد که در بسیاری از موارد کاربرد خوبی از خود به جای گذاشته است.
شایان ذکر است، اگر سرورهای بدون حالت به استقرار سازمانی دست پیدا کنند امکان چند مستاجری از شما سلب خواهد شد. حال تصور کنید که سرور شما هیچ حالتی ندارد، شما می‌توانید با نگاه کردن به درخواست‌ها، نیاز کاربر را بشناسید و تنها زمانی که کاربر به آن احتیاج دارد برنامه را به اجرا درآورید. این مسئله کمک می‌کند تا شما دیگر به برنامه چندگانه احتیاجی نداشته باشید. در عوض می‌توانید مجموعه‌ای از سرورهای مشترک را برای تمامی کاربران به اجرا درآورید و با ورود کاربران یک برنامه را به هر برنامه دیگری که می‌خواهید اختصاص دهید. برای داده‌ها نیز می‌توانید به سراغ یک پایگاه داده چند مستاجری بروید. درصورت اجرایی شدن این راه‌حل، پیچیدگی معماری شما را به میزان قابل توجهی کاهش می‌یابد.
داده‌های اجاره‌ای
دقت داشته باشید که پس از راه‌اندازی مجدد امکان از دست دادن VMها و دیسک‌ها وجود دارد. از همین‌رو، سرورهای اداری چند کاربره مانند پایگاه داده، کارگزاری ها و... بسیار پیچیده‌تر از اجرای آنها در یک برنامه هستند. یک گزینه استفاده از دیسک‌های نصب شده مانند دستگاه‌های S3 یا بلاک است. هر چند که این می‌تواند سرعت برنامه شما را کاهش دهد. در اکثر برنامه‌ها، اغلب از یک سیستم دیتابیس استفاده می‌شود که در بالای سخت‌افزار مستقر شده است.
دقت داشته باشید که حتی در قسمت بالایی سخت‌افزار نیز ما باید فضای ذخیره را در بین کاربران به اشتراک بگذاریم. در این راستا چندین انتخاب پیش روی افراد وجود دارد. مقاله Multi Tenant Architecture، داده‌ها را به‌جز انتخاب شماره 5 که در زمان نوشتن وجود نداشت، به صورت زیر ارائه می‌دهد:
رویکرد شماره 1 و 2 به اشتراک‌گذاشتن سرور پایگاه داده یا بانک اطلاعاتی است که در مجموعه IaaS قابل قبول است. هر چند که برای راه‌اندازی در PaaS یا SaaS گران است. به عنوان مثال نمی‌توان یک میلیون پایگاه داده از هر کاربر را نگه‌داری کرد.
رویکرد شماره 3، تهیه جدول برای هر کاربر است که نسبت به شماره 1 و 2 رویکرد بهتری از خود نشان داده است. اما باز هم استفاده از آن برای یک میلیون کاربر سخت خواهد بود.
رویکرد شماره 4، در اختیار داشتن یک جدول مشترک میان جمعی از کاربران است که توانسته عملکرد مثبتی را از خود به‌جای بگذارد. با این حال، تمامی کاربران باید یک طرح مشابه را با استفاده از این روش به اشتراک بگذارند که اکثرا این سناریو در سیستم‌های PaaS و SaaS قابل قبول است. این مسئله دقیقا همان چند مستاجری‌ست که برای امنیت بیشتر برنامه‌نویسان باید به سیستم پایگاه داده اعتماد کرده و از ارتکاب اشتباه جلوگیری به عمل آورند. با این وجود، تایید فیلتر SQL به جای تایید کد جاوا و C++ در چند مستاجری آسان‌تر است.
رویکرد پنجم اما بهترین رویکرد ارائه شده در جهان در طی چندین سال گذشته به حساب می‌آید. در واقع در صورتی که افراد بتوانند آن را به صورت دقیق به اجرا درآورند، نسبت به سطح 4 عملکرد و جداسازی بهتری را در سطح دیتابیس انجام می‌دهد. هر چند برای جلوگیری از بروز اشتباه باید به توسعه‌دهنده RDBMS نیز اعتماد کنید. علاوه‌براین، توسعه‌دهندگان پایگاه داده نسبت به دامنه اطلاعات بالاتری دارند که امکان ارائه بهترین عملکرد را فراهم می‌آورد.
تحلیل چند مستاجری
به لطف داده‌های بزرگی که در اختیار داریم، همه چیز باید تجزیه و تحلیل شود. در اکثر برنامه‌های SaaS، تجزیه و تحلیل به یک مزیت رقابتی تبدیل شده است. الزامات چند مستاجری برای Analytics با موارد استفاده OLTP که تاکنون در نظر گرفته‌اید متفاوت است. اجرای آنها در محیط PaaS یا SaaS در چالش‌های مختلف به پاسخ نیاز دارد.
تجزیه و تحلیل شامل جمع‌آوری داده‌ها، ذخیره‌سازی داده‌ها، داده‌های درحال اجرا و دسترسی کنترل شده به نتایج است. ارائه‌دهندگان رایانش ابری نیز می‌توانند برای تسهیل جمع‌آوری داده‌ها اقداماتی را انجام دهند:
در واقع هر روش باید با هر رویداد اطلاعاتی سرور میزبان و کاربر ردیابی شود.
در حین کار با سیستم، راه‌حل‌های ذخیره‌سازی، تجزیه و تحلیل جمع‌آوری داده‌ها با یکدیگر در هم تنیده شده‌اند. برای اینکه بتوانید پاسخی مناسب برای آن پیدا کنید باید موارد زیر را مورد سنجش قرار دهید:
با توجه به این الزامات، راه‌حل‌ها نیز تغییر می‌کند. نگاهی به هر راه‌حل می‌اندازیم.
استفاده از فضای اَبَرمستاجری
اگر PaaS به کنترل داده، تجزیه‌وتحلیل داده‌ها و ارائه نتایج نهایی بپردازد، سیستم این توانایی را دارد که کاربران را به سمت سیستم‌ها سوق داده و به کنترل مجوزها بپردازد. هر چند به عقیده بسیاری از افراد، این راه‌حل اندکی خسته‌کننده است اما یک راه‌حل کاملا عادی در برنامه‌های SaaS به حساب می‌آید که در عملکرد بهتر تجزیه و تحلیل کاربرد تاثیر بسیار زیادی می‌گذارد. اگر کاربرد بخواهد تجزیه و تحلیل‌های موجود را خودش انجام دهد، سیستم باید راهی برای انتقال داده‌ها پیدا کند.
جداول مشترک که بر‌اساس یک ستون فیلتر شده اند
درست همانند ذخیره‌سازی داده‌ها اگر همه کاربران بتوانند جداول را به اشتراک بگذارند، می‌توان با اضافه کردن یک ستون کاربر و سیستم به جدول، به کنترل داده‌ها بپردازیم. این راه‌حل تاکنون عملکرد خوبی از خود به جای گذاشته اما از پیچیدگی‌هایی نیز بهره‌مند است. با توجه به منطق موجود با اضافه کردن داده‌های مستاجر به هر کاربر باید آن را به عنوان بخشی از سوابق داده شناسایی کرد. مزیت دیگر این است که با استفاده از این روش در سیستم PaaS می‌توان مجموعه‌ای از تجزیه و تحلیل را تنها یک‌بار بر روی تمامی داده‌ها با استفاده از اپراتورهای گروه، تقسیم‌بندی کرد.
فضای شخصی کاربران
وجود انعطاف در فراهم کردن یک فضای شخصی برای کاربران از اهمیت بالایی برخوردار است. زیرا این قسمت بر روی کنترل نهایی آن تاثیر بسیار زیادی خواهد داشت. این فضا کمک می‌کند تا کاربران سوالات تحلیلی خود را فارغ از سیستم بیرونی مطرح نمایند. نکته اینجاست که برای ایجاد چنین فضایی باید مقدار پولی پرداخت شود که از نظر بسیاری از کاربران گران است.
اگر کاربران زیادی وجود داشته باشد، اگر از پایگاه داده معمولی بهره گیریم، تهیه جدول داده برای هر کاربر کاری سخت و مشکل است زیرا آنها برای رسیدگی به میلیون‌ها پایگاه داده طراحی نشده‌اند. همان‌طور که قبلا گفته شد، یک راه حل بسیار ساده وجود دارد و آن این است که از یک بانک اطلاعاتی محلی برای چندین کاربر استفاده نمائید. در غیر این‌صورت، PaaS باید بسیاری از سرورهای پایگاه داده و جداول تقسیم بین آن سرورها را کنترل نماید که انجام این کار بسیار پیچیده خواهد بود.
برخلاف روش قبلی که SaaS توانایی تجزیه و تحلیل کارها را داشته، تا کاربران به پردازش داده‌ها بپردازند، در اختیار داشتن فضای شخصی برای هر کاربر نیاز به تجزیه و تحلیل دارد. غالبا شروع کار تحلیلی از سرعت قابل توجهی برخوردار است. از این رو، برخلاف اجرای یک کار واحد، به همراه تعداد زیادی از کارها منجر به کند شدن آنها خواهد شد. در این تنظیم، SaaS به یک درگاه محاسباتی بسیار بزرگ‌تر نیاز دارد. در واقع چالش اینجاست که کاربران توانایی کارهای سنگین را داشته باشند. از همین‌رو، SaaS باید راهی برای محدود کردن میزان توان محاسباتی مورد استفاده توسط کاربر واحد پیدا نماید.
انجام یک راه حل ترکیبی نیز امکان‌پذیر است که در آن SaaS شمای مشترکی را برای داده‌های مشترک فراهم آورد و فضای شخصی کاربران را برای داده‌ها تعریف نماید. PaaS نیز این توانایی را دارد که برای فراهم آوردن فضای شخصی هزینه‌ای اضافی را برای کاربران ایجاد نماید و از این طریق به محدود کردن تعدادی از کاربران بپردازد. در هر صورت، هزینه می‌تواند متناسب با داده‌های ایجاد شده توسط کاربر و ساختار آنها تنظیم شود.
نتیجه گیری
بعد از 10 سال از راه‌اندازی رایانش ابری، هزاران سیستم به وجود آمده که از این فضا برای به اجرا درآوردن برنامه‌های خود استفاده می‌کنند. این مقاله به بررسی چند مستاجری، ایده اصلی در رایانش ابری پرداخت. در واقع چند مستاجری توانایی اجرای کار چندین کاربر در همان سیستم را دارد. در حین تحقیق در این راستا نیز، رایانش ابری ممکن است بین چندین سطح برای حفظ امنیت بیشتر از اشتراک گذاشتن سخت‌افزار از VMها استفاده نمایند تا فرآیندی مشابه را از طریق برنامه‌نویسی به اجرا درآورد. در این مقاله همچنین در رابطه با چگونگی ساخت یک برنامه با چندین مستاجر صحبت کردیم. یک برنامه با چند کاربر در رایانش ابری که به مدیریت سه نوع منبع اجرای داده‌ها، ذخیره داده‌ها و اجرای دسته‌ای OLAP (تجزیه و تحلیل) می‌پردازد. در رابطه با هر کدام از آنها صحبت کردیم و مشاهده شد که اجراهای انجام شده در کانتینرها و پایگاه‌های داده نتیجه‌ای همگرا را با خود به دنبال دارد. علاوه‌براین در این مقاله چندین راه‌حل برای پشتیبانی از تحلیل چند کاربر ارائه شده است.
