Category: Amazon ElastiCache


Amazon ElastiCache for Redis Update – Sharded Clusters, Engine Improvements, and More

by Jeff Barr | on | in Amazon ElastiCache | | Comments

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:

You can also create sharded clusters using the AWS Command Line Interface (CLI), the AWS Tools for Windows PowerShell, the ElastiCache API, or via a AWS CloudFormation template.

Engine Update
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.

Geospatial Data
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.

Available Now
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.

Jeff;

Amazon ElastiCache Update – Export Redis Snapshots to Amazon S3

by Jeff Barr | on | in Amazon ElastiCache, Amazon S3 | | Comments

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  copy-snapshot command.

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.

Jeff;

 

ElastiCache for Redis Update – Upgrade Engines and Scale Up

by Jeff Barr | on | in Amazon ElastiCache | | Comments

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).

You can, as always, accomplish the same operations by way of the ElastiCache API.  Here are some quick examples in PHP (via the AWS SDK for PHP):

// 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.

Available Now
This feature is available now and you  can start using it today!

Jeff;

Amazon ElastiCache Update – Redis 2.8.19 Now Available

by Jeff Barr | on | in Amazon ElastiCache |

You can use Amazon ElastiCache to easily create, scale, and maintain cloud-based in-memory key-value stores that use the Memcached or Redis engines.

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.

HyperLogLog
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.

Additional Commands
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.

Enhancements & Bug Fixes
The sorted set data type now supports lexicographic range queries by way of the ZRANGEBYLEX, ZLEXCOUNT, and ZREMRANGEBYLEX 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!

Jeff;

New – Tagging for ElastiCache Clusters & Snapshots

by Jeff Barr | on | in Amazon ElastiCache |

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!

Jeff;

AWS Expansion – WorkSpaces, Directory Service, ElastiCache, GovCloud, Kinesis, Traditional Chinese, More

by Jeff Barr | on | in Amazon CloudFront, Amazon ElastiCache, Amazon Kinesis, Amazon WorkSpaces, AWS Directory Service, AWS GovCloud (US), Route 53 | | Comments

We’ve increased the geographic footprint and international relevance of several AWS services this past month. Here’s a summary:

For more information on service availability, please take a look at our Products and Services by Region page.

Jeff;

 

Multi-AZ Support / Auto Failover for Amazon ElastiCache for Redis

by Jeff Barr | on | in Amazon ElastiCache | | Comments

Like every AWS offering, Amazon ElastiCache started out simple and then grew in breadth and depth over time. Here’s a brief recap of the most important milestones:

  • 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:

  1. Loss of availability in the primary’s Availability Zone.
  2. Loss of network connectivity to the primary.
  3. 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.

Available Now
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.

Jeff;

ElastiCache T2 Support

by Jeff Barr | on | in Amazon ElastiCache | | Comments

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!

Jeff;

Amazon ElastiCache Flexible Node Placement

by Jeff Barr | on | in Amazon ElastiCache | | Comments

Amazon ElastiCache makes it easy for you to deploy an in-memory cache in the cloud using the Memacached or Redis engines.

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:

This new feature is available now and you can start using it today! To learn more, take a look at Managing Cache Clusters in the ElastiCache User Guide.

Jeff;

ElastiCache Update – New M3 and R3 Instance Types

by Jeff Barr | on | in Amazon ElastiCache | | Comments

You can use Amazon ElastiCache to add a scalable caching layer to your application. As you may already know, you can use ElastiCache to create a Memcached or Redis Cache Cluster comprised of one or more Cache Nodes.

Today we are making ElastiCache even more flexible by adding support for two new types of Cache Nodes. The M3 Cache Nodes provide a balance of compute, network, and memory resources and are a perfect choice for general purpose use. The Memory-optimized R3 Cache Nodes provide the best price per GB of RAM and high memory performance. Here’s the full set of new instances:

  • cache.m3.medium – 2.78 GB memory
  • cache.m3.large – 6.05 GB memory
  • cache.m3.xlarge – 13.3 GB memory
  • cache.m3.2xlarge – 27.9 GB memory
  • cache.r3.large – 13.5GB memory
  • cache.r3.xlarge – 28.4GB memory
  • cache.r3.2xlarge – 58.2 GB memory
  • cache.r3.4xlarge – 118 GB memory
  • cache.r3.8xlarge – 237 GB memory

You can launch these new types of Cache Nodes today in the following AWS Regions:

  • US East (Northern Virginia)
  • EU (Ireland)
  • Asia Pacific (Singapore)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Sydney)
  • US West (Oregon)
  • US West (Northern California)
  • South America (São Paulo) – M3 only.
  • China (Beijing) – M3 only.

You can launch Cache Clusters from the AWS Command Line Interface, the ElastiCache API, or the AWS Management Console. Here’s the first page of the console’s launch wizard:

For pricing and other details, please take a look at the ElastiCache Product Details page.

Jeff;

PS – If you want to learn more about the process of adding a Cache Cluster to your application as part of an exercise in performance optimization, take a look at the article Develop, Deploy, and Manage for Scale with Elastic Beanstalk and CloudFormation.