Amazon ElastiCache

Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud. The service improves the performance of web applications by allowing users to retrieve information from fast, managed, in-memory caches, instead of relying entirely on slower disk-based databases. Amazon ElastiCache manages the work involved in setting up an in-memory service, from provisioning the AWS resources users request to installing the software. Using Amazon ElastiCache, users can add an in-memory caching layer to the application in a matter of minutes, with a few API calls. Amazon ElastiCache integrates with other AWS services such as Amazon EC2, Amazon RDS, AWS CloudFormation, AWS Elastic Beanstalk, and AWS OpsWorks.

Amazon ElastiCache supports two open-source in-memory caching engines:

  • Redis – a fast, open source, in-memory data store and cache. Amazon ElastiCache for Redis is a Rediscompatible in-memory service that delivers the ease-of-use and power of Redis along with the availability, reliability, and performance suitable for the most demanding applications. Both singlenode and up to 15-shard clusters are available, enabling scalability to up to 3.55 TiB of in-memory data. ElastiCache for Redis is fully managed, scalable, and secure. This makes it an ideal candidate to power high-performance use cases such as web, mobile apps, gaming, ad-tech, and IoT. 
  • Memcached – a widely adopted memory object caching system. Amazon ElastiCache for Memcached is protocol compliant with Memcached, so popular tools that users use today with existing Memcached environments will work seamlessly with the service.
Amazon ElastiCache

Amazon ElastiCache Benefits

Amazon ElastiCache works as an in-memory data store and cache to support the most demanding applications requiring sub-millisecond response times. By utilizing an end-to-end optimized stack running on customer dedicated nodes, Amazon ElastiCache provides secure, blazing fast performance. Amazon ElastiCache can scale-out, scale-in, and scale-up to meet fluctuating application demands. Write and memory scaling is supported with sharding. 

Users no longer need to perform management tasks such as hardware provisioning, software patching, setup, configuration, monitoring, failure recovery, and backups. Amazon ElastiCache continuously monitors the clusters to keep the workloads up and running so that users can focus on higher value application development.

Memcached—a widely adopted in-memory key store, and historically the gold standard of web caching. Amazon ElastiCache is protocol-compliant with Memcached, so popular tools that users use today with existing Memcached environments will work seamlessly with the service. Memcached is also multithreaded, meaning it makes good use of larger Amazon EC2 instance sizes with multiple cores.

Redis—an increasingly popular open-source key-value store that supports more advanced data structures such as sorted sets, hashes, and lists. Unlike Memcached, Redis has disk persistence built in, meaning that users can use it for long-lived data. Redis also supports replication, which can be used to achieve Multi-AZ redundancy, similar to Amazon RDS.

 

Amazon ElastiCache Features

Amazon ElastiCache

Amazon ElastiCache is a web service that makes it easy to set up, manage, and scale a distributed in-memory data store or cache environment in the cloud. It provides a high-performance, scalable, and cost-effective caching solution. At the same time, it helps remove the complexity associated with deploying and managing a distributed cache environment. Built on open-source Redis and compatible with the Redis APIs, ElastiCache for Redis works with the Redis clients and uses the open Redis data format to store thr data. Self-managed Redis applications can work seamlessly with ElastiCache for Redis without any code changes. Amazon ElastiCache for Redis combines the speed, simplicity, and versatility of open-source Redis with manageability, security, and scalability from Amazon to power the most demanding real-time applications in Gaming, Ad-Tech, E-Commerce, Healthcare, Financial Services, and IoT.

  • Redis is a widely adopted in-memory data store for use as a database, cache, message broker, queue, session store, and leaderboard. Amazon ElastiCache for Redis maintains compatibility with the open source Redis data formats, Redis APIs, and works with Redis clients. Users can migrate the self-managed Redis workloads to ElastiCache for Redis without any code change.
  • Amazon ElastiCache for Redis supports both Redis cluster and non-cluster modes and provides high availability via support for automatic failover by detecting primary node failures and promoting a replica to be primary with minimal impact.
  • Amazon ElastiCache for Redis works as an in-memory data store to support the most demanding applications requiring sub-millisecond response times. In comparison to disk-based databases where most operations need a roundtrip to disk, in-memory data stores manage data in-memory which is an order of magnitude faster than disks. The result is blazing fast performance with average read or write operations taking less than a millisecond.
  • Amazon ElastiCache provides the ability to create and manage users and user groups that can be used to set up Role-Based Access Control (RBAC) for Redis commands. Users can simplify the architecture while maintaining security boundaries and also take advantage of granular access control to manage groups. 
  • Amazon ElastiCache for Redis is a fully managed service. It provides detailed monitoring metrics of the Redis usage, enabling users to track application trends and adjust cluster configuration, as needed. Amazon ElastiCache adds automatic write throttling, intelligent swap memory management, and failover enhancements to improve upon the availability and manageability of open source Redis. 
  • With Amazon ElastiCache for Redis, users can start small and easily scale the Redis data as the application grows – all the way up to a cluster with 340 TB of in-memory data. It allows users to scale the Redis Cluster environment up to 500 nodes and 500 shards. It supports online cluster resizing to scale-out and scale-in the Redis clusters without downtime and adapts to changing demand.

