upstream my_app {
# ip_hash; # Activează asta dacă nu ai Redis pentru sesiuni încă
server 10.0.0.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
server_name aplicatie.ro;
location / {
proxy_pass http://my_app;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}Am avut recent cazul unui client cu un SaaS de e-commerce care a crescut brusc de la 2.000 la peste 12.000 de utilizatori activi pe zi. Serverul lor unic, un VPS bunicel, începuse să gâfâie la orele de vârf, așa că mi s-a cerut direct: „Vrem să mutăm aplicația pe 3 servere în spatele unui load balancer ca să fim siguri că nu pică”. Dacă ești în punctul ăsta și n-ai mai făcut-o, panica e normală, dar soluția e mai pământeană decât pare.
Nu te arunca direct la Kubernetes sau arhitecturi serverless complexe dacă nu le stăpânești deja. O să-ți prinzi urechile în debugging și vei pierde nopțile când pică ceva. Cel mai sănătos e să o iei pas cu pas, separând responsabilitățile.
Pasul 1: Load Balancer-ul și problema sesiunilor
Primul pas e să pui un server Nginx în fața celorlalte. Acesta va primi tot traficul și îl va distribui către cele 3 servere de aplicație (web nodes).
Aici apare primul blocaj major: unde ții sesiunile utilizatorilor? Dacă un user se loghează pe Serverul 1, iar la următoarea accesare Load Balancer-ul îl trimite pe Serverul 2, se va trezi delogat.
Pentru asta ai două variante. Varianta rapidă (dar „murdară”) este să folosești ip_hash în Nginx, care trimite mereu același IP către același server. Merge bine pentru început, dar e nasol dacă mulți useri vin din spatele aceluiași IP de corporație sau VPN, caz în care un singur server va fi supraîncărcat în timp ce celelalte șomează. Varianta corectă, pe care am aplicat-o și noi, este să muți sesiunile într-o bază de date Redis centralizată, accesibilă de toate cele 3 noduri.
Pasul 2: Baza de date și PgBouncer
Când ai un singur server, aplicația se conectează direct la baza de date locală. Când ai 3 servere de aplicație care bat în același server de PostgreSQL, numărul de conexiuni deschise crește de trei ori. PostgreSQL pornește câte un proces OS pentru fiecare conexiune, iar asta îți va îngenunchea rapid memoria RAM.
Am pățit ca serverul de DB să intre în Out-Of-Memory (OOM) în prima zi de teste. Salvarea a fost PgBouncer, un pooler de conexiuni ușor. L-am configurat în mod transaction pooling. Practic, aplicațiile cred că au sute de conexiuni deschise, dar PgBouncer folosește doar vreo 20 de conexiuni reale către PostgreSQL, reciclându-le extrem de rapid. Am economisit cam 35% din memoria RAM a bazei de date doar prin această mișcare.
Pasul 3: Unde punem fișierele încărcate de useri?
Dacă un utilizator încarcă un avatar pe Serverul 1, imaginea va fi salvată pe discul acelui server. Când alt utilizator (sau chiar el) va nimeri pe Serverul 3, imaginea nu va fi găsită.
Nu încerca să sincronizezi folderele cu rsync sau sshfs în timp real; e o rețetă sigură pentru lag și fișiere corupte. Soluția curată este să muți toate upload-urile într-un serviciu de stocare compatibil cu S3 (noi am ales Cloudflare R2 ca să evităm taxele de download/egress) și să pui un CDN (precum Cloudflare sau CloudFront) în față pentru cache-ul activelor statice.
Voi cum ați gestionat prima trecere de la un singur monolit la o arhitectură multi-server? Ați mers pe varianta clasică sau ați sărit direct în cloud-ul administrat?