رایانش ابری توضیح داده شد: ۱۱ مفهوم معماری که باید بدانید (مسترکلاس 4K).

این ویدیو چه مواردی را پوشش می‌دهد

• - دیوار معماری و نقشه اصلی
• - ۰۱. مقیاس‌بندی عمودی در برابر افقی
• - ۰۲. معماری متعادل‌سازی بار (L4 در برابر L7 و بررسی‌های سلامت)
• - ۰۳. مقیاس‌بندی خودکار و کشسانی
• - ۰۴. بدون سرور (FaaS و MicroVMهای Firecracker)

رونوشت ترجمه شده

ترجمه شده از روایت اصلی انگلیسی. صوت و زیرنویس‌های موجود توسط YouTube کنترل می‌شوند.

- دیوار معماری و نقشه اصلی

0:00 هر مهندس نرم‌افزاری بالاخره با دیوار معماری ابری روبرو می‌شود. شما یک برنامه را روی لپ‌تاپ خود می‌سازید، آن را به محیط تولید می‌فرستید، و به محض رسیدن کاربران واقعی، سرورها از کار می‌افتند، اتصالات پایگاه داده به پایان می‌رسد، و صورتحساب AWS شما مانند یک شماره تلفن به نظر می‌رسد. بیشتر توسعه‌دهندگان سعی می‌کنند مهندسی ابری را با حفظ کردن سیصد مخفف محصول مختلف AWS حل کنند. اما رایانش ابری واقعی درباره حفظ کردن کاتالوگ‌های فروشنده نیست: بلکه بر اساس یازده اصل معماری بنیادی ساخته شده است.

0:34 در این مسترکلاس، ما کل طرح سازمانی را بررسی خواهیم کرد: از مقیاس‌بندی و متعادل‌سازی بار تا بدون سرور، جداسازی رویدادمحور، سلسله‌مراتب ذخیره‌سازی، و شبکه‌سازی ابری. این یازده مفهوم را مسلط شوید، و می‌توانید هر بک‌اندی را در AWS، GCP، یا Azure طراحی کنید. این The Daily Diff است، در پشت صحنه.

- ۰۱. مقیاس‌بندی عمودی در برابر افقی

0:57 مفهوم شماره یک: مقیاس‌بندی. هنگامی که برنامه شما رشد ترافیک را تجربه می‌کند، دو روش اساساً متفاوت برای مدیریت بار دارید: مقیاس‌بندی عمودی، یا مقیاس‌بندی افقی. مقیاس‌بندی عمودی، یا افزایش مقیاس، به معنای گرفتن ماشین موجود شما و افزودن منابع بیشتر است: ارتقاء از چهار هسته CPU به سی و دو، یا تعویض سی و دو گیگابایت رم با صد و بیست و هشت گیگابایت. مقیاس‌بندی عمودی نیاز به هیچ تغییر معماری ندارد: کد شما

1:28 و پایگاه داده دقیقاً یکسان می‌مانند. اما به یک سقف سخت‌افزاری بی‌رحمانه می‌رسد. هیچ ماشین واحدی در جهان ده هزار هسته CPU ندارد، و نمونه‌های رده بالا قیمت گزافی دارند. مقیاس‌بندی افقی، یا گسترش مقیاس، به معنای کوچک نگه داشتن سرورهای شما و قیمت‌گذاری کالایی آنها، اما اجرای چندین نمونه به صورت موازی پشت یک روتر است. اگر یک نمونه از کار بیفتد، گره‌های باقیمانده ترافیک را با صفر زمان توقف جذب می‌کنند. قانون طلایی مقیاس‌بندی افقی،

2:01 بی‌حالتی است: سرورهای برنامه شما نمی‌توانند جلسات کاربر، فایل‌های بارگذاری شده، یا حالت را روی دیسک‌های محلی خود ذخیره کنند. حالت باید در یک پایگاه داده یا کش خارجی زندگی کند، که به هر گره اجازه می‌دهد هر درخواست کاربر را مدیریت کند.

