5 اصل برای معماری بومی ابری چیست و چگونه بر آن مسلط شویم؟

شرکت سیماگر 09121442355
متخصص معماری Google Cloud

در Google Cloud، ما اغلب اصطلاح «معماری بومی ابر» را به عنوان هدف نهایی مورد نظر برای برنامه‌هایی که مهاجرت می‌کنید یا بر روی Google Cloud Platform (GCP) می‌سازید، مطرح می‌کنیم. اما دقیقاً منظور ما از cloud-native چیست؟ بیشتر به این نکته، چگونه می خواهید چنین سیستمی را طراحی کنید؟

در سطح بالا، معماری بومی ابری به معنای انطباق با بسیاری از امکانات جدید – اما مجموعه بسیار متفاوتی از محدودیت‌های معماری – ارائه شده توسط ابر در مقایسه با زیرساخت‌های سنتی داخلی است. عناصر سطح بالایی را که ما به عنوان معماران نرم افزار آموزش دیده ایم در نظر بگیرید:

الزامات عملکردی یک سیستم (آنچه باید انجام دهد، به عنوان مثال “فرآیند سفارشات در این قالب…”)
الزامات غیر کاربردی (نحوه انجام آن به عنوان مثال «حداقل 200 سفارش در دقیقه پردازش شود»)
محدودیت‌ها (آنچه برای تغییر خارج از محدوده است، به عنوان مثال «سفارش‌ها باید در سیستم اصلی فعلی ما به‌روزرسانی شوند»).
در حالی که جنبه‌های عملکردی خیلی تغییر نمی‌کند، ابر راه‌های بسیار متفاوتی را برای برآورده کردن الزامات غیرعملکردی ارائه می‌کند، و گاهی اوقات نیازمند آن است، و محدودیت‌های معماری بسیار متفاوتی را تحمیل می‌کند. اگر معماران نتوانند رویکرد خود را با این محدودیت‌های مختلف تطبیق دهند، سیستم‌هایی که معمار می‌کنند اغلب شکننده، گران و سخت برای نگهداری هستند. از سوی دیگر، یک سیستم بومی ابری که به خوبی طراحی شده است، باید تا حد زیادی خود ترمیم کننده، مقرون به صرفه باشد و به راحتی از طریق یکپارچه سازی/تحویل مستمر (CI/CD) به روز شود و نگهداری شود.

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

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

اصول معماری بومی ابری
اصل معماری برای ابر، با نام مستعار معماری بومی ابر، بر چگونگی بهینه‌سازی معماری سیستم برای قابلیت‌های منحصربه‌فرد ابر تمرکز دارد. معماری سنتی تمایل به بهینه سازی برای یک زیرساخت ثابت و پرهزینه دارد که نیاز به تلاش دستی قابل توجهی برای اصلاح دارد. بنابراین معماری سنتی بر انعطاف‌پذیری و عملکرد تعداد نسبتاً کمی ثابتی از اجزاء متمرکز است. با این حال، در فضای ابری، چنین زیرساخت ثابتی بسیار کمتر منطقی است زیرا ابر بر اساس میزان استفاده شارژ می‌شود  و همچنین خودکار کردن آن بسیار آسان‌تر است . بنابراین، معماری بومی ابری بر دستیابی به انعطاف‌پذیری و مقیاس از طریق مقیاس‌بندی افقی، پردازش توزیع‌شده، و خودکارسازی جایگزینی اجزای شکست خورده تمرکز دارد. بیا یک نگاهی بیندازیم.
اصل 1: طراحی برای اتوماسیون
اتوماسیون همیشه بهترین روش برای سیستم‌های نرم‌افزاری بوده است، اما ابر خودکارسازی زیرساخت‌ها و همچنین اجزای بالای آن را برای طراحی سایت آسان‌تر از همیشه می‌کند. اگرچه سرمایه گذاری اولیه اغلب بیشتر است، ترجیح دادن راه حل خودکار تقریباً همیشه در میان مدت از نظر تلاش و همچنین از نظر انعطاف پذیری و عملکرد سیستم شما نتیجه خواهد داد. فرآیندهای خودکار می توانند سیستم شما را بسیار سریعتر از افراد دیگر تعمیر، مقیاس و استقرار دهند. همانطور که در ادامه بحث خواهیم کرد، معماری در فضای ابری یک معامله یکباره نیست، و اتوماسیون نیز از این قاعده مستثنی نیست – چون روش‌های جدیدی را پیدا می‌کنید که سیستم شما برای انجام آن نیاز دارد، بنابراین چیزهای جدیدی برای خودکارسازی پیدا خواهید کرد.
برخی از زمینه های رایج برای خودکارسازی سیستم های ابری بومی عبارتند از:

