The course is part of these learning paths
Amazon ElastiCache Service
This is a beginner level course intended for anyone who is interested in learning the basics about the Amazon ElastiCache Service. We will discuss the concept of caching and how it relates to the Amazon ElastiCache service. We will define and discuss ElastiCache. We will talk about the benefits of the service. Then we will talk about ElastiCache features. Next, we will talk about why we would use ElastiCache. And finally, we will discuss how to locate ElastiCache in the AWS console and describe the basic steps for setting it up. This course was authored by Sarah Blatnik and narrated by Mark Thomas.
About the Author
Sarah is an educator and instructional designer. She started her career doing computer training, Microsoft Certified training, then telephony training for a local Indianapolis start up. She has a passion for helping others to learn and writing engaging content. When she is not working, she loves to travel with her family, walk her dog, or curl up somewhere with a good book.
In this next section, we'll describe the Amazon ElastiCache Service and talk about how and why we should use it. So, what is ElastiCache? By definition, Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory data store or cache in the cloud. This service improves the performance of web applications by allowing you to retrieve information from fast, managed in-memory data stores, instead of relying entirely on slower, disk-based databases. So, what does that mean? Let's take a look at caching, and then expand our discussion to in-memory caching environments in the cloud.
Let's start out by discussing a basic caching concept. Think about your own computing devices. If you need more space to store your files, applications, and so on, you buy a larger hard drive. The hard drive is for items that you need to keep. They are persistent, however, even if you keep adding hard drive space, your computer may not seem to get faster. In fact, it may appear slower as you keep opening all of your new files and applications. How do we make the computer perform faster and serve up our information more quickly? We add RAM, more memory. Why do we do this? So that the computer can store frequently accessed information in memory instead of having to run to the disk for the information.
Now, let's take this analogy and relate it to how a web application uses in-memory caching. To be clear, ElastiCache is not just used for web applications. It can be used for any application that can benefit from increased performance using in-memory cache. But we're going to use a web application for our example. A common scenario is to have a web application that reads and writes data to persistent storage, like a relational database or NoSQL or MySQL, and so on. However, persistent storage, like hard disk storage tends to experience some fluctuations in latency as each piece of data needs to be written to or retrieved from a permanent media store. This can affect overall performance. This is where an in-memory cache is useful. It's generally used to improve read-only performance. Many websites get a high percentage of read hits, but less write hits. An in-memory cache can store frequently accessed read-only information, and serve it up much more quickly than having the application continually request it from a persistent data store. This diagram shows a very simple web app solution. Now imagine that your app becomes more popular, and you need to scale up. Adding more web servers is not that difficult. But vertically scaling a persistent data store, such as a relational database, is usually more complicated. That is where an in-caching layer can really make a difference. You can add more web servers and ElastiCache can automatically grow your caching layer based on the increased demand. This can eliminate or reduce the need to scale-up on your persistent data store.
By now, you might be asking, how is ElastiCache being used today? Some common uses for ElastiCache are online gaming applications, where it's important the game code presents information, like the scoreboard, as quickly and as consistently as possible to all the players of the game. Social networking sites, where we need a way to store temporary session information, and session management. Q and A sites, where some articles are very popular, and therefore are requested a lot. And recommendation engines, when we want the data sets that make up the recommendation presented quickly to a large number of users. As you can see, these are applications that have lots of read-only content, that would benefit from an in-memory cache. Oftentimes, users are scanning these websites for information like, who currently has the high score in a game, what are your friends up to, looking for how-tos or guidance on the best restaurant. Obviously, there is information written to these sites as well, like when something is updated or changed, so that information would be sent to a permanent data store. By the way, in-memory caching is not limited to read-only. An application developer may want to store write data using in-memory cache, which is also supported using ElastiCache. It's just less common. So our lesson is focused on read-only caching.
Now we've discussed when ElastiCache is a great solution. But when is it best to consider using something else? ElastiCache should never be used to store your only version of data records since a cache is designed to be a temporary data store. So, when data persistence is necessary, like when working with primary data records, or when we need write performance, rather than read performance, a persistent data store should be used instead of ElastiCache.
Amazon ElastiCache can be a very useful tool for developers. Application developers are always looking for ways to ensure the best performance and availability for their application. Databases and other permanent storage options are relatively slow. Users are impatient today. Waiting a few more seconds for an app to respond can mean losing business to a competitor. Developers are thrilled when an app becomes popular. But then there is the challenge of scaling. Adding front-end support, like more web servers, is fairly simple, but when it comes to scaling persistent storage, it starts getting complicated and messy. Then there are a number of management tasks to consider. Updating, patching, monitoring, and securing data takes time. Using ElastiCache allows the developer to focus on building and improving apps by simplifying and reducing administrative tasks.
Now that we have a better understanding of what the ElastiCache service is, let's look at the product features. Adding an in-memory caching layer using ElastiCache can increase performance by responding much more rapidly than a persistent data store, and more easily allow the application to scale as the application grows. And ElastiCache supports both Memcached and Redis, so existing applications can be easily moved to ElastiCache. But why would you consider the Amazon ElastiCache service over running version of Redis or Memcached on your own servers? The core benefit of using ElastiCache is that it's a managed service. That means that configuration is simplified. The ElastiCache management console allows you to create new nodes with just a few clicks. A cache node is a fixed sized chunk of secure, network-attached RAM, essentially the building block of the ElastiCache service. It also supports a clustered configuration. Clusters are a collection of one or more cache nodes. Once you've provisioned a cluster, Amazon ElastiCache automatically detects and replaces failed nodes, which helps reduce the risk of overloaded databases and therefore, reduces the website and application load times. Without ElastiCache, the tasks of managing the underlying infrastructure, like scaling, patching, and so on, will need to be done by you. Securing the data also falls upon the developer when they're using Memcached or Redis, but ElastiCache can make use of AWS and Virtual Public Cloud security features to protect the data.
To give you a general idea of the capabilities of both the supported caching store engines, we've compiled a list here, but we're not going to go through each item. In broad terms, Redis has more features, whereas Memcached is often recognized for its simplicity and speed of performance. Memcached really suits workloads where memory allocation is going to be consistent, and increased performance is more important than the additional Redis features. Often, the choice between the two comes down to memory and how you expect to use it.
So, how do I find ElastiCache? Amazon ElastiCache can be found in the AWS Management Console at aws.amazon.com. Once you log into the console, look for the Database options and select ElastiCache. From the ElastiCache Management Console, you have the option to create a cluster using the Memcached or Redis engine. Authorize and connect to Clusters, and manage your clusters. Add resources. Modify configuration settings and monitor your ElastiCache environments. Choosing the default configuration values will generally suffice to start getting familiar with the ElastiCache service.
Now, let's take a look at a scenario to get a better understanding of how ElastiCache really works. Let's imagine we manufacture motorcycles, and we have a website that provides support information about the range of motorcycles that we sell worldwide. We've sold five million motorcycles since 2010. Our support website usually receives around 100 thousand hits a day, generally from people looking for information about the specifications of our motorcycles and user guides. One day, a fault is reported in a hose pipe, commonly used in motorcycle engines. Anyone who has a motorcycle wants to verify that their bike does not use this hose pipe. Luckily, our motorcycles do not use the faulty hose pipe, and we put out a press release stating that fact. However, we fear the worst, since last year a similar fault was announced and our website crashed when two million customers checked our website for information about the fault. This time, our website received seven million views, however, the website was able to respond and deliver on those requests, because after the site crashed last year, we implemented Amazon ElastiCache between the web server and the MySQL database, to cache website-based content. Now when the web server requests the press release page, the content of that page is delivered out of Amazon ElastiCache, reducing the amount of time it takes the web server to display the press release by removing the need for the web server to request the press release page content from the MySQL database.