Ease of use: Getting started with Amazon ElastiCache for Redis is easy. Just launch a new Cache Cluster or Replication Group using the AWS Management Console or by making a single API call. Resources are pre-configured with the appropriate parameters and settings, and Cache Parameter Groups enable granular control and fine-tuning of the Redis environment. Users can launch a Redis resource and connect the application within minutes without additional configuration.

Fully Managed Redis: AWS automate time-consuming management tasks – such as software patch management, failure detection and recovery – allowing users to pursue higher value application development. Users still get native access to the underlying Redis in-memory database environment, making it easy to use Amazon ElastiCache for Redis with the existing Redis tools and applications.

Monitoring and Metrics: Amazon CloudWatch metrics provide insights to the Redis resources at no additional charge. Users can use the AWS Management Console to view over 20 key operational metrics for your Redis instances, including compute, utilized memory, cache hit ratio, active connections, Redis replication and Redis commands.

Event Notifications: Get notified via email or SMS of important events such as snapshot completion and scheduled node replacements. Users can use the AWS Management Console or APIs to subscribe to different events associated with the Redis resources.

Tagging: Benefit from the ability to tag the Cache Clusters and Redis snapshots for tracking and billing purposes. Users can use the Cost Explorer to attribute costs to resources and Resource Groups to easily create and maintain collections of resources that share a common set of tags.

Multi-AZ: Maximize availability by leveraging Multi-AZ with automatic failover functionality. Users can take advantage of multiple AWS Availability Zones to gain availability, and scale beyond the read capacity constraints of a single node. In case of primary node loss, we will automatically detect the failure and failover to a read replica to provide higher availability without the need for manual intervention.

Instance Monitoring and Repair: The service continuously monitors the health of the instances. In case a node experiences failure or a prolonged degradation in performance, AWS will automatically restart the node and associated processes.

Backup, Restore, and Export: AWS help users protect the data by creating snapshots of the clusters. Users can set up automatic snapshots or initiate manual backups, via a few clicks on the console or through simple API calls. Using these snapshots, or any Redis RDB-compatible snapshot stored on S3, users can then seed new Amazon ElastiCache for Redis clusters. Users can also export the snapshots to an S3 bucket of their choice for disaster recovery, analysis or cross-region backup and restore.

Cross-region Disaster Recovery: Global Datastore in Amazon ElastiCache for Redis provides fully managed, fast, reliable and secure cross-region replication. With Global Datastore, users can write to the Amazon ElastiCache for Redis cluster in one region and have the data available to be read from two other cross-region replica clusters, thereby enabling disaster recovery across regions. In the unlikely event of regional degradation, one of the healthy cross-region replica clusters can be promoted to become the primary cluster with full read/write capabilities. Once initiated, the promotion typically completes in less than a minute, allowing the applications to remain available.

Scaling the Workload: Using our APIs or with a few clicks in the AWS Management Console, users can easily scale up or scale out the existing Redis configuration. For non-cluster mode, users can scale up to a larger node type, and go up to a maximum of 635.61 GiB. Scale up for Redis is designed to make a best effort to retain the existing data and requires Redis replication to succeed.

  • Amazon ElastiCache for Redis cluster provides the ability to add and remove shards from a running cluster. Supporting up to 250 nodes and shards, users can scale up to 155.17 TiB (170.6 TB) of in-memory data with 48.6 million reads and 9.7 million writes per second.

Easy Engine Upgrades: Users can use the Amazon ElastiCache API or the AWS Management Console to easily upgrade the Redis clusters to the latest available engine version. The online engine upgrade process is designed to make a best effort attempt to retain the existing data and requires Redis replication to succeed.

Maximize Read Performance with Read Replicas: Users can add up to five Redis read replicas per primary node and serve high-volume application read traffic from multiple instances, thereby increasing aggregate read throughput.

Write locally, read globally: With Global Datastore, users can write to the Amazon ElastiCache for Redis cluster in one region and have the data available to be read from two other cross-region replica clusters to enable low-latency local reads. With a typical cross region replication latency of under 1 second, the applications enjoy quick data access across regions.