زیرساخت: با استفاده از ابزارهایی مانند Google Cloud Deployment Manager یا Terraform، ایجاد زیرساخت را به‌همراه به‌روزرسانی‌های آن به‌طور خودکار انجام دهید.
یکپارچه سازی مداوم/تحویل مستمر: ساخت، آزمایش و استقرار بسته هایی که سیستم را تشکیل می دهند را با استفاده از ابزارهایی مانند Google Cloud Build، Jenkins و Spinnaker به صورت خودکار انجام دهید. نه تنها باید استقرار را خودکار کنید، بلکه باید برای خودکارسازی فرآیندهایی مانند آزمایش قناری و بازگشت به عقب تلاش کنید.
افزایش مقیاس و کاهش مقیاس: مگر اینکه بار سیستم شما تقریباً هرگز تغییر نمی کند، باید مقیاس سیستم را در پاسخ به افزایش بار به طور خودکار انجام دهید و در پاسخ به افت مداوم بار، مقیاس را کاهش دهید. با افزایش مقیاس، اطمینان حاصل می کنید که خدمات شما در دسترس باقی می ماند و با کاهش هزینه ها را کاهش می دهید. این مهم برای برنامه های کاربردی در مقیاس بالا، مانند وب سایت های عمومی، اما همچنین برای برنامه های کوچکتر با بار نامنظم، به عنوان مثال برنامه های داخلی که در دوره های خاص بسیار شلوغ هستند، اما در دوره های دیگر به ندرت استفاده می شوند، منطقی است. برای برنامه‌هایی که گاهی تقریباً هیچ ترافیکی دریافت نمی‌کنند، و می‌توانید تأخیر اولیه را تحمل کنید، حتی باید مقیاس صفر را در نظر بگیرید (حذف همه نمونه‌های در حال اجرا و راه‌اندازی مجدد برنامه در صورت نیاز بعدی).

نظارت و بازیابی خودکار: شما باید از ابتدا نظارت و ورود به سیستم های ابری خود را آغاز کنید. ثبت و نظارت بر جریان های داده به طور طبیعی می تواند برای نظارت بر سلامت سیستم استفاده شود، اما می تواند کاربردهای زیادی فراتر از این داشته باشد. به عنوان مثال، آنها می توانند بینش های ارزشمندی در مورد استفاده از سیستم و رفتار کاربر ارائه دهند (چند نفر از سیستم استفاده می کنند، از چه قطعاتی استفاده می کنند، میانگین تأخیر آنها چقدر است و غیره). ثانیاً، می‌توان از آن‌ها به‌صورت مجموع برای اندازه‌گیری سلامت کلی سیستم استفاده کرد (به عنوان مثال، یک دیسک دوباره تقریباً پر است، اما آیا سریع‌تر از حد معمول پر می‌شود؟ رابطه بین استفاده از دیسک و جذب سرویس چیست؟ و غیره). در نهایت، آنها نقطه ایده آلی برای اتصال اتوماسیون هستند. اکنون هنگامی که دیسک پر می شود، به جای اینکه فقط یک خطا را ثبت کنید، می توانید به طور خودکار اندازه دیسک را تغییر دهید تا سیستم به کار خود ادامه دهد.
اصل 2: ​​با دولت هوشمند باشید
ذخیره سازی «وضعیت»، چه داده های کاربر (مثلاً موارد موجود در سبد خرید کاربران، یا شماره کارمند آنها) یا وضعیت سیستم (به عنوان مثال، چند نمونه از یک کار در حال اجرا است، چه نسخه ای از کد در حال اجرا است) ، سخت ترین جنبه معماری یک معماری توزیع شده و بومی ابری است. بنابراین باید سیستم خود را طوری طراحی کنید که عمداً در مورد زمان و نحوه ذخیره وضعیت و اجزای طراحی هر کجا که می توانید بدون حالت باشند.
اجزای بدون حالت به راحتی می توانند:

