This content originally appeared on Level Up Coding - Medium and was authored by Lee James Gilmore
Serverless Caching Strategies — Part 2 (Amazon DynamoDB DAX) 🚀
How to use serverless caching strategies within your solutions, with code examples and visuals, written in TypeScript and the CDK, and with associated code repository in GitHub. Part 2 covering Amazon DynamoDB DAX.
Introduction
This is Part 2 of a number of articles covering serverless caching strategies on AWS, and why you should use them. Part 1 was a high level introduction to caching, and examples in TypeScript and the CDK for caching with Amazon API Gateway.
This part is going to cover caching at the database layer using DynamoDB DAX.
🔵 Part 1 of this article covered caching at the API layer using Amazon API Gateway.
🔵 Part 2 of this article looks at caching at the database level using DynamoDB DAX.
🔵 Part 3 of this article will look at caching within the Lambda runtime environment itself.
🔵 Part 4 of this article will look at caching at the AppSync level.
🔵 Part 5 of this article will look at caching at the CDN level with CloudFront.
This article is sponsored by Sedai.io
What are we building? 🏗️
As described in Part 1 of the series, this is what we are building out:
Serverless Blog ✔️
The serverless blog has the following flow:
⚪ A CloudFront distribution caches the React website which has an S3 bucket as its origin. We can cache the web app at this level.
⚪ The React app utilises a GraphQL API for accessing its data using AWS AppSync. For certain endpoints we may look to utilise AppSync caching.
⚪ The AppSync API resolves to DynamoDB through Lambda for its data, and we are using DAX as a cache sitting in front of the database. We can utilise DAX to cache at the database level here.
AWS News Blog ✔️
The AWS News blog has the following flow:
⚪ A CloudFront distribution caches the React website which has an S3 bucket as its origin. We can cache the web app at this level.
⚪ The React app utilises a REST API for its data using Amazon API Gateway. We have caching here at the API level within API Gateway.
⚪ For cache misses we use a Lambda function to retrieve the data from a Serverless Aurora database. We can also cache certain data within the lambda itself in this scenario.
💡 Note: this is the minimal code and architecture to allow us to discuss key architecture points in the article, so this is not production ready and does not adhere to coding best practices. (For example no authentication on end points). I have also tried not to split out the code too much so example files are easy to view with all dependencies in one file.
What is DynamoDB DAX? ✔️
As a reminder, Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for Amazon DynamoDB that delivers up to a 10 times performance improvement — from milliseconds to microseconds — even at millions of requests per second.
DAX does all the heavy lifting required to add in-memory acceleration to your DynamoDB tables, without requiring developers to manage cache invalidation, data population, or cluster management.
Now you can focus on building great applications for your customers without worrying about performance at scale. You do not need to modify application logic because DAX is compatible with existing DynamoDB API calls. Learn more in the DynamoDB Developer Guide.
Getting Started! ✔️
To get started, clone the following repo with the following git command:
git clone https://github.com/leegilmorecode/serverless-caching
This will pull down the example code to your local machine.
Deploying the solution! 👨💻
🛑 Note: Running the following commands will incur charges on your AWS accounts, and some services are not in free tier.
In the ‘serverless-blog’ folder of the repo run the following command to install all of the dependencies:
npm i
Once you have done this, run the following command to deploy the solution:
npm run deploy
🛑 Note: Remember to tear down the stack when you are finished so you won’t continue to be charged, by using ‘npm run remove’.
💡 Note: We use a CustomResource as part of the deploy to create the blogs table and populate it with some dummy data, so you can use it straight away.
Talking through key code 👊
How is DAX setup?
Amazon DynamoDB Accelerator (DAX) is designed to run within an Amazon Virtual Private Cloud (Amazon VPC) environment, as shown in the diagram below:
At runtime, the DAX client directs all of your application’s DynamoDB API requests to the DAX cluster. If DAX can process one of these API requests directly, it does so. Otherwise, it passes the request through to DynamoDB.
How does the lambda read the data from DAX?
Your application can access DAX by specifying the endpoint for the DAX cluster. The DAX client software works with the cluster endpoint to perform intelligent load balancing and routing. This is shown below for a get item in our Lambda which is accessed via an AppSync resolver:
“If the request specifies eventually consistent reads (the default behaviour), it tries to read the item from DAX. If the request specifies strongly consistent reads, DAX passes the request through to DynamoDB. The results from DynamoDB are not cached in DAX. Instead, they are simply returned to the application”
DAX can respond to the following API calls:
🔵 GetItem
🔵 BatchGetItem
🔵 Query
🔵 Scan
If the request specifies eventually consistent reads (the default behaviour), it tries to read the item from DAX:
🔵 If DAX has the item available (a cache hit), DAX returns the item to the application without accessing DynamoDB.
🔵 If DAX does not have the item available (a cache miss), DAX passes the request through to DynamoDB. When it receives the response from DynamoDB, DAX returns the results to the application. But it also writes the results to the cache on the primary node.
“If there are any read replicas in the cluster, DAX automatically keeps the replicas in sync with the primary node.”
How can we write the data to DAX?
The following DAX API operations are considered “write-through”:
🔵 BatchWriteItem
🔵 UpdateItem
🔵 DeleteItem
🔵 PutItem
With these operations, data is first written to the DynamoDB table, and then to the DAX cluster. The operation is successful only if the data is successfully written to both the table and to DAX.
How does the caching actually work?
DAX manages two separate caches, the item cache, and the query cache. They are both discussed below
Item Cache
DAX maintains an item cache to store the results from GetItem and BatchGetItem operations. The items in the cache represent eventually consistent data from DynamoDB, and are stored by their primary key values.
When an application sends a GetItem or BatchGetItem request, DAX tries to read the items directly from the item cache using the specified key values. If the items are found (cache hit), DAX returns them to the application immediately. If the items are not found (cache miss), DAX sends the request to DynamoDB. DynamoDB processes the requests using eventually consistent reads and returns the items to DAX. DAX stores them in the item cache and then returns them to the application.
The item cache has a Time to Live (TTL) setting, which is 5 minutes by default. DAX assigns a timestamp to every item that it writes to the item cache. An item expires if it has remained in the cache for longer than the TTL setting. If you issue a GetItem request on an expired item, this is considered a cache miss, and DAX sends the GetItem request to DynamoDB.
Query Cache
DAX also maintains a query cache to store the results from Query and Scan operations. The items in this cache represent result sets from queries and scans on DynamoDB tables. These result sets are stored by their parameter values.
When an application sends a Query or Scan request, DAX tries to read a matching result set from the query cache using the specified parameter values. If the result set is found (cache hit), DAX returns it to the application immediately. If the result set is not found (cache miss), DAX sends the request to DynamoDB. DynamoDB processes the requests using eventually consistent reads and returns the result set to DAX. DAX stores it in the query cache and then returns it to the application.
Testing the solution 🎯
How can we determine that the caching is working for scans?
We can see on the following example in CloudWatch that the Scan caching is working through our listBlogs query via AppSync:
This shows the caching on the scan call through DAX (25+ cache hits):
and we can see here that we have one cache miss which is the first call as the cache is empty when this happens:
How can we determine that the caching is working for get items?
We can use the AppSync console to perform a query on an individual item using the getBlog query:
This shows the caching on the getItem call through DAX from the Lambda resolver (18 cache hits):
and we can see here that we have one cache miss which is the first call as the cache is empty at this point:
What are the advantages and disadvantages?
So now that we have covered what DAX is, how it works, and how to configure and test it; what are the advantages and disadvantages of DAX?
Advantages
🔵 DAX as a cache can deliver up to a 10 times performance improvement — from milliseconds to microseconds — even at millions of requests per second.
🔵 It has the same API as the SDK DocumentClient meaning there are no code changes required to use DAX as a cache for DynamoDB.
🔵 Developers don’t need to manage cache invalidation, data population, or cluster management.
🔵 DAX lets you scale on demand. You can start with a three-node DAX cluster, and then add capacity by adding additional nodes. DAX lets you scale out to a 10-node cluster, giving you millions of requests per second.
🔵 No need to worry about management tasks such as hardware or software provisioning, setup and configuration, software patching, operating a distributed cache cluster, or replicating data over multiple instances as you scale.
Disadvantages
🔵 It is a non serverless AWS service, i.e. this will not auto scale and you need to decide on the amount of nodes in the cluster and the instance type.
🔵 You need to understand caching consistency behaviours, and ensure your application code works as expected: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html
🔵 DAX requires that you put it into a VPC, which means potential re-architecture of your solutions to use it (i.e. you may not have your lambdas attached to private subnets and don’t use VPCs for your solution).
Summary
I hope you found that useful!
Go and subscribe to my Enterprise Serverless Newsletter here for more of the same content:
Enterprise Serverless 🚀 | LinkedIn
Wrapping up 👋
Please go and subscribe on my YouTube channel for similar content!
I would love to connect with you also on any of the following:
https://www.linkedin.com/in/lee-james-gilmore/
https://twitter.com/LeeJamesGilmore
If you found the articles inspiring or useful please feel free to support me with a virtual coffee https://www.buymeacoffee.com/leegilmore and either way lets connect and chat! ☕️
If you enjoyed the posts please follow my profile Lee James Gilmore for further posts/series, and don’t forget to connect and say Hi 👋
Please also use the ‘clap’ feature at the bottom of the post if you enjoyed it! (You can clap more than once!!)
About me
“Hi, I’m Lee, an AWS Community Builder, Blogger, AWS certified cloud architect and Principal Software Engineer based in the UK; currently working as a Technical Cloud Architect and Principal Serverless Developer, having worked primarily in full-stack JavaScript on AWS for the past 5 years.
I consider myself a serverless advocate with a love of all things AWS, innovation, software architecture and technology.”
*** The information provided are my own personal views and I accept no responsibility on the use of the information. ***
You may also be interested in the following:
Serverless Caching Strategies — Part 2 (Amazon DynamoDB DAX) 🚀 was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Lee James Gilmore
Lee James Gilmore | Sciencx (2022-01-20T16:40:16+00:00) Serverless Caching Strategies — Part 2 (Amazon DynamoDB DAX). Retrieved from https://www.scien.cx/2022/01/20/serverless-caching-strategies%e2%80%8a-%e2%80%8apart-2-amazon-dynamodb-dax/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.