Elasticache

Elasticache is an AWS managed data caching service mainly for databases and applications.

 

ElastiCache uses one of two open-source in-memory cache engines for its functionality:

 

Memcached and Redis.

 

 

 Elasticache is used to reduce traffic overhead for RDS and some other applications. It is extremely fast as db is held in ram memory.

 

Your cache must have an invalidation strategy defined to ensure only the most currently used data is stored in the cache.

 

It can also be used to store user sessions for an application for cases where users may be redirected later to different instances of the application, saving having to re-do the user login session.

 

But it does require code configurations for apps to be able to query the cache.

 

 

ElastiCache includes a feature for master/slave replication and multi-AZ, can be used for achieving cross-AZ redundancy and thus high-availability through the use of Redis replication groups.

 

 

Memcached

 

Memcached is an ASCII text file memory object caching system. ElastiCache is protocol compliant with Memcached, thus all the tools used with existing Memcached environments can also be used with ElastiCache. This is the simplest caching model and can also be used when deploying large nodes with multiple cores and threads.

 

Redis

Redis is an open-source in-memory key-value store that supports information structures such as lists and sorted sets.

 

Redis can power multiple databases, as well as maintain the persistence of your key store and works with complex data types — including bitmaps, sorted sets, lists, sets, hashes, and strings.

 

If Cluster-Mode is disabled, then there is only one shard. The shard comprises the primary node together with the read replicas. Read replicas store a copy of the data from the cluster’s primary node.

 

Elasticache allows for up to 250 shards for a Redis cluster if Cluster-Mode is enabled. Each shard has a primary node and up to 5 read replicas.

 

When reading or writing data to the cluster, the client determines which shard to use based on the keyspace. This avoids any potential single point of failure.

 

 

Implementing ElastiCache

 

There are three main implementation steps:

 

Creating an ElastiCache cluster
Connecting to the ElastiCache cluster from an EC2 instance
Managing the ElastiCache environment from the AWS console

 

 

Creating an ElastiCache cluster

 

This involves choosing and configuring the caching engine to be used. This will be either Redis or Memcached. For each caching engine, configuration parameters differ.

 

Next, we need to choose the location ie in AWS cloud or On-Premise.

 

AWS Cloud – This uses the AWS cloud for your ElastiCache instances

 

On-Premises – In this case, you can create your ElastiCache instances using AWS Outpost.

 

AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to your own on-site infrastructure.

 

 

ElastiCache REDIS Replication –  Cluster Mode Disabled

 

There are two possible configuration modes for running ElastiCache and REDIS:

 

Cluster Mode Disabled, and Cluster Mode Enabled:

 

In this configuration you run ONE PRIMARY NODE of ElastiCache with up to 5 Read Replicas

 

Note that uses asynchronous replication to maintain the Read Replicas, so there is a lag.

 

The primary node is always used for read/write. The other nodes are read-only.

 

There is just ONE SHARD and all shards hold all the data.

 

Multi-AZ is enabled by default for failovers.

 

 

ElastiCache REDIS Replication –  Cluster Mode Enabled 

 

With Cluster Mode Enabled the data is  partitioned across MULTIPLE SHARDS

 

Data is divided across all your shards. This helps especially with scaling write transactions.

 

Each shard consists of a primary node and up to 5 read replica nodes.

Also has multiple AZ availability

 

Provides up to 500 nodes per cluster with a single master node.

or 250 nodes with 1 master and 1 replica.

 

 

 

Scaling REDIS with ElastiCache

 

For “Cluster Mode Disabled”:

 

Horizontal scaling – you scale out or in by adding or removing read replicas

 

Vertical scaling – you alter the type of the underlying nodes 

 

Important for exam!

 

This is done by means of ElastiCache creating a NEW node group with the new type specification for the nodes, then performing a replication to the new node group, and then finally updating the DNS records so that they point to the new node group and not any longer to the old original node group before scaling.

 

