Category: Amazon ElastiCache
Most of us equate in-memory caching with improved performance and lower cost at scale when designing applications or building solutions. Now if there was only a service that would continually make it simpler to deploy and utilize in-memory cache in the cloud while increasing the ability to scale.
Okay no more joking around, the cloud service that provides this great functionality is, of course, Amazon ElastiCache. Amazon ElastiCache is an AWS managed service that provides a performant in-memory data store or cache in the cloud while offering a straightforward way to create, scale, and manage a distributed environment for low-latency, secure, access of I/O intensive or compute heavy data. Additionally, ElastiCache reduces the overhead of managing infrastructure for your in-memory data structure server or cache by detecting and replacing failed nodes while providing enhanced visibility into key performance metrics of the caching system nodes via Amazon CloudWatch. This exciting service is now launching support for Enhanced Redis Backup and Restore with Cluster Resizing.
For those of you familiar with Amazon ElastiCache, you are likely aware that ElastiCache currently supports two in-memory key-value engines:
- Memcached: an open source, high-performing, distributed memory object caching system developed in 2003 with the initial goal of speeding up dynamic web applications by alleviating database load
- Redis: an open source in-memory data structure store launched in 2009 developed as a broker for caching, messaging, and databases with built-in replication, atomic operation support, various levels of on-disk persistence, and high availability via Redis Cluster.
In October of 2016, support was added for Redis Cluster with Redis 3.2.4. This allowed ElastiCache Redis users to, not only take advantage of Redis clusters, but also gave users the ability to:
- Create cluster-level backups.
- Produce snapshots of each of the cluster’s shards contained within backups.
- Scale their workloads with 3.5TiB of data across up to 15 shards.
You can read more about using Redis with ElastiCache and the related features by reviewing the product page for Amazon ElastiCache for Redis.
With the launch of the Enhanced Backup and Restore with Cluster Resizing feature, ElastiCache is providing even deeper support for Redis with a clear-cut migration path to a managed Redis Cluster experience. There are several benefits of this enhancement for ElastiCache and Redis users alike, such as:
- Ability to restore backup into a Redis Cluster with a different number of shards and slot distribution
- Deliver the capability for users to resize Redis workloads
- Allow Redis database file (RDB) snapshots as input for creating a sharded Redis Cluster
- Offer option to use snapshot(s) of Redis on EC2 implementations (both Redis Cluster and single-shard Redis) as data input for sharded Redis Cluster creation
To accomplish these tasks, ElastiCache will parse the Redis key space across the backup’s individual snapshots, and redistribute the keys in the new Cluster according to the requested number of shards and hash slots. You would simply take your RDB snapshots and store them on S3, then provide ElastiCache with the desired number of shards and the snapshot file. ElastiCache handles the heavy lifting of restoring the Redis data store into a Redis cluster.
I am sure that you all may be thinking; Is it really that easy to leverage the Enhanced Redis Backup and Restore with Cluster Resizing feature in ElastiCache? Well, there is no time like the present to find out. Let’s take a trip to the AWS Management Console, and put this newly launched enhancement in action by restoring an external RDB snapshot to a new cluster using ElastiCache.
My first stop in the AWS Management console is to the Amazon S3 console. I have some Redis .rdb snapshot files I received from some of my peers here at AWS in order to test the restore of an external Redis snapshot to ElastiCache. I will need to put these files into Amazon S3 so that I can access the snapshots as input for my ElastiCache Redis cluster.
In the S3 console, I will go to my S3 bucket, aws-blog-tew-posts, that I created for testing and development purposes. I’ll upload the .rdb snapshot files that were provided to me into this S3 bucket.
It is important to note that the name of your S3 bucket must conform to DNS standards. To be DNS-compliant, the name must be at least three characters, must contain only lowercase letters, numbers, and/or dashes, and it must start and end with a lowercase letter or number. While this may be obvious, I will also note that the bucket name cannot be in an IP address format. You can learn more about the S3 Bucket Restrictions at the link provided here.
With my .rdb files successfully uploaded into my aws-blog-tew-posts bucket, I need to take note of the S3 path to these backup files. For these files, the path would be aws-blog-tew-posts/dump_1.rdb or aws-blog-tew-posts/dump_10.rdb. If you have placed your files into a folder, the folder name would need to be included in this path, i.e. thebucketname/thefoldername/thefilename.
For ElastiCache to access these files, I need to ensure that the service has read permissions for each of the files. To provide access, I will update the permissions for each of .rdb files by assigning the Grantee as the canonical id for my region and grant the user Open/Download permissions. The canonical id for all regions, outside of China (Beijing) and AWS GovCloud (US), is as follows:
After I click the Save button, I am all set to use these files as input for an ElastiCache Redis cluster.
The next step is to go to the ElastiCache console. Here I will create a new ElastiCache Redis cluster and seed this new cluster with data from one of the RDB snapshots located in the files in my S3 bucket. I’ll choose the dump_1.rdb snapshot file to use as my data input to seed this new cluster. Since I want to explore the ElastiCache Redis capabilities added on this past October with 3.2.4 support of Redis Cluster, as well as, discuss the new Backup and Restore with Cluster Resizing enhancements, I’ll create a new Redis Cluster and ensure I have cluster mode enabled. At this point, I should note that you cannot restore from a backup created using a Redis (cluster mode enabled) cluster to a Redis (cluster mode disabled) cluster.
First, I will click the Get Started Now button from the ElastiCache console dashboard or the Create button based upon your console view.
In the Create your Amazon ElastiCache cluster dialog window, I’ll select Redis for my caching and make sure I click the checkbox for Cluster Mode enabled (Scale Out). The name of my new cluster will be, tew-rediscluster and I since I am enabling a Cluster mode, my ElastiCache Redis Engine version is 3.2.4. For this cluster, I will keep the default Redis port of 6379.
The key benefit of the ElastiCache enhanced Redis Backup and Restore feature is the cluster resizing capability that allows me to build a new cluster with a different number of shards than was originally used for the backup file. To build the new Redis Cluster, I am using only one RDB snapshot file, dump_1.rdb which is a small Redis instance backup with only one shard. However, in the creation of my new tew-rediscluster, I have opted for 3 shards with 2 replicas per shard.
In addition, I have the ability to specify a node type for my new cluster that is a different size than my original instance from the RDB snapshot. As I mentioned, the dump_1.rdb is a backup of a Redis instance that is significantly smaller than the size of the chosen node type for my tew-rediscluster shown below.
There are other options and data input needed in order to complete the creation of my ElastiCache Redis cluster that I will not show in this blog post. However, if you want to go through each of the steps necessary for creating an ElastiCache Redis cluster you can find more information in the AWS ElastiCache Getting Started documentation for Launch a Cluster.
Once I have provided all the information needed to create my ElastiCache Redis cluster, I will need to tell ElastiCache how to seed the cluster with the .rdb file by providing the file location from my S3 bucket. In the Import Data to Cluster section of the create dialog, I will enter the S3 path to my dump_1.rdb in the Seed RDB file S3 location textbox. Remember, the nomenclature for the S3 file path is Bucket/Folder/ObjectName so I will enter aws-blog-tew-posts/dump_1.rdb as the path to the RDB file in S3. All that is left now is to click the Create button.
That’s it! ElastiCache goes to work to creating the new Redis cluster. After a short time period, the ElastiCache console shows my new Amazon ElastiCache Redis cluster as available and I have successfully created this cluster with data restored from an external RDB snapshot file.
I just demonstrated how you have the capability to create an ElastiCache Redis cluster using an external RDB snapshot, but of course, you can create backups and restore from backups from your existing ElastiCache Redis clusters as well. To dig deeper into information about this newly launched feature, visit Restoring From a Backup with Cluster Resizing in the Amazon ElastiCache User Guide.
To learn more about making your applications more performant with Amazon ElastiCache, visit the AWS Amazon ElastiCache page for product details, resources, and customer testimonials.
Many AWS customers use Amazon ElastiCache to implement a fast, in-memory data store for their applications.
We launched Amazon ElastiCache for Redis in 2013 and have added snapshot exports to S3, a refreshed engine, scale-up capabilities, tagging, and support for Multi-AZ operation with automatic failover over the past year or so.
Today we are adding a healthy collection of new features and capabilities to ElastiCache for Redis. Here’s an overview:
Sharded Cluster Support – You can now create sharded clusters that can hold more than 3.5 TiB of in-memory data.
Improved Console – Creation and maintenance of clusters is now more straightforward and requires far fewer clicks.
Engine Update – You now have access to the features of the Redis 3.2 engine.
Geospatial Data – You can now store and process geospatial data.
Let’s dive in!
Sharded Cluster Support / New Console
Until now, ElastiCache for Redis allowed you to create a cluster containing a single primary node and up to 5 read replicas. This model limited the size of the in-memory data store to 237 GiB per cluster.
You can now create clusters with up to 15 shards, expanding the overall in-memory data store to more than 3.5 TiB. Each shard can have up to 5 read replicas, giving you the ability to handle 20 million reads and 4.5 million writes per second.
The sharded model, in conjunction with the read replicas, improves overall performance and availability. Data is spread across multiple nodes and the read replicas support rapid, automatic failover in the event that a primary node has an issue.
In order to take advantage of the sharded model, you must use a Redis client that is cluster-aware. The client will treat the cluster as a hash table with 16,384 slots spread equally across the shards, and will then map the incoming keys to the proper shard.
ElastiCache for Redis treats the entire cluster as a unit for backup and restore purposes; you don’t have to think about or manage backups for the individual shards.
The Console has been improved and I can create my first Scale Out cluster with ease (note that I checked Cluster Mode enabled (Scale Out) after I chose Redis as my Cluster engine):
The Console helps me to choose a suitable node type with a handy new menu:
Amazon ElastiCache for Redis is compatible with version 3.2 of the Redis engine. The engine includes three new features that may be of interest to you:
Enforced Write Consistency – the new WAIT command blocks the caller until all previous write commands have been acknowledged by the primary node and a specified number of read replicas. This change does not make Redis in to a strongly consistent data store, but it does improve the odds that a freshly promoted read replica will include the most recent writes to previous primary.
SPOP with COUNT – The SPOP command removes and then returns a random element from a set. You can now request more than one element at a time.
Bitfields – Bitfields are a memory-efficient way to store a collection of many small integers as a bitmap, stored as a Redis string. Using the BITFIELD command, you can address (GET) and manipulate (SET, increment, or decrement) fields of varying widths without having to think about alignment to byte or word boundaries.
Our implementation of Redis includes a snapshot mechanism that does not need to fork the server process into parent and child processes. Under heavy load, the standard, fork-based snapshot mechanism can lead to degraded performance due to swapping. Our alternative implementation comes in to play when memory utilization is above 50% and neatly sidesteps the issue. It is a bit slower, so we use it only when necessary.
We have improved the performance of the syncing mechanism that brings a fresh read replica into sync with its primary node. We made a similar improvement to the mechanism that brings the remaining read replicas back in to sync with the newly promoted primary node.
As I noted earlier, our engine is compatible with the comparable open source version and your applications do not require any changes.
You can now store and query geospatial data (a latitude and a longitude). Here are the commands:
- GEOADD – Insert a geospatial item.
- GEODIST – Get the distance between two geospatial items.
- GEOHASH – Get a Geohash (geocoding) string for an item.
- GEOPOS – Return the positions of items identified by a key.
- GEORADIUS -Return items that are within a specified radius of a location.
- GEORADIUSBYMEMBER – Return items that are within a specified radius of another item.
Sharded cluster creation and all of the features that I mentioned are available now and you can start using them today in all AWS regions.
Amazon ElastiCache supports the popular Memcached and Redis in-memory caching engines. While Memcached is generally used to cache results from a slower, disk-based database, Redis is used as a fast, persistent key-value store. It uses replicas and failover to support high availability, and natively supports the use of structured values.
Today I am going to focus on a helpful new feature that will be of interest to Redis users. You already have the ability to create snapshots of a running Cache Cluster. These snapshots serve as a persistent backup, and can be used to create a new Cache Cluster that is already loaded with data and ready to go. As a reminder, here’s how you create a snapshot of a Cache Cluster:
You can now export your Redis snapshots to an S3 bucket. The bucket must be in the same Region as the snapshot and you need to grant ElastiCache the proper permissions (List, Upload/Delete, and View Permissions) on it. We envision several uses for this feature:
Disaster Recovery – You can copy the snapshot to another environment for safekeeping.
Analysis – You can dissect and analyze the snapshot in order to understand usage patterns.
Seeding – You can use the snapshot to seed a fresh Redis Cache Cluster in another Region.
Exporting a Snapshot
To export a snapshot, simply locate it, select it, and click on Copy Snapshot:
Verify the permissions on the bucket (read Exporting Your Snapshot to learn more):
Then enter a name and select the desired bucket:
ElastiCache will export the snapshot and it will appear in the bucket:
The file is a standard Redis RDB file, and can be used as such.
You can also exercise this same functionality from your own code or via the command line. Your code can call
CopySnapshot while specifying the target S3 bucket. Your scripts can use the
This feature is available now and you can start using it today! There’s no charge for the export; you’ll pay the usual S3 storage charges.
Amazon ElastiCache makes it easy for you to deploy, operate, and scale an in-memory database in the cloud. As you may already know, ElastiCache supports the Memcached and Redis engines.
More Power for Redis
Today we are launching an ElastiCache update that provides you with additional control over your Redis-based ElastiCache clusters. You can now scale up to a larger node type while ElastiCache preserves (on a best-effort basis) your stored information. While ElastiCache for Redis has always allowed you to upgrade the engine version, you can now do so while preserving the stored information. You can apply both changes immediately or during the cluster’s maintenance window.
Behind the scenes, ElastiCache for Redis uses several different strategies to scale up and to upgrade engines. Scaling is based on Redis replication. Engine upgrades use a foreground snapshot (SAVE) when Multi-AZ is turned off, and replication followed by a DNS switch when it is on.
To scale up to a larger node type, simply select the Cache Cluster in the AWS Management Console and click on Modify. Then select the new Node Type, decide if you want to apply the change immediately, and click on Modify to proceed:
Similarly, to upgrade to a newer version of the Redis engine, select the new version and click on Modify:
I would like to take this opportunity to encourage you to upgrade to the engine that is compatible with version 2.8.24 of Redis. This version contains a number of fixes and enhancements to Redis’ stability and robustness (some contributed by the ElastiCache team; see the What’s New for more information).
// Scale to larger node size $res = $client->modifyCacheCluster(['CacheNodeType' => 'cache.r3.4xlarge', 'ApplyImmediately' => true]); // Upgrade engine version $res = $client->modifyCacheCluster(['EngineVersion' => '2.8.24', 'ApplyImmediately' => true]); // Do both at once $res = $client->modifyCacheCluster(['CacheNodeType' => 'cache.r3.4xlarge', 'EngineVersion' => '2.8.24', 'ApplyImmediately' => true]);
In all three of these examples, the ApplyImmediately parameter indicates that the changes will be made right away rather than during the maintenance window.
To learn more, read Scaling Your Redis Cluster.
This feature is available now and you can start using it today!
Today we are making ElastiCache even more useful by adding support for version 2.8.19 of the Redis engine. Compared to version 2.8.6 (until now the latest version supported by ElastiCache Redis), this version of Redis adds an important new data type known as a HyperLogLog, along with some other commands, some functionality improvements, and some bug fixes.
Let’s take a closer look at each of these items.
A HyperLogLog is a compact (12 KB per key) Redis data object that can quickly and efficiently tabulate and approximate the number of unique elements in a set (mathematicians like to call this the cardinality).
Let’s say that you had a web site and wanted to keep reasonably close track the number of times per week each of your registered users visited the site, without wanting to update and query a database while generating each page. You would simply create a HyperLogLog and add (using the Redis PFADD command) a new occurrence as part of each visit, using the user name as the key. At any point you can call PFCOUNT to receive an estimate (with a standard error of 0.81%) of the number of visits made by the user or by multiple users (depending on how you use the command).
Because the data structure is compact and does not grow as the number of keys or occurrences of keys grows, you could conceivably use one HyperLogLog for each of the major pages on your site. After you implement this, you can then use the PFMERGE command to merge the HyperLogLogs for each page into a single value that will allow you to approximate the number of pages on the site accessed by each user.
Needless to say, this is a very powerful data object and one that should allow you to implement some interesting new functions for your application without adding much in the way of storage or processing requirements.
This version of Redis also includes the following new commands:
- ROLE – Return information about the replication state (master or slave) of the Redis instance.
- BITPOS – Return the position of the first 0 or 1 bit (as desired ) in a string.
- COMMAND – Return an array of details about all Redis commands.
Redis 2.8.19 also introduces several bug fixed including one which caused the primary to fail a SYNC operation if the child process used to implement state saving terminated unexpectedly. This had an impact on the correctness of the data on the replica.
This version of the Redis engine is available now and you can start using it today!
As you probably know, you can tag many types of AWS resources for tracking and billing purposes. You can use the Cost Explorer to attribute costs to resources and you can use Resource Groups to easily create and maintain collections of resources that share a common set of tags.
Today we are giving you the ability to tag your Amazon ElastiCache clusters and snapshots. To tag a cluster, simply open the ElastiCache console, select the cluster, and click on Manage Tags:
Enter the desired key(s) and values(s):
Your tags will be visible in the console:
You can also tag your cache cluster snapshots in the same way. The AWS Command Line Interface (CLI) and the AWS SDKs will be updated later this week.
This feature is available now and you can start using it today!
AWS Expansion – WorkSpaces, Directory Service, ElastiCache, GovCloud, Kinesis, Traditional Chinese, More
We’ve increased the geographic footprint and international relevance of several AWS services this past month. Here’s a summary:
- Amazon WorkSpaces and AWS Directory Service are now available in the Asia Pacific (Singapore) region.
- Amazon ElastiCache is now available in the EU (Frankfurt) region.
- AWS Trusted Advisor, Amazon ElastiCache, and RDS integration with AWS CloudTrail are now available in AWS GovCloud (US).
- We added a second location in Korea for Amazon CloudFront and Amazon Route 53.
- Amazon Kinesis is now available in the US West (Northern California) region.
- The AWS website is now available in Traditional Chinese.
For more information on service availability, please take a look at our Products and Services by Region page.
- August 2011 – Initial launch with support for the Memcached caching engine in one AWS Region.
- December 2011 – Expansion to four additional Regions.
- March 2012 – The first of several price reductions.
- April 2012 – Introduction of Reserved Cluster Nodes.
- November 2012 – Introduction of four additional types of Cache Nodes.
- September 2013 – Initial support for the Redis caching engine including Replication Groups with replicas for increased read throughput.
- March 2014 – Another price reduction.
- April 2014 – Backup and restore of Redis Clusters.
- July 2014 – Support for M3 and R3 Cache Nodes.
- July 2014 – Node placement across more than one Availability Zone in a Region.
- September 2014 – Support for T2 Cache Nodes.
When you start to use any of the AWS services, you should always anticipate a steady stream of enhancements. Some of them, as you can see from list above, will give you additional flexibility with regard to architecture, scalability, or location. Others will improve your cost structure by reducing prices or adding opportunities to purchase Reserved Instances. Another class of enhancements simplifies the task of building applications that are resilient and fault-tolerant.
Multi-AZ Support for Redis
Today’s launch is designed to help you to add additional resilience and fault tolerance to your Redis Cache Clusters. You can now create a Replication Group that spans multiple Availability Zones with automatic failure detection and failover.
After you have created a Multi-AZ Replication Group, ElastiCache will monitor the health and connectivity of the nodes. If the primary node fails, ElastiCache will select the read replica that has the lowest replication lag (in other words, the one that is the most current) and make it the primary node. It will then propagate a DNS change, create another read replica, and wire everything back together, with no administrative work on your side.
This new level of automated fault detection and recovery will enhance the overall availability of your Redis Cache Clusters. The following situations will initiate the failover process:
- Loss of availability in the primary’s Availability Zone.
- Loss of network connectivity to the primary.
- Failure of the primary.
Creating a Multi-AZ Replication Group
You can create a Multi-AZ Cache Replication Group by checking the Multi-AZ checkbox after selecting Create Cache Cluster:
A diverse set of Availability Zones will be assigned by default. You can easily override them in order to better reflect the needs of your application:
Multi-AZ for Existing Cache Clusters
You can also modify your existing Cache Cluster to add Multi-AZ residency and automatic failover with a couple of clicks.
Things to Know
The Multi-AZ support in ElastiCache for Redis currently makes use of the asynchronous replication that is built in to newer versions (2.8.6 and beyond) of the Redis engine. As such, it is subject to its strengths and weaknesses. In particular, when a read replica connects to a primary for the first time or when the primary changes, the replica will perform a full synchronization with the primary. This ensures that the cached information is as current as possible, but it will impose an additional load on the primary and the read replica(s).
The entire failover process, from detection to the resumption of normal caching behavior, will take several minutes. Your application’s caching tier should have a strategy (and some code!) to deal with a cache that is momentarily unavailable.
This new feature is available now in all public AWS Regions and you can start using it today. The feature is offered at no extra charge to all ElastiCache users.
As you may already know, Amazon Elastic Compute Cloud (EC2)‘s new T2 instance type provides a solid level of baseline performance and the ability to burst above the baseline as needed. As I wrote in my blog post, these instances are ideal for development, testing, and medium-traffic web sites.
Today we are bringing the benefits of the T2 instance type to Amazon ElastiCache. The cache.t2.micro (555 megabytes of RAM), cache.t2.small (1.55 gigabytes of RAM), and cache.t2.medium (3.22 gigabytes of RAM) cache nodes feature the latest Intel Xeon processors running at up to 3.3 GHz. You can launch new cache nodes using the Memcached or Redis engines.
T2 instances are supported only within an Amazon Virtual Private Cloud. The Redis Backup and Restore feature and the Redis AOF are not currently usable with the T2 instances. You can launch them in the usual ways (command line, API, CloudFormation, or Console):
Pricing and Availability
Pricing for T2 cache nodes starts at $0.008 per hour for Three Year Heavy Utilization Reserved Cache Nodes and $0.017 per hour for On-Demand Cache Nodes. (see the ElastiCache Pricing page for more information). As part of the AWS Free Tier, eligible AWS users have access to a cache.t2.micro instance for 750 hours per month at no charge.
The new cache nodes are available today in all AWS Regions except AWS GovCloud (US) and you can start using them today!
Today we are launching a new flexible node placement model for ElastiCache. Your Memcached Cache Clusters can now span multiple Availability Zones within a Region. This will help to improve the reliability of the Cluster.
You can now choose the Availability Zone for new nodes when you create a new Cache Cluster or add more nodes to an existing Cluster. You can specify the new desired number of nodes in each Availability Zone or you can simply choose the Spread Nodes Across Zones option. If the cluster is within a Virtual Private Cloud (VPC) you can place nodes in Availability Zones that are part of the selected cache subnet group (read Creating a Cache Cluster in a VPC to learn more).
Here is how you control node placement when you create a new Cache Cluster using the Memcached engine:
Here is how you control zone placement when you add nodes to an existing cluster: