REDIS II - o využití v našich projektoch, REDIS clustri a bezpečnosti

Ako využívame REDIS u nás na projektoch?
 

Takmer všetky projekty, ktoré prevádzkujeme či už pre vývojové, testovacie alebo produkčné účely, bežia u nás ako docker containery. REDIS taktiež beží ako samostatný container, s ktorým komunikuje výlučne aplikačný backend. Tento backend sa stará o Read aj Write operácie nad Redisom, o synchronizáciu údajov s SQL databázou a o komunikáciu s frontendovou aplikáciou prostredníctvom load balancera. Ako primárny storage Redis momentálne nepoužívame. Redis sa nachádza asi v 50 % projektov, ktoré sme vyvinuli a prevádzkujeme ich.
 

Použili sme ho na projektoch ako Fitshaker alebo Tiptravel kde plní úlohu cache odpovedí na requesty, ktoré môžu byť cacheované.

A taktiež na projekte Tipos Extraliga + Fantasyliga, kde okrem cache slúži aj na uchovanie rebríčka súťažiacich, ktorý sa dynamicky mení počas zápasu veľmi často a je potrebné ho držať aktuálny a dostupný.

Online záznam z Techband Meetupu:

Redis Cluster
 

Na vývojové alebo testovacie účely si väčšinou vystačíme s jednoduchou inštaláciou Redisu u seba na PC, prípadne si ho spustíme ako docker container. Pri produkčnej prevádzke a predovšetkým pri väčších projektoch však je vhodné a častokrát aj nevyhnutné zaoberať sa hlbšie aj dostupnosťou služby, nakoľko výpadok má pri niektorých typoch služieb priamy dopad aj na financie. Dostupnosť REDISu nám pomáha riešiť aj distribuovaný systém v podobe Redis Clustera.
 

Na vytvorenie distribuovaného prostredia máme 2 možnosti:

1. Redis Sentinel - nižšia rýchlosť oproti clusteru, vysoká dostupnosť (HA), automatic failover solution
2. Redis Cluster - vysoká rýchlosť, vysoká dostupnosť
    

Pre potreby clustera potrebujeme 2 TCP connectiony.

Redis Cluster využíva shardovanie pomocou hash slotu, kde každý kľúč je súčasťou hash slotu. Hash slotov v Redis Clusteri môže byť 16384. Každý node v clustri je zodpovedný za sub-set hash slotov. Napr. ak máme v clustri 3 nodes, tak:

Node A: od 0 do 5500

Node B: od 5501 do 11000

Node C: od 11001 do 16383

Minimálna požiadavka na cluster sú 3 master nodes. Slave nodes obsahujú redundantné dáta navzájom a spolu s masterom. Musí byť dostupný aspoň jeden node (aj keď by to bol slave) pre každý hash slot.
 

Ako je vidieť aj na schéme, máme nasledovné možnosti ako REDIS nie len v produkčnom prostredí prevádzkovať.

Bezpečnosť
 

Predposlednou témou je bezpečnosť, ktorej si myslím, že je potrebné venovať veľkú pozornosť. Vo väčšine prípadov s ktorými som sa stretol, si vývojári dokážu naštudovať perfektne funkcionality z rôznych dostupných zdrojov, dokumentácie, tutoriálov ale práve téma bezpečnosti býva zanedbávaná. Nakoľko REDIS na projekte s veľkou pravdepodobnosťou bude obsahovať citlivé údaje, alebo také, ktoré nechcete vystavovať verejne, je potrebné ho chrániť.
 

Izolované prostredie
 

Autorizácia prístupu k REDISu nie je implementovaná na veľmi pokročilej úrovni, je možné a aj veľmi dôležité nastaviť si heslo a nenechávať prístup k REDISu bez hesla. Avšak ideálne je podporiť bezpečnosť údajov izolovaním inštancie REDISu od vonkajšieho sveta. Pokiaľ beží REDIS spustený na serveri ako klasická aplikácia, je dobré obmedziť prístup k danému portu (6379) nastavením firewallu. Prístup k REDISu by mal byť prostredníctvom serverovej aplikácie (bezpečnej). Od verzie 3.2.0 v prípade ponechania defaultnej konfigurácie odpovedá klientom z iných ako loopback rozhraní chybou.

Spôsob zabezpečenia heslom nie je veľmi tlačený tvorcami s prihliadnutím na architektúru aplikácií a pozíciou, kde sa REDIS v architektúre nachádza.
 

Prístup z frontendu
 

Z môjho pohľadu chybným návrhom je vystavanie aplikácie tak, že frontend (teda aplikácia, ktorá beží priamo na zariadení klienta / používateľa) priamo komunikuje s REDISom. Tento spôsob je porušením aj predchádzajúceho bodu s izolovaním prostredia a nie je to vhodná praktika, udržateľnejšie je postaviť medzi frontend a Redis aplikačný backend, ktorý by komunikáciu zabezpečoval.
 

Premenovanie príkazov
 

Veľmi užitočná možnosť pre poskytovateľov služby REDISu, aby nebolo možné z ľubovoľnej inštancie meniť nastavenia napr. príkazom CONFIG (FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME a DEBUG)
 

Záver
 

REDIS nám má toho veľa čo ponúknuť, je neoddeliteľnou súčasťou veľkých projektov a je dobré vedieť o jeho možnostiach. Myslím si, že by mal byť súčasťou základnej výbavy každého vývojára. Ak sa chceš dozvedieť viac o základných funkciách REDIS či aké ma miesto v architektúre aplikácií prečítaj si prvý diel.

Online záznam z DSC: