Load Balancer چیست؟

لود بالانسر (Load Balancer) یا توزیع‌کننده بار، یک افزار سخت‌افزاری، نرم‌افزاری یا سرویس ابری است که به عنوان یک نقطه‌ی دسترسی واحد (Single Entry Point) و واسط میان کاربران و مجموعه‌ای از سرورها قرار می‌گیرد.

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

مقدمه

در سال‌های آغازین وب، اکثر وب‌سایت‌ها و اپلیکیشن‌ها ساختاری بسیار ساده داشتند: یک سرور فیزیکی واحد تمام اجزا شامل کد برنامه، دیتابیس و فایل‌ها را میزبانی می‌کرد. تمام درخواست‌های کاربران مستقیم به آدرس IP همین سرور هدایت می‌شد. اما با گسترش اینترنت و افزایش ناگهانی تعداد کاربران هم‌زمان (Concurrent Users)، این معماری تک‌سروری با دو چالش فاجعه‌بار روبرو شد:

1. محدودیت سخت‌افزاری (Hardware Bottleneck): یک سرور فیزیکی، هرچقدر هم گران‌قیمت و پیشرفته باشد، از نظر تعداد هسته‌های CPU، مقدار حافظه رم و پهنای باند کارت شبکه محدود است. زمانی که تعداد درخواست‌ها از توان پردازشی این سرور فراتر رود، صف پاسخ‌دهی طولانی شده، زمان پاسخ (Latency) افزایش می‌یابد و در نهایت سرور به دلیل اتمام منابع کاملاً از دسترس خارج می‌شود.

2. نقطه تک‌شکست (Single Point of Failure - SPOF): وقتی تمام سیستم روی یک سرور متکی باشد، با بروز کوچک‌ترین مشکل سخت‌افزاری، قطعی برق، خرابی سیستم‌عامل یا حتی یک باگ کوچک نرم‌افزاری، کل سرویس شما برای تمام کاربران جهان از دسترس خارج می‌شود (Downtime کامل).

برای حل این چالش دو رویکرد وجود دارد:

• مقیاس‌پذیری عمودی (Vertical Scaling / Scale-Up): یعنی ارتقای سخت‌افزار همان سرور موجود (مثلاً ارتقای رم از ۶۴ به ۱۲۸ گیگابایت). این روش فوق‌العاده گران است، سقف فیزیکی مشخصی دارد و مهم‌تر از همه، مشکل نقطه تک‌شکست را حل نمی‌کند؛ چون هنوز هم فقط یک سرور دارید.

• مقیاس‌پذیری افقی (Horizontal Scaling / Scale-Out): یعنی به‌جای یک سرور قوی، چندین سرور معمولی در کنار هم قرار گیرند تا کار را با هم انجام دهند.

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

انواع لود بالانسر بر اساس لایه‌های مدل OSI

در مدل ۷ لایه‌ای شبکه (OSI Model)، لود بالانسرها عمدتاً در دو لایه کار می‌کنند: لایه ۴ (Transport) و لایه ۷ (Application). درک تفاوت‌های این دو لایه برای معماران سیستم فوق‌العاده حیاتی است، چرا که انتخاب اشتباه می‌تواند منجر به افت شدید کارایی یا عدم امکان پیاده‌سازی ویژگی‌های امنیتی شود.

 لود بالانسینگ لایه ۴ (Layer 4 - Transport Layer)

لود بالانسینگ لایه ۴ در سطحی پایین‌تر از شبکه عمل می‌کند و تنها با پروتکل‌های انتقال مانند TCP و UDP سرکار دارد. در این لایه، لود بالانسر اصطلاحاً "کور" نسبت به محتوای پیام عمل می‌کند؛ یعنی نمی‌داند کدهای داخل بسته HTTP چیست، چه پاسخی قرار است داده شود یا چه کاربر با چه هویت ارسال‌کننده‌ای پشت درخواست است.

نحوه تصمیم‌گیری و عملکرد:

لود بالانسر لایه ۴ تصمیمات مسیریابی خود را صرفاً بر اساس اطلاعات موجود در هدر بسته‌های شبکه انجام می‌دهد:

• آدرس IP مبدا و مقصد

• پورت TCP/UDP مبدا و مقصد

وقتی یک بسته شبکه به لود بالانسر لایه ۴ می‌رسد، لود بالانسر بدون رمزگشایی یا خواندن محتوای بسته، آدرس IP مقصد بسته را به آدرس یکی از سرورهای پشتی تغییر داده (عملیات NAT) و بسته را مستقیماً عبور می‌دهد.

مزایا و کاربردها:

• سرعت و Efficiency بی‌نظیر: از آنجایی که لود بالانسر نیازی به باز کردن بسته، رمزگشایی SSL یا آنالیز هدرهای HTTP ندارد، بار محاسباتی فوق‌العاده کمی روی CPU می‌گذارد و می‌تواند میلیون‌ها بسته را در ثانیه هدایت کند.

• عدم وابستگی به پروتکل (Protocol Agnostic): شما می‌توانید از این نوع لود بالانسر برای هر نوع ترافیکی استفاده کنید؛ از پایگاه‌های داده (مثل MySQL یا PostgreSQL) گرفته تا سرویس‌های بازی‌های آنلاین، DNS، پروتکل‌های سفارشی IoT و ترافیک VoIP.

لود بالانسینگ لایه ۷ (Layer 7 - Application Layer)

لود بالانسینگ لایه ۷ در بالاترین لایه مدل OSI قرار دارد و به‌طور کامل با پروتکل‌های لایه کاربرد مانند HTTP، HTTPS، HTTP/2، HTTP/3 و WebSocket یکپارچه است. برخلاف لایه ۴، این لود بالانسر محتوای کامل درخواست را درک و آنالیز می‌کند.

نحوه تصمیم‌گیری و عملکرد:

در این روش، لود بالانسر ابتدا اتصال TCP با کاربر را کاملاً برقرار می‌سازد، بسته را باز کرده، ترافیک SSL را رمزگشایی می‌کند و تمامی اجزای درخواست HTTP را می‌خواند. سپس بر اساس محتوای داخل درخواست، تصمیم می‌گیرد آن را به کدام سرور بفرستد.

امکانات هوشمندی که لایه ۷ ارائه می‌دهد شامل موارد زیر است:

• مسیریابی بر اساس URL (URL-based Routing): برای مثال، درخواست‌های مربوط به /api/v1 را به سرورهای مخصوص پردازش API، درخواست‌های /images را به سرورهای ذخیره‌سازی فایل و درخواست‌های عادی را به سرورهای وب بفرستد.

• مسیریابی بر اساس Header یا Cookie: هدایت کاربران موبایل (با تشخیص User-Agent) به سرورهای بهینه‌شده برای موبایل، یا هدایت کاربران دارای کوکی‌های خاص (مثلاً کاربران VIP) به سرورهای قدرتمندتر.

• خاتمه رمزنگاری SSL/TLS: رمزگشایی ترافیک HTTPS روی لود بالانسر و ارسال ترافیک به‌صورت ساده و سبک در شبکه داخلی برای سرورهای اصلی.

مزایا و چالش‌ها:

این لود بالانسرها انعطاف‌پذیری و قدرت مانور بی‌نظیری به شما می‌دهند و قابلیت‌های امنیتی فراوانی مثل WAF (دیوار آتش وب) را پشتیبانی می‌کنند. اما در مقابل، به دلیل پردازش سنگین متون و رمزگشایی داده‌ها، نیازمند CPU و حافظه رم بسیار بیشتری نسبت به لایه ۴ هستند.

الگوریتم‌های توزیع بار (Load Balancing Algorithms)

لود بالانسر چطور تصمیم می‌گیرد درخواست بعدی باید دقیقاً به کدام سرور برسد؟ برای این کار از متدهای ریاضی و منطقی مختلفی استفاده می‌شود که به دو دسته کلی ایستا (Static) و پویا (Dynamic) تقسیم می‌شوند.

الگوریتم‌های ایستا (Static Algorithms)

این الگوریتم‌ها بر اساس فرمول‌های ریاضی ثابت کار می‌کنند و کاری به این ندارند که در حال حاضر مصرف CPU سرور چقدر است یا سرور تحت چه باری قرار دارد.

