REDIS II – o použití v našich projektech, Redis Clusteru a bezpečnosti

Jak využíváme Redis v našich projektech?

Téměř všechny projekty, které provozujeme, ať už pro vývojové, testovací nebo produkční účely, u nás běží jako docker kontejnery. Redis také běží jako samostatný kontejner, se kterým komunikuje výhradně aplikační backend. Tento backend se stará o operace Read a Write nad Redisem, o synchronizaci dat s databází SQL a o komunikaci s frontendovou aplikací prostřednictvím load balanceru. Jako primární úložiště Redis momentálně nepoužíváme. Redis se nachází přibližně v 50 % projektů, které jsme vyvinuli a které provozujeme.
 

Použili jsme ho v projektu, jako je Fitshaker, kde plní úlohu cache odpovědí na requesty, které mohou být cacheované.

A taky v projektu Tipos Extraliga + Fantasy Liga, kde se kromě cache používá i k uchovávání žebříčku soutěžících, který se v průběhu zápasu velmi často dynamicky mění a je třeba ho udržovat aktuální a dostupný.

Online záznam z Techband Meetupu:

Redis Cluster

Pro účely vývoje nebo testování si obvykle vystačíme s jednoduchou instalací Redisu u sebe na počítači, případně ho spustíme jako docker container. U produkčního provozu a zejména u větších projektů je ale vhodné a často i nevyhnutelné se dostupností služby zabývat hlouběji, protože výpadek má u některých typů služeb přímý dopad i na finance. Dostupnost Redisu nám pomáhá řešit i distribuovaný systém v podobě Redis Clusteru.

Máme dvě možnosti, jak vytvořit distribuované prostředí:

1. Redis Sentinel – nižší rychlost oproti clusteru, vysoká dostupnost (HA), automatic failover solution
2. Redis Cluster – vysoká rychlost, vysoká dostupnost

Pro potřeby clusteru potřebujeme 2 TCP connections.

Redis Cluster využívá shardování pomocí hash slotu, kde každý klíč je součástí hash slotu. Hash slotů může být v Redis Clusteru 16 384. Každý node v clusteru je zodpovědný za subset hash slotů. Pokud máme v clusteru například 3 nody, tak:

Node A: od 0 do 5 500

Node B: od 5 501 do 11 000

Node C: od 11 001 do 16 383

Minimální požadavek na cluster jsou 3 master nodes. Slave nodes obsahují redundantní data navzájem a spolu s masterem. Pro každý hash slot musí být k dispozici alespoň jeden node (i kdyby to byl slave).

Jak je vidět na schématu, máme k dispozici následující možnosti, jak provozovat Redis nejen v produkčním prostředí.

Bezpečnost

Předposledním tématem je bezpečnost, které je podle mého názoru třeba věnovat pozornost. Ve většině případů, se kterými jsem se setkal, jsou vývojáři schopni dokonale nastudovat funkcionality z různých dostupných zdrojů, dokumentace, tutoriálů, ale téma bezpečnosti se často opomíjí. Redis bude v projektu s velkou pravděpodobností obsahovat citlivé údaje nebo údaje, které nechcete zveřejnit, proto je třeba je chránit.

Izolované prostředí

Autorizace přístupu do Redisu není implementovaná na velmi pokročilé úrovni, takže je možné a taky velmi důležité nastavit heslo a nenechávat přístup do Redisu bez hesla. Ideální je ale podpořit zabezpečení dat tím, že se instance Redisu izoluje od vnějšího světa. Pokud je Redis na serveru spuštěný jako klasická aplikace, je dobré omezit přístup k danému portu (6379) nastavením firewallu. Přístup do Redisu by měl být zajištěn prostřednictvím (bezpečné) serverové aplikace. Od verze 3.2.0 (v případě ponechání defaultní konfigurace) odpovídá klientům z jiných než loopback rozhraní chybou.

Vývojáři na způsob zabezpečení heslem příliš netlačí vzhledem k architektuře aplikací a pozici, kterou Redis v architektuře zaujímá.

Přístup z frontendu

Z mého pohledu je chybou designu, pokud je aplikace postavena tak, aby frontend (tj. aplikace, která běží přímo na klientském/uživatelském zařízení) komunikoval přímo s Redisem. Tento způsob je zároveň porušením předchozího bodu s izolováním prostředí a nejedná se o vhodný postup. Udržitelnější je postavit mezi frontend a Redis aplikační backend, který bude zajišťovat komunikaci.

Přejmenování příkazů

Pro poskytovatele služby Redis je velmi užitečnou možností, aby nebylo možné měnit nastavení z libovolné instance, např. příkazem CONFIG (FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME a DEBUG)

Závěr

Redis nám má hodně co nabídnout, je nedílnou součástí velkých projektů a je dobré znát jeho možnosti. Myslím, že by měl být součástí základní výbavy každého vývojáře. Pokud se chcete dozvědět víc o základních funkcích Redisu nebo o jeho místě v architektuře aplikací, přečtěte si první část.

Online záznam z DSC: