Load Balancing — masshtab va ishonchlilik

Bitta NestJS serverni tasavvur qil: u sekundiga ma’lum miqdordagi so‘rovni ko‘taradi. Trafik o‘sgan sayin og‘riq boshlanadi.

Load balancer mijozlar bilan serverlar o‘rtasida turadi: barcha so‘rov unga keladi, u esa ularni sog‘lom serverlarga uzatadi.

Bu bir vaqtning o‘zida ikki muammoni hal qiladi: masshtab (server qo‘shib o‘sasan) va ishonchlilik (biri o‘lsa, balanser uni navbatdan chiqaradi, qolganlari ishlaydi).

L4 va L7 — balanser qaysi darajada ishlaydi

Balanser so‘rovni qaysi serverga yuborishini algoritm bilan hal qiladi. Eng muhimlari:

Health check — o‘lik serverni chetlab o‘tish

Balanser doimo serverlarni tekshirib turadi. Javob bermaganini navbatdan chiqaradi, tuzalganda qaytaradi. Ikki xil: aktiv (balanser /healthga so‘rov yuborib turadi) va passiv (oddiy so‘rovlardagi xatolarni kuzatadi). Health check bo‘lmasa — balanser o‘lik serverga ham so‘rov yuborib, foydalanuvchiga xato qaytaradi.

Load balancing ko‘proq infratuzilma ishi, lekin ilova ham unga moslashishi shart. Uch qism: balanser konfiguratsiyasi (Nginx), ilovaning health endpointi va graceful shutdown.

1 · Nginx — upstream va proxy

# nginx.conf — eng keng tarqalgan L7 balanser
upstream app_servers {
    least_conn;                              # eng kam band serverga
    server 10.0.0.1:3000 max_fails=3 fail_timeout=10s;   # passiv health check
    server 10.0.0.2:3000;
    server 10.0.0.3:3000 weight=2;           # kuchliroq server -> 2x yuk
}
server {
    listen 80;
    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # haqiqiy IP
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

2 · NestJS health endpoint

Balanser serverning tirikligini shu yerdan biladi. Muhim: u shunchaki "200 OK" qaytarmasin — haqiqiy bog‘liqliklarni (baza, Redis) tekshirsin:

// NestJS health endpoint — balanser shu yerga so'rov yuboradi (@nestjs/terminus)
@Controller('health')
export class HealthController {
  constructor(
    private health: HealthCheckService,
    private db: PrismaHealthIndicator,
    private prisma: PrismaService,
  ) {}

  @Get()
  @HealthCheck()
  check() {
    // server "sog'lom" deyishi uchun bazaga ham ulana olishi kerak
    return this.health.check([
      () => this.db.pingCheck('database', this.prisma),
    ]);
  }
}

3 · Graceful shutdown — uzilishsiz deploy

Deploy paytida server qayta ishga tushadi. Agar u so‘rovlar o‘rtasida birdan o‘chsa — foydalanuvchilar xato oladi. Graceful shutdown buni hal qiladi:

// main.ts — uzilishsiz deploy uchun graceful shutdown
async function bootstrap() {
  const app = await NestFactory.create<NestExpressApplication>(AppModule);

  app.set('trust proxy', 1);     // LB orqasida -> req.ip haqiqiy mijoz IP'si bo'lsin
  app.enableShutdownHooks();     // SIGTERM/SIGINT'ni ushlaydi

  await app.listen(3000);
}

// onModuleDestroy / onApplicationShutdown hook'ida:
//  1) readiness'ni "unhealthy" qil -> LB yangi so'rov yubormaydi (drain)
//  2) ishdagi so'rovlarni tugat
//  3) DB/Redis ulanishlarini toza yop
// Shunda deploy/restart paytida BIRORTA so'rov yo'qolmaydi.

Yechim 1 · Sticky session (session affinity)

Bitta mijozni doim bitta serverga bog‘lash (IP hash yoki cookie orqali). Oddiy, lekin kamchiliklari bor: yuk notekis taqsimlanadi va o‘sha server o‘chsa — session baribir yo‘qoladi.

Yechim 2 · Stateless server (afzal yo‘l)

Eng to‘g‘ri yo‘l — serverlarni holatsiz (stateless) qilish: hech narsani xotirada saqlamasin. Session’ni tashqi umumiy joyga (Redis) chiqarasan yoki stateless JWT ishlatasan. Shunda istalgan server istalgan so‘rovni qabul qila oladi:

// MUAMMO: session serverning XOTIRASIDA saqlansa -> LB boshqa serverga yuborganda
// foydalanuvchi "tizimdan chiqib ketgan"dek bo'ladi (session o'sha serverda qoldi).

// YECHIM 1: session'ni tashqi umumiy joyga (Redis) chiqarish
import RedisStore from 'connect-redis';
app.use(session({
  store: new RedisStore({ client: redis }),   // session Redis'da, hamma server ko'radi
  secret: process.env.SESSION_SECRET,
  resave: false, saveUninitialized: false,
}));

// YECHIM 2 (ko'proq ishlatiladi): stateless JWT — server hech narsa saqlamaydi,
// token o'zida ma'lumotni olib yuradi -> istalgan server tekshira oladi.

WebSocket holati — alohida e’tibor

WebSocket ulanishi uzoq yashaydi va bitta serverga bog‘lanadi (sticky kerak). Lekin bir serverdagi emit boshqa serverdagi mijozlarga yetishi uchun umumiy "backplane" — masalan Socket.IO Redis adapteri — zarur:

// WebSocket masshtablash: ulanish bitta serverga "yopishadi". Bir serverdagi
// emit boshqa serverdagi clientlarga yetishi uchun Redis "backplane" kerak.
import { createAdapter } from '@socket.io/redis-adapter';

const pub = createClient({ url: 'redis://localhost:6379' });
const sub = pub.duplicate();
await Promise.all([pub.connect(), sub.connect()]);
io.adapter(createAdapter(pub, sub));   // endi broadcast HAMMA server bo'ylab ishlaydi

"Load balancer" — bitta narsa emas; bir necha turi va joyi bor:

Load balancing — deyarli har bir jiddiy production tizimida bor. Lekin to‘g‘ri ishlashi uchun ilova ham qoidalarga rioya qilishi kerak.

• Load balancer — bir nechta bir xil server oldida turib, so‘rovlarni teng taqsimlaydi: masshtab + ishonchlilik (SPOF yo‘qoladi).
• L7 (HTTP, aqlli marshrut) — veb uchun standart; L4 (TCP, tez) — oddiy yuqori hajm uchun. Algoritm: ko‘pincha round robin yoki least connections.
• Health check o‘lik serverni chetlab o‘tadi; graceful shutdown uzilishsiz deploy beradi; trust proxy haqiqiy IP’ni beradi.
• Eng muhim ilova qoidasi — stateless bo‘lish. Session → Redis/JWT. WebSocket → sticky + Redis adapter.
• Balanserning o‘zi SPOF bo‘lmasligi uchun — zaxira LB + floating IP yoki boshqariladigan cloud LB.