۱. نوبت‌گردشی (Round Robin)

این ساده‌ترین و شناخته‌شده‌ترین الگوریتم توزیع بار است. لود بالانسر یک لیست از سرورها دارد و درخواست‌ها را دقیقاً به ترتیب به آن‌ها اختصاص می‌دهد: درخواست اول به سرور ۱، درخواست دوم به سرور ۲، درخواست سوم به سرور ۳، و درخواست چهارم دوباره به سرور ۱.

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

۲. نوبت‌گردشی وزن‌دار (Weighted Round Robin)

برای برطرف کردن مشکل سخت‌افزارهای ناهمگون، به هر سرور عددی به عنوان "وزن" (Weight) داده می‌شود که نشان‌دهنده توان پردازشی آن است.

• مثال کاربردی: اگر سرور A دارای ۳۲ هسته CPU باشد و سرور B دارای ۱۶ هسته باشد، به سرور A وزن ۲ و به سرور B وزن ۱ داده می‌شود. در این حالت، لود بالانسر به ازای هر ۲ درخواستی که به سرور A می‌فرستد، ۱ درخواست به سرور B ارسال می‌کند.

۳. هش‌سازی آدرس IP (IP Hash)

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

• ویژگی کلیدی: به دلیل ثابت بودن آدرس IP کاربر، تمامی درخواست‌های آتی او همواره به همان سرور قبلی هدایت می‌شود. این روش برای حفظ حالت نشست کاربر (Session State) مفید است، اما اگر تعداد زیادی کاربر پشت یک NAT عمومی یا Proxy مشترک باشند، همه آن‌ها به یک سرور فرستاده می‌شوند و توازن بار به هم می‌خورد.

الگوریتم‌های پویا (Dynamic Algorithms)

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

۱. کمترین اتصال (Least Connections)

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

• کاربرد عالی: این روش برای سیستم‌هایی که نشست‌های کاری آن‌ها طولانی‌مدت است (مانند ارتباطات دیتابیس، برنامه‌های مبتنی بر WebSocket یا نشست‌های زنده) فوق‌العاده است؛ زیرا ممکن است تعداد اتصالات دو سرور برابر باشد، اما یکی از آن‌ها همچنان درگیر پردازش اتصالات قبلی باشد.

۲. کمترین زمان پاسخ (Least Response Time / Latency)

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

• عملکرد: درخواست جدید به سروری فرستاده می‌شود که ترکیب "کمترین زمان پاسخ" و "کمترین اتصالات فعال" را داشته باشد. این الگوریتم تضمین می‌کند که اگر یک سرور به دلیل کندی دیسک یا مشکل شبکه پاسخ‌ها را دیرتر می‌دهد، کمتر زیر بار برود.

 Health Check, Sticky Session, SSL Termination

راه‌اندازی یک سیستم توزیع بارِ قابل اتکاء، مستلزم پیاده‌سازی درست سه مفهوم کلیدی زیر است:

 پایش سلامت سرورها (Health Checks)

یک لود بالانسر بدون پایش سلامت، خطرناک است! اگر یکی از سرورهای پشتی به دلیل اتمام رم یا خرابی دیتابیس باگ داده و متوقف شود، لود بالانسر بدون پایش سلامت همچنان بخشی از ترافیک کاربران را به آن سرور مرده فرستاده و باعث نمایش خطای ۵۰۰ به کاربران می‌شود.

پایش سلامت به دو روش انجام می‌شود:

• پایش فعال (Active Health Check): لود بالانسر به‌طور مداوم (مثلاً هر ۳ یا ۵ ثانیه) یک درخواست ساختگی مجزا به تمامی سرورها می‌فرستد (مثلاً درخواست GET /healthcheck). اگر سرور پاسخ HTTP 200 ارسال کند، آن را سالم تلقی می‌کند. اگر سرور ۳ بار متوالی پاسخ نداد، لود بالانسر بلافاصله آن را از چرخه خارج کرده و ارسال ترافیک به آن را متوقف می‌کند.

• پایش غیرفعال (Passive Health Check): لود بالانسر پاسخ‌های واقعی سرورها به کاربران را زیر نظر می‌گیرد. اگر ببیند یک سرور در پاسخ به درخواست‌های واقعی کاربران شروع به دادن خطاهای متعدد شبکه یا کدهای 5xx کرده است، بدون منتظر ماندن برای تست‌های دوره ای، آن سرور را موقتاً کنار می‌گذارد.

نشست‌های چسبنده (Sticky Sessions / Session Affinity)

بسیاری از برنامه‌های وب سنتی، اطلاعات لاگین و سبد خرید کاربر را در حافظه رم همان سروری نگه‌می‌دارند که کاربر برای بار اول به آن وصل شده است (In-Memory Session). در چنین برنامه‌هایی، اگر درخواست اول کاربر به سرور A برود و درخواست دوم او توسط لود بالانسر به سرور B فرستاده شود، سرور B کاربر را شناسایی نکرده و از او می‌خواهد دوباره لاگین کند!

برای حل این مشکل از Sticky Session استفاده می‌شود:

• روش کار: لود بالانسر در اولین پاسخ به کاربر، یک کوکی اختصاصی (مثلاً SERVERID=web01) در مرورگر او قرار می‌دهد. در درخواست‌های بعدی، لود بالانسر این کوکی را خوانده و کاربر را بدون توجه به الگوریتم‌های دیگر، دقیقاً به همان سرور اول هدایت می‌کند.

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

• راهکار مدرن مهندسی: استفاده از معماری بی‌وضعیت (Stateless). در این معماری، اطلاعات نشست‌ها به‌جای حافظه سرورها، در یک پایگاه داده مرکزی بسیار سریع مانند Redis یا Memcached ذخیره می‌شود تا هر سروری بتواند به اطلاعات کاربر دسترسی داشته باشد.

خاتمه رمزنگاری SSL/TLS (SSL Termination)

پردازش الگوریتم‌های رمزنگاری پیچیده پروتکل HTTPS (مانند الگوریتم‌های RSA یا ECC) و انجام فرایند Handshake فشار محاسباتی فوق‌العاده سنگینی به CPU وارد می‌کند. اگر قرار باشد هر سرور وب به‌تنهایی این رمزگشایی‌ها را انجام دهد، بخش زیادی از توان پردازشی سرور صرف امور رمزنگاری می‌شود به جای اینکه صرف اجرای کد برنامه شود.

معماری SSL Termination این چالش را برطرف می‌کند:

• کلیدهای امنیتی SSL/TLS روی خود لود بالانسر نصب می‌شوند.

• ارتباط امن HTTPS میان کاربر و لود بالانسر روی اینترنت برقرار می‌شود.

• لود بالانسر ترافیک را رمزگشایی کرده و درخواست‌ها را به‌صورت HTTP ساده (غیررمزنگاری شده اما با سرعت بالا) در شبکه داخلی امن (LAN یا VPC) به سرورهای اصلی می‌فرستد.

• SSL Pass-through (جایگزین امن‌تر): اگر سازمان شما استانداردهای امنیتی بسیار سخت‌گیرانه‌ای دارد (مثل بانک‌ها) و حتی شبکه داخلی هم نباید ترافیک غیررمزنگاری شده داشته باشد، از روش Pass-through استفاده می‌شود که در آن لود بالانسر بسته را بدون رمزگشایی عبور داده و رمزگشایی نهایی روی خود سرور مقصد انجام می‌شود.

بررسی و مقایسه ابزارهای محبوب لود بالانسینگ

ابزارهای متعددی برای پیاده‌سازی لود بالانسینگ وجود دارند که هرکدام برای سناریوهای خاصی طراحی شده‌اند:

HAProxy (High Availability Proxy)

• ماهیت: یک نرم‌افزار فوق‌العاده سریع، تخصصی و open-source برای لود بالانسینگ لایه ۴ و ۷.

• ویژگی‌های برجسته: پایداری بی‌نظیر، مصرف بسیار ناچیز منابع (رم و CPU)، توانایی مدیریت صدها هزار اتصال هم‌زمان. HAProxy به عنوان استاندارد طلایی زیرساخت‌های بزرگ شناخته می‌شود.

 NGINX

