Amazon MemoryDB for Redis

Use cases

Here are a few industrial use cases where MemoryDB for Redis is a huge advantage:

• Retail/E-commerce applications: Retail customers need speed and agility to keep their applications’ loading time as low as possible, because long wait time on a website or difficulty in communicating with other services on a website results in losing visitors. MemoryDB for Redis supports applications built on microservices architecture. 

• Financial services: Because of the very low latency in MemoryDB, it helps real-time fraud detection.

• Media and entertainment: The entertainment industry has become one of the most important, demanding, and challenging one in the last few years. Customers need lighter, faster, and cleaner applications with extreme performance. 

Core components

MemoryDB for Redis works in cluster formation. Each cluster consists of shards that contain nodes. Let’s briefly look at these core components of MemoryDB for Redis cluster.

• Nodes: A node is an EC2 instance that runs a particular version of the Redis engine selected at the time of cluster creation. It’s the smallest component of a MemoryDB cluster, and we can add or remove nodes from a shard. There are two types of nodes: Primary and Replica. A primary node can entertain read and write requests, while the replica nodes can only have read requests. 

• Shards: A shard is a collection of one or more nodes. A shard must contain at least one node (primary node) and can have up to five replica nodes, which makes a shard a group of a maximum of six nodes. Our dataset is partitioned across shards.

• Cluster: A cluster is a collection of shards responsible for managing the shards and nodes. Each cluster has a specific Redis engine version that defines the functionalities of the cluster. A MemoryDB cluster can have up to 500 shards.

Note: A cluster can have a maximum of 500 shards with no replica nodes or 100 shards with 4 replica nodes totaling 500 nodes per cluster. 

Multi-AZ replication and failover

Amazon MemoryDB for Redis cluster spans replica nodes in different availability zones in a region to ensure high data availability. Each replica maintains a copy of the primary node’s storage in their AZ, and the primary node’s data is asynchronously replicated to other nodes using transactional logs. Primary and replica nodes should be spread across multiple AZs in an AWS Region to achieve fault tolerance.

There can be unfortunate events where primary node becomes unavailable or its AZ goes down. If Multi-AZ is enabled, primary node failovers to any replica node within a few seconds of downtime.

Scaling

Our applications can’t run with the same storage and computing power. There can be chances when we want to scale out or in our MemoryDB cluster based on our application’s requirements. Amazon MemoryDB for Redis allows two ways to scale the resources. One is horizontal scaling, and the second is vertical scaling. In horizontal scaling, the number of shards is increased or decreased according to the requirement, while in vertical scaling, the capacity of already existing nodes is modified. The scaling process can be offline or online. In offline scaling, the cluster is offline and can’t entertain incoming requests. Therefore, the online scaling is recommended as it allows the cluster to respond to the incoming requests.

Backup and restore

Amazon MemoryDB takes data backup in Multi-AZ transactional logs to make it highly available across the AWS Region. It also allows us to take periodic or on-demand snapshots for point-in-time recovery. The snapshots are stored in an Amazon S3 bucket, and we can restore it anytime by creating a new cluster from the snapshot.

Note: Amazon MemoryDB does not allow creating more than 20 manual snapshots per cluster within a 24-hour window. Snapshots are available at the cluster level only, and it always taken from the primary instance so that the latest changes are backed up.