Redis plan per instance

In this issue, I would like to keep a summary of the different instances and the latest thoughts on the strategy that we will implement for each. The understanding is that this is current thinking and not final.

Conclusion

We opted for a sync conversation to be sure that we weren't mixing operability and scaling concerns incorrectly.

The recording of the call is available here: https://youtu.be/cWkgGe2mGyY and the agenda notes are here: https://docs.google.com/document/d/1lZ7RKtv7yCkV7MVx-7UfZZMvEB9lzLrrFDUw0oVFxXA/edit#heading=h.lsbqser997qr

In summary, we decided that the plan is to:

Take this action	Because
1. Migrate the Redis instances for rate-limiting and tracechunks to Kubernetes	We are still learning about how to operate Redis on Kubernetes. Everything we learn here is a base for advancing to Redis Cluster. We will use these instances as a way to gain confidence about working with Redis in Kubernetes.
2. Handle redis-cache	It is less risky to learn on this instance than on redis-persistent. The plan is to move into Kubernetes and into Redis Cluster in one go. As we learn more (from the line above) we will refine if this is still a reasonable idea.
3. Handle redis-sessions	This is currently not a production instance. By having it further down the list we give it time to land on Production and gather data about how it runs, and about how it changes the behaviour of redis-persistent (from which it will be extracted).
4. Handle redis-persistent	We want to know where the pit-falls are through the work above before addressing this instance.
x. Deal with redis-sidekiq separately	We decided to keep this separate because there are so many unknowns. We will continue to monitor this instance and be prepared to adjust our plans above if we need to switch to working on this instance first. The only aspect we will investigate at this time is the idea of instance-per-queue