نحوه توزیع ترافیک در زیرساخت‌های Cloud

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

معماری ابری برای حل این مشکل، راهکار توزیع بار را معرفی کرده است. در این معماری، به جای تکیه بر یک ابررایانه متمرکز، مجموعه‌ای از هزاران سرور کوچک‌تر به صورت هماهنگ در کنار یکدیگر کار می‌کنند. اما داشتن صدها سرور به تنهایی کافی نیست؛ چالش اصلی این است که چگونه میلیون‌ها Request ورودی به صورت عادلانه، هوشمند و بدون ایجاد گلوگاه میان این سرورها پخش شوند. نقش سیستم‌های مدیریت و توزیع ترافیک دقیقا در همین نقطه پررنگ می‌شود. این سیستم‌ها به عنوان رهبر ارکستر در شبکه‌های ابری عمل کرده و تضمین می‌کنند که هیچ سروری بیش از حد توان خود تحت فشار قرار نگیرد و هیچ کاربری با قطعی سرویس مواجه نشود.

توزیع ترافیک در Cloud به چه معناست؟

مفهوم Traffic Distribution در زیرساخت‌های ابری، به مجموعه‌ای از فرآیندهای نرم‌افزاری و سخت‌افزاری اطلاق می‌شود که وظیفه دارند ترافیک ورودی کاربران را دریافت کرده و آن را بر اساس الگوریتم‌های مشخصی میان چندین سرور یا Instance پردازشی پخش کنند. این فرآیند از لحظه‌ای که کاربر آدرس یک وب‌سایت را در مرورگر خود وارد می‌کند آغاز می‌شود و تا زمان دریافت کامل پاسخ ادامه می‌یابد.

هدف نهایی در توزیع ترافیک، دستیابی به بالاترین سطح از Availability یا دسترسی‌پذیری است. در یک محیط ابری استاندارد، سیستم‌ها باید دارای ویژگی Fault Tolerance یا تحمل‌پذیری در برابر خطا باشند. این یعنی زیرساخت باید به گونه‌ای مهندسی شده باشد که اگر یک یا چند سرور پردازشی به صورت ناگهانی دچار نقص فنی فیزیکی یا نرم‌افزاری شدند، ترافیک بلافاصله و در کسری از ثانیه به سمت سرورهای سالم هدایت شود، بدون اینکه کاربر نهایی متوجه هیچ‌گونه اختلال یا توقفی در دریافت خدمات شود. درک عمیق این مکانیزم نیازمند شناخت ابزارهای پایه‌ای است که این توزیع هوشمند را در لایه‌های مختلف شبکه ممکن می‌سازند.

Load Balancer چیست و چگونه کار می‌کند؟

ابزار Load Balancer قلب تپنده فرآیند توزیع ترافیک در شبکه‌های مدرن است. این سیستم به عنوان یک واسط هوشمند میان کاربران اینترنت و سرورهای پردازشی یا Origin قرار می‌گیرد. زمانی که ترافیک عظیمی به سمت یک دامنه سرازیر می‌شود، این ترافیک مستقیما به سرورهای میزبان پایگاه داده یا کدهای نرم‌افزار برخورد نمی‌کند، بلکه ابتدا وارد Load Balancer می‌شود. این ابزار با بررسی لحظه‌ای وضعیت سرورهای متصل به خود، تصمیم می‌گیرد که هر Request باید به کدام سرور ارسال شود تا تعادل بار در کل شبکه حفظ گردد.

در دنیای حرفه‌ای شبکه‌های ابری، این تجهیزات به دو دسته کلی Hardware Load Balancer و Software Load Balancer تقسیم می‌شوند و فرآیند توزیع را در لایه‌های مختلف مدل استاندارد شبکه (OSI) انجام می‌دهند.

مدیریت ترافیک در لایه چهار شبکه

