Salutare tuturor. Am dat de o problemă de infrastructură care mă cam strânge în spate și am nevoie de experiența voastră. Am un client cu un SaaS de nișă care a crescut destul de mult în ultimele 6 luni. Acum avem în jur de 12.000 de utilizatori activi zilnic. Totul rulează pe un singur VPS la Hetzner (8 vCPUs, 32GB RAM). Problema e că în orele de vârf, pe la prânz, baza de date și parserul de PDF-uri îmi duc procesorul în 98%.
Clientul a mirosit că treaba e instabilă și a venit cu directiva: „Vreau scalare pe 3 servere, să fim siguri că dacă pică unul, aplicația merge mai departe”. Sună bine pe hârtie. În practică, eu sunt software engineer, nu sysadmin. N-am configurat în viața mea un load balancer de producție și acum mă uit ca mâța-n calendar la opțiuni.
De unde începem separarea?
Din ce am citit, prima mișcare e să scot baza de date pe un server separat. Deci aș avea:
- Server 1: Load Balancer (Nginx sau HAProxy?)
- Server 2: Aplicația Web (PHP/Laravel)
- Server 3: Baza de date (PostgreSQL)
But wait, asta nu rezolvă cerința clientului de „high availability” pentru codul de aplicație. Ca să am redundanță reală, îmi trebuie cel puțin două servere de aplicație identice în spatele load balancer-ului. Asta înseamnă deja 4 servere în total, nu 3.
Dilemele tehnice care mă țin treaz noaptea
Dacă sparg aplicația pe două servere web, apar imediat trei probleme mari pe care pe un singur server le ignoram elegant.
1. Sesiunile utilizatorilor
Acum sesiunile sunt salvate pe disc, local. Dacă un user nimerește pe Serverul A și apoi load balancer-ul îl trimite pe Serverul B, e delogat instant.
- Trade-off: Aș putea folosi „sticky sessions” în Nginx. E simplu de configurat și scap de bătăi de cap pe moment. Totuși, dacă Serverul A pică, toți userii de pe el își pierd sesiunea. Soluția curată ar fi să mut sesiunile în Redis. Dar asta înseamnă încă un serviciu de administrat și securizat. Merită efortul acum?
2. Upload-urile de fișiere
Avem mulți useri care încarcă PDF-uri și imagini. Momentan le salvez local în /storage. Dacă am două servere web, fișierul urcat pe Serverul A nu va exista pe Serverul B.
- Soluția rapidă: Un share de rețea prin NFS. Am auzit însă că NFS încetinește request-urile groaznic când ai multe fișiere mici.
- Soluția corectă: Să migrez tot codul să folosească AWS S3 sau o alternativă compatibilă S3 de la Hetzner/Cloudflare. Asta implică refactoring în cod și teste masive.
3. Conexiunile la baza de date (PgBouncer?)
Dacă am două servere de aplicație care rulează procese PHP-FPM, numărul de conexiuni simultane către Postgres se va dubla. Am citit că Postgres suferă dacă are prea multe conexiuni deschise degeaba. Am nevoie de PgBouncer din prima zi sau la 12k useri Postgres se descurcă și singur pe un server dedicat?
Cum ați abordat voi prima scalare?
Sunt destul de stresat pentru că riscul să stric ceva ce acum funcționează (chiar și la 98% CPU) este destul de mare.
Voi cum ați face tranziția asta cu cel mai mic risc de downtime? Ați merge direct pe AWS cu servicii managed (RDS, ALB, S3) deși costurile cresc de 5 ori, sau ați construi infrastructura asta „de mână” pe servere VPS ieftine? Cum ați rezolvat problema fișierelor și a sesiunilor la prima voastră scalare?