- ۰۲. معماری متعادل‌سازی بار (L4 در برابر L7 و بررسی‌های سلامت)

2:17 مفهوم شماره دو: متعادل‌سازی بار. مقیاس‌بندی افقی روی کاغذ عالی به نظر می‌رسد، اما یک مشکل فوری ایجاد می‌کند: هنگامی که ده هزار کاربر به نام دامنه شما مراجعه می‌کنند، کدام سرور خاص ترافیک آنها را دریافت می‌کند؟ یک متعادل‌کننده بار به عنوان یک پروکسی معکوس بین اینترنت عمومی و خوشه بک‌اند خصوصی شما عمل می‌کند. اتصالات TCP یا HTTP ورودی را می‌پذیرد و درخواست‌ها را بین نمونه‌های سالم شما توزیع می‌کند.

2:47 متعادل‌کننده‌های بار در دو لایه اصلی شبکه کار می‌کنند. متعادل‌کننده‌های بار شبکه لایه ۴ در لایه انتقال کار می‌کنند، بسته‌های TCP و UDP خام را بر اساس آدرس IP و پورت مسیریابی می‌کنند با تأخیر میکروثانیه و میلیون‌ها درخواست در ثانیه. متعادل‌کننده‌های بار برنامه لایه ۷ پروتکل HTTP را خود بررسی می‌کنند: مسیرهای URL، هدرهای درخواست، کوکی‌ها، و متدهای HTTP را می‌خوانند. این امکان مسیریابی مبتنی بر مسیر را فراهم می‌کند: ارسال درخواست‌های slash-api به خوشه بک‌اند شما و درخواست‌های slash-static به یک

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

- ۰۳. مقیاس‌بندی خودکار و کشسانی

3:45 مفهوم شماره سه: مقیاس‌بندی خودکار. اگر برنامه وب شما در ساعت سه صبح به دو سرور نیاز دارد، اما در طول یک راه‌اندازی در اواسط روز به بیست سرور نیاز دارد، دستی کلیک کردن روی دکمه‌ها در کنسول ابری راهی تضمینی برای زمان توقف و ورشکستگی است. مقیاس‌بندی خودکار کشسانی پویا را به مجموعه‌های سرور افقی می‌آورد. یک گروه مقیاس‌بندی خودکار معیارهای عملکردی مانند میانگین استفاده از CPU، ورودی/خروجی شبکه، یا عمق صف backlog را نظارت می‌کند. هنگامی که میانگین CPU از یک آستانه تعریف شده عبور می‌کند - مثلاً،

4:19 هفتاد درصد برای سه دقیقه متوالی - مقیاس‌دهنده خودکار به طور خودکار ماشین‌های مجازی جدید را راه‌اندازی می‌کند، آنها را با متعادل‌کننده بار شما ثبت می‌کند، و شروع به مسیریابی ترافیک می‌کند. همینقدر مهم است کاهش مقیاس: هنگامی که موج ترافیک فروکش می‌کند، مقیاس‌دهنده خودکار نمونه‌های اضافی را خاتمه می‌دهد تا شما دیگر هزینه پردازش بیکار را پرداخت نکنید. برای جلوگیری از نوسان - جایی که سرورها به سرعت ایجاد و در یک حلقه بی‌پایان نابود می‌شوند - معماران ابری دوره‌های خنک‌سازی را پیکربندی می‌کنند. مفهوم شماره چهار: بدون سرور.

- ۰۴. بدون سرور (FaaS و MicroVMهای Firecracker)

4:53 برای سال‌ها، تیم‌های بازاریابی سرورلس را به عنوان کد جادویی که در آسمان اجرا می‌شود، معرفی می‌کردند. در واقعیت، سرورلس هنوز از سرورها استفاده می‌کند - اما شما مالک آنها نیستید، آنها را پچ نمی‌کنید، یا زمانی که کدی در حال اجرا نیست، برای آنها پول نمی‌دهید. با Function-as-a-Service مانند AWS Lambda یا Google Cloud Functions، شما یک تابع handler مستقل می‌نویسید. هنگامی که یک درخواست HTTP، بارگذاری فایل S3، یا تغییر پایگاه داده رخ می‌دهد، زمان اجرای ابری یک

