Often, there comes a time when you have to choose between managed services versus self-hosted services, especially in the cloud world. Both these services have their own set of pros and cons. But, each of these services provide an added advantage, provided you know your use case well. This theory holds true for ElastiCache versus self-hosted Redis on EC2.
This post compares practical and impractical pointers around these two services, so you can choose the right service for your use case.
The Practical Comparison: ElastiCache Vs. Self-hosted Redis on EC2
Redis is one of the leading open source, in-memory, key value store. It is a good caching tool. If you are an AWS user, you can leverage this tool via an EC2 instance (by self-hosting) or ElastiCache.
The benefits of using ElastiCache is that AWS manages the servers hosting the Redis. Whereas, the benefits of using self-hosted Redis on EC2 is it provides the freedom to maneuver between configurations. There are several other such differences. Knowing these differences will equip you enough to make the right choice.
To start with, let’s walk you through the top differences between ElastiCache and self-hosted Redis on EC2.
Deep Diving into the Practicalities of ElastiCache and Self-hosted Redis on EC2
ElastiCache: Supports Fully Managed Redis and Memcached
ElastiCache seamlessly deploys, runs, and scales Redis as well as MemCached in-memory data stores. It automatically performs management tasks like software patching, setup, configuration, hardware provisioning, failure recovery, backups etc. There’s no risk of losing workloads, as it continuously monitors clusters. This makes it ideal for building data-intensive apps for media sharing, social networking, gaming, Ad-Tech, finance, healthcare, IoT, etc.
ElastiCache: Scales Automatically According to Requirements
One of the most adored features of ElastiCache is its scalability feature. It can scale-out, scale-in, and scale-up as per application demands. In addition, write and memory scaling is supported with sharding, while replicas provide read scaling.
ElastiCache: Instances with More Than One vCPU Cannot Utilize All the Cores
Redis uses a single thread of execution for reads/writes. Only one thread/process will take care of reads/writes in the database. This ensures that there are no deadlocks occurring due to multiple threads of writing/reading multiple information into a disk. This is an extremely powerful feature of Redis in terms of performance, as it removes the need to manage locks and latches. However, this one thread can use only one core, and vCPU does all the job. So, you do not have the freedom to use multiple CPUs. Consequently, ElastiCache instances with more than 1 CPU face wastage of extra vCPUs.
To provide better visibility into CPU utilization, Amazon introduced ‘EngineCPUUtilization’ metric sometime during April 2018.
Self Hosted Redis on EC2: Allows You to Update Latest Version ASAP
One of the major advantages of using self hosted Redis cluster is that the you can always stay updated with the most recent version. You can utilize the best features of the software even before the rest of the world can actually start using it.
Self Hosted Redis on EC2: Provides the Freedom to Modify Configurations
Self hosted Redis on EC2 provides the freedom to understand its underlying functionalities and modify the configurations as per your requirement. For example, to modify Redis configuration to continually take snapshots, you can:
save 900 1 save 300 10 save 60 10000
Create Snapshot if there is a minimum of 1 change within 900 seconds
Create Snapshot if there are minimum 10 changes within 300 seconds
Create Snapshot if there are minimum 10000 changes within 900 seconds
Other configurations like "stop-writes-on-bgsave-error" and "maxmemory" are very useful config changes. If you are looking for more tweaking details, check this list below:
- https://scaleyourcode.com/blog/article/25
- https://scaleyourcode.com/blog/article/15
- https://dzone.com/articles/redis-performance-benchmarks
Self Hosted Redis on EC2: Unavailability of Pertinent Metrics Makes Maintenance Tedious
Even though Redis on EC2 provides the freedom to maneuver in terms of configuration, it is difficult to maintain. Monitoring the metrics is not easy. You either need to use a third party tool, like AppDynamics, or call APIs manually to monitor the metrics from Redis. You can automate scaling/updating/upgrading/security patches etc. using tools like Ansible, Chef, or Puppet. This is cost-effective but effort intensive.
Self Hosted Redis on EC2: Instance Limitations
Amazon recommends users to only use HVM based EC2 instances. Only a handful of PV based instances are available due to latency issues.
In Conclusion:
If cost is a big concern, a self hosted Redis cluster is a better option. If cost is not a concern and seamless maintenance is a priority, Elasticache is a better option. Here’s an year’s comparison:
If you ever wondered which service to opt, you know where to reach out!
Note: Originally published at blog.totalcloud.io on October 17, 2018.
Top comments (0)