MongoDB și Redis administrat în România

Ce facem pentru MongoDB și pentru Redis

Sunt două roluri diferite, deci două configurații diferite. MongoDB primește un replica set pe trei noduri, indecși potriviți pe interogările reale, validare de schemă unde contează și backup cu restaurare verificată. Redis primește limită de memorie, politică de evacuare aleasă în funcție de rol, persistență AOF sau RDB și Sentinel pentru comutare. Le monitorizăm împreună, pentru că o cădere de cache se vede imediat ca presiune pe baza principală.

• Indecși și proiecții revizuite pe interogările din trafic real
• TTL pe colecțiile de sesiuni, evenimente și cozi temporare
• Redis separat pe roluri: cache, cozi, rate limiting
• Alertare pe rata de succes a cache-ului și pe memoria consumată

Bune practici pe care le aplicăm la NoSQL

Majoritatea incidentelor cu MongoDB și Redis nu vin din trafic, ci din configurația implicită lăsată neatinsă după instalare. De aceea aplicăm aceeași listă la fiecare livrare și o notăm în documentația pe care o primești, ca să poți verifica singur oricând. Instanțele expuse public, fără parolă, sunt găsite de scanere automate în câteva ore de la pornire, așa că izolarea de rețea nu este opțională la noi, în niciun mediu.

• Replica set pe trei noduri, cu comutare verificată în practică
• Autentificare și TLS obligatorii, legare doar pe rețeaua privată
• maxmemory și politică de evacuare stabilite explicit pentru fiecare instanță
• Persistență AOF sau RDB plus Sentinel ori Cluster, în funcție de rol
• ACL-uri în Redis și exerciții periodice de restaurare din backup

Unde se potrivesc în arhitectura ta

Redis intră când același răspuns este calculat de mii de ori: cataloage, disponibilitate, coșuri, limitare de cereri, cozi de procesare. MongoDB intră când documentele diferă între ele și schema se schimbă de la o versiune la alta: cataloage cu atribute variabile, fișe de client, evenimente, conținut. Când datele au relații stricte și rapoarte financiare, spunem direct că PostgreSQL este alegerea mai bună și îți arătăm de ce.

• Cache de citire în fața API-urilor cu trafic inegal
• Cozi de procesare pentru facturi, e-mailuri și rapoarte
• Documente cu atribute variabile, fără migrări de schemă la fiecare lansare

Orele incluse și cum le ceri

Administrarea intră în orele lunare din abonament: 1–8 ore pe VPS, 5–10 ore pe servere dedicate, în funcție de plan, și 10 ore pe GPU, iar pe cPanel 1 oră de la planul Advanced în sus. Se cer din panoul de client, secțiunea Servicii DevOps, cu termen propus de tine. Orele nu se reportează în luna următoare, deci le planificăm: într-o lună migrarea și hardeningul, în alta indecșii și politica de cache. Peste cotă lucrăm în continuare, cu facturare separată.

Cum lucrăm

1. Ceri lucrarea din panou

   Deschizi cererea în panoul de client, la Servicii DevOps, cu volumele actuale, tipul de trafic și termenul care îți convine.

2. Stabilim scopul și termenul

   Ne uităm la interogări, memorie și modul în care aplicația folosește cache-ul, apoi convenim ce intră în orele incluse luna asta.

3. Livrăm și verificăm sub trafic

   Punem replica set, autentificarea, politicile de memorie și backupul, apoi urmărim rata de cache și latența percepută de aplicație.

4. Predăm cu documentație

   Primești configurațiile, regulile de acces, planul de backup și pașii de comutare, plus rezultatul exercițiului de restaurare.

Cazuri de utilizare

Tehnologii

• MongoDB
• Redis
• Redis Sentinel
• Percona Backup for MongoDB
• HAProxy
• Prometheus
• Grafana
• WireGuard

Întrebări frecvente

• Ce este Redis și la ce folosește?

  Redis este o bază de date în memorie, folosită pentru cache, sesiuni, cozi de procesare și limitarea cererilor. Ține datele în RAM, deci răspunde foarte rapid, dar are nevoie de limită de memorie, politică de evacuare și persistență configurate corect ca să nu piardă date la repornire.

• Ce hosting suportă MongoDB și Redis?

  Planurile VPS, serverele dedicate și cele GPU, cu acces root, în Frankfurt. Pe cPanel nu se poate: acolo rulează stiva LAMP clasică. Dacă vii de la alt furnizor, migrarea este gratuită și o facem noi, cu fereastră de indisponibilitate stabilită împreună.

• Pot rula MongoDB pe un hosting shared sau am nevoie de VPS?

  Ai nevoie de VPS sau de server dedicat. MongoDB cere control asupra procesului, memoriei și rețelei, lucruri care nu există pe shared. În plus, un replica set corect are trei noduri, deci presupune resurse dedicate și rețea privată între ele.

• MongoDB vs Redis: când folosești fiecare?

  MongoDB este depozitul principal pentru documente care trebuie păstrate: fișe, cataloage, evenimente. Redis este stratul rapid, de obicei temporar: cache, sesiuni, cozi. Se completează, nu se înlocuiesc. Dacă datele au relații stricte, îți recomandăm PostgreSQL în locul ambelor.

• Cum securizez o instanță Redis sau MongoDB expusă public?

  Prima măsură este să nu fie expusă. Legăm serviciul pe interfața privată sau pe VPN, închidem portul în firewall, activăm autentificarea, TLS și ACL-urile, apoi verificăm din exterior că portul nu răspunde. O instanță deschisă, fără parolă, este compromisă în ore.

• Ce se întâmplă dacă un nod din replica set cade?

  Setul alege automat un nod primar nou, iar aplicația se reconectează prin driver. Comutarea o testăm la livrare, nu doar o configurăm, și notăm în documentație ce urme lasă în loguri, ca echipa ta să recunoască situația imediat.