8. Jul 2021Backend & DevOps

REDIS II - about use in our projects, the redis cluster and security

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.

Dušan DragulaHead of DevOps

How do we use REDIS on our projects?

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.

visualization of REDIS in GoodRequest projects, where runs as a docker container

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.

Logos of partners that use REDIS in their application architecture

Recording from #TechbandMeetups (Slovak):

Redis Cluster

To create a distributed environment we have 2 options:

Redis Sentinel - lower speed compared to the cluster, high availability (HA), automatic failover solution
Redis Cluster - high speed, high availability

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.

‍

REDIS operation options with visualisation

Privacy

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.

Ready for a new challenge? We are expanding our DevOps team!

Isolated environment

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.

Access from the frontend

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.

Renaming commands

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)

Conclusion

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.