راهنمای انتخاب Load Balancer: الگوریتم توزیع بار، Health Check و SSL Termination

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

این راهنما چهار تصمیم اصلی را بررسی می‌کند: Load Balancer را در لایه ۴ یا لایه ۷ قرار بدهید، کدام الگوریتم توزیع بار را انتخاب کنید، Health Check را چطور تنظیم کنید و SSL Termination را کجا انجام بدهید. در پایان هم می‌بینیم سرویس Load Balancer آریانت چه مواردی را پوشش می‌دهد.

Load Balancer چیست و چه زمانی به آن نیاز دارید؟

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

نیاز به Load Balancer معمولاً از یکی از این نشانه‌ها شروع می‌شود: سایت یا API روی یک سرور دیگر جواب‌گوی ترافیک نیست، یک deploy باعث قطعی کامل سرویس می‌شود، یا پروژه برای دسترس‌پذیری بالا باید حداقل دو نسخه از هر سرویس را هم‌زمان اجرا کند. اگر هنوز روی یک سرور تنها کار می‌کنید و مشکل فقط کمبود منابع است، شاید ارتقای پلن سرور کافی باشد؛ Load Balancer زمانی معنا پیدا می‌کند که چند سرور Backend همزمان در کار باشند.

اولین تصمیم: Load Balancer لایه ۴ یا لایه ۷؟

قبل از رفتن سراغ الگوریتم و Health Check، باید مشخص شود Load Balancer روی کدام لایه شبکه کار می‌کند. این انتخاب روی سرعت تصمیم‌گیری، تنظیمات SSL Termination و امکان مسیریابی بر اساس محتوای درخواست اثر می‌گذارد.

Load Balancer لایه ۴ (TCP/UDP) فقط به آدرس IP و پورت نگاه می‌کند و بدون باز کردن محتوای بسته، ترافیک را هدایت می‌کند؛ به همین دلیل سربار پردازشی کمتری دارد. Load Balancer لایه ۷ (HTTP/HTTPS) محتوای درخواست را می‌خواند و می‌تواند بر اساس مسیر URL، هدر یا کوکی تصمیم بگیرد، اما همین کار اضافه کمی سربار پردازشی به همراه دارد.

اگر فقط یک اپلیکیشن وب ساده پشت Load Balancer دارید و نیازی به مسیریابی بر اساس URL نیست، لایه ۴ کافی است. اگر چند سرویس یا نسخه مختلف از یک API را باید بر اساس مسیر یا دامنه از هم جدا کنید، لایه ۷ را انتخاب کنید.

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

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

• Round Robin: درخواست‌ها به‌ترتیب و یکی‌درمیان بین سرورها پخش می‌شوند. ساده‌ترین گزینه و مناسب زمانی که همه سرورهای Backend از نظر منابع و بار یکسان هستند.
• Weighted Round Robin: مثل Round Robin است، با این تفاوت که به هر سرور وزنی می‌دهید؛ سروری با منابع بیشتر سهم بیشتری از درخواست‌ها را می‌گیرد. برای Backendهای ناهمگن (مثلاً دو سرور قدیمی و یک سرور قوی‌تر) مناسب است.
• Least Connections: درخواست به سروری می‌رود که در آن لحظه کمترین تعداد اتصال فعال را دارد. برای درخواست‌هایی که زمان پردازش متفاوت دارند (مثل آپلود فایل یا کوئری‌های سنگین) بهتر از Round Robin عمل می‌کند.
• IP Hash (Source Hash): سرور مقصد بر اساس IP کاربر محاسبه می‌شود، در نتیجه یک کاربر مشخص همیشه به همان سرور وصل می‌شود. وقتی session کاربر روی حافظه محلی یک سرور نگه‌داری می‌شود و از Redis یا دیتابیس مشترک برای session استفاده نمی‌کنید، این گزینه معمولاً تنها راه ساده برای جلوگیری از قطع‌شدن session است.