• ماهیت: یک وب‌سرور قدرتمند که توانایی عملکرد به عنوان Reverse Proxy و لود بالانسر را نیز دارد.

• ویژگی‌های برجسته: تنظیمات بسیار آسان، سرو سریع فایل‌های استاتیک، پشتیبانی عالی از لایه ۷. اگر علاوه بر توزیع بار، به وب‌سرور و Caching هم نیاز دارید، NGINX انتخابی عالی است.

Traefik

• ماهیت: یک لود بالانسر مدرن و Edge Router متولد شده برای دنیای کانتینرها، Docker و Kubernetes.

• ویژگی‌های برجسته: قابلیت پیکربندی کاملاً پویا (Dynamic Configuration). یعنی وقتی یک کانتینر جدید در Docker بالا می‌آید، Traefik بدون نیاز به ریستارت شدن یا تغییر دستی کانفیگ، آن را شناسایی کرده و ترافیک را به سمت آن هدایت می‌کند.

بررسی یک نمونه کانفیگ واقعی و عملی در HAProxy

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

# 1. تنظیمات سراسری سیستم
global
    log /dev/log local0
    maxconn 5000              # حداکثر اتصالات هم‌زمان کل سیستم
    user haproxy
    group haproxy

# 2. تنظیمات پیش‌فرض برای تمامی بخش‌ها
defaults
    log     global
    mode    http              # حالت کاری در لایه ۷ (HTTP)
    option  httplog
    timeout connect 5s        # حداکثر زمان انتظار برای اتصال به سرور
    timeout client  50s       # حداکثر زمان انتظار برای پاسخ کاربر
    timeout server  50s       # حداکثر زمان انتظار برای پاسخ سرور

# 3. بخش Frontend (جایی که ترافیک ورودی کاربران دریافت می‌شود)
frontend http_in
    bind *:80                 # گوش دادن روی تمام IPها و پورت ۸۰
    mode http
    
    # تفکیک ترافیک بر اساس URL (Layer 7 Routing)
    acl is_api path_beg /api  # اگر مسیر درخواست با api/ شروع شد
    use_backend api_servers if is_api
    
    # در غیر این صورت ارسال به بخش پیش‌فرض
    default_backend web_servers

# 4. بخش Backend اول: سرورهای وب عادی
backend web_servers
    mode http
    balance roundrobin        # الگوریتم توزیع بار نوبت‌گردشی
    option httpchk GET /health # پایش سلامت با ارسال درخواست به health/
    
    # لیست سرورها همراه با پایش سلامت (چک هر ۲ ثانیه، ۳ خطا = خروج از مدار)
    server web01 192.168.1.10:80 check inter 2000ms fall 3 rise 2 weight 2
    server web02 192.168.1.11:80 check inter 2000ms fall 3 rise 2 weight 1

# 5. بخش Backend دوم: سرورهای مخصوص پردازش API
backend api_servers
    mode http
    balance leastconn         # الگوریتم کمترین اتصال برای APIهای زمان‌بر
    server api01 192.168.1.20:8080 check
    server api02 192.168.1.21:8080 check

چطور لود بالانسر را High Available کنیم؟

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

در این حالت، خودِ لود بالانسر تبدیل به همان نقطه تک‌شکست (SPOF) می‌شود! تمام سرورهای پشتی سالم هستند اما هیچ درخواستی به آن‌ها نمی‌رسد.

 پیاده‌سازی جفتِ رزرو (Active-Passive Pair)

برای حل این مشکل، هرگز از یک لود بالانسر استفاده نمی‌شود؛ بلکه حداقل دو لود بالانسر همزاد راه‌اندازی می‌شوند:

1. Master / Active Load Balancer: لود بالانسری که در حالت عادی تمام ترافیک را دریافت و توزیع می‌کند.

2. Backup / Passive Load Balancer: لود بالانسری که در حالت آماده‌باش قرار دارد و هیچ ترافیکی پردازش نمی‌کند، اما آماده است.

مکانیزم کار با Virtual IP (VIP) و پروتکل VRRP:

برای یکپارچه‌سازی این دو سرور، تکنولوژی Virtual IP (آدرس IP مجازی) همراه با ابزاری مانند Keepalived (که از پروتکل VRRP استفاده می‌کند) پیاده‌سازی می‌شود.