For “Cluster Mode Enabled”:

 

this can be done in two different ways – online, and offline:

 

Online: no interruption to service no downtime, but can be some performance degredation during the scaling.

 

Offline: service is down, but additional configurations are supported

 

So, when doing horizontal REDIS scaling, you can do online and office rescaling, and you can do resharding or shard rebalancing for this:

 

Resharding: “resharding” – this means scaling in or out by adding or removing shards.

 

Shard rebalancing:  involves equally redistributing the keyspaces among the shards as balanced as possible.

 

Vertical Scaling: you are changing to a larger or smaller node type, this is done online only, relatively straightforward.

 

 

 

REDIS Metrics to Monitor

 

Evictions: this is the number of non-expired items the cache has removed in order to make space for new writes ie the memory was full.

 

In this case choose an eviction policy to evict expired items eg least recently used items, LRU  or scale up to a larger node type with more memory, or else scale out by adding more nodes

 

CPUUtilization: this monitors CPU usage for the entire host, if too high, then scale up to a larger node type with more memory

 

SwapUsage: this should not be allowed to exceed 50Mb, if it does then verify you have configured enough reserved memory

 

CurrConnections: no of current connections – see if a specific app is causing this

 

DatabaseMemoryUsagePercentage:

 

NetworkBytesIn/Out & NetworkPAcketsIn/Out

 

ReplicationBytes: vol of data being replicated

 

ReplicationLag: how far behind the replica is from the primary node

 

 

 

 

 

 

 

 

 

Some ElastiCache use cases

 

know these for the exam!

 

Updating and managing leaderboards in the gaming industry

 

Conducting real-time analytics on live e-commerce sites

 

Monitoring status of customers’ accounts on subscription-based sites

 

Processing and relaying messages on instant messaging platforms

 

Online media streaming

 

Performing geospatial processes

 

 

 

Pros and Cons of Using ElastiCache

 

Pros of ElastiCache

 

Fully-managed – ElastiCache is a fully-managed cloud-based solution.

 

AWS takes care of backups, failure recovery, monitoring, configuration, setup, software updating and patches, and hardware provisioning.

 

Improved application performance – ElastiCache provides in-memory RAM data storage that substantially reduces database query times.

 

Easily scalable – you can scale up and down with minimal overhead

 

Highly available – ElastiCache achieves high availability through automatic failover detection and use of standby read replicas.

 

Cons of ElastiCache

 

Limited and complex integration – ElastiCache doesn’t provide many easy options for integration. And you can only connect Elasticache to databases and applications hosted by AWS.

High learning curve – the Elasticache user interface is not intuitive and the system requires a high learning overhead to properly understand.

 

High price – You pay only for what you use but the costs of using Elasticache can swiftly rise according to usage.

 

 

Comparison of ElastiCache With Redis, CloudFront, And DynamoDB

 

ElastiCache is very different to all these services.

 

 

AWS ElastiCache versus Redis

 

 

ElastiCache is an in-memory cache in the cloud. With very fast retrieval of data from managed in-memory caches, Elasticache improves overall response times, and saves relying wholly on slow disk-based databases for processing queries.

 

Redis stands for Remote Dictionary Server — a fast, in-memory, open-source, key-value data store that is usually implemented as a queue, message broker, cache, and database.

 

ElastiCache is developed on open-source Redis to be compatible with the Redis APIs, as well as operating seamlessly with Redis clients.

 

This means that you can run your self-managed Redis applications and store the data in an open Redis format, without having to change the code.

 

ElastiCache versus CloudFront

 

While ElastiCache and CloudFront are both AWS caching solutions, their approaches and framework differ greatly.

 

ElastiCache enhances the performance of web applications by retrieving information from fully-managed in-memory data stores at high speed.

 

To do this it utilizes Memcached and Redis, and is able in this way to substantially reduce the time applications need to read data from disk-based databases.

 

