لود بالانسر چیست؟ راهنمای کامل توزیع بار و الگوریتم‌ها

لود بالانسر چیست و چرا به آن نیاز دارید؟

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

کاربرد اصلی لود بالانسر فراتر از «فقط پخش کردن ترافیک» است. یک لود بالانسر خوب باید سه کار را همزمان انجام دهد: توزیع بار بر اساس الگوریتم مناسب، بررسی سلامت (Health Check) مداوم سرورها، و مدیریت نشست (Session Persistence) برای کاربرانی که درخواست‌های متوالی دارند. بدون هر کدام از این سه، زیرساخت شما در عمل ناپایدار خواهد بود.

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

انواع لود بالانسر: سخت‌افزاری، نرم‌افزاری و DNS

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

لود بالانسر سخت‌افزاری

دستگاه‌های فیزیکی مانند F5 BIG-IP یا Citrix ADC هستند که به‌صورت اختصاصی برای توزیع بار طراحی شده‌اند. مزیت اصلی آن‌ها کارایی بسیار بالا و قابلیت‌های پیشرفته مانند SSL termination و فایروال لایه ۷ است. اما هزینه خرید و نگهداری آن‌ها بالاست و مقیاس‌پذیری آن‌ها محدود به سخت‌افزار است. برای کسب‌وکارهای کوچک و متوسط معمولاً گزینه‌ای غیراقتصادی محسوب می‌شوند.

لود بالانسر نرم‌افزاری

ابزارهایی مانند NGINX، HAProxy و Traefik که روی یک سرور معمولی نصب می‌شوند. این گزینه محبوب‌ترین انتخاب برای استارتاپ‌ها و شرکت‌های متوسط است. HAProxy به‌ویژه برای توزیع بار لایه ۴ (TCP/UDP) و لایه ۷ (HTTP/HTTPS) بسیار قدرتمند است. NGINX علاوه بر لود بالانسر بودن، می‌تواند نقش وب سرور و reverse proxy را هم ایفا کند. نصب و پیکربندی آن‌ها نسبتاً ساده است و مستندات خوبی دارند.

لود بالانسر DNS

در این روش، از DNS برای توزیع بار استفاده می‌شود. به این صورت که یک دامنه به چند IP پاسخ می‌دهد و کلاینت به‌صورت تصادفی یکی را انتخاب می‌کند. سرویس‌هایی مانند AWS Route 53 یا Cloudflare از این روش استفاده می‌کنند. مزیت آن سادگی و عدم نیاز به زیرساخت اضافی است، اما معایب جدی دارد: اگر یکی از سرورها از کار بیفتد، DNS همچنان IP آن را برمی‌گرداند تا زمانی که TTL منقضی شود. همچنین کنترل دقیقی روی توزیع بار ندارد و برای برنامه‌های حساس به نشست مناسب نیست.

در زیرساخت‌های ابری مدرن، معمولاً ترکیبی از لود بالانسر نرم‌افزاری (برای ترافیک داخلی) و DNS (برای failover در سطح منطقه) استفاده می‌شود. اگر به‌تازگی قصد راه‌اندازی سرویسی دارید، پیشنهاد می‌کنم با HAProxy یا NGINX شروع کنید؛ این ابزارها در سرورهای ابری ServerNet نیز به‌راحتی قابل نصب هستند.

الگوریتم‌های توزیع بار: کدام یک برای شما مناسب است؟

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

Round Robin و Weighted Round Robin

ساده‌ترین الگوریتم، Round Robin است که درخواست‌ها را به‌صورت چرخشی بین سرورها توزیع می‌کند: درخواست اول به سرور A، دوم به B، سوم به C و سپس دوباره به A. این روش برای سرورهایی با توان یکسان عالی است. اما اگر سرورها توان متفاوتی دارند، از Weighted Round Robin استفاده کنید. به هر سرور یک وزن اختصاص می‌دهید؛ مثلاً سرور A وزن ۳ و سرور B وزن ۱ داشته باشد، یعنی از هر ۴ درخواست، ۳ تا به A و ۱ تا به B می‌رود.

مثال پیکربندی در HAProxy:

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:80 weight 3 check
    server web2 192.168.1.11:80 weight 1 check

Least Connections

این الگوریتم درخواست را به سروری می‌فرستد که در حال حاضر کمترین تعداد اتصال فعال را دارد. برای برنامه‌هایی که درخواست‌های طولانی دارند (مانند آپلود فایل یا WebSocket) بسیار مناسب است. در HAProxy با دستور balance leastconn فعال می‌شود. این روش نسبت به Round Robin هوشمندتر است، اما نیاز به نظارت مداوم بر تعداد اتصالات دارد.

