AWS OpsWorks: use Redis instead of Memcached

Question

Is it possible to use Redis instead of Memcached as a layer on AWS OpsWorks?

I'll start working on a project soon and I was thinking about using Redis as my only database because:

- It's really fast
- Has built-in persistence 
- Is available as a service on AWS, unlike MongoDB

During development (and probably on the final production enviroment) servers will run only during business ours to reduce expenses.

Any ideas on how to use Redis and shutdown the cache/database servers when nobody is using?

I'm quite new to DevOps and never worked with Chef receipts before. Just checked out AWS OpsWorks service for the first time today, so please be patient.

Thanks!

Answer 1

If you want to stick to OpsWorks only then there is no out-of-the box Redis there. You can however create custom recipes and make your own Redis layer.

If you do not have to stick to OpsWorks only then ElastiCache can use memcached or Redis.

Answer 2

I think for this scenario, the best way is to put your own Redis copy running on a standard EC2.

Why is that?

1. You can't use Elasticache, there's no way to stop it, so you will have to pay 24/7.
2. Using OpsWorks or Beanstalk for the cache layer is not so efficient, you will not have control of how the shards is distributed on the other instances, so it's not useful.
3. Redis is very fast and 1 instance can handle lot's of commands per second, something like 1 to 5 thousand.
4. You still can use your application on OpsWorks, just point the cache layer to your EC2 structure. Of course you can create a domain name for your QA environment, and also have a ELB in front of it, if you want to.
5. Even using only one instance you can create lot's of Redis instances inside it. This way you can emulate your production shards. Even in production I think is a good idea to have more than 1 redis instance per server, usually I configure 1 instance per core. e.g.: 4 cpus, 4 redis.

By your question I understood that we are talking about QA/Dev environment, because your concern was to disable the servers when nobody is using them. =]