راهکار چندمنطقه‌ای AWS برای بازیابی خودکار سرویس‌های WebSocket
به گزارش وبلاگ معماری AWS، یک الگوی چندمنطقه‌ای برای بازیابی از بحران در APIهای WebSocket سرویس Amazon API Gateway معرفی شده است. این معماری با انتقال خودکار ترافیک به منطقه پشتیبان، اتصال دوباره کلاینت‌ها و بازیابی وضعیت نشست، برای تیم‌هایی اهمیت دارد که سرویس‌های بلادرنگ و حساس به قطعی را روی زیرساخت ابری اجرا می‌کنند.
ترکیب DNS، پایگاه داده و پایش فعال
در این طرح، دو پشته یکسان WebSocket API در یک ساختار active-passive و در دو منطقه AWS مستقر می‌شوند. منطقه اصلی در شرایط عادی اتصال‌ها را پاسخ می‌دهد و Amazon Route 53 با سیاست failover، نام دامنه مشترک را به همان منطقه هدایت می‌کند. هم‌زمان، Amazon DynamoDB Global Tables وضعیت برنامه را به‌صورت ناهمگام در منطقه دوم تکثیر می‌کند تا مقصد پشتیبان برای پذیرش ترافیک آماده بماند.
تشخیص اختلال تنها به وجود ترافیک کاربران وابسته نیست. یک تابع canary در AWS Lambda هر دقیقه به نقطه پایانی WebSocket متصل می‌شود، پیام heartbeat می‌فرستد و نتیجه را در قالب معیار سفارشی Amazon CloudWatch ثبت می‌کند. اگر دو ارزیابی پیاپی ناموفق باشد یا داده‌ای منتشر نشود، هشدار فعال می‌شود و Route 53 منطقه اصلی را ناسالم در نظر می‌گیرد. در آزمایش ارائه‌شده، این فرایند حدود دو دقیقه پس از شبیه‌سازی خرابی آغاز شد.
اتصال مجدد بدون از دست رفتن زمینه نشست
پس از تغییر مقصد DNS، کلاینت از طریق همان دامنه به منطقه دوم متصل می‌شود و تازه‌ترین وضعیت را از نسخه محلی DynamoDB دریافت می‌کند. برای جلوگیری از هجوم هم‌زمان درخواست‌ها، منطق اتصال مجدد از exponential backoff همراه با jitter استفاده می‌کند؛ یعنی فاصله تلاش‌ها افزایش می‌یابد و زمان هر تلاش کمی تصادفی می‌شود. heartbeat کلاینت نیز هر ۳۰ ثانیه اجرا می‌شود و پس از دو پاسخ نامعتبر پیاپی، اتصال را می‌بندد تا فرایند اتصال مجدد آغاز شود.
AWS تأکید کرده است که وضعیت نشست باید بر مبنای شناسه کاربر، نه شناسه اتصال، ذخیره شود؛ زیرا شناسه اتصال با هر بار برقراری مجدد تغییر می‌کند. احراز هویت نیز باید در هر دو منطقه در دسترس باشد. تکثیر DynamoDB معمولاً در کمتر از یک ثانیه انجام می‌شود، اما ناهمگام بودن آن به این معناست که آخرین تغییرات پیش از خرابی ممکن است هنوز به منطقه دوم نرسیده باشند.
این الگو برای سامانه‌هایی مانند داشبوردهای زنده، ابزارهای همکاری گروهی، چت و برنامه‌های تعاملی کاربرد دارد. برای کسب‌وکارها، نتیجه اصلی کاهش مداخله دستی هنگام قطعی منطقه‌ای و کوتاه‌تر شدن زمان بازگشت سرویس است؛ با این حال آستانه‌های پایش، زمان‌بندی اتصال مجدد و سازوکار بازیابی داده باید متناسب با نیاز هر بارکاری تنظیم شوند.