High availability and Disaster Recovery: Amazon ElastiCache for Redis provides high availability through support for automatic failover by detecting the primary node failure and promoting the replica to be the primary with minimal impact.

  • Amazon ElastiCache provides cross region replication with Global Datastore. With Global Datastore, users can write to the Amazon ElastiCache for Redis cluster in one region and have the data available to be read from two other cross-region replica clusters.

Easily Scalable: With Amazon ElastiCache for Redis, users can start small and easily scale the Redis data as the application grows – all the way up to a cluster with 170.6 TB of in-memory data. It allows users to scale your Redis Cluster environment up to 250 nodes and 250 shards. 

  • Amazon ElastiCache provides cross region replication with Global Datastore. With Global Datastore, you can write to the Amazon ElastiCache for Redis cluster in one region and have the data available to be read from two other cross-region replica clusters, thereby enabling low-latency reads across regions. 

Network Isolation: Amazon ElastiCache for Redis allows users to run the resources in Amazon Virtual Private Cloud (Amazon VPC). Amazon VPC enables users to isolate the Redis resources by specifying the IP ranges to use for the nodes, and to connect to other applications inside the same Amazon VPC. In addition, the service allows users to configure firewall settings that control network access to the resources.

Encryption: Amazon ElastiCache for Redis  supports encryption in-transit and at-rest for secure internode communications to help keep personally identifiable information (PII) safe. The encryption in-transit feature enables users to encrypt all communications between clients and Redis server as well as between the Redis servers (primary and read replica nodes).

  • The encryption at-rest feature allows users to encrypt the disk usage and backups in Amazon S3. Additionally, Amazon ElastiCache for Redis provides AWS KMS integration that allows customers to use own customer managed CMK’s for encryption.
  • Users can use the Redis AUTH command for an added level of authentication. You do not have to manage the lifecycle of the certificates, as Amazon ElastiCache for Redis automatically manages the issuance, renewal, and expiration of certificates.

API-level Permissions: Using the AWS Identity and Access Management (IAM) features integrated with Amazon ElastiCache, users can control the actions that AWS IAM users and groups can take on Amazon ElastiCache resources. For example, users can configure the IAM rules to ensure that certain users only have read-only access, while an Administrator can create, modify and delete resources. For more information about API-level Permissions, refer to Using AWS IAM Policies for Amazon ElastiCache.

Compliance : Amazon ElastiCache for Redis supports compliance programs such as SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI, HIPAA, and FedRAMP. See AWS Services in Scope by Compliance Program for current list of supported compliance programs.

Pay Only for What You Use: Users only pay for the resources they actually consume. On-demand pricing allows users to pay for memory and compute capacity by the hour with no long-term commitments, making Amazon ElastiCache for Redis very cost effective to use. 

Save on Valuable Time and Expertise: Amazon ElastiCache for Redis is engineered for cloud scale, saving the time and expertise needed for setting up and managing a robust, highly available and reliable Redis environment.

Amazon Redshift performance 

Whether serving the latest news, a top-10 leaderboard, a product catalog, or selling tickets to an event, speed is the name of the game. The success of a website and business is greatly affected by the speed at which deliver content. The following are common use case of Redis ElastiCache: 

In-Memory Data Store

The primary purpose of an in-memory key-value store is to provide ultrafast (submillisecond latency) and inexpensive access to copies of data. Most data stores have areas of data that are frequently accessed but seldom updated. Additionally, querying a database is always slower and more expensive than locating a key in a key-value pair cache. Some database queries are especially expensive to perform. An example is queries that involve joins across multiple tables or queries with intensive calculations. By caching such query results, users pay the price of the query only once. Then customers can quickly retrieve the data multiple times without having to re-execute the query.

When deciding what data to cache, consider these factors:

  • Speed and expense – It’s always slower and more expensive to get data from a database than from a cache. Some database queries are inherently slower and more expensive than others. For example, queries that perform joins on multiple tables are much slower and more expensive than simple, single table queries. If the interesting data requires a slow and expensive query to get, it’s a candidate for caching. If getting the data requires a relatively quick and simple query, it might still be a candidate for caching, depending on other factors.
  • Data and access pattern – Determining what to cache also involves understanding the data itself and its access patterns. For example, it doesn’t make sense to cache data that changes quickly or is seldom accessed. For caching to provide a real benefit, the data should be relatively static and frequently accessed. An example is a personal profile on a social media site. On the other hand, you don’t want to cache data if caching it provides no speed or cost advantage. For example, it doesn’t make sense to cache webpages that return search results because the queries and results are usually unique.
  • Staleness – By definition, cached data is stale data. Even if in certain circumstances it isn’t stale, it should always be considered and treated as stale. To tell whether the data is a candidate for caching, determine the application’s tolerance for stale data.
Gaming Leaderboards (Redis Sorted Sets)

Redis sorted sets move the computational complexity of leaderboards from the application to the Redis cluster. Leaderboards, such as the top 10 scores for a game, are computationally complex. This is especially true when there is a large number of concurrent players and continually changing scores.

  • Redis sorted sets guarantee both uniqueness and element ordering. Using Redis sorted sets, each time a new element is added to the sorted set it’s reranked in real time. It’s then added to the set in its correct numeric order.
Messaging (Redis Pub/Sub)

When sending an email message, users send it to one or more specified recipients. In the pub/sub paradigm, users send a message to a specific channel not knowing who, if anyone, receives it. The people who get the message are those who are subscribed to the channel. For example, suppose that you subscribe to the news.sports.golf channel.

  • All others subscribed to the news.sports.golf channel get any messages published to news.sports.golf.
  • Redis pub/sub functionality has no relation to any key space. Therefore, it doesn’t interfere on any level.
Recommendation Data (Redis Hashes)

Using INCR or DECR in Redis makes compiling recommendations simple. Each time a user “likes” a product, users increment an item:productID:like counter. Each time a user “dislikes” a product, users increment an item:productID:dislike counter. Using Redis hashes, users can also maintain a list of everyone who has liked or disliked a product.

ElastiCache for Redis real-time analytics store
ElastiCache for Redis real-time analytics store

Redis Components

#01

ElastiCache Nodes

 
 

node is the smallest building block of an Amazon  ElastiCache deployment. A node is a fixed-size chunk of secure, network-attached RAM. Each node runs an instance of the engine and version that was chosen when creating the cluster. A node can exist in isolation from or in some relationship to other nodes. Each node runs the engine that was chosen when the cluster or replication group was created or last modified. Each node has its own Domain Name Service (DNS) name and port. Multiple types of Amazon ElastiCache nodes are supported, each with varying amounts of associated memory and computational power.

Every node within a cluster is the same instance type and runs the same cache engine. Each cache node has its own Domain Name Service (DNS) name and port. Multiple types of cache nodes are supported, each with varying amounts of associated memory. For a list of supported node instance types, see Supported Node Types.

Users can purchase nodes on a pay-as-you-go basis, where customers only pay for the use of a node. Or purchase reserved nodes at a much-reduced hourly rate. If the usage rate is high, purchasing reserved nodes can save money. Suppose that the cluster is almost always in use, and users occasionally add nodes to handle use spikes. In this case, they can purchase a number of reserved nodes to run most of the time. Users can then purchase pay-as-you-go nodes for the times the occasionally need to add nodes. 

A shard (in the API and CLI, a node group) is a hierarchical arrangement of nodes, each wrapped in a cluster. Shards support replication. Within a shard, one node functions as the read/write primary node. All the other nodes in a shard function as read-only replicas of the primary node. Redis version 3.2 and later support multiple shards within a cluster (in the API and CLI, a replication group). This support enables partitioning the data in a Redis (cluster mode enabled) cluster.

When creating a Redis cluster, users specify whether to create a cluster with clustering enabled. Redis (cluster mode disabled) clusters never have more than one shard, which can be scaled horizontally by adding (up to a total of five) or deleting read replica nodes. Redis (cluster mode disabled) clusters can also scale vertically by changing node types.

ElastiCache clusters for Redis only contain a single primary node. After creating the primary node, users can configure one or more replica nodes and attach them to the primary Redis node. An ElastiCache for Redis replication group consists of a primary and up to five read replicas. Redis asynchronously replicates the data from the primary to the read replicas.

Amazon ElastiCache for Redis has the concept of a primary endpoint, which is a DNS name that always points to the current Redis primary node. If a failover event occurs, the DNS entry will be updated to point to the new Redis primary node. To take advantage of this functionality, make sure to configure your Redis client so that it uses the primary endpoint DNS name to access the Redis cluster.

Using read replicas with Redis, users can separate your read and write workloads. This separation lets users scale reads by adding additional replicas as your application grows. In this pattern, users configure the application to send writes to the primary endpoint. Then read from one of the replicas, as shown in the following diagram. With this approach, users can scale the read and write loads independently, so the primary node only has to deal with writes.

Amazon ElastiCache for Redis Typical Redis clusters
Amazon ElastiCache for Redis Typical Redis clusters

