Salutare tuturor. Am dat de un prag de care m-am tot ferit în ultimii ani, preferând să fac scale-up pe verticală până nu se mai poate. Un client cu un SaaS destul de activ (avem cam 14.000 de utilizatori unici pe zi) s-a trezit că vrea high availability și scalare pe trei servere de aplicație în spatele unui load balancer. Până acum totul rula pe un singur VPS baban de 64GB RAM, unde aveam și Node.js, și Postgres, și fișierele încărcate de useri.
Problema e că n-am mai configurat o infrastructură multi-server cap-coadă și mi-e teamă să nu dau chix cu sincronizarea. Când ai o singură mașină, viața e simplă. Când ai trei, încep durerile de cap.
Prima dilemă: Load balancer-ul și sesiunile sticky
M-am gândit să pun un Nginx ca reverse proxy și load balancer pe o mașină separată, cea mai ieftină. Totuși, dacă pică VPS-ul cu Nginx, pică tot sistemul, deci am rezolvat fix nimic pe partea de redundanță reală. Alternativa ar fi un Application Load Balancer de la AWS sau cel de la DigitalOcean, dar asta mă leagă de cloud-ul lor și costurile cresc destul de repede. Să merg pe managed sau să-mi bat capul cu Keepalived și IP-uri flotante?
La nivel de cod, sesiunile utilizatorilor sunt acum stocate local, în memoria procesului Node. Știu, e o practică proastă, dar a funcționat perfect pentru că aveam un singur server. Acum, dacă un user nimerește pe Serverul 1 la login și apoi pe Serverul 2 la următoarea cerere, e deconectat instant. Soluția logică e Redis pentru sesiuni. Dar merită să configurez un Redis Sentinel pentru redundanță sau e suficient un singur nod Redis securizat? Trade-off-ul e destul de dureros: petrec trei zile configurând clustering sau risc să am un single point of failure în Redis pentru a economisi timp?
Baza de date și coșmarul conexiunilor
Aici cred că e cel mai mare risc de blocaj. Postgres rulează pe mașina lui separată. În prezent, aplicația Node are un pool de maximum 80 de conexiuni și rareori trece de 40 active. Dacă pun trei servere de aplicație, fiecare va încerca să își rezerve propriul pool de conexiuni. Riscăm să atingem limita de conexiuni active foarte repede când avem spike-uri de trafic.
Am citit despre PgBouncer, dar pare o bestie destul de greu de îmblânzit dacă n-ai mai făcut asta. Întrebarea mea este: la doar trei servere de aplicație, chiar am nevoie de PgBouncer ca middleware de pooling, sau pot să scap pur și simplu reducând pool-ul din Node la 20 de conexiuni per server și crescând limita în Postgres? Am testat faza asta pe un mediu de staging improvizat și latency-ul a crescut cu vreo 15ms la query-uri simple când pool-ul era prea mic și se băteau procesele pe el.
Fișierele statice și CDN-ul
Asta pare singura parte ușoară. Momentan salvăm PDF-urile generate și pozele de profil direct pe SSD-ul VPS-ului. Pe infrastructură multiplă, asta clar nu mai merge. Planul meu e să migrez totul pe Cloudflare R2 sau AWS S3. Am făcut deja un script de migrare care mută cele 120GB de asset-uri existente, dar mă îngrijorează costurile de API calls dacă nu pun un CDN deștept în față.
Voi cum ați trecut pragul ăsta prima dată? Ați mers pe varianta simpleră cu setări minimale în Postgres și Redis pe o singură mașină, sau ați făcut overengineering din prima zi ca să dormiți liniștiți noaptea? Ce capcane ascunse are configurarea asta pe care un dev de backend clasic s-ar putea să le rateze?