1. یک آدرس IP عمومی واحد (مثلاً 192.168.1.100) به عنوان Virtual IP تعریف می‌شود. کاربران و DNS فقط این IP را می‌شناسند.

2. این Virtual IP در حالت عادی روی لود بالانسر اصلی (Active) فعال است.

3. دو لود بالانسر از طریق یک سیگنال قلبی (Heartbeat) در شبکه داخلی، پیوسته وضعیت یکدیگر را چک می‌کنند (مثلاً هر ۱ ثانیه).

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

سوالات متداول

۱. لود بلانسر دقیقاً چیست و چه کار می‌کند؟

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

۲. تفاوت اصلی L4 Load Balancer و L7 Load Balancer چیست؟

پاسخ:

• Layer 4 (لایه انتقال): بر اساس اطلاعات لایه شبکه و انتقال مانند IP و Port تصمیم‌گیری می‌کند. بسیار سریع است اما از محتوای پیام (مثل URL یا Cookie) بی‌خبر است.

• Layer 7 (لایه کاربردی): محتوای درخواست (HTTP Headers، HTTP Body، Cookie، URL path) را آنالیز می‌کند. هوشمندتر است و می‌تواند ترافیک را بر اساس مسیر (مثل ارسال /api به یک سرور خاص) هدایت کند.

۳. الگوریتم‌های رایج لود بلانسینگ کدامند؟

پاسخ:

• Round Robin: درخواست‌ها به ترتیب و نوبتی بین سرورها تقسیم می‌شوند.

• Weighted Round Robin: به سرورهای قوی‌تر وزن (سهم) بیشتری داده می‌شود.

• Least Connections: درخواست جدید به سروری ارسال می‌شود که اتصالات فعال کمتری دارد.

• IP Hash: بر اساس IP کاربر یک هش ساخته می‌شود تا درخواست‌های یک کاربر همیشه به یک سرور مشخص برود.

۴. مفهوم Sticky Sessions (یا Session Affinity) چیست و چه زمانی استفاده می‌شود؟

پاسخ: مکانیزمی است که باعث می‌شود تمام درخواست‌های یک کاربر مشخص در طول یک Session، همیشه به همان سرور اولیپ پیوند داده شوند. این روش زمانی استفاده می‌شود که Sessionهای کاربر به صورت متمرکز (مثل Redis) ذخیره نشده باشند و روی حافظه همان سرور قرار داشته باشند.

۵. مکانیزم Health Check در لود بلانسر چگونه کار می‌کند؟

پاسخ: لود بلانسر به طور مداوم (مثلاً هر ۵ ثانیه) پنگ یا درخواست‌های تست (HTTP Get / Health endpoint) به سرورهای پشت سر خود ارسال می‌کند. اگر سروری پاسخ ندهد یا خطایی مثل 500 برگرداند، لود بلانسر آن سرور را Unhealthy تشخیص داده و ترافیک را از روی آن برمی‌دارد تا زمانی که دوباره سالم شود.

۶. منظور از SSL Termination (یا SSL Offloading) چیست؟

پاسخ: فرایندی است که در آن گواهی SSL/TLS روی خودِ لود بلانسر نصب می‌شود. لود بلانسر رمزنگاری HTTPS را رمزگشایی کرده و درخواست را به صورت HTTP ساده به سرورهای داخلی فرستاده تا بار پردازشی سنگین سنگین‌سازی/رمزنگاری SSL از روی سرورهای اصلی برداشته شود.

۷. معروف‌ترین ابزارهای لود بلانسینگ (نرم‌افزاری و ابری) کدامند؟

پاسخ:

• نرم‌افزاری/اپن‌سورس: Nginx ،HAProxy ،Traefik ،Envoy

• ارائه‌دهندگان ابری: AWS ALB/NLB ،Azure Load Balancer ،Cloudflare

• سخت‌افزاری: F5 BIG-IP ،Citrix ADC

۸. چطور خودِ Load Balancer را از تک‌نقطه خرابی (Single Point of Failure) خارج کنیم؟

