وقتی میگوییم یک اپلیکیشن «روی Cloud اجرا میشود»، پشت این عبارت مجموعهای از لایهها قرار دارد: دیتاسنترهای فیزیکی، شبکه، سرور، مجازیسازی، Container، ذخیرهسازی، دیتابیس، سیستمهای توزیعشده و ابزارهایی که منابع را در چند دقیقه در اختیار تیم توسعه میگذارند. پردازش ابری فقط اجاره یک سرور از راه دور نیست؛ معماریای است که منابع را قابل برنامهریزی، مقیاسپذیر و قابل اندازهگیری میکند.
در این مقاله بهجای تکرار تعریف مقدماتی «رایانش ابری چیست»، وارد سازوکار فنیتر میشویم: Cloud چگونه از دیتاسنتر تا Region و Availability Zone ساخته میشود، مجازیسازی چه نقشی دارد، شبکه و Storage چگونه طراحی میشوند، Serverless و Container کجا قرار میگیرند، مدل مسئولیت مشترک امنیت یعنی چه و چرا هزینه و Latency باید از همان مرحله معماری در نظر گرفته شوند.
از دیتاسنتر فیزیکی تا منابع ابری
در پایینترین لایه، Cloud همچنان از سختافزار واقعی ساخته شده است: سرورها، سوئیچها، روترها، رکها، سیستم برق، خنککننده و تجهیزات ذخیرهسازی. تفاوت اصلی این است که این منابع با لایههای نرمافزاری مدیریت و به واحدهایی تبدیل میشوند که از طریق API قابل ایجاد، حذف و تغییر هستند.
این تصاویر نمای کلی از مفهوم Cloud و مسیر تکامل آن را نشان میدهند.
در یک دیتاسنتر سنتی ممکن است برای راهاندازی سرویس جدید نیاز به خرید سرور، نصب در رک و پیکربندی شبکه باشد. در Cloud، همان نیاز میتواند به درخواست API برای ایجاد Instance، Volume و شبکه تبدیل شود. پشت این تجربه ساده، سیستمهای Orchestration باید ظرفیت، خرابی سختافزار، شبکه و جداسازی مشتریان را مدیریت کنند.
لایه فیزیکی و لایه انتزاع؛ معماری Cloud از نگاه NIST
NIST زیرساخت Cloud را متشکل از یک لایه فیزیکی و یک لایه انتزاعی توصیف میکند. لایه فیزیکی شامل Server، Storage و Network است و لایه انتزاعی نرمافزاری است که روی سختافزار قرار میگیرد و ویژگیهای Cloud را ممکن میکند. این جداسازی دلیل مهمی است که کاربر لازم نیست بداند Workload دقیقاً روی کدام سرور فیزیکی اجرا میشود.
این انتزاع البته به معنی حذف فیزیک نیست. خرابی برق، کابل، Storage یا Cooling همچنان ممکن است رخ دهد؛ طراحی ابری تلاش میکند خرابی اجزای منفرد را با افزونگی و توزیع Workload قابل تحمل کند.
مجازیسازی چگونه منابع را تقسیم میکند؟
Virtualization یکی از فناوریهای پایه Cloud است. Hypervisor میتواند یک سرور فیزیکی را به چند Virtual Machine تقسیم کند. هر VM سیستمعامل و منابع منطقی خودش را دارد و از دیگر VMها جدا میشود. این مدل باعث افزایش بهرهوری سختافزار و Provision سریعتر میشود.
در نسلهای جدید، معماری Cloud فقط به Hypervisor محدود نیست. Containerها Processها را در سطح سیستمعامل جدا میکنند و سربار کمتری نسبت به VM کامل دارند. در بسیاری از معماریها، Container داخل VM اجرا میشود؛ بنابراین این دو فناوری رقیب مطلق نیستند.
Container و Kubernetes در کجای معماری قرار میگیرند؟
Container یک واحد سبک برای بستهبندی برنامه و وابستگیهای آن است. Kubernetes و Orchestratorهای مشابه تعداد زیادی Container را روی مجموعهای از Nodeها زمانبندی میکنند، Service Discovery، Restart، Scaling و Rollout را مدیریت میکنند. ارائهدهندگان Cloud سرویس Kubernetes مدیریتشده عرضه میکنند تا بخشی از پیچیدگی Control Plane را از تیم کاربر بگیرند.
اما Kubernetes برای هر پروژهای لازم نیست. یک سرویس کوچک ممکن است با PaaS یا Serverless سادهتر، ارزانتر و قابل نگهداریتر باشد. استفاده از ابزار پیچیده فقط به دلیل محبوبیت، بدهی عملیاتی ایجاد میکند.
Region و Availability Zone چیست؟
ارائهدهندگان بزرگ Cloud زیرساخت را در مناطق جغرافیایی مختلف تقسیم میکنند. Region معمولاً یک ناحیه جغرافیایی مستقل است و Availability Zone یا مفهوم مشابه، مجموعهای از دیتاسنترهای جداشده درون آن Region را نمایندگی میکند. هدف این است که خرابی یک محل فیزیکی الزاماً کل سرویس را از دسترس خارج نکند.
اگر اپلیکیشن حیاتی است، قرار دادن همه Instanceها و دیتابیسها در یک Failure Domain ریسک ایجاد میکند. معماری Multi-AZ میتواند Availability را بهتر کند، اما هزینه، Replication و پیچیدگی بیشتری دارد. Multi-Region سطح بالاتری از تابآوری ایجاد میکند و در عوض طراحی داده و Failover دشوارتر میشود.
شبکه ابری چگونه کار میکند؟
در Cloud معمولاً یک شبکه منطقی خصوصی مانند VPC/VNet ایجاد میکنید. داخل آن Subnet، Route Table، Firewall/Security Group، NAT Gateway و Load Balancer تعریف میشوند. این عناصر به شما اجازه میدهند Web Server عمومی، Database خصوصی و سرویسهای داخلی را از نظر دسترسی جدا کنید.
نمودار بالا مفهوم پایه یک شبکه را نشان میدهد: Clientها از طریق تجهیزات شبکه به سرویسها متصل میشوند. در Cloud همین منطق با لایههای نرمافزارمحور و شبکه مجازی پیاده میشود. تفاوت مهم این است که Route، Firewall و Interfaceها غالباً با API یا Infrastructure as Code ساخته میشوند و میتوان آنها را همراه برنامه Version کرد.
Load Balancer چه کاری انجام میدهد؟
Load Balancer ترافیک ورودی را میان چند Backend توزیع میکند. این کار علاوه بر افزایش ظرفیت، امکان خارج کردن Instance خراب یا انجام Rolling Deployment را فراهم میکند. Load Balancer ممکن است در Layer 4 بر اساس TCP/UDP یا در Layer 7 بر اساس HTTP، Host و Path تصمیمگیری کند.
برای مقیاسپذیری واقعی، برنامه نیز باید تا حد امکان Stateless طراحی شود یا State را در سرویسهای مشترک مثل Database و Cache نگه دارد. اضافه کردن ده Instance به برنامهای که Session را فقط روی دیسک محلی ذخیره میکند، بدون طراحی Session مناسب مشکل ایجاد میکند.
ذخیرهسازی ابری فقط یک «هارد آنلاین» نیست
Cloud چند مدل Storage دارد و انتخاب اشتباه میتواند هم کارایی و هم هزینه را خراب کند.
| نوع Storage | ویژگی | کاربرد |
|---|---|---|
| Object Storage | مقیاس بالا، دسترسی با API | تصویر، Backup، Log، Data Lake |
| Block Storage | شبیه دیسک متصل به VM | سیستمعامل، دیتابیس، فایلسیستم |
| File Storage | فایلسیستم مشترک شبکهای | Workloadهای نیازمند Shared Files |
| Archive | ارزانتر با بازیابی کندتر | نگهداری بلندمدت و Compliance |
Object Storage برای فایلهای عظیم و تعداد بسیار زیاد Object مناسب است، اما رفتار آن با فایلسیستم محلی یکی نیست. برنامه باید بر اساس Semantics سرویس طراحی شود.
دیتابیس در Cloud؛ Self-managed یا Managed؟
میتوانید دیتابیس را داخل VM خود نصب کنید یا سرویس مدیریتشده بگیرید. در حالت Self-managed کنترل زیادی دارید، اما Patch، Backup، Replication، Monitoring و Recovery بیشتر با تیم شماست. Managed Database بخشی از این کارها را خودکار میکند و در عوض هزینه و محدودیتهای پلتفرم را میپذیرید.
انتخاب فقط فنی نیست؛ اگر تیم کوچک است، زمانی که با سرویس مدیریتشده آزاد میشود ممکن است از تفاوت قیمت زیرساخت ارزشمندتر باشد. در سازمانی با نیاز خاص، حجم عظیم یا Database Engine سفارشی، Self-managed میتواند منطقی باشد.
Cloud-first در سمت کاربر؛ دستگاههای سبک چه نقشی دارند؟
رایانش ابری فقط معماری سمت سرور را تغییر نداده است. دستگاههای Cloud-first مانند Chromebook نشان میدهند بخشی از پردازش، ذخیرهسازی و همگامسازی میتواند به سرویسهای آنلاین منتقل شود و دستگاه کاربر نقش یک کلاینت سبکتر را داشته باشد. این مدل وابستگی به اتصال شبکه را افزایش میدهد، اما مدیریت مرکزی و همگامسازی داده را سادهتر میکند.
پردازش ابری چگونه Scale میشود؟
دو مدل اصلی Scaling وجود دارد: Vertical یعنی بزرگتر کردن یک ماشین، مثلاً افزایش RAM و CPU؛ Horizontal یعنی افزایش تعداد Instanceها. Cloud هر دو را سادهتر میکند، اما Horizontal Scaling معمولاً برای Availability و رشد بزرگتر انعطاف بیشتری دارد.
Auto Scaling میتواند براساس CPU، Queue Length، تعداد Request یا Metric سفارشی ظرفیت را تغییر دهد. Metric باید با رفتار واقعی برنامه مرتبط باشد؛ اگر CPU پایین است اما Database Bottleneck دارد، Scaling کورکورانه Web Serverها مشکل را حل نمیکند.
AWS Cloud را چگونه توصیف میکند؟
در راهنمای معماری Amazon Web Services، Cloud Computing دسترسی درخواستی به منابع فناوری از طریق اینترنت با مدل پرداخت متناسب با مصرف توصیف میشود. نتیجه عملی این مدل آن است که تیم بهجای خرید و نگهداری ظرفیت ثابت، میتواند منابع را هنگام نیاز فراهم کند و با تغییر تقاضا آنها را افزایش یا کاهش دهد. ارزش اصلی فقط اجاره سختافزار نیست؛ سرعت Provision، انعطاف ظرفیت و دسترسی به مجموعهای از سرویسهای مدیریتشده است که زمان ساخت و آزمایش محصول را کاهش میدهد.
Serverless چیست و آیا واقعاً «بدون سرور» است؟
Serverless به معنی نبودن سرور نیست؛ یعنی کاربر مدیریت مستقیم Server Instance را انجام نمیدهد. در Function as a Service، کد در پاسخ به Event اجرا میشود و پلتفرم ظرفیت و Runtime را مدیریت میکند. این مدل برای APIهای Event-driven، پردازش فایل، Automation و Workloadهای Burst مناسب است.
محدودیتها شامل Cold Start در برخی معماریها، محدودیت زمان اجرا، وابستگی به سرویسهای پلتفرم و هزینه متفاوت در بارهای دائمی است. Serverless باید براساس الگوی Workload انتخاب شود، نه صرفاً به دلیل حذف مدیریت VM.
امنیت Cloud و Shared Responsibility
یکی از مفاهیم بنیادی امنیت Cloud «مسئولیت مشترک» است. ارائهدهنده معمولاً امنیت زیرساخت فیزیکی و بخشهایی از سرویس را مدیریت میکند، اما مشتری همچنان مسئول Identity، Permission، Data Classification، Secret، پیکربندی Network و امنیت کد خودش است. مرز دقیق مسئولیت به نوع سرویس بستگی دارد؛ در SaaS کار بیشتری با ارائهدهنده است، در IaaS مشتری کنترل و مسئولیت بیشتری دارد.
اصول کلیدی امنیت Cloud شامل MFA، Least Privilege، جداسازی Account/Project، Secret Manager، رمزنگاری، Logging، Patch Management، Backup و تست Recovery است. Public بودن اشتباه یک Storage Bucket یا Security Group باز میتواند یک معماری قوی را به رخداد امنیتی تبدیل کند.
چارچوب Cloud Computing در NIST نیز امنیت و آمادگی Forensics را از موضوعات اصلی استفاده سازمانی از Cloud میداند.
Latency و انتخاب Region
سرعت پردازنده تنها معیار عملکرد نیست. اگر کاربر در یک کشور و Server در قاره دیگری باشد، Round-trip شبکه میتواند تجربه را کند کند. انتخاب Region نزدیک، CDN، Edge Cache و معماری مناسب داده تأثیر زیادی بر Latency دارند.
در کنار فاصله، قوانین Data Residency و Compliance نیز ممکن است محل نگهداری داده را محدود کنند. بنابراین نزدیکترین Region همیشه تنها معیار نیست.
CDN و Edge چه تفاوتی با Cloud مرکزی دارند؟
CDN محتوا را در نقاط نزدیکتر به کاربر Cache میکند تا Latency و بار Origin کاهش یابد. Edge Computing یک مرحله جلوتر میرود و بخشی از پردازش را نزدیک منبع داده یا کاربر انجام میدهد. برای IoT، بازی، ویدئو، امنیت شبکه و پردازش بلادرنگ، Edge میتواند مکمل Cloud مرکزی باشد.
معماری آینده الزاماً «همهچیز در یک دیتاسنتر Cloud» نیست؛ ترکیبی از Central Cloud، Regionهای مختلف و Edge محتملتر است.
هزینه Cloud از کجا زیاد میشود؟
قیمت فقط Instance نیست. Storage، IOPS، Snapshot، ترافیک خروجی، NAT Gateway، Load Balancer، Database، Log و سرویسهای مدیریتشده روی صورتحساب اثر دارند. معماریای که از نظر فنی Scale میشود ممکن است از نظر اقتصادی Scale نشود.
FinOps تلاش میکند تیم فنی، مالی و محصول را حول هزینه Cloud هماهنگ کند. Tagging منابع، Budget، Alert، حذف منابع Idle، Reserved/Committed Capacity برای بار ثابت و بررسی Data Transfer از اقدامات پایهاند.
High Availability با Disaster Recovery فرق دارد
High Availability یعنی سرویس در برابر خرابیهای معمول با حداقل وقفه ادامه دهد؛ مثلاً چند Instance در چند Zone. Disaster Recovery درباره سناریوهای بزرگتر است: خرابی Region، حذف داده، خطای انسانی یا حمله. Backup باید خارج از همان Failure Domain نگهداری و بازیابی آن آزمایش شود.
دو شاخص مهم DR عبارتاند از RPO، یعنی چه مقدار از داده قابل از دست رفتن است، و RTO، یعنی سرویس حداکثر در چه زمانی باید برگردد. معماری و هزینه بر اساس این اهداف تغییر میکند.
Multi-cloud همیشه مزیت نیست
استفاده همزمان از چند ارائهدهنده میتواند برای الزامات قانونی، کاهش وابستگی یا نیازهای خاص مفید باشد، اما پیچیدگی Identity، Network، Monitoring، Skill و Data Transfer را بالا میبرد. اگر دلیل مشخصی ندارید، «قابل انتقال بودن معماری» معمولاً هدف عملیتری از اجرای فعال همهچیز روی چند Cloud است.
هوش مصنوعی و GPU چگونه Cloud را تغییر دادهاند؟
Workloadهای AI تقاضا برای GPU، شبکه پرسرعت و Storage با Throughput بالا را افزایش دادهاند. Cloud اجازه میدهد تیم بدون خرید Cluster اختصاصی به Acceleratorهای مختلف دسترسی پیدا کند؛ اما هزینه Training و Inference میتواند بسیار بالا باشد. انتخاب مدل، Batch Size، Quantization، Cache و نوع GPU بخشی از معماری هزینه محسوب میشود.
سرویسهای AI مدیریتشده نیز لایه دیگری ایجاد کردهاند؛ تیم میتواند مدل یا API آماده استفاده کند، ولی باید Privacy، Data Retention، Vendor Lock-in و هزینه Token/Inference را بررسی کند.
چکلیست مهاجرت یک برنامه به Cloud
- وابستگیهای برنامه و جریان داده را مستند کنید.
- هدف مهاجرت را مشخص کنید: هزینه، Scale، Availability یا سرعت توسعه؟
- Region و الزامات قانونی داده را تعیین کنید.
- Identity و Network را قبل از Workload طراحی کنید.
- برای Backup، RPO و RTO تصمیم بگیرید.
- Metric، Log و Alert را از روز اول تعریف کنید.
- هزینه Data Transfer و سرویسهای جانبی را تخمین بزنید.
- ابتدا با Workload کمریسک Pilot اجرا کنید.
- Load Test و Failure Test انجام دهید.
- برنامه Rollback و خروج از سرویس را داشته باشید.
جمعبندی
پردازش ابری نتیجه ترکیب زیرساخت فیزیکی با لایههای انتزاع، اتوماسیون و سرویسهای مدیریتشده است. VM و Container منابع را جدا میکنند، شبکه مجازی ارتباط را کنترل میکند، Storage و Database مدلهای مختلف داده را پوشش میدهند و Region/Zone امکان طراحی برای خرابی را فراهم میکنند. Serverless و سرویسهای Managed عملیات را کاهش میدهند، اما مسئولیت معماری، امنیت داده و کنترل هزینه از بین نمیرود. معماری Cloud خوب معماریای نیست که بیشترین سرویس را استفاده کند؛ معماریای است که نیاز محصول را با کمترین پیچیدگی لازم، Availability مناسب و هزینه قابل کنترل حل کند.
