MongoDB és Redis üzemeltetés

Amit a MongoDB-hez és a Redishez teszünk

Két különböző szerep, ezért két különböző beállítás. A MongoDB háromcsomópontos replica setet kap, a valódi lekérdezésekhez illő indexeket, ahol számít, sémaellenőrzést, és tesztelt visszaállítással rendelkező mentést. A Redis memóriakorlátot kap, a szerephez illő kiürítési szabályt, AOF vagy RDB perzisztenciát, valamint Sentinelt az átváltáshoz. A kettőt együtt figyeljük, mert egy cache-kiesés azonnal terhelésként jelenik meg a fő adatbázison. A beállítást minden esetben a te forgalmi mintáid alapján finomítjuk, nem egy általános sablon szerint.

• Indexek és projekciók a valódi forgalom lekérdezéseihez igazítva
• TTL a munkamenet-, esemény- és ideiglenes sorkollekciókon
• Redis szerep szerint elkülönítve: cache, sorok, forgalomkorlátozás
• Riasztás a cache-találati arányra és a felhasznált memóriára

Bevált gyakorlatok, amelyeket alkalmazunk

A legtöbb MongoDB- és Redis-incidens nem a forgalomból, hanem a telepítés után érintetlenül hagyott alapértelmezett beállításból ered. Ezért minden átadásnál ugyanazt a listát alkalmazzuk, és beírjuk a dokumentációba, hogy bármikor magad is ellenőrizhesd. A nyilvánosan elérhető, jelszó nélküli példányokat automatikus scannerek órákon belül megtalálják a telepítés után, ezért nálunk a hálózati elkülönítés egyetlen környezetben sem opcionális. Ezt a fegyelmet a teszt- és a fejlesztői környezetekben is ugyanúgy tartjuk, nem csak éles rendszeren.

• Háromcsomópontos replica set, gyakorlatban tesztelt átváltással
• Kötelező hitelesítés és TLS, kötés csak a privát hálózatra
• maxmemory és kiürítési szabály minden egyes példányra kifejezetten beállítva
• AOF vagy RDB perzisztencia, plusz Sentinel vagy Cluster a szereptől függően
• Redis ACL-ek és rendszeres visszaállítási gyakorlat a mentésekből

Hova illik a te architektúrádba

A Redis akkor lép be, amikor ugyanazt a választ ezerszer kellene újraszámolni: katalógusok, elérhetőség, kosarak, forgalomkorlátozás, feldolgozási sorok. A MongoDB akkor, amikor a dokumentumok eltérnek egymástól, és a séma verzióról verzióra változik: változó attribútumú katalógusok, ügyféllapok, események, tartalom. Ha az adataid szigorúan relációsak, és pénzügyi riportokra van szükséged, nyíltan elmondjuk, hogy a PostgreSQL a jobb választás, és megmutatjuk, miért ezt javasoljuk helyette.

• Olvasási cache az ingadozó forgalmú API-k elé
• Feldolgozási sorok számlákhoz, e-mailekhez és riportokhoz
• Változó attribútumú dokumentumok, sémamigráció nélkül minden kiadásnál

A beleértett órák és a migráció

Az üzemeltetés a havi keretbe tartozik: 1–8 óra a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken, a cPanelen 1 óra az Advanced tervtől felfelé. Az ügyfélpanelből kéred, a DevOps szolgáltatások menüpontban, a te javasolt határidőddel. Az órák nem gördülnek át a következő hónapra, ezért tervezünk velük: egyik hónapban a migráció és a hardening, a másikban az indexek és a cache-szabály. A kereten felül is dolgozunk, külön számlázással.

Hogyan dolgozunk

1. Igényled a panelből

   Kérést nyitsz az ügyfélpanel DevOps szolgáltatások menüpontjában, megadod a jelenlegi adatmennyiséget, a forgalom típusát és a neked megfelelő határidőt.

2. Egyeztetjük a kereteket

   Megnézzük a lekérdezéseket, a memóriahasználatot és azt, hogyan használja az alkalmazás a cache-t, majd megegyezünk, mi fér bele az adott havi keretbe.

3. Megvalósítjuk és teszteljük

   Beállítjuk a replica setet, a hitelesítést, a memóriaszabályokat és a mentést, majd figyeljük a cache-találati arányt és az alkalmazás által érzékelt válaszidőt.

4. Dokumentálva átadjuk

   Megkapod a konfigurációkat, a hozzáférési szabályokat, a mentési tervet, az átváltási lépéseket, valamint a visszaállítási gyakorlat eredményét.

Felhasználási esetek

Technológiák

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

Gyakori kérdések

• Mi az a Redis, és mire használható?

  A Redis egy memóriaalapú adatbázis, amelyet cache-elésre, munkamenetekre, feldolgozási sorokra és forgalomkorlátozásra használnak. Az adatokat RAM-ban tartja, ezért nagyon gyorsan válaszol, de helyesen beállított memóriakorlátra, kiürítési szabályra és perzisztenciára van szüksége, hogy újraindításkor ne veszítsen adatot.

• Milyen hosting támogatja a MongoDB-t és a Redist?

  A VPS-csomagok, a dedikált szerverek és a GPU szerverek, root hozzáféréssel, Frankfurtban. A cPanelen ez nem lehetséges, ott a klasszikus LAMP-verem fut. Ha másik szolgáltatótól jössz, a migráció ingyenes, és mi végezzük, közösen egyeztetett leállási ablakkal.

• Futtathatom a MongoDB-t megosztott tárhelyen, vagy VPS kell?

  VPS-re vagy dedikált szerverre van szükséged. A MongoDB a folyamat, a memória és a hálózat feletti kontrollt igényli, ami megosztott tárhelyen nem érhető el. Ráadásul egy helyesen kialakított replica set három csomópontból áll, ami dedikált erőforrást és privát hálózatot feltételez közöttük.

• MongoDB vagy Redis: mikor melyiket használod?

  A MongoDB a fő tároló azokra a dokumentumokra, amelyeket meg kell őrizni: lapok, katalógusok, események. A Redis a gyors, jellemzően ideiglenes réteg: cache, munkamenetek, sorok. Kiegészítik, nem helyettesítik egymást. Ha az adataid szigorúan relációsak, mindkettő helyett a PostgreSQL-t javasoljuk.

• Hogyan biztosítok egy nyilvánosan elérhető Redis vagy MongoDB példányt?

  Az első lépés, hogy ne legyen nyilvánosan elérhető. A szolgáltatást a privát interfészre vagy VPN-re kötjük, lezárjuk a portot a tűzfalon, bekapcsoljuk a hitelesítést, a TLS-t és az ACL-eket, majd kívülről ellenőrizzük, hogy a port nem válaszol. Egy nyitott, jelszó nélküli példány órák alatt kompromittálódik.

• Mi történik, ha egy csomópont kiesik a replica setből?

  A halmaz automatikusan új elsődleges csomópontot választ, az alkalmazás pedig a driveren keresztül újracsatlakozik. Az átváltást átadáskor teszteljük, nem csak beállítjuk, és a dokumentációban rögzítjük, milyen nyomot hagy a naplókban, hogy a csapatod azonnal felismerje a helyzetet.