cluster is a collection of one or more cache nodes, all of which run an instance of the Redis cache engine software. When creating a cluster, users specify the engine and version for all of the nodes to use. The following diagram illustrates a typical Redis cluster. Redis clusters can contain a single node or up to six nodes inside a shard (API/CLI: node group), A single-node Redis (cluster mode disabled) cluster has no shard, and a multi-node Redis (cluster mode disabled) cluster has a single shard. Redis (cluster mode enabled) clusters can have up to 250 shards, with the data partitioned across the shards.

  • The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version is 5.0.6 or higher. For example, users can choose to configure a 500 node cluster that ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas).
  • Make sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters. 

Most Amazon ElastiCache operations are performed at the cluster level. Users can set up a cluster with a specific number of nodes and a parameter group that controls the properties for each node. All nodes within a cluster are designed to be of the same node type and have the same parameter and security group settings. Every cluster must have a cluster identifier. The cluster identifier is a customer-supplied name for the cluster. This identifier specifies a particular cluster when interacting with the Amazon ElastiCache API and AWS CLI commands. The cluster identifier must be unique for that customer in an AWS Region.

  • Amazon ElastiCache clusters are designed to be accessed using an Amazon EC2 instance. When launching the cluster in a virtual private cloud (VPC) based on the Amazon VPC service, users can access it from outside AWS. 
  • The basic building block of Amazon ElastiCache is the node. Nodes are configured singularly or in groupings to form clusters. When determining the node type to use for the cluster, take the cluster’s node configuration and the amount of data have to store into consideration.
Redis Cluster Configuration

ElastiCache for Redis clusters are comprised of from 0 to 250 shards (also called node groups). The data in a Redis cluster is partitioned across the shards in the cluster. Users application connects with a Redis cluster using a network address called an Endpoint. The nodes in a Redis shard fulfill one of two roles: one read/write primary and all other nodes read-only secondary’s (also called read replicas). In addition to the node endpoints, the Redis cluster itself has an endpoint called the configuration endpoint. Users application can use this endpoint to read from or write to the cluster, leaving the determination of which node to read from or write to up to Amazon ElastiCache for Redis.

  • All clusters can be scaled up by creating a new cluster with the new, larger node type. When scaling up a Redis cluster, users can seed it from a backup and avoid having the new cluster start out empty. 
  • In addition to adding or removing nodes from a cluster, there can be times where needed to make other changes to an existing cluster, such as, adding a security group, changing the maintenance window or a parameter group.

#02

ElastiCache Clusters

 
 

 

#03

Replication Groups

 
 

Single-node Amazon ElastiCache Redis clusters are in-memory entities with limited data protection services (AOF). If the cluster fails for any reason, users lose all the cluster’s data. However, if running the Redis engine, users can group 2 to 6 nodes into a cluster with replicas where 1 to 5 read-only nodes contain replicate data of the group’s single read/write primary node. In this scenario, if one node fails for any reason, users do not lose all the data since it is replicated in one or more other nodes. Due to replication latency, some data may be lost if it is the primary read/write node that fails.

  • The replication structure is contained within a shard (called node group in the API/CLI) which is contained within a Redis cluster. Redis (cluster mode disabled) clusters always have one shard. Redis (cluster mode enabled) clusters can have up to 250 shards with the cluster’s data partitioned across the shards.
  • Users can create a cluster with higher number of shards and lower number of replicas totaling up to 90 nodes per cluster. This cluster configuration can range from 90 shards and 0 replicas to 15 shards and 5 replicas, which is the maximum number of replicas allowed.

The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version is 5.0.6 or higher. For example, users can choose to configure a 500 node cluster that ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters. Redis implements replication in two ways:

  • With a single shard that contains all of the cluster’s data in each node—Redis (cluster mode disabled)
  • With data partitioned across up to 250 shards—Redis (cluster mode enabled)
Redis (Cluster Mode Disabled)

A Redis (cluster mode disabled) cluster has a single shard, inside of which is a collection of Redis nodes; one primary read/write node and up to five secondary, read-only replica nodes. Each read replica maintains a copy of the data from the cluster’s primary node. Asynchronous replication mechanisms are used to keep the read replicas synchronized with the primary. Applications can read from any node in the cluster. Applications can write only to the primary node. Read replicas improve read throughput and guard against data loss in cases of a node failure.

