Redis Production Checklist
If you are going into production with Redis, it is a good idea to check over a few things before you go live.
Are you going into production with Redis? Make sure you have done everything on this checklist!
Run the Redis Benchmark
One test you can run is the Redis benchmark. The benchmark will perform a stress test on your Redis installation to ensure everything will run smoothly with your current settings. An example of running the benchmark from the command line is shown below.
In this case, the test will run 100,000 requests from 50 different clients, which are all sending 10 commands at once.
Firewall the Redis Port
The Redis port should only be directly accessible to the specific computers that are being used to implement your Redis application. As a result, the Redis port should be restricted by a firewall to prevent outside (and potentially unwanted) access to the system.
Set an Authentication Password
Enabling the Redis authorization layer allows queries from unauthorized clients to be refused. To be authorized, the client must send and AUTH command with the correct password.
This can act as a redundant layer of security in case, for instance, the firewall fails. The authentication password can be set by a system administrator inside the redis.conf file.
Backup and Logging
Backups and logs are always good to have if something should go wrong. Redis provides two options, which can be used individually or both at the same time.
RDB (Redis Database File): With RDB enabled, you will have access to point-in-time snapshots of the dataset, which allows you to easily restore the dataset if needed. However, since snapshots are taken at intervals, you may lose some data between the last snapshot and the incident.
AOF (Append Only File): With AOF enabled, Redis will log all write operations. Because the data is written instantly, you can recover even the most recent data.
It is often recommended that both of these options are enabled so that you have both available when you need to recover data after an incident.
Disable Potentially Harmful Commands
Some commands could be harmful in the wrong hands, so disabling them in production may be a good idea. Some of these could include:
- FLUSHALL: Removes all keys from all databases
- FLUSHDB: Removes all keys from the current database
- CONFIG: Allows runtime server configuration
- SHUTDOWN: Shuts down Redis
To disable a command, simply rename it to an empty string.
Published at DZone with permission of Darren Perucci. See the original article here.
Opinions expressed by DZone contributors are their own.