5:23 میکرو-ماشین مجازی موقت مانند Firecracker را در کمتر از پنج میلی‌ثانیه راه‌اندازی می‌کند. کد شما اجرا می‌شود، پاسخ را برمی‌گرداند، و خاموش می‌شود. اگر کسی برای سه ماه از وب‌سایت شما بازدید نکند، صورتحساب محاسباتی شما دقیقاً صفر دلار و صفر سنت است. اگر یک میلیون کاربر به طور همزمان به آن مراجعه کنند، ارائه دهنده یک میلیون microVM همزمان را راه‌اندازی می‌کند. مبادلات مهندسی واقعی هستند: تأخیر شروع سرد هنگام راه‌اندازی زمان‌های اجرای تازه، یک محدودیت اجرای سفت و سخت پانزده دقیقه‌ای در Lambda، و بی‌حالتی سختگیرانه.

5:55 سرورلس برای خطوط لوله رویداد و APIهای پراکنده بی‌نظیر است، اما برای WebSockets پایدار یا اجرای آموزش چند ساعته ضعیف است.

- ۰۵. معماری رویدادمحور (EDA و جداسازی)

6:05 مفهوم شماره پنج: معماری رویدادمحور، یا EDA. در معماری‌های سنتی، خدمات به صورت همزمان ارتباط برقرار می‌کنند. سرویس تسویه حساب شما به پرداخت تماس می‌گیرد، پرداخت به موجودی تماس می‌گیرد، موجودی به تقلب تماس می‌گیرد، و تقلب به ایمیل تماس می‌گیرد. این آبشار همزمان فنا را ایجاد می‌کند. اگر ارائه‌دهنده ایمیل شخص ثالث دچار اختلال شبکه شود و ده ثانیه طول بکشد تا پاسخ دهد، کل درخواست تسویه حساب مشتری شما با یک خطا زمان‌بندی می‌شود. در یک معماری رویدادمحور، خدمات به طور کامل جدا می‌شوند.

6:37 هنگامی که مشتری روی خرید کلیک می‌کند، سرویس تسویه حساب به خدمات پایین‌دستی تماس نمی‌گیرد. فقط یک رویداد به نام OrderPlaced را به یک گذرگاه رویداد مرکزی مانند Amazon EventBridge یا یک موضوع SNS منتشر می‌کند. تسویه حساب در پنجاه میلی‌ثانیه تکمیل می‌شود. کارگران پایین‌دستی برای پرداخت، کسر موجودی، و رسیدهای ایمیل پیام‌ها را به طور مستقل از صفوف SQS اختصاصی خود دریافت می‌کنند. اگر سرویس ایمیل برای یک ساعت از کار بیفتد، پیام‌ها به طور ایمن در صف بافر می‌شوند بدون اینکه حتی یک سفارش از دست برود.

- ۰۶. ارکستراسیون کانتینر (Docker و Kubernetes)

7:13 مفهوم شماره شش: ارکستراسیون کانتینر. داکر بسته‌بندی را حل کرد: کد برنامه شما را، کتابخانه‌های سیستمی، پیکربندی، و زمان اجرا را در یک ایمیج تغییرناپذیر که به طور یکسان روی مک‌بوک شما و در ابر اجرا می‌شود، لفافه‌بندی می‌کند. اما بسته‌بندی یک کانتینر آسان است. اجرای پانصد کانتینر در پنجاه ماشین مجازی فیزیکی جایی است که مهندسی از کار می‌افتد. به همین دلیل است که ارکستراتورهای کانتینر مانند Kubernetes و AWS ECS