توزیع در لایه چهارم شبکه، بر مبنای پروتکل‌های پایه انتقال داده یعنی TCP و UDP انجام می‌شود. در این سطح، Load Balancer هیچ نگاهی به محتوای بسته اطلاعاتی کاربر نمی‌اندازد و برایش تفاوتی ندارد که کاربر در حال آپلود یک تصویر است یا در حال لاگین کردن به حساب کاربری. این سیستم صرفا بر اساس آدرس IP مبدا و پورت درخواستی، بسته‌ها را به سمت سرورهای مقصد شوت می‌کند. از آنجایی که در این لایه پردازش و رمزگشایی روی محتوای داده‌ها انجام نمی‌شود، سرعت انتقال ترافیک به شدت بالا بوده و تاخیر در کمترین میزان ممکن است. این لایه برای مسیریابی ترافیک دیتابیس‌ها و سرورهای بازی که نیازمند تبادل سریع بسته‌های خام هستند، کاربرد فراوانی دارد.

مدیریت ترافیک در لایه هفت شبکه

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

الگوریتم‌های توزیع ترافیک در Cloud

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

الگوریتم Round Robin

الگوریتم قطار چرخشی یا Round Robin، ساده‌ترین و در عین حال یکی از پایدارترین روش‌های توزیع بار است. در این مکانیزم، درخواست‌ها به ترتیب و به صورت دایره‌وار میان سرورهای موجود پخش می‌شوند. درخواست اول به سرور یک، درخواست دوم به سرور دو و به همین ترتیب تا آخرین سرور؛ سپس چرخه مجددا از سرور اول آغاز می‌شود. بزرگ‌ترین مزیت این روش، سادگی و عدم نیاز به محاسبات سنگین پردازشی برای تصمیم‌گیری است. با این حال، عیب اصلی آن عدم درک وضعیت فعلی سرورهاست.

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

الگوریتم Least Connections

این الگوریتم برخلاف مدل قبلی، کاملا هوشمندانه عمل می‌کند. مکانیزم Least Connections تعداد نشست‌های فعال و اتصالات باز روی هر سرور را به صورت لحظه‌ای مانیتور می‌کند. زمانی که یک Request جدید از راه می‌رسد، الگوریتم ترافیک را به سمت سروری می‌فرستد که کمترین میزان اتصال فعال را در آن لحظه داشته باشد. مزیت این رویکرد، جلوگیری قطعی از انباشت درخواست‌ها روی یک سرور خاص است. اگر یک سرور در حال پردازش یک فرآیند طولانی‌مدت باشد، ترافیک‌های جدید به سمت سرورهای خلوت‌تر هدایت می‌شوند. این الگوریتم برای پلتفرم‌هایی مانند چت‌روم‌ها، سوکت‌های ارتباطی زنده (WebSockets) و سیستم‌هایی که زمان پردازش درخواست‌ها در آن‌ها متغیر و طولانی است، بهترین گزینه محسوب می‌شود.

الگوریتم Weighted Load Balancing

در زیرساخت‌های Cloud که در طول زمان گسترش می‌یابند، معمولا سرورها از نسل‌های سخت‌افزاری متفاوتی تشکیل شده‌اند. طبیعی است که یک سرور با پردازنده نسل جدید نباید بار کاری مساوی با یک سرور قدیمی را تحمل کند. در الگوریتم وزن‌دهی (Weighted)، مدیران زیرساخت به هر سرور بر اساس توان پردازشی و میزان حافظه آن یک ضریب یا وزن عددی اختصاص می‌دهند. سیستم توزیع ترافیک با استفاده از این ضرایب، سهم بیشتری از ترافیک را به سرورهای قدرتمندتر و سهم کمتری را به سرورهای ضعیف‌تر اختصاص می‌دهد. این کار باعث می‌شود تا از تمامی منابع موجود در دیتاسنترها با بالاترین بهره‌وری ممکن استفاده شود و هیچ قطعه سخت‌افزاری بدون استفاده باقی نماند.

الگوریتم IP Hash

بسیاری از نرم‌افزارهای تحت وب نیازمند این هستند که کاربر در طول مدت حضور خود در سایت، همواره با یک سرور ثابت در ارتباط باشد تا نشست‌های کاربری (Sessions) و اطلاعات سبد خرید او از بین نرود. الگوریتم IP Hash دقیقا برای حل این نیاز طراحی شده است. این سیستم با دریافت آدرس IP کاربر و اجرای یک تابع ریاضی (Hash) روی آن، یک کلید اختصاصی تولید می‌کند.