IP Hash و Source IP Affinity

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

الگوریتم‌های پیشرفته‌تر

برخی لود بالانسرها الگوریتم‌های پیچیده‌تری دارند، مانند Least Response Time (کمترین زمان پاسخ) یا Consistent Hashing که برای کش‌های توزیع‌شده استفاده می‌شود. این الگوریتم‌ها معمولاً در ابزارهای تجاری یا سرویس‌های ابری موجود هستند. برای شروع، Round Robin و Least Connections کافی است.

Health Check: تضمین پایداری سرویس

لود بالانسر بدون health check فقط یک توزیع‌کننده کور است. اگر سروری از کار بیفتد، لود بالانسر همچنان درخواست‌ها را به آن می‌فرستد و کاربران خطا می‌بینند. Health check مکانیزمی است که لود بالانسر به‌طور دوره‌ای سلامت سرورها را بررسی می‌کند و سرورهای ناسالم را از چرخه حذف می‌کند.

انواع Health Check

• TCP Check: لود بالانسر یک اتصال TCP به پورت مشخص (مثلاً ۸۰ یا ۴۴۳) برقرار می‌کند. اگر اتصال موفق باشد، سرور سالم است. این ساده‌ترین روش است اما فقط بررسی می‌کند که پورت باز است، نه اینکه برنامه واقعاً کار می‌کند.
• HTTP Check: لود بالانسر یک درخواست HTTP به یک مسیر خاص (مثلاً /health) می‌فرستد و بررسی می‌کند که پاسخ با کد 200 برگردد. این روش دقیق‌تر است و می‌تواند وضعیت اتصال به دیتابیس یا سرویس‌های دیگر را هم بررسی کند.
• Custom Script Check: برای نیازهای خاص، می‌توانید یک اسکریپت بنویسید که سلامت برنامه را به‌طور کامل بررسی کند. مثلاً بررسی کند که صف پیام‌ها پر نشده باشد.

مثال پیکربندی HTTP health check در NGINX:

upstream backend {
    server 192.168.1.10:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:80 max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_next_upstream error timeout http_502;
    }
}

در این مثال، اگر سروری سه بار در ۳۰ ثانیه خطا بدهد، به‌طور موقت از چرخه حذف می‌شود. پارامتر proxy_next_upstream باعث می‌شود اگر سرور اول خطای 502 برگرداند، درخواست به سرور بعدی ارسال شود.

مدیریت نشست (Session Persistence)

بسیاری از برنامه‌های وب، اطلاعات نشست کاربر را روی سرور ذخیره می‌کنند. اگر کاربری که به سرور A متصل شده، درخواست بعدی‌اش به سرور B برود، نشست او از بین می‌رود و مجبور می‌شود دوباره لاگین کند. برای حل این مشکل، از مدیریت نشست استفاده می‌شود که به آن Sticky Session یا Session Affinity نیز گفته می‌شود.

روش‌های پیاده‌سازی Sticky Session

• Cookie-based: لود بالانسر یک کوکی به نام SERVERID در مرورگر کاربر تنظیم می‌کند. در درخواست‌های بعدی، کاربر این کوکی را می‌فرستد و لود بالانسر بر اساس آن، کاربر را به همان سرور هدایت می‌کند. این روش در HAProxy با گزینه cookie SERVERID insert indirect فعال می‌شود.
• Source IP Affinity: همان الگوریتم IP Hash که قبلاً توضیح دادیم. ساده است اما اگر کاربران پشت یک NAT یا پروکسی باشند، همه آن‌ها یک IP دارند و به یک سرور هدایت می‌شوند.
• Session Replication: به‌جای چسباندن کاربر به یک سرور، نشست را بین همه سرورها کپی می‌کنید. این روش پیچیده است اما مقیاس‌پذیری بهتری دارد. ابزارهایی مانند Redis یا Hazelcast برای این کار استفاده می‌شوند.

مثال Sticky Session در HAProxy:

backend web_servers
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 192.168.1.10:80 cookie web1 check
    server web2 192.168.1.11:80 cookie web2 check

جمع‌بندی و توصیه عملی

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

1. اگر زیرساخت کوچکی دارید (کمتر از ۵ سرور)، با HAProxy و الگوریتم Round Robin شروع کنید.
2. حتماً health check را از روز اول فعال کنید؛ حتی اگر فقط یک سرور دارید.
3. اگر برنامه شما نشست دارد، ابتدا سعی کنید آن را stateless کنید (با Redis). اگر نشد، از Sticky Session استفاده کنید.
4. برای ترافیک بسیار بالا، لود بالانسر را به‌صورت Active-Passive راه‌اندازی کنید تا خود لود بالانسر هم نقطه شکست نباشد.

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