7:41 وجود دارند. یک ارکستراتور یک صفحه کنترل را فراهم می‌کند: یک سرور API، یک فروشگاه حالت etcd، و یک برنامه‌ریز هوشمند. شما حالت مطلوب خود را اعلام می‌کنید: من ده نمونه از سرویس احراز هویت خود را با دو گیگابایت رم برای هر کدام می‌خواهم. برنامه‌ریز خوشه را بازرسی می‌کند، پادها را روی گره‌هایی با حافظه آزاد قرار می‌دهد، شبکه‌سازی داخلی را پیکربندی می‌کند، و واقعیت را به طور مداوم تطبیق می‌دهد. اگر یک گره دچار خرابی سخت‌افزاری شود، Kubernetes فقدان را تشخیص می‌دهد و فوراً همه پادهای جابجا شده را روی

- ۰۷. ۴ ستون ذخیره‌سازی ابری (S3, EBS, DBs و Redis)

8:16 گره‌های سالم دوباره برنامه‌ریزی می‌کند. مفهوم شماره هفت: سلسله‌مراتب ذخیره‌سازی ابری. مبتدیان اغلب ذخیره‌سازی ابری را به عنوان یک سطل واحد در نظر می‌گیرند که در آن فایل‌ها را می‌ریزند. در معماری تولید، ذخیره‌سازی به چهار ستون مجزا بر اساس الگوهای دسترسی و تأخیر تقسیم می‌شود. اول ذخیره‌سازی اشیاء است، مانند Amazon S3 یا Google Cloud Storage. شما به فایل‌ها از طریق HTTP REST API با استفاده از فراخوانی‌های ساده PUT و GET دسترسی پیدا می‌کنید. ظرفیت افقی بی‌نهایت را با دو سنت به ازای هر گیگابایت در ماه ارائه می‌دهد،

8:49 که آن را برای ویدئو، بارگذاری‌های کاربر، لاگ‌ها، و پشتیبان‌گیری ایده‌آل می‌کند. دوم ذخیره‌سازی بلوکی است، مانند Amazon EBS. اینها هارد دیسک‌های مجازی هستند که مستقیماً به یک ماشین مجازی خاص از طریق اتصالات پرسرعت متصل می‌شوند. آنها به سیستم‌فایل‌های استاندارد مانند ext4 فرمت می‌شوند، که دسترسی سریع خواندن و نوشتن تصادفی مورد نیاز موتورهای پایگاه داده را پشتیبانی می‌کنند. سوم پایگاه داده‌های مدیریت شده هستند: موتورهای رابطه‌ای مانند PostgreSQL در RDS که تراکنش‌های ACID و پیوندهای پیچیده را فراهم می‌کنند،

9:21 و موتورهای NoSQL مانند DynamoDB که تأخیر یک رقمی میلی‌ثانیه را در مقیاس عظیم ارائه می‌دهند. و چهارم کش‌های درون حافظه‌ای مانند Redis هستند. خواندن داده‌ها از RAM میکروثانیه به جای میلی‌ثانیه طول می‌کشد. کش‌ها جلوی پایگاه داده شما قرار می‌گیرند، آن را از ترافیک خواندن مکرر محافظت می‌کنند و توکن‌های جلسه کاربر فرار را مدیریت می‌کنند.

- ۰۸. در دسترس بودن بالا و نه‌ها (بازیابی در صورت شکست چند منطقه‌ای)

9:44 مفهوم شماره هشت: در دسترس بودن بالا، یا HA. در دسترس بودن به یک سوال پاسخ می‌دهد: چند درصد از زمان، برنامه شما عملیاتی و برای کاربران قابل دسترس است؟ در قراردادهای سازمانی، در دسترس بودن با نه‌ها اندازه‌گیری می‌شود. دو نه، یا نود و نه درصد در دسترس بودن، بیش از سه و نیم روز زمان توقف در هر سال را اجازه می‌دهد. چهار نه، زمان توقف مجاز را به پنجاه و دو دقیقه کاهش می‌دهد، و پنج نه، فقط پنج دقیقه زمان توقف کلی در هر