بر اساس این کلید، کاربر در هر بار مراجعه مجدد به سایت، دقیقا به همان سروری متصل می‌شود که در ابتدا به آن متصل شده بود. بزرگترین نقطه ضعف این روش این است که اگر تعداد زیادی از کاربران اینترنت از یک شبکه مشترک اداری یا شرکتی (پشت یک IP عمومی) وارد سایت شوند، تمام ترافیک آن‌ها به سمت یک سرور سرازیر شده و تعادل توزیع بار در کلود مختل می‌شود.

الگوریتم Geographic Routing

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

نقش Health Check در جلوگیری از Down شدن سرویس‌ها

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

مکانیزم چک کردن سلامت، فرآیندی است که در آن ابزار توزیع ترافیک، در فواصل زمانی مشخص (مثلا هر پنج ثانیه یک بار)، سیگنال‌های آزمایشی را به تمامی سرورهای زیرمجموعه خود ارسال می‌کند. این سیگنال می‌تواند بررسی باز بودن پورت شبکه، پینگ ساده، یا درخواست یک فایل متنی خاص از سرور وب باشد. اگر سروری در چند تلاش متوالی پاسخ صحیح و به موقع را ارسال نکند، سیستم آن سرور را در وضعیت ناسالم (Unhealthy) قرار می‌دهد.

بلافاصله و به صورت کاملا خودکار، سرور معیوب از چرخه دریافت ترافیک خارج (حذف) شده و تمامی اتصالات جدید به سمت سرورهای سالم هدایت می‌شوند. این پدیده که به آن Failover گفته می‌شود، پایه و اساس ساختار Self Healing Infrastructure یا زیرساخت‌های خودترمیم است.

به عنوان مثال، در یک فروشگاه اینترنتی بزرگ در روزهای تخفیف ویژه، اگر یکی از نودهای میزبان دیتابیس به دلیل بار زیاد متوقف شود، سیستم نظارت سلامت فورا متوجه عدم پاسخگویی آن شده و مسیر ترافیک را به سمت نودهای پشتیبان دیتابیس تغییر می‌دهد. در سناریوی دیگر، در یک پلتفرم API Infrastructure که توسعه‌دهندگان از آن استفاده می‌کنند، اگر یکی از میکروسرویس‌ها خطای داخلی ۵۰۰ برگرداند، سیستم توزیع آن را ایزوله کرده و از خراب شدن تجربه کاربری سایر نرم‌افزارهای متصل به API جلوگیری می‌کند.

Auto Scaling چگونه با توزیع ترافیک ترکیب می‌شود؟

یکی از درخشان‌ترین مفاهیم در معماری Cloud، توانایی انطباق‌پذیری با تغییرات ناگهانی و غیرقابل پیش‌بینی است. توزیع ترافیک میان ده سرور زمانی موثر است که ترافیک از حد توان آن ده سرور فراتر نرود. اما اگر یک کمپین تبلیغاتی موفق باعث شود ترافیک سایت در عرض چند دقیقه صد برابر شود، حتی توزیع هوشمندانه نیز از نابودی سرویس جلوگیری نخواهد کرد. اینجا است که فناوری Auto Scaling یا مقیاس‌پذیری خودکار وارد عمل می‌شود تا در ترکیب با سیستم توزیع ترافیک، یک مفهوم کامل از Elastic Infrastructure یا زیرساخت کشسان را خلق کند.