Amazon CloudFront is primarily a Content Delivery Network (CDN) for faster delivery of web-based data through deploying endpoint caches that are positioned closer to the traffic source. This saves too much web traffic from further-flung geolocations from having to source content entirely from the original hosting server.

 

ElastiCache versus DynamoDB

 

DynamoDB is a NoSQL fully-managed AWS database service that holds its data on solid state drives (SSDs). These SSDs are then cloned across three availability zones to increase reliability and availability. In this way, it saves the overhead of building, maintaining, and scaling costly distributed database clusters.

 

ElastiCache is the AWS “Caching-as-a-Service”, while DynamoDB serves as the AWS “Database as a Service”.

 

 

Pricing of ElastiCache

 

To use ElastiCache you have to make a reservation- Pricing for this is based on the caching engine you choose, plus the type of cache nodes.

 

If you are using multiple nodes (ie replicas) in your cluster, then ElastiCache will require you to reserve a node for each of your cluster nodes.

 

 

Difference Between Redis and Memcached

 

 

REDIS: similar to RDS

multi AZ with auto failover
read replicas used to scale reads and provide HA.

 

Data durability

 

provides backup and restore

REDIS:

Primary use case: In-memory database & cache   Cache
Data model: In-memory key-value 
Data structures: Strings, lists, sets, sorted sets, hashes, hyperlog
High availability & failover: Yes 

 

Memcached by contrast:

 

Memcached
Primary use case: Cache
Data model: In-memory key-value
Data structures: Strings, objects
High availability & failover: No

 

 

is multi-node data partitioning ie sharding

 

no HA

 

non-persistent data

 

no backup and restore

multi-threaded architecture

 

 

Main Points To Remember About REDIS and Memcached

 

REDIS is for high-availability – memcached has no AZ-failover, only sharding.

 

Also REDIS provides backup & restore – memcached does not.

 

Memcached has a multi-threaded architecture, unlike REDIS.

 

 

 

Redis Metrics to Monitor

 

Evictions: this is the number of non-expired items the cache has removed in order to make space for new writes ie the memory was full.

 

In this case choose an eviction policy to evict expired items eg least recently used items, LRU

 

scale up to a larger node type with more memory, or else scale out by adding more nodes

 

CPUUtilization: this monitors CPU usage for the entire host, if too high, then scale up to a larger node type with more memory

 

SwapUsage: this should not be allowed to exceed 50Mb, if it does then verify you have configured enough reserved memory

CurrConnections: no of current connections – see if a specific app is causing this

 

DatabaseMemoryUsagePercentage:

 

NetworkBytesIn/Out & NetworkPAcketsIn/Out

 

ReplicationBytes: vol of data being replicated

 

ReplicationLag: how far behind the replica is from the primary node

 

 

 

Memcached Scaling

 

Memcached clusters can have 1-40 nodes soft limit

 

Horizontal scaling: you add or remove nodes from the cluster and use “Auto-discovery” to allow you app to identify the new nodes or new node config.

 

Vertical scaling:  scale up or down to larger or smaller node types

 

to scale up: you create a new cluster with the new node type

 

then update your app to use the new cluster endpoints

 

then delete the old cluster

 

Important to note that memcached clusters/nodes start out empty, so your data will be re-cached from scratch once again.

 

there is no backup mechanism for memcached.

 

 

Memcached Auto Discovery

 

automatically detects all the nodes

 

all the cache nodes in the cluster maintain a list of metadata about all the nodes

 

note: this is seamless from the client perspective

 

Memcached Metrics to Monitor

Evictions: the number of non-expired items the cache evicted to allow space for new writes (when memory is overfilled). The solution: use a new eviction policy to evict expired items, and/or scale up to larger node type with more RAM or else scale out by adding more nodes

 

CPUUtilization: solution: scale up to larger node type or else scale out by adding more nodes

 

SwapUsage: should not exceed 50MG

 

CurrConnections: the number of concurrent and active connections

 

FreeableMemory: amount of free memory on the host