10:15 سال را مجاز می‌داند. برای دستیابی به در دسترس بودن بالا، باید نقاط شکست واحد را در سراسر دامنه‌های خطا حذف کنید. در ابر، این به معنای استقرار در چندین منطقه در دسترس بودن است. یک منطقه در دسترس بودن یک قفسه واحد نیست: بلکه یک یا چند مرکز داده فیزیکی مجزا با مایل‌ها فاصله با برق و خنک‌کننده مستقل است. با اجرای نمونه‌های فعال در منطقه A و منطقه B با تکثیر پایگاه داده همزمان، یک رعد و برق یا قطع فیبر که کل یک تأسیسات فیزیکی را از کار می‌اندازد، منجر به یک بازیابی خودکار می‌شود.

10:50 در سی ثانیه با صفر مداخله انسانی.

- ۰۹. دوام در برابر در دسترس بودن (چرا ۱۱ نه، زمان فعال بودن نیست)

10:53 مفهوم شماره نه: دوام در مقابل در دسترس بودن. این رایج‌ترین تله مفهومی در مصاحبه‌های معماری ابری است. مهندسان اغلب کلمات را به جای یکدیگر استفاده می‌کنند، اما آنها ویژگی‌های کاملاً متفاوتی را اندازه‌گیری می‌کنند. در دسترس بودن زمان کار را اندازه می‌گیرد: آیا می‌توانم همین الان یک فراخوانی API برای خواندن یا نوشتن داده‌هایم انجام دهم؟ داده‌هایم همین الان؟ دوام حفظ و نگهداری را اندازه‌گیری می‌کند: آیا داده‌های من بدون خرابی دائمی، فساد یا تخریب در طی ده سال باقی می‌مانند؟

11:24 به Amazon S3 Standard نگاه کنید. توافق‌نامه سطح خدمات آن نود و نه ممیز نه درصد در دسترس بودن را ارائه می‌دهد که تقریباً چهل و سه دقیقه از زمان خرابی در هر ماه را مجاز می‌داند که در آن درخواست API ممکن است خطای پانصد را برگرداند. اما S3 یازده نه از دوام را وعده می‌دهد: نود و نه ممیز نه نه نه نه نه نه نه نه نه درصد. اگر ده میلیون فایل را در S3 ذخیره کنید، می‌توانید به صورت آماری انتظار داشته باشید که به طور متوسط یک فایل را هر ده هزار سال از دست بدهید.

11:56 به طور متوسط یک فایل را هر ده هزار سال از دست بدهید. S3 این را با کدگذاری محوکننده اشیاء و تکثیر تکه‌ها در حداقل سه مرکز داده جدا شده جغرافیایی به دست می‌آورد. در طول یک قطعی شبکه منطقه‌ای عمده، S3 ممکن است به طور موقت در دسترس نباشد، اما داده‌های شما هرگز از بین نمی‌روند.

- ۱۰. زیرساخت به عنوان کد (Terraform در برابر Console Drift)

12:14 مفهوم شماره ده: زیرساخت به عنوان کد، یا IaC. در روزهای اولیه محاسبات ابری، مهندسان وارد کنسول مدیریت وب AWS می‌شدند و به صورت دستی برای ایجاد ماشین‌های مجازی، پیکربندی زیرشبکه‌ها و پیوست کردن گروه‌های امنیتی کلیک می‌کردند. ماشین‌های مجازی، زیرشبکه‌ها را پیکربندی و گروه‌های امنیتی را پیوست می‌کردند. صنعت این را ClickOps می‌نامد و در تولید، یک فاجعه مطلق است. تغییرات دستی کنسول فاقد مسیر حسابرسی، مکانیسم بازگشت به عقب هستند و به ناچار باعث رانش پیکربندی بین محیط‌های مرحله‌بندی و تولید می‌شوند. با ابزارهای Infrastructure as Code مانند Terraform,

