Getting Started with Amazon ElastiCache

Editor's Notes

1. Device Fragmentation [click] Does anyone bother making phone calls from their phone anymore? (RAISE HAND) Yeah it’s all text and email. [click, click] The takeaway point here is that the rendering is drastically different but the data is the same – whether you’re Logging into Facebook on your phone or laptop or tablet, you’d syncing with your friends, posting updates, what have you. This means that the arguably naive strategies from years past of caching the rendered HTML page don’t work – not only do We have PC website views, we have mobile apps, JSON API’s, and so on that all use the same data [click] And CDN’s are great and definitely an important piece of the puzzle…. (pause) [click] but the problem is most pages have a mix of static slash global content, and a mix of “Welcome Back Cotter!” across the top Along with “You have 5 new pokes” =>
2. Device Fragmentation [click] Does anyone bother making phone calls from their phone anymore? (RAISE HAND) Yeah it’s all text and email. [click, click] The takeaway point here is that the rendering is drastically different but the data is the same – whether you’re Logging into Facebook on your phone or laptop or tablet, you’d syncing with your friends, posting updates, what have you. This means that the arguably naive strategies from years past of caching the rendered HTML page don’t work – not only do We have PC website views, we have mobile apps, JSON API’s, and so on that all use the same data [click] And CDN’s are great and definitely an important piece of the puzzle…. (pause) [click] but the problem is most pages have a mix of static slash global content, and a mix of “Welcome Back Cotter!” across the top Along with “You have 5 new pokes” =>
3. Speaking of Real Time Performance, let’s look at data from the biggest Entertainment event of the Year: the American Football Superbowl This chart shows US mobile app usages during the Super Bowl 50 (Broncos v. Panthers played in the heart of Silicon Valley in Santa Clara, CA). Super Bowl 50 proved to be the most mobile of all Super Bowls to-date. Viewers watched with their smartphones in hand more so than any given Sunday* or previous Super Bowls on record.   While the Denver Broncos took the Vince Lombardi Trophy in the end, the real winner of Super Bowl 50 was halftime guest performer Beyonce, whose two minute solo contribution commanded the most undivided viewer attention over the four hour game.    As they’ve done in years past, Flurry Analytics (Yahoo) examined app usage activity during The Big Game. In this data, we analyze how what was happening throughout the game, affected viewers’ engagement with their phones.   Before the start of Coldplay’s halftime performance during the NFL’s halftime commentator report, we observed a spike in app activity, but Coldplay’s initial solo act (and then addition of Bruno Mars) brought smartphone activity back down to Super Bowl 50 average. Only when Beyoncé joined the performance did viewers put their smartphones down, with our session index dropping the lowest throughout the game.  Viewers immediately re-engaged with their smartphones at 5:39pm when Coldplay retook the stage alone. One can say that anticipation and excitement for Beyoncé, due to her previous Super Bowl performance and the release of her new song, Formation, the day before the game, piqued viewer interest. While both years’ halftime performances commanded viewers’ attention, Katy Perry in 2015 initial appearance immediately prompted viewers to put their smartphones down, but attention eased while her act when on. While 2016 headliner Coldplay slowly engaged the audience, it was Beyoncé’s guest appearance that cut mobile usage by a third (33.8% decrease) during her mere two minutes on-screen. Spikes in activity result in increases on the load on your application, and this when users expect Apps to perform the most. When something interesting is happening. We are seeing such cases all the time, spikes as a result of a sports event, a celebrity mentioned your app in an interview and all of a sudden the number of users increased 1000x. We see such cases all the time. And your application needs to be ready for it. If you are provisioned for the steady state in your database layer, when a spike comes your app might become slow or even crash. And we want to avoid that.
4. More of a noSQL db in memory – FAST Single threaded – but generally fast enough that it doesn’t matter – gives way to some neat things – gives the feel of a mostly ACID compliant noSQL DB Read-replicas (in replication group) - can promote Supports backups and restore Supports data types
5. Device Fragmentation [click] Does anyone bother making phone calls from their phone anymore? (RAISE HAND) Yeah it’s all text and email. [click, click] The takeaway point here is that the rendering is drastically different but the data is the same – whether you’re Logging into Facebook on your phone or laptop or tablet, you’d syncing with your friends, posting updates, what have you. This means that the arguably naive strategies from years past of caching the rendered HTML page don’t work – not only do We have PC website views, we have mobile apps, JSON API’s, and so on that all use the same data [click] And CDN’s are great and definitely an important piece of the puzzle…. (pause) [click] but the problem is most pages have a mix of static slash global content, and a mix of “Welcome Back Cotter!” across the top Along with “You have 5 new pokes” =>
6. So what is it that ElastiCache can do for you? We have divided the benefits into 6 main categories. Of course this is an overview, and we will go into more detail on the key features later in this webinar. But these are the value categories on a high level: Extreme performance – We covered this in previous slide, that ElastiCache is the service you use for the fastest data. So we have optimized and tuned ElastiCache from the binaries all the way down the stack to the OS and the customer dedicated nodes. Open source compatible – all the powerful capabilities of Memcached and Redis are available within ElastiCache. We are fully compatible with open source, thus there is no lock-in, it is easy to take an existing application code and just move it from self-managed Redis/Memcached to ElastiCache. And it is just as easy to move out. Fully Managed. You no longer need to worry about management tasks such as hardware provisioning, software patching, setup, configuration, monitoring, failure recovery, and backups. Amazon ElastiCache automatically and continuously monitors your ElastiCache clusters, taking the necessary action to keep your environment up and running so you could focus on higher value application development. Secure and Hardened – security is always #1 priority at AWS and ElastiCache is no different. Both in terms of securing access to your data through things like VPC and IAM, and also monitoring your nodes and applying security patches whenever necessary. Highly Available and Scalable – we will cover this part in more detail later in this webinar, ElastiCache provides high availability to your Redis data so that in case of node failure your data is retained and available for access. Cost effective – when you compare running a self-managed EC2 instance of Redis for example vs. ElastiCache for Redis, the price difference for a month of ownership of r3.large, a fairly large node type, is $20-$40, a month. This is 30 minutes time of a devops or software engineer, a month. And that already includes the cross-availability-zone data transfer traffic in replicated environment. The reason we can offer such service so cost effectively is the economies of scale that we are able to leverage.
7. For going to production, we'll want to use Redis Multi-AZ capabilities. This is one example of where Redis and Memcache are managed quite differently. With Redis Multi-AZ, we attach one or more replicas, in different AZ's, and then ElastiCache will automatically failover if the primary has an issue. Replication bandwidth is free.
8. Looking at it in the context of our application, we have Redis nodes in two AZ's. The primary is in availability zone A, it can be used for both reads and writes, while the node on the right is a read only replica. Let’s see what happens if there is a primary node failure.
9. In the event the Primary node fails, ElastiCache will detect this, select the most up to date replica and promote it to primary. Then, it will update the Primary DNS endpoint to point to the replica node. This is an important part. For a replication group with one primary and one replica, ElastiCache will have 3 endpoints, 2 individual ones and one persistent primary endpoint that always points at the primary. So when we propagate the primary endpoint to now point at the newly promoted primary, that means you don’t need to update the endpoint in your application.
10. This slides shows exactly that. Once failover is complete, the App will be able to reconnect to new Primary endpoint, which is the node on the right.
11. Finally, ElastiCache will replace the failed node with a new node and re-sync it to the replication group. At the end of this process, you will have one primary and one replica fully functioning, just like before the failure occurred. One thing to notice is that now your primary will be in a different availability zone. We do not automatically failover again to return your primary to the original availability zone because we don’t want to cause any unnecessary interruptions to your app. However you can manually select to promote any replica to primary if you so choose.
12. Device Fragmentation [click] Does anyone bother making phone calls from their phone anymore? (RAISE HAND) Yeah it’s all text and email. [click, click] The takeaway point here is that the rendering is drastically different but the data is the same – whether you’re Logging into Facebook on your phone or laptop or tablet, you’d syncing with your friends, posting updates, what have you. This means that the arguably naive strategies from years past of caching the rendered HTML page don’t work – not only do We have PC website views, we have mobile apps, JSON API’s, and so on that all use the same data [click] And CDN’s are great and definitely an important piece of the puzzle…. (pause) [click] but the problem is most pages have a mix of static slash global content, and a mix of “Welcome Back Cotter!” across the top Along with “You have 5 new pokes” =>
13. In your app, then, you will need to configure two separate sets of handles: One for writes, and one for reads. Then you will need to make choices as to where you could display data that is very slightly delayed. Not, in practices, we're talking tens of milliseconds max, and usually less. But if a person is editing their profile, and then clicks save, and you read it from a replica, it could display their old information, which would be very confusing. The rule of thumb I say is that
14. Device Fragmentation [click] Does anyone bother making phone calls from their phone anymore? (RAISE HAND) Yeah it’s all text and email. [click, click] The takeaway point here is that the rendering is drastically different but the data is the same – whether you’re Logging into Facebook on your phone or laptop or tablet, you’d syncing with your friends, posting updates, what have you. This means that the arguably naive strategies from years past of caching the rendered HTML page don’t work – not only do We have PC website views, we have mobile apps, JSON API’s, and so on that all use the same data [click] And CDN’s are great and definitely an important piece of the puzzle…. (pause) [click] but the problem is most pages have a mix of static slash global content, and a mix of “Welcome Back Cotter!” across the top Along with “You have 5 new pokes” =>
15. ElastiCache works great in front of a database hosted in Amazon RDS, or A self-managed database running in Amazon EC2 So common design patterns in use cases that we see… Emphasize the caching layer on DBs The most common one we is as a cache. Historically, Memcached been the most popular caching option and continues to be popular because of its simplicity, high performance ,and scale-out capabilities. However, we see the caching space has been evolving over the past few years and now see Redis as also a good caching option. This allows your solution to be much more scalable and responsive on the front by having a low latency path to application data without having to go to the backend database. The main benefit here is that you can independently scale your front end to cater to a spiking loads without having to grow the costlier backend database. I would like to emphasize that dealing with spikey loads is not only about ensuring lower latency but often to be able to handle a very high request rate for which a cache is perfect especially for Ad-tech / gaming use cases. Ephemeral key-value data Web session management Leaderboards come up often. Users are having rapid interactions with a site , for example in Gaming use cases, and rather than deal with a round trip latency with a database every time, operating out of the cache is more convenient. One thing to remember is that typically you do want to provide persistence for this user state and want to manage that at the application level. But you can do that asynchronously. Here you use ElastiCache Redis to get response time and high request rates and use the backend database for persistence if not doing using ElastiCache Redis. In addition, you also track key statistics of the entire user base in Redis and order users. High speed sorting is the other one we see. Here you have a set of key/values and you want to order them across various dimensions that can change on demand. Typically the value here is a pointer to the actual object so this behaves as an index Distributed Counters is also a popular design pattern. You may want to keep track of an event occurrence throughout a day. Redis bitmaps are ideal for this and are also space efficient. For queuing support Redis allows push and pop from a list. A related design pattern is to use Redis PubSub which allows you to implement messaging between applications. Publish allows you to push a message to a channel and subscribe listens on a channel. Lastly, a common pattern is track a stream of events or activity stream that a user may like to monitor. Redis lists are good for this. You can list sizes using LTRIM and get the most recent list items using LRANGE.
16. Another cool application is rate-limiting, either for building or consuming an API. You can use a Redis counter, associated with a client's API key, to count the number of accesses within a certain time period. And if a limit is exceeded, then you just reject that request
17. Lets take another look at the streaming data use-case. When your streaming time-series data, typically you are most concerned with the most active data. Amazon ElastiCache for Redis provides a high availability solution enabling automated failover. In the event you want to persist data with longer retention periods. Amazon DynamoDB may be a good option and provides consistent single-digit millisecond latency. Data stored in DynamoDB is replicated across 3 storage facilities providing high durability and availability. This could also be Amazon RDS. You might also have an application hosted on EC2 that acts as a dashboard to runs analytics on your Redis cluster and query the data.
18. You can also use Redis counters and hashes to model items like & dislikes for a recommendation engine. When a user likes an item, you can increment that item's total number of likes, and then also store that item in the history of that user's ratings. From there, you can use