Working of DAX ( DynamoDB Accelerator) Part- 1

DAX and DynamoDB

Let's understand how DAX and DynamoDB are related to each other.

Major problems encountered while utilizing AWS DynamoDB databases include validating cached data and data population. AWS offers an entirely managed in-memory cache known as DynamoDB Accelerator or DAX. The response time to queries is halved, thanks to DynamoDB Accelerator in AWS, going from milliseconds to microseconds.

Amazon Virtual Private Cloud is where DynamoDB Accelerator is hosted on AWS. A virtual private cloud (VPC) aids in the creation of a virtual network and manages security, IP access, networks, routings, etc. A DAX cluster must be set up inside the VPC. When building the cluster inside a VPC, AWS may use the default VPC or accept our specification.

How does DAX Work?

• To execute an application code, we utilize an AWS EC2 instance.
• In this EC2 instance, the DAX Client and the application code are both started.
• DAX client facilitates communication between the EC2 instance and the DAX Cluster inside the VPC.
• Client requests for certain CRUD operations are forwarded to the DAX Cluster by the DAX Client.
• The DAX Cluster answers the request, and the application sends the response back to the client. Otherwise, if the DAX cluster cannot reply, the requests are passed on to the Amazon DynamoDB database, which replies and returns the result to the client via the same route.

DAX Clusters

A logical collection of nodes is known as a DAX Cluster which works as a single entity.

• It consists of a primary database, also known as the source database, and additional read replicas, which are copies of the original database and are only able to read data. In other words, only read requests can be fulfilled by read replicas.
• The primary node responds to all write requests and serves requests made to the cache cluster.
• Ideally, the production environment should include at least three nodes, each of which is situated in a distinct availability zone. This improves the DAX Cluster's data storage availability and reliability.

Managing DAX Clusters

Let's understand how to manage the DAX clusters. We follow these common management tasks to understand them.

• IAM permissions for managing a DAX cluster
• Scaling a DAX cluster
• Customizing DAX cluster settings
• Configuring TTL settings
• Tagging support for DAX
• AWS CloudTrail integration
• Deleting a DAX cluster

IAM Permissions for Managing DAX Cluster

We should restrict what people can do when managing a DAX cluster using the AWS Management Console or the AWS Command Line Interface (AWS CLI). It will conform with the principle of least privilege and assist in risk mitigation.

Let's see an example of the approach to include both DAX management APIs and DAX data plane APIs in the IAM policy.

We can modify the policy as per our need for the application.

Scaling a DAX Cluster

In DAX clusters, two scaling options are present. They are:

• Horizontal scaling - In this scaling option, we can add read replicas to the cluster. It will increase throughput for read operations. We can add up to 10 read replicas in a single DAX cluster, and these replicas can be added or removed while the cluster is active.
• Vertical scaling - We can select different node types in this scaling option. The application might profit from using larger node types in a large working set of data. Larger nodes help the cluster store more data in memory, which lowers cache misses and boosts overall application performance.

Customizing DAX Cluster Settings

The following default settings are used while building a DAX cluster:

• Automatic cache eviction enabled with Time to Live (TTL) of 5 minutes
• No preference for Availability Zones
• No preference for maintenance windows
• Notifications disabled

We can customize the setting for new clusters at the creation time. Clear the Use default settings to modify Network and Security, Parameter Group, and Maintenance Window. We can modify the Parameter Group and Maintenance Window on a running cluster when necessary.

Configuring TTL Settings

TTL stands for Time-To-Live, which represents the time for which the data will remain intact. The TTL for both the item cache and query cache is 5 minutes by default. We can change the default TTL using AWS CLI by creating a custom parameter group. Follow the given steps in the AWS CLI to configure TTL settings.

1. First, we must create a new parameter group using the given command.

2. Next, we can set the time to live for the item cache using the command given below. Here we are setting the TTL as 10 minutes, equal to 600000 milliseconds, so we have used 600000 in the command.

3. We can also set the time to live for the query cache using the command given below. Here we are setting the TTL as 10 minutes, equal to 600000 milliseconds, so we have used 600000 in the command.

4. Now, we can verify if the parameters have been set correctly using the following command.

5. Now, the parameter group we created can be used to launch a DAX cluster with the configured TTL settings.

Tagging Support for DAX

Tagging helps in identifying and working on a given set of clusters. To add tags to the DAX clusters, we can use the following command:

We tag the cluster with the ClusterUsage value as prod using the above command. We can also untag a DAX cluster using the following command, where we need to specify the key for removing the associated tag.

AWS CloudTrail Integration

AWS provides the feature to integrate DAX with AWS CloudTrail. It helps monitor cluster activity and see every change done at the cluster level using the CloudTrail logs. We can see changes to nodes, subnet groups, and parameter groups in the cluster's components. We can easily track DAX cluster activity with the help of AWS CloudTrail integration.

Deleting a DAX Cluster

We can delete the DAX cluster if it is no longer needed to avoid extra charges. We can easily delete the DAX cluster using the command:

aws dax delete-cluster --cluster-name mydaxcluster

The cluster name can be replaced with the name of your DAX cluster.

DAX Cluster Sizing Guide

The DAX cluster sizing guide provides you assistance in choosing the right node size and node type for your DAX cluster instances. The sizing guide estimates the traffic incoming to your DAX cluster and, based on that, provides suggestions on the type of node which will be helpful. The entire decision is derived based on the following steps:

• Traffic Estimation: Under this step, an estimation is made on the amount of traffic the application will send to the DAX. It also predicts the number of read and writes operations to be executed by DAX.
• Load Testing: Under this step, we need to create a cluster and send traffic to it. Based on the traffic estimations made in the previous step, the requests are sent to the cluster, the response is analyzed, and the suitable cluster configuration is found.
• Monitoring the Production: As the workload keeps changing, we need to monitor our cluster in production and scale accordingly constantly.

DAX T3/T2 Burstable Instances

While working with DAX, you can choose the type of instance you want to use. You can either use fixed performance instances, for example, R3 and R4, or burstable instances, for example, T2 and T3. Burstable instances provide a baseline or basic level of CPU whose capacity can be improved or burst when needed, hence the name burstable.

How do Burstable Instances Work?

The ability of the burstable instances to burst depends on the CPU credits. The burstable instances keep on accumulating CPU credits whenever the capacity being used by the workload is less than the Baseline level of the CPU of the instances. The CPU credits also depend on the size of the instance.

Whenever the workload of the burstable instances increases, the CPU credits become helpful. The credits can be used to increase performance. A single CPU credit can increase the performance to a full CPU core for one minute.

DAX T2 Instance Family

• These are general-purpose instances capable of extending the performance capacity of the instances beyond the baseline value.
• DAX T2 Instances are the right choice when using instances for testing and development environments, i.e., when we need price predictability.
• Under the standard mode of the DAX T2 Instance, the CPU utilization is lowered to baseline when the accumulated credit count decreases.
• For more info on the standard mode of DAX T2 Instance, refer here.

DAX T3 Instance Family

• DAX T3 Instances are next-generation burstable instances, with the capability to burst the capacity anytime and for as long as needed.
• Unlike DAX T2 Instances which are configured in standard mode, the DAX T3 Instances are configured in unlimited mode.
• Under the unlimited mode of DAX T3 Instances, they can burst the performance capacity beyond the baseline for around 24 hours with additional cost. They can continue to serve for whatever time is needed by the workload, although some additional charges are involved.
• For more info on the unlimited mode of DAX T3 Instance, refer here.

Using Service-Linked IAM Roles for DAX

Service-linked roles are special IAM roles that can be used to connect directly to the DAX cluster. They are predefined and can be used to access all the resources included within the cluster and perform any associated actions. It contains all the permissions required for accessing resources and executing tasks within the cluster.

Service-Linked Role Permissions

AWSServiceRoleForDAX is the Service-Linked Role used by DAX to perform actions that are to be performed by the DAX cluster. We can use the following statements to create a service-linked role for DAX and associate it with an IAM entity.

Creating Service-Linked Role

Creating a service-linked role does not require manual intervention, as it gets automatically created when you create the DAX cluster. But you might need to create one if you delete the service-linked role, which was created automatically at the time of cluster creation.

Editing Service-Linked Role

You do not have permission to edit the AWSServiceRoleForDAX service-linked role. You are also not allowed to change the name of a service-linked role after creation, as various entities might reference the role.

Deleting Service-Linked Role

If you think a particular service-linked role is useless, you can delete that role. But before deleting a role, you must delete all the DAX clusters referencing that role.

Accessing DAX Across AWS Accounts

Suppose you work in a team, and your friend created a DAX cluster under his account. You launched a new EC2 instance in your account and want to connect with the DAX cluster in your friend's AWS account. Can this be achieved?

Yes, we can access DAX across AWS accounts by following the steps given below:

Setting up Identity Access Management

Instead of carrying out the steps on the AWS Management Console, we are using AWS CLI to avoid changing tabs and searching for buttons for every action.

1. We will create a JSON file named AssumeDaxRoleTrust.json. The content of this JSON file functions in a way that the manual tasks can be done by using an Amazon EC2 instance.

2. In the second account (our account, if we take reference of the previous example), we will create an IAM role using the following command to launch EC2 instances:

3. Create another JSON file named AssumeDaxRolePolicy.json. This file allows the crosslink between two accounts say A and B. It allows the code running in the Amazon EC2 server of account B to access an IAM role in account A. In the JSON file, replace the accountA_ID with the actual ID of account A.

4. To the newly created role, we will add the IAM policy using the following command:

5. To allow the EC2 instances to use the newly created IAM roles, we need to create instance profiles using the below command. AssumeDaxInstanceProfile can be replaced with any name you want to give to your Instance profile.

6. Now, we will attach the IAM role to the instance profile using the following command:

7. Next, we need to create another JSON file with the name DaxCrossAccountRoleTrust.json. You can use other names as well. This JSON file allows role assumption from account B to account A. In the JSON file, replace the accountB_ID with the actual ID of account B.

8. Within account A, we will create another IAM role, assuming account B, using the following command.

9. We will create another JSON file named DaxCrossAccountPolicy.json. This helps the specified Amazon Resource to access the DAX Cluster.

10. Next, in account A, we will use the following command to add the policy which allows access to the DAX cluster to the IAM role.

Setting Up a Virtual Private Cloud

1. First, we will find the subnet group of the DAX cluster using the following command. Here, replace cluster-name with the name you provided to your DAX cluster.

2. Now, the query returns the subnet group. Using this subnet group, we will find the VPC to which the DAX cluster belongs.

3. The above query returns the VPC_ID. We will use the VPC_ID to run the following command and get information about the CIDR associated with the VPC.

4. Now, as we know the CIDR from account B, we will create a new VPC with a non-overlapping CIDR. Within the VPC, we will create at least one subnet.
5. Now, we will use a VPC peering connection to connect the VPCs. Here we will request the connection from account B and accept the connection request from account A. For more details on this step, refer here.
6. Now, in account B, we will locate the routing table of the newly created VPC using the following command. In the command below, replace the value vpc-id with the original VPC ID associated with the new VPC created in account B.

7. We will use the following command to route traffic to the destination VPC's CIDR. Make sure to replace all the IDs mentioned with the correct ID and CIDR.

8. In the previous steps, we found the VPC ID of the DAX cluster. We will use that VPC ID to find the route table ID of the DAX cluster using the following command.

9. Now, we will update the routing table of account A using the route table ID to route traffic to account B using the command specified below.

10. Next, we can launch EC2 instances in the VPC of account B and add the instance profile AssumeDaxInstanceProfile to it.
11. Next, we need to find the security group of the DAX cluster present in account A. The following command is helpful:

12. We will now update the DAX cluster's security group to allow traffic incoming from account B's EC2 instances.

The EC2 instances launched in account B, which has the instance profile attached, can now access the DAX cluster.

Modify the DAX Client

Some temporary credentials are generated using AWS Security Token Service (AWS STS) to allow cross-account access. Some additional coding is required to automatically refresh the credentials without having to configure it each time.

The code can be written in integration with the application code in multiple languages like Java, .NET, Go, etc. Here we will learn to modify the DAX Client using Python.

1. First, we will import the boto3 module, which allows the AWS commands to be executed within Python code. To import the module, use the command: import boto3.
2. Next, we will create an AmazonDaxClient object by using temporary credentials provided by AWS STS. Make use of the following command by updating the credentials.

We can connect to the DAX cluster on another account by including the above code in our application code.

DAX and DynamoDB Consistency Models

DAX helps simplify the process of adding cache to the DynamoDB tables. This might affect the consistency of the tables, so we need to have an idea of the consistency models followed by DAX and DynamoDB.

Consistency Among DAX Cluster Nodes

• To ensure high availability, we generally have at least three nodes in each DAX cluster. The nodes are distributed across the different Availability Zones within a given region.
• The updates are made to all the nodes of the cluster.
• Suppose you update an item in the cache memory. The data of the primary node is updated, which is then replicated across all other nodes of the DAX cluster.

DAX Item Cache Behavior

For an item cached in the DAX cluster, the read and write operations are dealt with differently.

• Read Consistency: GetItem is used to perform the read operations. Suppose you use the UpdateItem operation to update some database tables on DynamoDB. If you try to read the data immediately after this, you might not be able to see the update due to propagation delay. Usually, it takes some seconds to update the table on all the database instances of the cluster.
• Write Consistency: DAX client supports all the write operations like PutItem, UpdateItem, DeleteItem, BatchWriteItem, and TransactWriteItems.

DAX Query Cache Behavior

• The results returned as part of the Query and Scan operations are stored in the query cache.
• The query cache is stored separately from the item cache, and they do not affect each other.
• Any updates made in the item cache or DynamoDB table do not make any changes to the query cache.

Strongly Consistent and Transactional Reads

• The operations need to be consistent across all the instances in the DAX cluster to avoid the presence of different information across each instance of the cluster.
• Strongly consistent requests can be made for the following operations / requests:
  • GetItem
  • BatchGetItem
  • Query
  • Scan
• To perform strongly consistent requests, we need to set the ConsistentRead parameter to true.
• The TransactGetItems requests are also handled similarly as consistent reads.

Negative Caching

• When DAX cannot find a response related to a particular request in the DynamoDB table, no valid data is received to store in the cache. This is called negative caching.
• DynamoDB Accelerator supports negative caching both in query cache and item cache.
• Under this, DAX returns an empty result instead of throwing an error. The user receives the empty result.

Strategies for Write

• DAX uses write-through behavior which makes changes to data across all the instances which are part of DAX cluster.
• For some applications, the write-through behavior of DAX is appropriate, while for some, it is not.
• The item cache implements a write-through policy.
• Some of the applications experience higher latency for a write operation. In such cases, we can write directly to DynamoDB to reduce the latency.