12:48 با ابزارهای زیرساخت به عنوان کد مانند Terraform، OpenTofu، Pulumi یا AWS CDK، شما کل معماری ابری خود را در فایل‌های پیکربندی اعلامی ذخیره شده در Git تعریف می‌کنید. هر تغییری در یک پورت باز یا یک پایگاه داده تکراری از طریق یک درخواست pull و بازبینی همتا انجام می‌شود. اجرای طرح Terraform، diff دقیق API را قبل از دست زدن به هر چیزی پیش‌نمایش می‌کند، و راه‌اندازی یک کپی یکسان از پشته تولید شما چهار دقیقه به جای چهار هفته طول می‌کشد.

- ۱۱. شبکه‌سازی ابری (VPC, Subnets, NAT و Security Groups)

13:20 مفهوم شماره یازده: شبکه‌بندی ابری و ابرهای خصوصی مجازی. هنگامی که سرورها را در ابر مستقر می‌کنید، آنها در اینترنت عمومی خام آشکار نیستند. آنها در یک مرز ایزوله تعریف شده توسط نرم‌افزار به نام VPC زندگی می‌کنند. در داخل VPC خود، یک فضای آدرس IP خصوصی مانند ده-نقطه-صفر-نقطه-صفر-نقطه-صفر اسلش شانزده اختصاص می‌دهید و آن را به زیرشبکه‌های عمومی و خصوصی تقسیم می‌کنید. یک زیرشبکه عمومی دارای یک مسیر مستقیم به یک اینترنت گیت‌وی است.

13:51 این شامل دارایی‌های رو به روی عمومی مانند متعادل‌کننده‌های بار برنامه شما و NAT گیت‌وی‌ها می‌شود. این تنها بخشی از شبکه شما است که دارای آدرس‌های IP عمومی است. سرورهای برنامه و پایگاه داده‌های تولیدی شما به طور کامل در زیرشبکه‌های خصوصی با IPهای عمومی صفر و مسیرهای ورودی صفر از اینترنت زندگی می‌کنند. هنگامی که سرورهای پشتیبان شما نیاز به دانلود به‌روزرسانی‌های امنیتی دارند، ترافیک خروجی آنها از طریق NAT Gateway در زیرشبکه عمومی هدایت می‌شود. در اطراف هر نمونه گروه‌های امنیتی وجود دارد: فایروال‌های مجازی وضعیت‌دار که اصل حداقل امتیاز را اعمال می‌کنند.

- ۱۲. نقشه کامل سازمانی و رأی

14:28 گروه امنیتی پایگاه داده شما فقط اتصالات را روی پورت 5432 فقط از گروه امنیتی سرورهای برنامه شما می‌پذیرد، که نفوذ خارجی را از نظر ریاضی غیرممکن می‌کند. وقتی به عقب برگردید، این یازده اصل به یک سیستم منسجم متصل می‌شوند. DNS شما به یک متعادل‌کننده بار در یک زیرشبکه عمومی مسیردهی می‌کند، گروه‌های مقیاس‌پذیری خودکار افزایش ترافیک را در چندین منطقه در دسترس بودن مدیریت می‌کنند، باس‌های رویداد کارگران پشتیبان را از یکدیگر جدا می‌کنند، و کل پشته شما با استفاده از Infrastructure as Code از Git مستقر می‌شود.

15:02 نتیجه‌گیری مسترکلاس امروز: SHIP IT. حفظ کردن صدها اختصار بازاریابی ابری را متوقف کنید. این یازده الگوی معماری را مسلط شوید، وضعیت خود را از یکدیگر جدا کنید، و سیستم‌هایی بسازید که نمی‌توانند از کار بیفتند. به من بگویید کدام مفهوم ابری هنگام شروع به ساخت و ساز در نظرات، بزرگترین دردسر را برای شما ایجاد کرد. هنگام شروع به ساخت و ساز در نظرات. و برای دریافت برگه تقلب کامل معماری، در خبرنامه در the daily diff dot dev مشترک شوید،

15:28 لینک زیر. و این diff برای امروز است. من نیکو از Axrisi هستم. با مسئولیت‌پذیری ادغام کنید.

منابع

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io