مقیاس‌پذیری در معماری مدرن ابری بیشتر به صورت Horizontal Scaling یا توسعه افقی انجام می‌شود. این بدان معناست که به جای قوی‌تر کردن سرورهای فعلی، ماشین‌های مجازی جدیدی کپی شده و به مدار اضافه می‌شوند. زمانی که سیستم مقیاس‌پذیری تشخیص دهد بار روی سیستم افزایش یافته است، سرورهای جدیدی را روشن می‌کند و فورا آدرس آن‌ها را به Load Balancer معرفی می‌نماید تا توزیع ترافیک روی این نودهای تازه‌نفس نیز انجام شود. پس از فروکش کردن ترافیک، سرورهای اضافی به صورت خودکار خاموش شده و از چرخه توزیع حذف می‌شوند تا در هزینه‌های سازمان صرفه‌جویی شود.

Scaling بر اساس پردازنده (CPU)

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

Scaling بر اساس ترافیک ورودی (Traffic)

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

Scaling بر اساس صف درخواست‌ها (Queue)

در معماری‌های پیشرفته نرم‌افزاری که از سیستم‌های صف پیام (Message Brokers) مانند RabbitMQ یا Kafka استفاده می‌کنند، درخواست‌های کاربران به جای اجرای مستقیم، در یک صف پردازشی قرار می‌گیرند. سیستم ابری مانیتور می‌کند که چه تعداد پیام در صف انباشته شده است. اگر طول صف افزایش یابد و سرورهای فعلی نتوانند با سرعت کافی پیام‌ها را پردازش کنند، سیستم سرورهای جدیدی را مخصوص تخلیه صف راه‌اندازی می‌کند تا از ایجاد تاخیر در فرآیندهای پس‌زمینه جلوگیری شود.

نقش CDN در توزیع ترافیک جهانی

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

شبکه‌های توزیع محتوا (CDN) به عنوان یک لایه توزیع‌کننده واسط و بسیار قدرتمند عمل می‌کنند تا مفهوم توزیع ترافیک را از یک اتاق سرور به کل کره زمین گسترش دهند. این شبکه‌ها با قرار دادن ده‌ها Edge Server در نقاط مختلف دنیا، به جای اینکه اجازه دهند ترافیک مستقیما به سرور اصلی و مرکزی (Origin) برسد، داده‌ها را در لبه‌های شبکه و نزدیک‌ترین نقطه به کاربر تحویل می‌دهند.

مسیر یابی Anycast چیست؟

یکی از جادویی‌ترین تکنولوژی‌ها در شبکه‌های توزیع جهانی، مکانیزم Anycast است. در شبکه‌های سنتی، هر آدرس IP به یک سرور فیزیکی مشخص در یک نقطه از جهان تعلق دارد. اما در مسیریابی Anycast، یک آدرس IP مشترک به ده‌ها سرور در کشورهای مختلف اختصاص داده می‌شود. پروتکل‌های مسیریابی جهانی (مانند BGP) به صورت ذاتی ترافیک هر کاربر را به سمت سروری هدایت می‌کنند که کمترین تعداد پرش شبکه را با او داشته باشد. با این روش، میلیون‌ها کاربر از سراسر جهان تنها یک IP واحد را فراخوانی می‌کنند، اما ترافیک آن‌ها به صورت کاملا هوشمند در گره‌های توزیع شده شبکه جهانی پخش می‌شود.

پردازش لبه چگونه کار می‌کند؟

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

تفاوت بین شبکه‌های CDN و Load Balancer

گرچه هر دو ابزار در مسیر توزیع ترافیک نقش دارند، اما وظایف آن‌ها متفاوت است. یک شبکه توزیع محتوا بیشتر بر روی کش کردن (Cache) فایل‌های ایستا مانند تصاویر، کدهای جاوااسکریپت و ویدیوها در لبه شبکه تمرکز دارد و از رسیدن ترافیک‌های تکراری به سرور اصلی جلوگیری می‌کند. در مقابل، Load Balancer در دیتاسنتر اصلی قرار می‌گیرد تا ترافیک‌های پویا و پردازشی (مانند درخواست جستجو در دیتابیس یا ثبت سفارش) را که امکان کش شدن ندارند، میان کلاستر سرورهای موجود به صورت عادلانه توزیع کند. این دو سیستم مکمل یکدیگر در یک معماری ابری پایدار هستند.

نحوه توزیع ترافیک در معماری چند منطقه‌ای