مقیاس: برای افزایش مقیاس، فقط کپی های بیشتری اضافه کنید. برای کاهش مقیاس، به نمونه‌ها دستور دهید تا پس از اتمام کار فعلی خود، خاتمه دهند.
تعمیر: برای “تعمیر” یک نمونه شکست خورده از یک جزء، به سادگی آن را تا حد امکان با ظرافت پایان دهید و یک جایگزین را بچرخانید.
بازگشت مجدد: اگر استقرار بدی دارید، بازگرداندن اجزای بدون حالت بسیار آسان تر است، زیرا می توانید آنها را خاتمه دهید و به جای آن نمونه هایی از نسخه قدیمی را راه اندازی کنید.
Load-Balance در سراسر: هنگامی که مؤلفه ها بدون حالت هستند، تعادل بار بسیار ساده تر است زیرا هر نمونه می تواند هر درخواستی را انجام دهد. متعادل‌سازی بار در مؤلفه‌های حالت‌دهنده بسیار سخت‌تر است، زیرا وضعیت جلسه کاربر معمولاً بر روی نمونه قرار می‌گیرد و آن نمونه را مجبور می‌کند تا همه درخواست‌های یک کاربر مشخص را رسیدگی کند.
اصل 3: خدمات مدیریت شده را مورد پسند قرار دهید
ابر چیزی فراتر از زیرساخت است. اکثر ارائه دهندگان ابری مجموعه ای غنی از خدمات مدیریت شده را ارائه می دهند که انواع عملکردهایی را ارائه می دهند که شما را از دردسر مدیریت نرم افزار یا زیرساخت باطن رها می کند. با این حال، بسیاری از سازمان‌ها در مورد استفاده از این خدمات محتاط هستند زیرا نگران قفل شدن در یک ارائه‌دهنده خاص هستند. این یک نگرانی معتبر است، اما خدمات مدیریت شده اغلب می تواند سازمان را در زمان و هزینه های عملیاتی بسیار نجات دهد.
به طور کلی، تصمیم در مورد پذیرش یا عدم پذیرش خدمات مدیریت شده به قابلیت حمل و نقل در مقابل هزینه های عملیاتی بستگی دارد، هم از نظر پول و هم از نظر مهارت. به طور کلی، خدمات مدیریت شده ای که ممکن است امروز در نظر بگیرید به سه دسته کلی تقسیم می شوند:

منبع باز مدیریت شده یا سرویس های سازگار با منبع باز: خدماتی که منبع باز مدیریت می شوند (به عنوان مثال Cloud SQL) یا یک رابط سازگار با منبع باز ارائه می کنند (مثلا Cloud Bigtable). این باید یک انتخاب آسان باشد زیرا مزایای زیادی در استفاده از سرویس مدیریت شده و ریسک کمی وجود دارد.
سرویس‌های مدیریت‌شده با صرفه‌جویی عملیاتی بالا: برخی از سرویس‌ها فوراً با منبع باز سازگار نیستند یا جایگزین منبع باز فوری ندارند، اما مصرف آن‌ها بسیار آسان‌تر از گزینه‌های جایگزین است که ارزش ریسک را دارند. به عنوان مثال، BigQuery اغلب توسط سازمان ها پذیرفته می شود زیرا کار با آن بسیار آسان است.
هر چیز دیگر: سپس موارد سخت وجود دارد، جایی که هیچ مسیر مهاجرت آسانی در خارج از سرویس وجود ندارد و یک مزیت عملیاتی کمتر آشکار را ارائه می دهد. شما باید این موارد را به صورت موردی بررسی کنید، با در نظر گرفتن مواردی مانند اهمیت استراتژیک سرویس، هزینه عملیاتی اجرای آن توسط خودتان، و تلاش مورد نیاز برای مهاجرت.
با این حال، تجربه عملی نشان داده است که اکثر معماری‌های بومی ابری از خدمات مدیریت شده حمایت می‌کنند. خطر بالقوه مهاجرت از آنها به ندرت بر صرفه جویی عظیم در زمان، تلاش و ریسک عملیاتی مدیریت خدمات در مقیاس بزرگ توسط ارائه دهنده ابر از طرف شما بیشتر است.

اصل 4: دفاع را عمیقاً تمرین کنید
معماری‌های سنتی اعتقاد زیادی به امنیت محیطی دارند، محیطی سخت شبکه با «چیزهای قابل اعتماد» در داخل و «چیزهای غیرقابل اعتماد» در خارج. متأسفانه، مانند ما، این رویکرد همیشه در برابر حملات خودی آسیب پذیر بوده است

به عنوان تهدیدهای خارجی مانند نیزه فیشینگ. علاوه بر این، فشار فزاینده برای ارائه کار انعطاف پذیر و سیار، محیط شبکه را بیشتر تضعیف کرده است.
معماری‌های بومی ابری منشأ خود را در سرویس‌های روبه‌روی اینترنت دارند و بنابراین همیشه برای مقابله با حملات خارجی نیاز بوده‌اند. بنابراین آنها با اعمال احراز هویت بین هر مؤلفه، و با به حداقل رساندن اعتماد بین آن مؤلفه‌ها (حتی اگر «داخلی» باشند، رویکرد دفاعی عمیق را اتخاذ می‌کنند. در نتیجه، «درون» و «بیرون» وجود ندارد.

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

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