برای اکثر پروژه‌های جدید که session را در یک منبع مشترک (مثل Redis) نگه می‌دارند، Least Connections یا Weighted Round Robin نقطه شروع مناسبی است؛ IP Hash را فقط وقتی انتخاب کنید که واقعاً به sticky session نیاز دارید، چون انعطاف توزیع بار را کم می‌کند.

Health Check: بدون آن Load Balancer فقط نیمی از کار را انجام می‌دهد

توزیع بار به‌تنهایی کافی نیست؛ اگر یکی از سرورهای Backend خراب شود و Load Balancer همچنان درخواست به آن بفرستد، بخشی از کاربران با خطا مواجه می‌شوند. Health Check همین مشکل را حل می‌کند: به‌صورت دوره‌ای وضعیت هر سرور را بررسی می‌کند و سرورهای ناسالم را موقتاً از چرخه خارج می‌کند.

دو نوع رایج Health Check وجود دارد:

• Active Health Check: Load Balancer خودش به‌طور مستقل درخواست آزمایشی (مثلاً یک TCP handshake ساده یا یک HTTP GET به مسیر /health) به هر Backend می‌فرستد و بر اساس پاسخ تصمیم می‌گیرد.
• Passive Health Check: Load Balancer ترافیک واقعی کاربران را زیر نظر می‌گیرد و اگر یک سرور پشت‌سرهم خطا برگرداند یا تایم‌اوت شود، آن را موقتاً کنار می‌گذارد.

هنگام تنظیم Health Check، این سه پارامتر مهم‌ترند:

• فاصله بررسی (interval): چک خیلی مکرر بار اضافه روی Backend می‌گذارد، چک خیلی کم‌تکرار باعث می‌شود یک سرور خراب مدت بیشتری در چرخه بماند.
• آستانه خرابی (threshold): چند بار پاسخ ناموفق پشت‌سرهم لازم است تا سرور از چرخه خارج شود؛ عدد خیلی پایین باعث حذف اشتباهی سرور سالم به‌خاطر یک تاخیر موقت می‌شود.
• مسیر و معیار سلامت: یک endpoint اختصاصی مثل /health بهتر از چک کردن صفحه اصلی است، چون می‌تواند وضعیت واقعی سرویس (مثلاً اتصال به دیتابیس) را هم گزارش کند، نه فقط اینکه وب‌سرور بالاست.

SSL Termination: گواهی TLS را کجا باز کنیم؟

وقتی ترافیک HTTPS از کاربر می‌رسد، گواهی TLS آن باید جایی رمزگشایی شود. محل این رمزگشایی سه حالت دارد و انتخاب بین آن‌ها روی مصرف CPU سرورهای Backend و پیچیدگی مدیریت گواهی اثر می‌گذارد.

• SSL Termination روی Load Balancer: گواهی TLS فقط روی Load Balancer نصب و مدیریت می‌شود؛ ترافیک بین Load Balancer و Backendها به‌صورت HTTP ساده (یا در شبکه خصوصی) جریان دارد. رایج‌ترین و ساده‌ترین حالت برای اکثر پروژه‌ها، چون تمدید گواهی فقط در یک نقطه انجام می‌شود.
• SSL Passthrough: Load Balancer ترافیک رمزگذاری‌شده را دست‌نخورده به Backend می‌فرستد و رمزگشایی روی خود سرور Backend انجام می‌شود. وقتی الزام امنیتی یا قانونی ایجاب می‌کند ترافیک تا رسیدن به سرور نهایی رمزگذاری بماند، این گزینه لازم می‌شود، هرچند مدیریت گواهی روی هر Backend را پیچیده‌تر می‌کند.
• SSL Re-encryption: Load Balancer ترافیک را رمزگشایی می‌کند، سپس با یک گواهی دیگر دوباره رمزگذاری و به Backend ارسال می‌کند. ترکیبی از دو حالت بالاست: هم مسیریابی لایه ۷ روی Load Balancer ممکن می‌شود، هم ترافیک داخلی رمزگذاری‌شده باقی می‌ماند.

