The sequel about REDIS is here! The first part, focused on the introduction of REDIS as such, or its functions and possibilities of use, this time I will expand on its real use in our projects, its placement in docker containers or caching. I will also say more about security, which is now the most popular topic in the IT world.
Almost all projects that we operate, whether for development, testing or production purposes, run as docker containers. REDIS also runs as a separate container with which only the application backend communicates. This backend takes care of both Read and Write operations over Redis, data synchronization with the SQL database and communication with the front-end application via the load balancer. We do not currently use Redis as primary storage. Redis is in about 50% of the projects we have developed and run.
We have used it on projects such as Fitshaker or Tiptravel where it acts as a cache of responses to requests that can be cached.
And also on the Tipos Extraliga + Fantasyliga project, where in addition to the cache, it also serves to keep the leaderboard, which changes dynamically during the match very often and it is necessary to keep it current and available.
To create a distributed environment we have 2 options:
For the needs of the cluster we need 2 TCP connections.
Redis Cluster uses hash slot sharding, where each key is part of a hash slot. The hash of slots in the Redis Cluster can be 16384. Each node in the cluster is responsible for a sub-set of hash slots. E.g. if we have 3 nodes in the cluster, then:
Node A: from 0 to 5500
Node B: from 5501 to 11000
Node C: from 11001 to 16383
The minimum cluster request is 3 master nodes. Slave nodes contain redundant data with each other and with the master. At least one node (even if it would be a slave) must be available for each hash slot.
As can be seen in the diagram, we have the following options as REDIS not only to run in a production environment.
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ť.
The penultimate topic is security, which I think needs to be given a lot of attention. In most of the cases I've encountered, developers can study perfect functionalities from various available sources, documentation, tutorials, but the topic of security is often neglected. As REDIS on a project is likely to contain sensitive data or ones that you do not want to exhibit publicly, it needs to be protected.
Authorization of access to REDIS is not implemented at a very advanced level, it is possible and very important to set a password and not leave access to REDIS without a password. However, it is ideal to support data security by isolating the REDIS instance from the outside world. If REDIS is running on the server as a classic application, it is a good idea to restrict access to the given port (6379) by setting the firewall. Access to REDIS should be via a server application (secure). As of version 3.2.0, if the default configuration is left, it responds to clients from other than loopback interfaces with an error.
The method of password security is not very pushed by the creators, taking into account the architecture of the applications and the position where the redis is located in the architecture.
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.
From my point of view, the wrong design is to build the application so that the frontend (ie the application that runs directly on the client / user device) communicates directly with REDIS. This method is a violation of the previous point with the isolation of the environment and it is not a suitable practice, it is more sustainable to build an application backend between the frontend and Redis, which would ensure communication.
A very useful option for Redis service providers, so that it is not possible to change settings from any instance, e.g. command CONFIG (FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME a DEBUG)
REDIS has a lot to offer us, it is an integral part of big projects and it is good to know about its possibilities. I think it should be part of the basic equipment of every developer. If you want to learn what can you do with REDIS or its place in application architecture, read the first part.