REDIS II - o využití v našich projektoch, REDIS clustri a bezpečnosti
Technology
3
 min read
July 27, 2021

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

Dušan Dragula
Dušan Dragula
DevOps

Pokračovanie o REDISe je tu! Prvý diel, zameraný na predstavenie REDISu ako takého, či jeho funkcií a možností využitia tentokrát rozšírim o jeho reálne využitie v našich projektoch, jeho umiestnení v docker containeroch či o cachovaní a taktiež poviem viac k bezpečnosti, ktorá je snaď najpopulárnejšou témou vo svete IT.

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.

Využitie REDIS v projektoch GoodRequest


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ý.

Logá partnerov, ktorý využívajú REDIS v acrchitektúre aplikácií

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ť.


Možnosti prevádzkovanie REDIS


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:

Like what you see?
Join our newsletter.

Great! Welcome to newsletter.
Oops! Something went wrong while submitting your email.
High quality content once a month. No spam, we promise.
Your personal data is processed in accordance with our Memorandum on Personal Data Protection.

Páči sa vám náš content?
Odoberajte newsletter.

Great! Welcome to newsletter.
Oops! Something went wrong while submitting your email.
Vaše osobné údaje sú spracované v súlade s našim Memorandom na ochranu osobných údajov.