Hands-On with Amazon ElastiCache for Redis - Workshop (DAT309-R1) - AWS re:Invent 2018

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Hands-on Amazon ElastiCache for Redis
Michael Labib
AWS Principal Solutions
Architect
D A T 3 0 9
John Husemoller
AWS Solutions Architect
Matt Wolff
John Marciniak
David Rodriguez

Agenda
 What’s New
 Amazon ElastiCache for Redis Overview
 Lab Time

Data categories and common use cases
Relational
Referential
integrity, ACID
transactions,
schema-
on-write
Lift and shift,
CRM, finance
Key-value
Low-latency,
key lookups
with high
throughput and
fast ingestion
of data
Real-time bidding,
shopping cart,
social, product
catalog, customer
preferences
Document
Indexing and
storing
documents
with support
for query on
any attribute
Content
management,
personalization,
mobile
In-memory
Microseconds
latency, key-
based queries,
and specialized
data structures
Leaderboards,
real-time analytics,
caching
Graph
Creating and
navigating
relationships
between data
easily and
quickly
Fraud detection,
social networking,
recommendation
engine

Can you think of an application that
can’t benefit from ?speed

What’s New: Redis & Memcached
• Redis Streams
• SortedSets now have LIST capabilities (POP and BLOCK)
• HyperLogLogs has an optimized algorithm
• Speed Improvements (Jemalloc additions, etc.)
• Active Defragmentation
• Added In-line HELP command for redis-cli
• Native TLS Integration Redis (ElastiCache)
• More at https://aws.amazon.com/re dis/Whats_ Ne w_Re dis5
• Automated Slab rebalancing
• LRU crawler to background-reclaim memory
• Faster hash table lookups with murmur3 algorithm
 Redis 5.0
 Memcached 1.5.10

Review: Time Series in Redis before Redis 5
SortedSet - Use the Unix time as a score
• Values (messages) have to be unique
• Scores can be modified (are mutable)
Key
value: mike
score: 50 score: 75
value: dan value: emma
score: 79
value: lina
score: 123
value: luke
score: 350
Key HEAD value 1 value 2 value 3 TAIL
List - (blocking queue)
• No message recovery or fanout capabilities
Pub/Sub
• No persistence
• No recovery from failed clients
Channel SubscriberPublisher
Subscriber
Subscriber

New: Redis 5 (Redis Streams)
Hello!
Producer
XADD mystream * msg
Stream
XRANGE mystream - +
1) 1) "1542737709872-0"
2) 1) "msg"
2) "hello!“
Consumer
Generate a unique ID = time - sequence
Log data structure for time series
Append only data structure with ability to fan
out
Add messages to a stream Single Consumer
Listen to items : XREAD
Query by range: XRANGE, XREVRANGE
Items in the stream: XLEN
at least once messaging
"154273770872-0"
Redis generated unique ID
Consumer Groups (X G R O U P , X R E A D G R O U P )
Allow multiple consumers to participate in processing messages
by each consuming a unique subset of the data

New: Amazon ElastiCache: In-Place Version Upgrades
• Upgrade a Redis Cluster to newer engine version in-place
• No Manual Steps or Application Changes
• Available for ElastiCache for Redis Version 3.2 and Higher

New: Amazon ElastiCache Optimized Instances M5 | R5
• Scale up to 9.5 TiB of in-
memory capacity
• AWS Nitro System,
dedicated hardware &
lightweight hypervisor,
delivers performance
indistinguishable from
bare metal
• Custom Intel Xeon
Scalable processors up to
3.1 GHz & AVX-512

When 9.5 TiB is not enough!
Example 1:
• Assume 125 shards made of 1 Primary + 1 Replica = 250 nodes
• Assume R5.24xlarge ( 635.61 GiB )
• Cluster memory 635.61 GiB X 125 = ~80 TiB = ~88 TB
Example 2:
• Assume 250 shards made of 1 Primary + 0 Replica = 250 nodes
• Assume R5.24xlarge ( 635.61 GiB )
• Cluster memory 635.61 GiB X 250 = ~159 TiB = ~170 TB
New: Amazon ElastiCache 250 node support

Coming soon….
PERFORMANCE BOOST FOR MULTI-CORE NODES
Further optimizations providing significant throughput boost
RENAME COMMAND SUPPORT
Ability to rename a command
SELF-SERVICE PATCHING
Provides increased flexibility to control when updates occur

Redis Overview
Fast
<1ms latency for most commands
Open source
Easy to learn
Highly available
Replication
Atomic operations
Supports transactions
In-memory
key-value store
Powerful
~200 commands, Lua scripting,
Geospatial, Pub/Sub
Various data structures
Strings, lists, hashes, sets,
sorted sets, bitmaps, streams,
and HyperLogLogs
Persistence
Snapshots

Difficult to ScaleDifficult to
Manage
Hard to make
Highly
Available
Self-Managing Redis is Challenging
Expensive
Online scaling can be
error prone. Replication
performance needs to
be monitored
Manage hardware
provisioning, software
patching, setup,
configuration, and
backups
Redis outage impacts
application performance
Invest in people, processes,
hardware, and software

Introducing Amazon ElastiCache for Redis
Fully-managed, Redis compatible, in-memory data store in the cloud
Extreme Performance
In-memory data store and
cache for sub-millisecond
response times
Fully Managed
AWS manages all hardware
and software setup,
configuration, monitoring
Easily Scalable
Read scaling with replicas
Write and memory
scaling with sharding
Non disruptive scaling
Redis Compatible
Redis 5 Support
Redis clients compatible
Reliable
Multi-AZ
Deep monitoring
Automatic failover
Secure & Compliant
Amazon VPC
HIPAA, PCI, FedRAMP
Encryption at-rest and in-transit
Authentication

Redis Use Cases
Gaming
leaderboards
Chat apps
Caching
Session
store
Machine learning
Real-time
analytics
Media
streaming
Geospatial
Message queues

VPC
Public subnet
Availability zone 1
Public subnet
Availability zone 2
Auto Scaling group
Private subnet Private subnet
Cache node Cache node
Redis Cluster-mode disabled (Vertically Scale)
Primary Endpoint Replica Endpoints
All keys on
same node
Keyspace
Connect to Primary for
Read/Writes and Replica’s
for Reads

VPC
Public subnet
Availability zone 1
Public subnet
Availability zone 2
Auto Scaling group
Private subnet Private subnet
Cache node
Redis Cluster (Horizontally Scaled)
Zero Downtime Scaling
Configuration
Endpoint
Cache node Cache nodeCache node
Shard 1 Slot 0 - …
Shard 2 Slot … to …
Keyspace
Shard 3 Slot … to …
Shard 4 Slot … to 16383
Partitioned by Shard
Cluster Map
Clients use hash value for
a key CRC16(key) mod
16384
Distribution
Equal | Custom
( CW Metric: CurrItems )

Feature Enabled Disabled
Configuration Data is partitioned across shards (up to 15)
Each shard has 1 primary and up to 5 replicas
Data resides in one primary
May have up to 5 replicas
Redis Compliant Fully compliant with Open Source Redis Cluster APIs
and client ecosystem
Fully compliant with Open Source Redis
Classic APIs and client ecosystem
Cluster Size 90 nodes—15 primaries + 0–5 replicas per shard 6 nodes (1 primary + 0–5 replicas)
Scalability and Performance • Throughput scales with number of shards
• In-memory capacity up to 9.5 TiB
• Throughput limited by 1 primary, 5
replicas
• In-memory capacity up to 635 GiB
Max connections • Primaries (65,000 x 15 = 975,000)*
• Replicas (65,000 x 75 = 4,875,000)
• Primary: 65,000
• Replicas: (65,000 x 5 = 325,000)
Redis Cluster mode enabled vs disabled

Feature Enabled Disabled
Scaling Operation Online Cluster Resizing
• Horizontal Scaling to add/remove shards
• Read Scalability to add/remove replicas
Vertical Scaling
• Writes are blocked
• Reads not supported on master node
Failover 15–30 sec (Non-DNS) 30-45 sec + additional DNS propagation
Failover risk • Writes affected on partial dataset
• Reads available
• Writes affected on entire dataset
• Reads available
Cost
Example: Assume workload
needs 140 GB
Similar (Many Smaller nodes)
15 x cache.r4.large ($0.228hr) = $3.42 hour 184.5 GB
Similar (Few larger nodes)
1 X cache.r4.8xlarge = $3.64 hr , 203.26 GB
Redis Cluster mode enabled vs disabled

Cluster-mode enabled failover
Cache node
Primary Replica
Shard
x5
x15
Cache node
async replication
CW Metric: ReplicationLag

Cache node
Primary Replica
Shard
Cache node
async replication
Failover Detection

Cache node
Primary Replica
Shard
Cache node
async replication
Automatic Failover
(with no DNS propagation)
Test with Failover API
SNS Event: ElastiCache:CacheNodeReplaceComplete
SNS Event: ElastiCache:FailoverComplete

0-5461
reads/ writes
Shard 1 Shard 2 Shard 3
Shard 4 Shard 5
5462--10922 10923-163830-2909,
5095-5461
5462-5783,
6876-9830
10923-14199
2910-5094,
9831--10922
No Application Interruption
Uniform slot distribution across shards
5784-6875,
14200-16383
Zero downtime - Online re-sharding - scale out
Cache node Cache node Cache node
Cache nodeCache node

0-5461
reads/ writes
Shard 1 Shard 2 Shard 3
Shard 4 Shard 5
5462--10922 10923-16383
Uniform slot distribution across shards
Cache node Cache node Cache node
Cache nodeCache node
No Application Interruption
Zero downtime - Online re-sharding - scale in

