عملکرد یک Load Balancer و چگونگی توزیع ترافیک کاربران در این مقاله مورد بررسی خواهد گرفت.برای درک آنکه چگونه شرکت‌ها می‌توانند به چالش‌های پیچیده‌ی این بازار پویای در حال تحول پاسخ دهند، می‌خواهیم توزیع جریان ترافیکی کاربران در زمان استفاده از یک برنامه تحت وب یا اپلیکیشن های موبایل را شرح دهیم.
در بازار پویای امروزی که محور آن برنامه‌های کاربردی است، سازمان‌ها بیش از پیش تحت فشار هستند تا اطلاعات، خدمات و تجربه‌هایی را که مشتریان انتظار دارند، به‌سرعت، با قابلیت اطمینان بالا و به‌صورت ایمن ارائه دهند. عملکردهای کلیدی شبکه و اپلیکیشن مانند متعادل‌سازی بار (Load Balancing)، رمزنگاری، شتاب‌دهی (Acceleration) و امنیت، می‌توانند از طریق کنترل‌کننده‌های تحویل برنامه یا ADCها (Application Delivery Controllers) ارائه شوند؛ تجهیزاتی فیزیکی یا مجازی که به‌عنوان پروکسی برای سرورهای فیزیکی عمل می‌کنند.
با انفجار تعداد برنامه‌های کاربردی و فشارهای ناشی از چرخه سخت‌گیرانه ادغام و استقرار مستمر (CI/CD)، جای تعجب نیست که بازار ADCها تا سال 2020 به حدود 2.9 میلیارد دلار در سال رسیده باشد.
اما پیش از آنکه به آینده نگاه کنیم، بهتر است بدانیم چطور به این نقطه رسیده‌ایم. متعادل‌سازی بار مبتنی بر شبکه، اساس عملکرد ADCها را تشکیل می‌دهد. در اواسط دهه 1990، اولین تجهیزات سخت‌افزاری Load Balancer به سازمان‌ها کمک کردند تا برنامه‌های خود را از طریق توزیع بار کاری بین سرورها و شبکه‌ها مقیاس‌پذیر کنند. این دستگاه‌ها در ابتدا مستقل از برنامه‌ها بودند و خارج از سرورهای برنامه قرار داشتند؛ به همین دلیل می‌توانستند با استفاده از روش‌های ساده شبکه، بار را متعادل کنند. اساس کار این دستگاه‌ها به این شکل بود که یک "آدرس IP مجازی" به دنیای بیرون ارائه می‌کردند و وقتی کاربری تلاش می‌کرد متصل شود، اتصال را با استفاده از ترجمه دوطرفه آدرس شبکه (bi-directional NAT) به مناسب‌ترین سرور واقعی هدایت می‌کردند.
با ظهور مجازی‌سازی و رایانش ابری، نسل جدیدی از ADCها عرضه شد که به صورت نرم‌افزاری و مجازی ارائه می‌شدند و روی هایپروایزرها اجرا می‌گردیدند. امروزه، نسخه‌های مجازی این تجهیزات می‌توانند خدمات برنامه‌ای را با همان گستردگی ویژگی‌ها ارائه دهند که در تجهیزات سخت‌افزاری تخصصی وجود دارد. علاوه بر این، نسخه‌های مجازی پیچیدگی جابه‌جایی خدمات برنامه‌ای بین محیط‌های مجازی، ابری و ترکیبی را به میزان قابل توجهی کاهش می‌دهند و به سازمان‌ها امکان می‌دهند به‌سرعت و آسانی، خدمات موردنظر را در محیط‌های ابری خصوصی یا عمومی پیاده‌سازی کنند.
جدیدترین روندی که وارد مراکز داده شده، کانتینری‌سازی (Containerization) است؛ روشی برای مجازی‌سازی برنامه‌ها که به اجرای اپلیکیشن‌های توزیع‌شده کمک می‌کند. این فرآیند برنامه‌ها را ایزوله کرده و در فضاهای حافظه مشخص روی یک سیستم‌عامل مشترک قرار می‌دهد؛ این امر نه‌تنها توسعه و پیاده‌سازی برنامه را آسان‌تر از ساختن یک ماشین مجازی می‌سازد، بلکه سرعت آن را نیز افزایش می‌دهد. با توجه به بهبود چشمگیر در قابلیت حمل و عملکرد، کانتینری‌سازی می‌تواند مقیاس‌پذیری و چابکی بیشتری برای کسب‌وکارها به ارمغان آورد. در آینده، معماری مبتنی بر کانتینر می‌تواند به سازمان‌ها کمک کند تا از محیط‌های ابری مختلف، بهره بیشتری ببرند.
ADCهای امروزی، نتیجه تکامل از Load Balancerهای اولیه از طریق فرایند مجازی‌سازی سرویس‌ها هستند. اکنون با نسخه‌های کاملاً نرم‌افزاری، ADCها می‌توانند نه‌تنها دسترس‌پذیری را افزایش دهند، بلکه به سازمان‌ها کمک کنند تا برنامه‌هایی مقیاس‌پذیر، با عملکرد بالا و ایمن ارائه دهند؛ درست همان چیزی که کسب‌وکار به آن نیاز دارد. با این حال، همه این خدمات مجازی‌شده، زیرساخت‌های اشتراکی و مسیر‌یابی هوشمند بدون پایه‌ای محکم در فناوری متعادل‌سازی بار امکان‌پذیر نبودند.
برای درک بهتر چگونگی مواجهه سازمان‌ها با چالش‌های پیچیده بازار در حال تغییر، بیایید پایه‌ی تحویل برنامه را بررسی کنیم: مبانی متعادل‌سازی بار – Load Balancing 101.
پیش از ورود به جزئیات، بهتر است مفاهیم پایه و واژگان رایج در دنیای متعادل‌سازی بار (Load Balancing) را مرور کنیم. اگر همه‌ی تولیدکنندگان تجهیزات متعادل‌سازی بار از یک واژه‌نامه مشترک استفاده می‌کردند، این کار بسیار ساده‌تر بود؛ اما متأسفانه، هر تولیدکننده‌ای اصطلاحات خاص خود را دارد. با کمی توضیح، می‌توان این ابهام را برطرف کرد.
بیشتر کنترل‌کننده‌های تحویل برنامه (ADC) از مفاهیمی مانند نود، میزبان، عضو یا سرور استفاده می‌کنند. برخی هر چهار اصطلاح را دارند، ولی معانی آن‌ها لزوماً یکسان نیست. با این حال، همه‌ی این اصطلاحات تلاش می‌کنند دو مفهوم پایه را بیان کنند:
چرا این همه پیچیدگی وجود دارد؟ زیرا تمایز بین سرور و سرویس‌های در حال اجرا روی آن به ADC اجازه می‌دهد تا به‌جای تعامل با سخت‌افزار یا هایپروایزر، مستقیماً با برنامه‌ها در ارتباط باشد؛ چه در دیتاسنتر و چه در فضای ابری.
برای مثال، یک میزبان (172.16.1.10) می‌تواند چند سرویس داشته باشد: HTTP، FTP، DNS و غیره. با تعریف مجزای هر سرویس (مثلاً 172.16.1.10:80 برای HTTP، 172.16.1.10:21 برای FTP و 172.16.1.10:53 برای DNS)، ADC می‌تواند متعادل‌سازی بار و پایش سلامت (Health Monitoring) را برای هر سرویس به‌صورت جداگانه انجام دهد، نه فقط برای خود میزبان.
بنابراین، در اکثر تکنولوژی‌های مبتنی بر Load Balancing، یک اصطلاح نماینده‌ی میزبان (Host) یا سرور فیزیکی است و اصطلاح دیگر نماینده‌ی سرویس‌های در حال اجرا روی آن — که ما در این متن آن‌ها را به ترتیب Host و Service می‌نامیم.
یکی از اصول Load Balancing، توزیع ترافیک ورودی برنامه بین چندین مقصد در سمت سرور است — از جمله پیاده‌سازی‌هایی در فضای ابری خصوصی یا عمومی. بنابراین، باید مفهومی برای مجموعه‌ای از سرویس‌های مقصد وجود داشته باشد.
ما این مفهوم را Cluster (کلاستر) می‌نامیم (برخی آن را Pool یا Farm هم می‌نامند). کلاستر مجموعه‌ای از سرویس‌های مشابه است که روی یک یا چند میزبان اجرا می‌شوند.
برای مثال، همه‌ی سرویس‌هایی که صفحه‌ی اصلی وب‌سایت شرکت را ارائه می‌دهند در یک کلاستر به نام «صفحه اصلی وب‌سایت شرکت» قرار می‌گیرند و همه‌ی سرویس‌های تجارت الکترونیکی در کلاستر دیگری به نام «e-commerce» دسته‌بندی می‌شوند.
سرور مجازی یک پراکسی برای سرور واقعی است — چه فیزیکی، چه مجازی یا کانتینری. در ترکیب با یک آدرس IP مجازی، این همان نقطه‌ی انتهایی (Endpoint) است که از دید کاربران یا دنیای بیرونی قابل مشاهده است.
با آشنایی با این مفاهیم، اکنون درک اولیه‌ای از سازوکار Load Balancing داریم. ADC، سرورهای مجازی را به دنیای بیرون نمایش می‌دهد. هر سرور مجازی به یک کلاستر از سرویس‌ها اشاره دارد که روی یک یا چند میزبان فیزیکی یا مجازی اجرا می‌شوند.
هرچند «شکل ۲» ممکن است نمایانگر یک پیاده‌سازی واقعی در دنیای واقعی نباشد، اما ساختار پایه‌ای مناسبی برای ادامه‌ی بحث درباره فرآیند متعادل‌سازی بار و تحویل برنامه ارائه می‌دهد.
با تعریف واژگان مشترک، حالا می‌توانیم یک تراکنش ساده از نحوه‌ی تحویل برنامه به کاربر را بررسی کنیم. همان‌طور که در تصویر نشان داده شده، کنترل‌کننده‌ی تحویل برنامه (ADC) معمولاً به‌صورت درون‌خطی (In-line) بین کلاینت و میزبان‌هایی قرار می‌گیرد که سرویس‌های مورد نیاز کلاینت را فراهم می‌کنند.
مانند بسیاری از موارد دیگر در تحویل برنامه، این موقعیت قرارگیری یک قانون سخت‌گیرانه نیست، بلکه بیشتر یک بهترین روش در پیاده‌سازی‌ها به‌شمار می‌رود.
فرض کنیم که ADC قبلاً پیکربندی شده و یک سرور مجازی دارد که به یک کلاستر شامل دو سرویس اشاره می‌کند. در این سناریوی پیاده‌سازی، معمولاً میزبان‌ها مسیر بازگشت خود را به‌سمت Load Balancer تنظیم می‌کنند تا ترافیک بازگشتی نیز از طریق ADC پردازش شده و به کلاینت بازگردد.
فرآیند پایه‌ای تحویل برنامه به‌صورت زیر است:
کلاینت بسته‌ی بازگشتی را دریافت می‌کند و گمان می‌برد که این پاسخ از سرور مجازی آمده است، بنابراین فرآیند را ادامه می‌دهد.
این مثال ساده ممکن است در ظاهر ابتدایی به نظر برسد، اما چند نکته کلیدی در آن نهفته است. نخست، از دید کلاینت، همه چیز ساده است: بسته‌ها را به سرور مجازی می‌فرستد و پاسخ را از همان سرور دریافت می‌کند. دوم، فرآیند NAT انجام می‌شود. در این مرحله، ADC آدرس IP مقصدی را که کلاینت ارسال کرده (آدرس سرور مجازی) با آدرس IP میزبان واقعی که قرار است درخواست را دریافت کند، جایگزین می‌کند. سومین نکته همان چیزی‌ست که باعث می‌شود این NAT «دوطرفه» باشد: بسته‌ی بازگشتی از طرف میزبان دارای IP مبدأ میزبان است. اگر این IP بدون تغییر به کلاینت ارسال شود، کلاینت تصور می‌کند که پاسخ از منبعی ناشناخته آمده و آن را رد می‌کند. در نتیجه، Load Balancer با استفاده از اطلاعات مربوط به همان اتصال، آدرس مبدأ را به آدرس سرور مجازی بازنویسی کرده و مشکل را برطرف می‌کند.
در این مرحله، معمولاً دو سوال مطرح می‌شود:
Load Balancer چگونه تصمیم می‌گیرد که اتصال به کدام میزبان ارسال شود؟
اگر میزبان انتخاب‌شده در دسترس نباشد، چه اتفاقی می‌افتد؟
بیایید از سوال دوم شروع کنیم. اگر میزبان در دسترس نباشد، به درخواست پاسخ نمی‌دهد و اتصال در نهایت با Time Out مواجه می‌شود. این وضعیت قطعاً ایده‌آل نیست، زیرا تضمینی برای دسترس‌پذیری بالا (High Availability) فراهم نمی‌کند. به همین دلیل، بیشتر فناوری‌های Load Balancing شامل مانیتورینگ سلامت (Health Monitoring) هستند تا پیش از ارسال ترافیک، از فعال بودن میزبان‌ها اطمینان حاصل کنند.
مانیتورینگ سلامت در سطوح مختلفی انجام می‌شود:
مزیت مانیتورهای سطح بالا این است که وضعیت واقعی سرویس را می‌سنجند، نه فقط دسترس‌پذیری میزبان را. همچنین، Load Balancer می‌تواند بین چندین سرویس روی یک میزبان تمایز قائل شود. ممکن است یک سرویس خراب باشد ولی سرویس دیگر همچنان کار کند.
و حالا به سوال اول می‌رسیم: چگونه ADC تصمیم می‌گیرد که ترافیک به کدام سرویس ارسال شود؟
هر سرور مجازی به یک کلاستر اختصاصی از سرویس‌ها متصل است. مانیتورینگ سلامت، فهرست میزبان‌ها را پالایش می‌کند و فقط میزبان‌های در دسترس را باقی می‌گذارد. سپس، Load Balancer با استفاده از الگوریتم Load Balancing، یکی از میزبان‌های باقی‌مانده را انتخاب می‌کند.
الگوریتم‌های متداول Load Balancing عبارت‌اند از:
در ADCهای پیشرفته‌تر، الگوریتم‌ها می‌توانند داده‌های مانیتورینگ را با هم ترکیب کنند تا وابستگی سرویس‌ها (Service Dependency) را هم در نظر بگیرند. مثلاً اگر میزبانی دو سرویس دارد و یکی از آن‌ها از کار بیفتد، سرویس دیگر نیز از فهرست حذف می‌شود، چون هر دو برای انجام کار کاربر مورد نیازند. این موضوع با پیچیده‌تر شدن خدمات تحت وب اهمیت بیشتری پیدا می‌کند.
Load Balancer تنها در آغاز اتصال تصمیم می‌گیرد ترافیک به کدام میزبان برود، اما پس از آن باید بداند که آیا باید بقیه‌ی ترافیک را نیز Load Balance کند یا خیر.
دو چالش اصلی در این مرحله وجود دارد:
روش‌های ایجاد Persistence:
در ADCهای هوشمندتر، امکان بررسی محتوای بسته‌ها و ساخت جدول چسبندگی براساس داده‌هایی مثل نام کاربری هم وجود دارد. البته در این روش، سازمان باید اطمینان حاصل کند که این اطلاعات در هر درخواست وجود داشته باشند، در غیر این صورت ارتباط قطع می‌شود.
نتیجه‌گیری
در ابتدا، Load Balancer صرفاً برای توزیع بار و دسترسی‌پذیری طراحی شده بود. اما با پیشرفت فناوری، به یک پلتفرم جامع برای تحویل برنامه‌ها (Application Delivery) تبدیل شده است؛ پلتفرمی که نه‌تنها دسترسی، بلکه امنیت و کارایی برنامه‌ها را نیز تضمین می‌کند.
امروزه ADCها قابلیت‌هایی چون:
را در یک نقطه متمرکز فراهم می‌کنند. این نقطه‌ی مشترک برای همه‌ی سرویس‌ها و میزبان‌ها باعث می‌شود تیم‌های شبکه، اپلیکیشن و عملیات بتوانند با سرعت بیشتر و در مقیاس گسترده‌تر، نیازهای کسب‌وکار را پاسخ دهند—بدون اینکه امنیت قربانی شود.