سازمان‌های بزرگ و حساس نظیر بانک‌ها و پلتفرم‌های بین‌المللی نمی‌توانند پایداری کسب‌وکار خود را تنها به یک دیتاسنتر ابری گره بزنند. حوادث طبیعی، قطعی سراسری برق منطقه‌ای یا خطاهای سطح کلان می‌توانند یک دیتاسنتر را به طور کامل از مدار خارج کنند. برای دستیابی به بالاترین سطح از مقاومت در برابر حوادث، معماران شبکه از ساختار Multi Datacenter استفاده می‌کنند که در آن منابع پردازشی در چندین ناحیه جغرافیایی مختلف توزیع شده‌اند و ترافیک بین این مناطق مدیریت می‌شود. این نوع طراحی هسته اصلی برنامه‌های Disaster Recovery یا بازیابی از فاجعه به شمار می‌رود.

ساختار مبتنی بر مدل Active Active

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

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

ساختار مبتنی بر مدل Active Passive

در این مدل که مقرون‌به‌صرفه‌تر اما کمی کندتر است، ترافیک اصلی تنها به سمت یک دیتاسنتر (Active) هدایت می‌شود و دیتاسنتر دوم (Passive) در منطقه‌ای دیگر، صرفا در وضعیت آماده‌باش قرار دارد و داده‌ها را به صورت مداوم از سرور اصلی دریافت و کپی می‌کند اما پاسخی به کاربران نمی‌دهد. در صورت بروز حادثه و خارج شدن دیتاسنتر اول از مدار، سیستم مسیریابی ترافیک، با تشخیص قطعی، مسیرها را تغییر داده و ترافیک را به سمت دیتاسنتر پشتیبان هدایت می‌کند. این تغییر مسیر ممکن است به چند دقیقه زمان نیاز داشته باشد، اما از نابودی کامل سرویس جلوگیری می‌کند.

چالش‌های توزیع ترافیک در زیرساخت Cloud

با وجود تمام مزایا، پیاده‌سازی و نگهداری یک ساختار توزیع ترافیک توزیع‌شده با چالش‌های مهندسی فراوانی روبرو است که مدیران سیستم باید برای آن‌ها چاره‌اندیشی کنند:

• Session Persistence: نگه داشتن وضعیت نشست کاربران بین سرورهای متعددی که به صورت مداوم خاموش و روشن می‌شوند یکی از بزرگترین معضلات توسعه‌دهندگان است که اغلب نیازمند راه‌اندازی دیتابیس‌های میانی سریع مانند Redis برای ذخیره نشست‌ها است.
• Latency: عبور بسته‌های اطلاعاتی از چندین لایه مسیریاب، فایروال، لبه شبکه و در نهایت توزیع‌کننده‌های بار، باعث ایجاد تاخیرهای متوالی می‌شود که بهینه‌سازی مسیرها را به یک فرآیند پیچیده تبدیل می‌کند.
• Packet Loss: در ارتباطات درون‌شبکه‌ای بین صدها ماشین مجازی، احتمال گم شدن بسته‌های داده و نیاز به ارسال مجدد آن‌ها افزایش می‌یابد که این موضوع ارتباطات لایه دیتابیس را به شدت تحت تاثیر قرار می‌دهد.
• DNS Propagation: زمانی که سیستم توزیع ترافیک تصمیم می‌گیرد سرورهای ناحیه‌ای را از مدار خارج کند، اعمال تغییرات در رکوردهای DNS در سطح جهان ممکن است ساعت‌ها طول بکشد و باعث هدایت ترافیک به سمت سرورهای مرده شود.
• Bottleneck: گاهی اوقات خود دستگاه Load Balancer به دلیل پردازش‌های سنگین رمزگشایی در لایه هفتم، به یک گلوگاه ترافیکی تبدیل می‌شود و نیازمند کلاسترینگ و مقیاس‌پذیری مختص به خود است.

تفاوت توزیع ترافیک در Cloud و سرور سنتی