Online re-sharding— CW alarm trigger
…
var params = {
ApplyImmediately: true,
NodeGroupCount: 5,
ReplicationGroupId: ‘rep-group-id’,
… }
elasticache.modifyReplicationGroupShardConfiguration(params, function(err, data) {
if (err) console.log(err, err.stack);
else console.log(data);
}); …
Alarm
Lambda
Function
Topic

Caching
In-memory cache
relational
object
API Responses
connected data
non-relational
search
analytics
application
Cache it if
you can

Real-time: Sentiment Analysis
Queue (List) ,
Redis Streams
Sentiment
Leaderboard
Sentiment
Data store
Ingestion Tools
Worker,
Consumer
Sentiment
Analysis
Ingest High Velocity
(Rank and Query)

Real-time: AWS IoT Core
Rule
Generic
Lambda
function
House Lightbulb Thermostat Utility
Devices
Redis Streams
Data Lake
Real-time
Store Time Series

Filter Raw
Stream
Cleansed
Stream
Raw
Stream
Parse
Stream
(RAW)
Real-time: Amazon Kinesis Filtering
Lambda
function
Lambda
function
Parse
Stream
(Cleansed)
Stream
(Analytics)
RAW
Stream
(Analytics)
Decorate and Filter
Raw Data

Mobile
Lambda
Function
devices
authenticate
authorize
geo-based
queries
write-back,
geo add
APIs
primary
Data store
Geospatial and
Cached Data

Rate Limiting
Other Resources
APIs
Application
Rate Limiter
(Redis Counter)
Reduce backend
pressure

Graph & Search Integration
Logstash (Redis Channels, List)
Buffered
data
Application
Search & Log AnalyticsConnected Data
https://github.com/logstash-plugins/logstash-input-redis
BLPOP
Compliment Graph:
Geospatial ,
Aggregation ,
Cache
Ingest High Velocity

Cluster sizing best practices
• Storage—Clusters should have adequate memory
• Recommended: Memory needed + 25% reserved memory (for Redis) + some room for growth (optional 10%)
• Optimize using eviction policies and TTLs
• Scale up or out when before reaching max-memory using CloudWatch alarms
• Use memory optimized nodes for cost effectiveness (R5 support )
• Performance—Performance should not be compromised
• Benchmark operations using Redis Benchmark tool
• For more READIOPS—Add replicas
• For more WRITEIOPS—Add shards (scale out)
• For more network IO—Use network optimized instances and scale out
• Use pipelining for bulk reads/writes
• Consider Big(O) time complexity for data structure commands
• Cluster Isolation (apps sharing key space)—Choose a strategy that works for your workload
• Identify what kind of isolation is needed based on the workload and environment
• Isolation: No Isolation $ | Isolation by Purpose $$ | Full Isolation $$$

CloudWatch Monitoring
• Metric: BytesUsedForCache
• Resolution: scale up | out
• Metric: CacheHits / Metric: CacheMisses
• Aim for +80% Hits/Misses ratio
• Resolution: Optimize TTL & Cache Strategy
• Metric: CurrConnections
• Should be stable
• Resolution: Connection Pooling, Scale out
• Metric: EngineCPUUtilization
• Should not exceed 90% allocation,
• Resolution: Scale out
• Metric: Evictions > 1
• Metric: SwapUsage > few MBs
Lambda
Function
Alarm Topic

Redis max-memory policies
Select a max-memory policy based on your workload needs
• noeviction: return errors when the memory limit was reached and the client is trying to execute
commands that might result in more memory to be used.
• allkeys-lru: evict keys trying to remove the less recently used (LRU) keys first.
• volatile-lru: evict keys trying to remove the less recently used (LRU) keys first, but only among keys that
have an expire set.
• allkeys-random: evict random keys to make space for the new data added.
• volatile-random: evict random keys to make space for the new data added, but only evict keys with an
expire set.
• volatile-ttl: evict only keys with an expire set, and try to evict keys with a shorter time to live (TTL) first.
• volatile-lfu: evict least frequently used containing an expiration
• allkeys-lfu: evict any keys using least frequently used

Q&A

Lab Time
1. Login to your temp account: (You should have received your temporary account card)
2. Download the lab guide: http://bit.ly/reInventRedis
3. Make sure you are working in: US-EAST-2

Thank you!
https://aws.amazon.com/elasticache/
John Husemoller
@jdhusem
Matt Wolff
@matwolff
John Marciniak
@jomarcin
David Rodriguez
@rodzdavi
Michael Labib
@mlabib

Hands-On with Amazon ElastiCache for Redis - Workshop (DAT309-R1) - AWS re:Invent 2018

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Hands-On with Amazon ElastiCache for Redis - Workshop (DAT309-R1) - AWS re:Invent 2018

Similaire à Hands-On with Amazon ElastiCache for Redis - Workshop (DAT309-R1) - AWS re:Invent 2018 (20)

Plus de Amazon Web Services

Plus de Amazon Web Services (20)

Hands-On with Amazon ElastiCache for Redis - Workshop (DAT309-R1) - AWS re:Invent 2018