Users can use Redis (cluster mode disabled) clusters with replica nodes to scale the Redis solution for Amazon ElastiCache to handle applications that are read-intensive or to support large numbers of clients that simultaneously read from the same cluster. All of the nodes in a Redis (cluster mode disabled) cluster must reside in the same region. To improve fault tolerance, users can provision read replicas in multiple Availability Zones within that region.

  • When adding a read replica to a cluster, all of the data from the primary is copied to the new node. From that point on, whenever data is written to the primary, the changes are asynchronously propagated to all the read replicas.
  • To improve fault tolerance and reduce write downtime, enable Multi-AZ with Automatic Failover for the Redis (cluster mode disabled) cluster with replicas. 

Users can change the roles of the nodes within the Redis (cluster mode disabled) cluster, with the primary and one of the replicas exchanging roles. Users might decide to do this for performance tuning reasons. For example, with a web application that has heavy write activity, users can choose the node that has the lowest network latency. 

  • Redis (cluster mode disabled) clusters with replicas have three types of endpoints; the primary endpoint, the reader endpoint and the node endpoints. The primary endpoint is a DNS name that always resolves to the primary node in the cluster. The primary endpoint is immune to changes to the cluster, such as promoting a read replica to the primary role. For write activity, we recommend that the applications connect to the primary endpoint instead of connecting directly to the primary.
  • A reader endpoint will evenly split incoming connections to the endpoint between all read replicas in an Amazon ElastiCache for Redis cluster. Additional factors such as when the application creates the connections or how the application (re)-uses the connections will determine the traffic distribution. Reader endpoints keep up with cluster changes in real-time as replicas are added or removed. Users can place the Amazon ElastiCache for Redis cluster’s multiple read replicas in different AWS Availability Zones (AZ) to ensure high availability of reader endpoints.

For read activity, applications can also connect to any node in the cluster. Unlike the primary endpoint, node endpoints resolve to specific endpoints. When make a change in the cluster, such as adding or deleting a replica, users must update the node endpoints in the application.

Redis (cluster mode enabled)

A Redis (cluster mode enabled) cluster is comprised of from 1 to 250 shards (API/CLI: node groups). Each shard has a primary node and up to five read-only replica nodes. The configuration can range from 90 shards and 0 replicas to 15 shards and 5 replicas, which is the maximum number or replicas allowed. 

  • The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version is 5.0.6 or higher. For example, users can choose to configure a 500 node cluster that ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas).
  • Make sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters. 

Each read replica in a shard maintains a copy of the data from the shard’s primary. Asynchronous replication mechanisms are used to keep the read replicas synchronized with the primary. Applications can read from any node in the cluster. Applications can write only to the primary nodes. Read replicas enhance read scalability and guard against data loss. Data is partitioned across the shards in a Redis (cluster mode enabled) cluster. Applications use the Redis (cluster mode enabled) cluster’s configuration endpoint to connect with the nodes in the cluster. 

  • Redis (cluster mode enabled) clusters with replicas, because they have multiple shards (API/CLI: node groups), which mean they also have multiple primary nodes, have a different endpoint structure than Redis (cluster mode disabled) clusters.
  • Redis (cluster mode enabled) has a configuration endpoint which “knows” all the primary and node endpoints in the cluster.
  • Users application connects to the configuration endpoint. Whenever the application writes to or reads from the cluster’s configuration endpoint, Redis, behind the scenes, determines which shard the key belongs to and which endpoint in that shard to use. 
Which endpoints to use
  • Redis standalone node, use the node’s endpoint for both read and write operations. 
  • Redis (cluster mode disabled) clusters, use the Primary Endpoint for all write operations. Use the Reader Endpoint to evenly split incoming connections to the endpoint between all read replicas. Use the individual Node Endpoints for read operations (In the API/CLI these are referred to as Read Endpoints). 
  • Redis (cluster mode enabled) clusters, use the cluster’s Configuration Endpoint for all operations. Users must use a client that supports Redis Cluster (Redis 3.2). Users can still read from individual node endpoints (In the API/CLI these are referred to as Read Endpoints).

A shard (API/CLI: node group) is a collection of one to six Redis nodes. A Redis (cluster mode disabled) cluster will never have more than one shard. Redis (cluster mode enabled) clusters can have from 1 to 250 shards. Users can create a cluster with higher number of shards and lower number of replicas totaling up to 90 nodes per cluster. This cluster configuration can range from 90 shards and 0 replicas to 15 shards and 5 replicas, which is the maximum number of replicas allowed. The cluster’s data is partitioned across the cluster’s shards. If there is more than one node in a shard, the shard implements replication with one node being the read/write primary node and the other nodes read-only replica nodes.

The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version is 5.0.6 or higher. For example, users can choose to configure a 500 node cluster that ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters. 

Global Datastores

Global datastores are supported in the following AWS Regions: Asia Pacific (Seoul) Region, Asia Pacific (Tokyo) Region, Asia Pacific (Singapore) Region, Asia Pacific (Sydney) Region, Asia Pacific (Mumbai) Region, Europe (Frankfurt) Region, EU (Paris) Region, Europe (London) Region, Europe (Ireland) Region, US East (N. Virginia) Region, US East (Ohio) Region, US West (N. California) Region, US West (Oregon) Region, South America (São Paulo) Region, AWS GovCloud (US-West), AWS GovCloud (US-East), Canada (Central) Region, China (Beijing) Region and China (Ningxia) Region.

  • To use global datastores, use Redis engine version 5.0.6 or higher and R5 or M5 node types or higher.
  • All clusters—primary and secondary—in the global datastore should have the same number of primary nodes, node type, engine version, and number of shards (in case of cluster-mode enabled). Each cluster in the global datastore can have a different number of read replicas to accommodate the read traffic local to that cluster. Replication must be enabled if users plan to use an existing single-node cluster.
  • Users can set up replication for a primary cluster from one AWS Region to a secondary cluster in up to two other AWS Regions.
  • Users can work with global datastores only in VPC clusters.  Global datastores aren’t supported when using EC2-Classic
  • Amazon ElastiCache doesn’t support autofailover from one AWS Region to another. When needed, users can promote a secondary cluster manually
  • To bootstrap from existing data, use an existing cluster as primary to create a global datastore. We don’t support adding an existing cluster as secondary. The process of adding the cluster as secondary wipes data, which may result in data loss.
  • Parameter updates are applied to all clusters when users modify a local parameter group of a cluster belonging to a global datastore.
  • Users can scale regional clusters both vertically (scaling up and down) and horizontally (scaling in and out). Users can scale the clusters by modifying the global datastore. All the regional clusters in the global datastore are then scaled without interruption.
  • Global datastores support encryption at restencryption in transit, and Redis AUTH.
  • Global datastores support AWS KMS customer master keys
  • Security for cross-Region communication is provided through VPC peering

#04

Working with Shards

 
 

 

Redis Tools & Terminology

When users have granted the Amazon EC2 instance access to the ElastiCache cluster, theyt have four means by which you can manage the Amazon ElastiCache cluster: the AWS Management Console, the AWS CLI for Amazon ElastiCache, the AWS SDK for Amazon ElastiCache, and the ElastiCache API.

Using the AWS Management Console

The AWS Management Console is the easiest way to manage Amazon ElastiCache. The console lets users create cache clusters, add and remove cache nodes, and perform other administrative tasks without having to write any code. The console also provides cache node performance graphs from CloudWatch. These show cache engine activity, memory and CPU utilization, and other metrics. 

Using the AWS CLI

Users can also use the AWS Command Line Interface (AWS CLI) for Amazon ElastiCache. The AWS CLI makes it easy to perform one-at-a-time operations, such as starting or stopping the cache cluster. Users can also invoke AWS CLI for ElastiCache commands from a scripting language of their choice, letting the automate repeating tasks. 

Using the AWS SDK

To access Amazon ElastiCache from an application, users can use one of the AWS software development kits (SDKs). The SDKs wrap the ElastiCache API calls, and insulate the application from the low-level details of the Amazon ElastiCache API. Users provide the credentials, and the SDK libraries take care of authentication and request signing. 

Using the Amazon ElastiCache API

Users can also write application code directly against the Amazon ElastiCache web service API. When using the API, users must write the necessary code to construct and authenticate the HTTP requests. Users also write code to parse results from Amazon ElastiCache and handle any errors. 

The following list identifies terms that might differ between the API and CLI and the console.

Cache cluster or node vs. node

There is a one-to-one relationship between a node and a cache cluster when there are no replica nodes. Thus, the ElastiCache console often used the terms interchangeably. The console now uses the term node throughout. The one exception is the Create Cluster button, which launches the process to create a cluster with or without replica nodes.

  • The ElastiCache API and AWS CLI continue to use the terms as they have in the past.
Cluster vs. replication group

The console now uses the term cluster for all ElastiCache for Redis clusters. The console uses the term cluster in all these circumstances:

  • When the cluster is a single node Redis cluster.
  • When the cluster is a Redis (cluster mode disabled) cluster that supports replication within a single shard (in the API and CLI, called a node group).
  • When the cluster is a Redis (cluster mode enabled) cluster that supports replication within 1–250 shards or up to 500 with a limit increase request. To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per instance type.
 
ElastiCache for Redis clusters from the console's perspective
ElastiCache for Redis clusters from the console’s perspective
Amazon ElastiCache 1

Choosing the engine

 

 

Although both Memcached and Redis appear similar on the surface, in that they are both in-memory key stores, they are quite different in practice. Because of the replication and persistence features of Redis, Amazon ElastiCache manages Redis more as a relational database. Redis ElastiCache clusters are managed as stateful entities that include failover, similar to how Amazon RDS manages database failover. Conversely, because Memcached is designed as a pure caching solution with no persistence, Amazon ElastiCache manages Memcached nodes as a pool that can grow and shrink, similar to an Amazon EC2 Auto Scaling group. Individual nodes are expendable, and Amazon ElastiCache provides additional capabilities here such as automatic node replacement and Auto Discovery. When deciding between Memcached and Redis, here are a few questions to consider:

  • Is object caching the primary goal, for example to offload the database? If so, use Memcached.
  • If interested in as simple a caching model as possible? If so, use Memcached.
  • Are the planning on running large cache nodes, and require multithreaded performance with utilization of multiple cores? If so, use Memcached.
  • The ability to scale your cache horizontally as the business grow? If so, use Memcached.
  • Does the app need to atomically increment or decrement counters? If so, use either Redis or Memcached.
  • Whether more advanced data types, such as lists, hashes, bit arrays, HyperLogLogs, and sets? If so, use Redis. 
  • Does sorting and ranking datasets in memory help, such as with leaderboards? If so, use Redis.
  • Are publish and subscribe (pub/sub) capabilities of use to the application? If so, use Redis.
  • Is persistence of the key store important? If so, use Redis.
  • Whether to run in multiple AWS Availability Zones (Multi-AZ) with failover? If so, use Redis.
  • Is geospatial support important to the applications? If so, use Redis.
  • Is encryption and compliance to standards, such as PCI DSS, HIPAA, and FedRAMP, required for the business? If so, use Redis.

Redis Vs Memcached 

Amazon ElastiCache

Redis and Memcached are popular, open-source, in-memory data stores. Although they are both easy to use and offer high performance, there are important differences to consider when choosing an engine. Memcached is designed for simplicity while Redis offers a rich set of features that make it effective for a wide range of use cases. Understand the requirements and what each engine offers to decide which solution better meets the needs

  • Sub-millisecond latency: Both Redis and Memcached support sub-millisecond response times. By storing data in-memory they can read data more quickly than disk based databases.
  • Developer ease of use: Both Redis and Memcached are syntactically easy to use and require a minimal amount of code to integrate into your application.
  • Data partitioning: Both Redis and Memcached allow you to distribute the data among multiple nodes. This allows you to scale out to better handle more data when demand grows.
  • Support for a broad set of programming languages: Both Redis and Memcached have many open-source clients available for developers. Supported languages include Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, Go and many others.
  • Advanced data structures: In addition to strings, Redis supports lists, sets, sorted sets, hashes, bit arrays, and hyperloglogs. Applications can use these more advanced data structures to support a variety of use cases. For example, users can use Redis Sorted Sets to easily implement a game leaderboard that keeps a list of players sorted by their rank.
  • Multithreaded architecture: Since Memcached is multithreaded, it can make use of multiple processing cores. This means that users can handle more operations by scaling up compute capacity.
  • Snapshots: With Redis users can keep the data on disk with a point in time snapshot which can be used for archiving or recovery.
  • Replication: Redis lets users create multiple replicas of a Redis primary. This allows users to scale database reads and to have highly available clusters.
  • Transactions: Redis supports transactions which let users execute a group of commands as an isolated and atomic operation.
  • Pub/Sub: Redis supports Pub/Sub messaging with pattern matching which users can use for high performance chat rooms, real-time comment streams, social media feeds, and server intercommunication.
  • Lua scripting: Redis allows users to execute transactional Lua scripts. Scripts can help boost performance and simplify the application.
  • Geospatial support: Redis has purpose-built commands for working with real-time geospatial data at scale. Users can perform operations like finding the distance between two elements (for example people or places) and finding all elements within a given distance of a point.

Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud. The service improves the performance of web applications by allowing users to retrieve information from fast, managed, in-memory caches, instead of relying entirely on slower disk-based databases. Amazon ElastiCache manages the work involved in setting up an in-memory service, from provisioning the AWS resources users request to installing the software. Using Amazon ElastiCache, users can add an in-memory caching layer to the application in a matter of minutes, with a few API calls. Amazon ElastiCache integrates with other AWS services such as Amazon EC2, Amazon RDS, AWS CloudFormation, AWS Elastic Beanstalk, and AWS OpsWorks.