در زیرساخت‌های سنتی و کلاسیک، معماری شبکه معمولا بر پایه یک سرور متمرکز و بسیار قدرتمند بنا می‌شد. این معماری به صورت ذاتی دارای یک Single Point of Failure یا نقطه شکست واحد است؛ به این معنا که اگر منبع تغذیه پردازنده سرور بسوزد، تمام سرویس‌ها با هم قطع می‌شوند. اما با توسعه پلتفرم‌های مدرنی مانند زیرساخت ابری سرور.آی‌آر، معماری کلود بر پایه اجزای توزیع‌شده و سیستم‌های نامتمرکز طراحی شده است که مقاومت بی‌نظیری در برابر خطاهای سخت‌افزاری ایجاد می‌کند.

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

نقش Kubernetes و Container Orchestration در مدیریت ترافیک

ظهور تکنولوژی کانتینرها، معماری نرم‌افزارها را از ساختارهای یکپارچه به سمت میکروسرویس‌ها سوق داده است. در پلتفرم‌های ارکستریشن کانتینر مانند Kubernetes، مفهوم توزیع ترافیک بسیار پیچیده‌تر و ظریف‌تر از زیرساخت‌های معمولی انجام می‌شود. در یک کلاستر کوبرنیتیز، هزاران بسته نرم‌افزاری ایزوله به نام Pod در حال اجرای مستقل هستند که عمر کوتاهی دارند و دائما از بین رفته و جایگزین می‌شوند.

در این اکوسیستم پویا، مفهومی به نام Service Discovery وجود دارد که آدرس‌های دائما متغیر کانتینرها را در یک پایگاه داده مرکزی ردیابی می‌کند. ترافیک ورودی از دنیای بیرون، ابتدا به یک کنترل‌کننده مرزی به نام Ingress Controller می‌رسد. این کنترلر با بررسی قوانین تعریف شده و هدرهای درخواستی، ترافیک را به سمت سرویس مربوطه در داخل کلاستر هدایت می‌کند. سپس سرویس داخلی کوبرنیتیز با استفاده از مکانیزم‌های توزیع بار درونی شبکه مجازی، درخواست را مستقیما به دست Pod هدف می‌رساند. این لایه‌بندی چندگانه توزیع، پایداری استثنایی را برای نرم‌افزارهای مدرن به ارمغان می‌آورد.

چه سرویس‌هایی بیشتر به توزیع ترافیک پیشرفته نیاز دارند؟

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

فروشگاه‌های اینترنتی پرترافیک

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

پلتفرم‌های استریم ویدیو و رسانه

ارائه محتوای ویدیویی با کیفیت 4K به میلیون‌ها کاربر، پهنای باند وحشتناکی می‌طلبد. استفاده از معماری ابری لبه شبکه و هدایت ترافیک هر کاربر به نزدیک‌ترین نود پردازشی، تنها راهکار عملی برای جلوگیری از قطعی و بافرینگ مداوم تصاویر است.

نرم‌افزارهای مبتنی بر پلتفرم‌های SaaS

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

سرورهای میزبان بازی‌های آنلاین

در دنیای گیم سرورها، تاخیرهای چند میلی‌ثانیه‌ای (Ping) تاثیر مستقیمی روی کیفیت بازی و شکست یا پیروزی کاربران دارد. توزیع ترافیک در لایه چهار شبکه با هدف پیدا کردن خلوت‌ترین سرورها در کوتاه‌ترین مسیر فیزیکی شبکه، چالش بزرگ زیرساخت‌های بازی محسوب می‌شود.

معماری مبتنی بر پلتفرم‌های API

پلتفرم‌هایی که زیرساخت بانکی یا اعتبارسنجی را برای اپلیکیشن‌های موبایل فراهم می‌کنند، روزانه با میلیاردها ریکوئست ماشین به ماشین مواجه هستند. توزیع و مهار این نرخ عظیم درخواست‌ها بدون سیستم‌های متعادل‌کننده قدرتمند، در چند دقیقه کل هسته نرم‌افزاری را فلج خواهد کرد.

زیرساخت‌های پردازشی هوش مصنوعی

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

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

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