ra2 studio - Fotolia


Use Amazon ElastiCache to preserve database performance

Amazon ElastiCache enables developers to choose between Memcached or Redis for a caching engine, depending on the complexity of the data structures.

AWS developers want fast data stores, but excessive disk can slows databases as apps hit the disk to read or write...

data. In-memory databases can boost performance, but they're costly for very large databases. A cloud cache service might be the best solution.

AWS offers a wide variety of database services, and it makes a lot of sense to tie in the Amazon ElastiCache cloud cache service. ElastiCache is a managed, in-memory, key-value store that offers high performance, scalability, reliability and security. ElastiCache supports two caching engines: Memcached for a simple array of objects and Redis for more complex data structures.

Amazon ElastiCache is a distributed, scale-out cloud cache service comprised of two components:

  • Nodes of individual RAM-based caching engines of fixed-memory capacity, each with a separate DNS name, address and port.
  • Clusters of nodes that work together, splitting data across them. When using the Memcached engine, nodes are independent, but ElastiCache lets client applications auto-discover all nodes in a cache cluster and brokers connections to nodes using a configuration endpoint. Redis supports clusters and shards -- collections of up to six nodes -- with automatic replication between them. In a shard, one node is primary -- used mainly for data writes; the other replicas are read-only nodes.

Memcached is ideal for simple data models or applications that need to dynamically scale cache capacity to meet demand -- up to 100 nodes per AWS region. But developers should use Redis for everything else, particularly applications that use complex data types, such as strings, hashes, lists, sets, sorted sets and bitmaps. With support for automatic read-only replication, Redis is also a good fit for read-intensive applications.

Redis is a popular open source product, and AWS improved the Redis engine to better utilize swap memory for RAM and minimize swap use, which reduces the risk of performance issues during snapshots and synchronization. AWS Redis implementation also includes dynamic write throttling to improve output buffer management when nodes run low on memory. It also includes a feature that can ease failovers to speed up cluster recovery.

Amazon ElastiCache buffers database requests and mitigates performance issues during spikes in demand. Caching works best when database access is slow or computationally expensive, such as during complex queries or when the data is frequently accessed and relatively static with many more reads than writes.

Use cases and sizing

Some common ElastiCache uses include:

  • A front end to Amazon Relational Database Service -- for SQL databases -- or Amazon DynamoDB -- NoSQL -- databases.
  • Session caching to store state when using Elastic Load Balancing Auto Scaling groups for web front ends.
  • Receives hot data from AWS IoT or AWS Lambda before passing it onto a database or Amazon Kinesis stream for internet of things (IoT) device data.
  • Ingesting other streaming data from Kinesis or Elastic MapReduce, which could be combined with other data from an Elastic Compute Cloud (EC2) application before it stores in Amazon Redshift or a Simple Storage Service bucket.

Sizing guidelines for ElastiCache clusters depend on the caching engine. For Memcached, guidelines are relatively straightforward and start with an estimate of the total working set size. But there are several combinations of node types that a developer can use to achieve his goals, including a large number of smaller nodes and a small number of larger nodes.

Most node instance types run about 2 cents per GB, with the cache.r3.large being the cheapest at 1.7 cents per GB. If a developer needs a small working set that can be satisfied by one or two nodes, a smaller instance type preserves more cache capacity in case of a node failure.

Redis sizing can be more complicated, as developers have to estimate both the working set and the read-write mix of the data. In general, read-heavy applications work best for Redis, which uses auto-replicating shards for very large data sets and cluster mode to aggregate multiple shards.

ElastiCache best practices and recommendations

Although Amazon cloud services are highly reliable, it's best to spread data across many nodes to mitigate or avoid performance degradation in case of node failures. For example, losing a single node out of a 10-node cluster results in a 10% performance hit. Redis supports writes and more complex data operations, so many users will want to generate periodic snapshots to protect data in case of a failure. When using snapshots or synchronization, developers must ensure that the Redis instance isn't using all available memory for the cache and has enough for background operations.

In an Amazon ElastiCache deep-dive session at AWS re:Invent, Michael Labib, a solutions architect at AWS, and Brian Kaiser, the CTO at Hudl, focused on Redis, offered some advice on how to maximize ElastiCache availability that was specific to Redis:

  • Use the latest version of Redis.
  • Set reserved memory to 30% of the total available.
  • Keep swap space very low or zero, and scale the cache instead.
  • Put read replicas in different availability zones from the primary. For important workloads, use two read replicas per primary.
  • Write to the primary and read from the replicas and take snapshots from the replicas.

When configuring and using Redis with Amazon ElastiCache, developers should:

  • Avoid very short key names -- added space from longer names can simplify application development and debugging.
  • Create a logical schema using a standard format, for example [Object]:[Value].
  • Use hashes, lists and sets, where possible, to improve efficiency. Avoid small Strings values; hashes are preferable.
  • Avoid KEYS and other long-running commands.
  • The maximum key size and value size is 512 MB, and the maximum size for lists, sets and hashes is 2^32 - 1 (4 GB).

IT teams should use Amazon CloudWatch to monitor ElastiCache and other services. As with EC2 instances, CloudWatch for ElastiCache provides added metrics and flexible control over alerts. These include both host-level measures like CPU and metrics that are unique to caching software, like cache gets and misses. CloudWatch measures all metrics and publishes for each cache node in 60-second intervals.

Next Steps

Determine which caching engines ElastiCache supports

Use CloudWatch to monitor ElastiCache

What are your options for cache node deployment?

Dig Deeper on AWS database management