برای اکثر وب‌اپلیکیشن‌هایی که Backend در شبکه خصوصی قرار دارد، SSL Termination روی Load Balancer کافی است. SSL Passthrough یا Re-encryption را فقط زمانی انتخاب کنید که یک الزام مشخص (امنیتی، قانونی یا نیاز به دیدن گواهی اصلی سمت Backend) آن را ایجاب کند.

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

چهار مورد بالا بیشترین اثر را روی رفتار روزمره Load Balancer دارند، اما قبل از انتخاب نهایی این موارد را هم بررسی کنید:

• در دسترس‌بودن خود Load Balancer: یک Load Balancer تکی خودش می‌تواند نقطه خرابی جدید باشد. اگر دسترس‌پذیری در سطح ورودی حیاتی است، به دو نمونه Load Balancer با یک IP مجازی یا سرویس Failover نیاز دارید، نه فقط یک سرور تکی.
• مقیاس‌پذیری: وقتی تعداد سرورهای Backend یا حجم ترافیک رشد می‌کند، آیا باید Load Balancer را دستی مجدداً پیکربندی کنید یا سرویس به‌صورت خودکار Backendهای جدید را تشخیص می‌دهد؟
• هزینه و مدیریت: راه‌اندازی و نگهداری یک Load Balancer خودمیزبان (مثل HAProxy یا Nginx) زمان و دانش فنی می‌خواهد؛ یک سرویس مدیریت‌شده این بار را کم می‌کند اما هزینه ماهانه جداگانه‌ای دارد.

چک‌لیست قبل از انتخاب Load Balancer

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

• ترافیک HTTP/HTTPS است یا نیاز به مسیریابی TCP/UDP خام (مثل دیتابیس) دارید؟
• آیا نیاز به مسیریابی بر اساس URL، دامنه یا هدر دارید؟
• session کاربران در یک منبع مشترک (Redis، دیتابیس) نگه‌داری می‌شود یا به sticky session نیاز دارید؟
• Health Check چه endpoint یا پورتی را باید بررسی کند؟
• گواهی TLS کجا باید مدیریت شود: روی Load Balancer یا روی هر Backend؟
• خود Load Balancer هم به پیکربندی High Availability نیاز دارد یا یک نمونه کافی است؟

کدام سرویس Load Balancer آریانت مناسب شماست؟

اگر پاسخ به چک‌لیست بالا را دارید اما نمی‌خواهید وقت تیم را صرف نصب، تنظیم Health Check و نگهداری روزانه یک Load Balancer خودمیزبان کنید، سرویس Load Balancer آریانت را ببینید. پیکربندی الگوریتم توزیع بار، Health Check و SSL Termination از طریق پنل مدیریت انجام می‌شود، بدون نیاز به ورود به سرور و ویرایش فایل تنظیمات. برای انتخاب پلن مناسب، تعداد Backendها، میزان ترافیک مورد انتظار و نیاز یا بی‌نیازی به مسیریابی لایه ۷ را از قبل مشخص کنید و با پشتیبانی هماهنگ کنید.

جمع‌بندی

انتخاب Load Balancer مناسب از چهار تصمیم تشکیل می‌شود: مشخص‌کردن لایه ۴ یا لایه ۷ بر اساس نیاز به مسیریابی محتوایی، انتخاب الگوریتم توزیع بار متناسب با نحوه مدیریت session، تنظیم دقیق Health Check برای حذف خودکار سرورهای ناسالم، و تصمیم‌گیری درباره محل SSL Termination. چک‌لیست بالا را قبل از خرید یا راه‌اندازی مرور کنید تا تنظیماتی که معمولاً بعد از اولین قطعی کشف می‌شوند، از همان ابتدا روشن باشند.