پاسخ: با استفاده از HA (High Availability) و قرار دادن حداقل دو لود بلانسر به صورت Active/Passive یا Active/Active. ابزارهایی مثل Keepalived یا پروتکل VRRP با استفاده از یک IP شناور (Virtual IP)، در صورت از دست رفتن لود بلانسر اصلی، بلافاصله ترافیک را روی لود بلانسر پشتیبان سوئیچ می‌کنند.

جمع‌بندی و نتیجه‌گیری

برخلاف دیدگاه سنتی که لود بالانسر (Load Balancer) را صرفاً ابزاری برای «توزیع و تقسیم ترافیک» می‌دانست، در امروزه این تکنولوژی هسته مرکزی پایداری (Availability)، مقیاس‌پذیری (Scalability) و امنیت (Security) در زیرساخت‌های مدرن وب، سامانه‌های ابری (Cloud-Native) و معماری‌های میکروسرویس محسوب می‌شود. لود بالانسر دقیقاً در نقطه‌ای قرار دارد که تجربه کاربر نهایی را به کیفیت زیرساخت پشت صحنه پیوند می‌دهد؛ بنابراین، کوچک‌ترین خطا در انتخاب یا تنظیم آن، کل زیرساخت را تحت تأثیر قرار خواهد داد.

برای دستیابی به یک پیاده‌سازی بهینه، هوشمندانه و پایدار، اتکا به سه اصل کلیدی زیر ضروری است:

۱. شناخت دقیق جنس و ماهیت ترافیک (توازن میان لایه ۴ و لایه ۷): انتخاب لایه عملکردی باید بر اساس نیاز واقعی برنامه باشد. اگر با ترافیک غیر وب (مانند پروتکل‌های UDP/TCP، دیتابیس‌ها یا بازی‌های آنلاین) سروکار دارید یا نیاز به پردازش فوق‌العاده سریع با حداقل تاخیر (Latency) دارید، لود بالانسینگ لایه ۴ (Transport Layer) بهترین گزینه است. در مقابل، اگر به مسیریابی هوشمند بر اساس URL، مدیریت کوکی‌ها، بررسی هدرهای HTTP و سبک‌سازی بار پردازشی سرورها از طریق SSL Termination نیاز دارید، باید به سراغ لود بالانسینگ لایه ۷ (Application Layer) بروید.

۲. حرکت به سمت معماری بدون وضعیت (Stateless Architecture): وابستگی سرورها به نشست‌های کاربر (Session State)، بزرگ‌ترین مانع در مسیر مقیاس‌پذیری پویاست. تا حد امکان برنامه‌ها را به‌صورت بی‌وضعیت (Stateless) طراحی کنید یا مدیریت وضعیت‌ها را به پایگاه‌های داده مستقل (مانند Redis) بسپارید. این کار نیاز به Sticky Session را از بین می‌برد و به لود بالانسر اجازه می‌دهد با استفاده از الگوریتم‌های پیشرفته و پویایی نظیر Least Connections یا Weighted Response Time، بار کاری را به‌طور کاملاً متوازن و عادلانه توزیع کند.

۳. حذف نقطه تک‌شکست (SPOF) در تمام سطوح زیرساخت: اضافه کردن یک لود بالانسر منفرد، خود می‌تواند به یک نقطه شکست خطرساز (Single Point of Failure) تبدیل شود. برای تضمین تداوم کسب‌وکار، همواره باید لود بالانسرها را به‌صورت جفت و در حالت Active-Passive یا Active-Active به همراه تکنولوژی‌هایی نظیر Virtual IP (VIP) و پروتکل‌های هم‌بندی (مانند VRRP یا Keepalived) پیاده‌سازی کنید. تنها در این صورت است که زیرساخت شما در برابر حوادث غیرمنتظره و قطعی‌های ناگهانی مقاوم شده و پایداری واقعی را تجربه خواهد کرد.

در نهایت، لود بالانسر یک قطعه ایستا در شبکه نیست؛ بلکه موجودیتی پویاست که باید همگام با رشد ترافیک، تغییر الگوی کاربران و توسعه برنامه‌ها، به‌روزرسانی و پایش (Monitor) شود.

• 🎯 دریافت مشاوره تخصصی و ثبت سفارش در ImaniNova