طراحی وب سایت اختصاصی برای مقیاس بالا و در دسترس بودن بالا در پروژه‌های مثل اسنپ و دیجی کالا
این سند در Google Cloud Architecture Framework اصول طراحی سایت اختصاصی را برای معماری سرویس‌های شما ارائه می‌کند تا بتوانند شکست‌ها و مقیاس را در پاسخ به تقاضای مشتری تحمل کنند. یک سرویس قابل اعتماد همچنان به درخواست‌های مشتری پاسخ می‌دهد زمانی که تقاضای زیادی برای سرویس وجود دارد یا زمانی که یک رویداد تعمیر و نگهداری وجود دارد. اصول طراحی قابلیت اطمینان زیر و بهترین شیوه ها باید بخشی از معماری سیستم و طرح استقرار شما باشد.
برای دسترسی بیشتر، افزونگی ایجاد کنید
سیستم‌هایی که نیاز به قابلیت اطمینان بالا دارند، نباید نقطه‌ای از خرابی واحد داشته باشند و منابع آن‌ها باید در چندین حوزه خرابی تکرار شوند. دامنه شکست مجموعه ای از منابع است که می تواند به طور مستقل از کار بیفتد، مانند یک نمونهVM ، منطقه یا منطقه. هنگامی که در دامنه‌های شکست تکرار می‌کنید، سطح دسترسی کلی بالاتری نسبت به نمونه‌های منفرد دریافت می‌کنید. برای اطلاعات بیشتر، به مناطق و مناطق مراجعه کنید.
*به عنوان یک مثال خاص از افزونگی که ممکن است بخشی از معماری سیستم شما باشد، به منظور جداسازی خرابی‌ها در ثبت DNS در مناطق جداگانه، از نام‌های DNS منطقه‌ای برای نمونه‌هایی در همان شبکه برای دسترسی به یکدیگر استفاده کنید.
یک معماری چند منطقه‌ای با failover برای دسترسی بالا طراحی کنید
برنامه خود را در برابر خرابی‌های ناحیه ای با معماری آن برای استفاده از مجموعه‌هایی از منابع توزیع شده در چندین منطقه، با تکرار داده ها، متعادل سازی بار و خطای خودکار بین مناطق، انعطاف پذیر کنید. کپی‌های منطقه‌ای هر لایه از پشته برنامه را اجرا کنید و تمام وابستگی‌های منطقه‌ای متقاطع را در معماری حذف کنید.
تکرار داده‌ها در سراسر مناطق برای بازیابی فاجعه
داده‌ها را در یک منطقه دورافتاده کپی یا بایگانی کنید تا در صورت قطع یا از دست رفتن داده‌ها، بازیابی بلایای طبیعی را فعال کنید. وقتی از Replication استفاده می‌شود، بازیابی سریع‌تر انجام می‌شود، زیرا سیستم‌های ذخیره‌سازی در منطقه دور از قبل دارای داده‌هایی هستند که تقریباً به‌روز هستند، جدای از از دست دادن احتمالی مقدار کمی از داده‌ها به دلیل تأخیر تکرار. وقتی از بایگانی دوره ای به جای تکرار مداوم استفاده می کنید، بازیابی فاجعه شامل بازیابی داده ها از پشتیبان ها یا بایگانی ها در یک منطقه جدید است. این روش معمولاً منجر به از کار افتادن سرویس طولانی‌تر از فعال‌سازی یک نسخه به‌روزرسانی مداوم پایگاه داده می‌شود و به دلیل فاصله زمانی بین عملیات پشتیبان‌گیری متوالی می‌تواند منجر به از دست دادن داده‌های بیشتری شود. از هر رویکردی که استفاده شود، کل پشته برنامه باید مجدداً مستقر شود و در منطقه جدید راه اندازی شود، و تا زمانی که این اتفاق می افتد، سرویس در دسترس نخواهد بود.
برای بحث دقیق در مورد مفاهیم و تکنیک‌های بازیابی فاجعه، به معماری بازیابی فاجعه برای خاموشی‌های زیرساخت ابری مراجعه کنید.
طراحی معماری چند منطقه‌ای برای تاب‌آوری در برابر قطعی‌های منطقه‌ای
اگر سرویس شما حتی در موارد نادری که کل یک منطقه از کار می افتد نیاز به اجرای مداوم دارد، آن را طوری طراحی کنید که از مجموعه هایی از منابع محاسباتی توزیع شده در مناطق مختلف استفاده کند. کپی های منطقه ای هر لایه از پشته برنامه را اجرا کنید.
از تکثیر داده‌ها در مناطق مختلف و از خطای خودکار زمانی که یک منطقه پایین می‌رود استفاده کنید. برخی از سرویس‌های Google Cloud دارای انواع چند منطقه‌ای هستند، مانند BigQuery و Cloud Spanner. برای انعطاف پذیری در برابر شکست های منطقه ای، در صورت امکان از این خدمات چند منطقه ای در طراحی خود استفاده کنید. برای اطلاعات بیشتر در مورد مناطق و در دسترس بودن خدمات، مکان‌های Google Cloud را ببینید.
اطمینان حاصل کنید که هیچ وابستگی بین منطقه ای وجود ندارد تا وسعت تأثیر یک شکست در سطح منطقه به آن منطقه محدود شود.
نقاط خراب منطقه ای را حذف کنید، مانند پایگاه داده اولیه تک منطقه ای که ممکن است در صورت غیرقابل دسترس بودن باعث قطعی جهانی شود. توجه داشته باشید که معماری های چند منطقه ای اغلب هزینه بیشتری دارند، بنابراین قبل از اتخاذ این رویکرد، نیاز کسب و کار را در مقابل هزینه در نظر بگیرید.
برای راهنمایی بیشتر در مورد اجرای افزونگی در دامنه‌های خرابی، به مقاله نظرسنجی Deployment Archetypes for Cloud Applications (PDF) مراجعه کنید.
گلوگاه‌های مقیاس‌پذیری را از بین ببرید
اجزای سیستم را که نمی توانند فراتر از محدودیت منابع یک VM یا یک منطقه واحد رشد کنند، شناسایی کنید. برخی از برنامه‌ها به صورت عمودی مقیاس می‌شوند، جایی که شما هسته‌های CPU، حافظه یا پهنای باند شبکه بیشتری را در یک نمونه ماشین مجازی اضافه می‌کنید تا از افزایش بار استفاده کنید. این برنامه‌ها محدودیت‌های سختی در مقیاس‌پذیری خود دارند، و اغلب باید به صورت دستی آن‌ها را برای مدیریت رشد پیکربندی کنید.
در صورت امکان، این مؤلفه‌ها را به‌گونه‌ای طراحی سایت کنید که به صورت افقی، مانند تقسیم‌بندی یا پارتیشن‌بندی، در بین ماشین‌های مجازی یا مناطق، مقیاس‌بندی شوند. برای مدیریت رشد ترافیک یا استفاده، قطعات بیشتری اضافه می‌کنید. از انواع استاندارد VM استفاده کنید که می توانند به طور خودکار اضافه شوند تا افزایش بار هر خرده را کنترل کنند. برای اطلاعات بیشتر، الگوهای برنامه‌های مقیاس‌پذیر و انعطاف‌پذیر را ببینید.
اگر نمی‌توانید برنامه را دوباره طراحی کنید، می‌توانید مؤلفه‌های مدیریت شده توسط شما را با سرویس‌های ابری کاملاً مدیریت‌شده که برای مقیاس افقی بدون هیچ اقدام کاربر طراحی شده‌اند، جایگزین کنید.
در صورت بارگذاری بیش از حد، سطح خدمات را به خوبی تنزل دهید
خدمات خود را طوری طراحی سایت و سئو سایت کنید که بار اضافی را تحمل کند. سرویس‌ها باید اضافه بار را شناسایی کرده و پاسخ‌های با کیفیت پایین‌تر را به آن برگردانند
کاربر یا تا حدی ترافیک را کاهش نمی دهد، به طور کامل تحت بار اضافی شکست نمی خورد.
*به عنوان مثال، یک سرویس می‌تواند به درخواست‌های کاربر با صفحات وب استاتیک پاسخ دهد و رفتار پویا را که پردازش آن هزینه بیشتری دارد، موقتاً غیرفعال کند. این رفتار در الگوی شکست گرم از Compute Engine تا Cloud Storage به تفصیل آمده است. یا، این سرویس می‌تواند به عملیات فقط خواندنی اجازه دهد و به‌روزرسانی داده‌ها را موقتاً غیرفعال کند.
باید به اپراتورها اطلاع داده شود تا هنگام تنزل سرویس، وضعیت خطا را تصحیح کنند.
جلوگیری و کاهش افزایش ترافیک
درخواست ها را بین مشتریان همگام نکنید. تعداد زیادی از مشتریانی که ترافیک را در همان لحظه ارسال می کنند باعث افزایش ترافیک می شود که ممکن است باعث خرابی های آبشاری شود.
استراتژی‌های کاهش سنبله را در سمت سرور اجرا کنید، مانند throttling، صف‌بندی، کاهش بار یا قطع شدن مدار، تخریب زیبا و اولویت‌بندی درخواست‌های حیاتی.
استراتژی‌های کاهش در مشتری شامل مهار سمت مشتری و عقب‌نشینی نمایی با جیتر است.
ورودی ها را ضدعفونی و تأیید کنید
برای جلوگیری از ورودی‌های اشتباه، تصادفی یا مخرب که باعث قطع سرویس یا نقض امنیت می‌شوند، پارامترهای ورودی APIها و ابزارهای عملیاتی را پاکسازی و اعتبارسنجی کنید. به عنوان مثال، Apigee و Google Cloud Armor می توانند به محافظت در برابر حملات تزریق کمک کنند.
به طور منظم از تست فازی استفاده کنید، جایی که یک مهار تست عمداً APIهایی را با ورودی های تصادفی، خالی یا خیلی بزرگ فراخوانی می کند. این تست ها را در یک محیط تست ایزوله انجام دهید.
ابزارهای عملیاتی باید به طور خودکار تغییرات پیکربندی را قبل از اجرای تغییرات تأیید کنند و در صورت عدم موفقیت باید تغییرات را رد کنند.
ایمن از کار افتادن به گونه ای که عملکرد را حفظ کند
اگر به دلیل مشکلی نقصی وجود داشته باشد، اجزای سیستم باید به نحوی از کار بیفتند که به کل سیستم اجازه دهد به کار خود ادامه دهد. این مشکلات ممکن است یک اشکال نرم افزاری، ورودی یا پیکربندی نامناسب، قطعی نمونه برنامه ریزی نشده یا خطای انسانی باشد. فرآیند خدمات شما به تعیین اینکه آیا باید بیش از حد سهل‌گیرانه یا بیش از حد ساده‌گرا باشید، به جای اینکه بیش از حد محدودکننده باشید، کمک می‌کند.
سناریوهای نمونه زیر و نحوه پاسخگویی به شکست را در نظر بگیرید:
معمولاً بهتر است یک مؤلفه فایروال با پیکربندی بد یا خالی باز نشود و اجازه دهد ترافیک شبکه غیرمجاز برای مدت کوتاهی از آن عبور کند در حالی که اپراتور خطا را برطرف می کند. این رفتار سرویس را در دسترس نگه می‌دارد، نه اینکه شکست بخورد و 100% ترافیک مسدود شود. این سرویس باید به بررسی های احراز هویت و مجوز بیشتر در پشته برنامه تکیه کند تا در حین عبور تمام ترافیک از مناطق حساس محافظت کند.
با این حال، بهتر است یک جزء سرور مجوز که دسترسی به داده‌های کاربر را کنترل می‌کند بسته نشود و همه دسترسی‌ها را مسدود کند. این رفتار وقتی که پیکربندی خراب است باعث قطع سرویس می شود، اما از خطر نشت اطلاعات محرمانه کاربر در صورت باز نشدن آن جلوگیری می کند.
در هر دو مورد، خرابی باید یک هشدار با اولویت بالا ایجاد کند تا اپراتور بتواند شرایط خطا را برطرف کند. مؤلفه‌های سرویس باید در جهت باز نشدن خطا باشند، مگر اینکه خطرات شدیدی برای کسب‌وکار به همراه داشته باشد.
فراخوانی های API و دستورات عملیاتی را طوری طراحی کنید که قابل امتحان مجدد باشند
APIها و ابزارهای عملیاتی باید فراخوانی را تا آنجا که ممکن است ایمن کنند. یک رویکرد طبیعی برای بسیاری از شرایط خطا، تکرار عمل قبلی است، اما ممکن است ندانید که آیا اولین تلاش موفقیت آمیز بوده است یا خیر.
معماری سیستم شما باید اکشن‌ها را بی‌توان می‌سازد - اگر عمل یکسان را دو یا چند بار پشت سر هم روی یک شی انجام دهید، باید همان نتایجی را ایجاد کند که یک فراخوانی منفرد است. اقدامات غیر توانمند به کد پیچیده تری نیاز دارند تا از خراب شدن وضعیت سیستم جلوگیری شود.
_ierc.jpeg)
وابستگی‌های استارت آپی
خدمات در هنگام راه اندازی در مقایسه با رفتار حالت پایدارشان رفتار متفاوتی دارند. وابستگی های راه اندازی می تواند به طور قابل توجهی با وابستگی های زمان اجرا حالت پایدار متفاوت باشد.
*به عنوان مثال، در هنگام راه اندازی، یک سرویس ممکن است نیاز به بارگیری اطلاعات کاربر یا حساب از یک سرویس فوق داده کاربر داشته باشد که به ندرت دوباره آن را فراخوانی می کند. هنگامی که بسیاری از کپی‌های سرویس پس از خرابی یا تعمیرات معمولی راه‌اندازی مجدد می‌شوند، کپی‌ها می‌توانند به شدت بار وابستگی‌های راه‌اندازی را افزایش دهند، به‌ویژه زمانی که حافظه‌های پنهان خالی هستند و باید دوباره پر شوند.
راه‌اندازی سرویس را تحت بار آزمایش کنید و وابستگی‌های راه‌اندازی را بر این اساس ارائه دهید. طرحی را در نظر بگیرید
نظر دهید