AZ-Affinity strategy blog #186
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Adar Ovadia <[email protected]>
stockholmux
reviewed
Jan 2, 2025
| @@ -0,0 +1,166 @@ | |||
| +++ | |||
| # `title` is how your post will be listed and what will appear at the top of the post | |||
There was a problem hiding this comment.
delete these comments in the front matter.
| ## AZ Affinity routing advantages | ||
|
|
||
| 1. **Reduce Data Transfer Costs** Cross-zone data transfer often incurs additional charges in Cloud environments. By ensuring operations are directed to nodes within the same AZ, you can minimize or eliminate these costs. | ||
| **Example:** An application in AWS with a Valkey cluster of 2 shards, each with 1 primary and 2 replicas, the instance type is m7g.xlarge. The cluster processes 250MB of data per second and to simplify the example 100% of the traffic is read operation. 50% of this traffic crosses AZs at a cost of $0.01 per GB, the monthly cross-AZ data transfer cost would be approximately $3,285. In addition the cost of the cluster is $0.252 per hour per node. Total of $1,088 per month. By implementing AZ affinity routing, you can reduce the total cost from $4,373 to $1,088, as all traffic remains within the same AZ. |
There was a problem hiding this comment.
De-inlining the example looks better.
Suggested change
| **Example:** An application in AWS with a Valkey cluster of 2 shards, each with 1 primary and 2 replicas, the instance type is m7g.xlarge. The cluster processes 250MB of data per second and to simplify the example 100% of the traffic is read operation. 50% of this traffic crosses AZs at a cost of $0.01 per GB, the monthly cross-AZ data transfer cost would be approximately $3,285. In addition the cost of the cluster is $0.252 per hour per node. Total of $1,088 per month. By implementing AZ affinity routing, you can reduce the total cost from $4,373 to $1,088, as all traffic remains within the same AZ. | |
| **Example:** An application in AWS with a Valkey cluster of 2 shards, each with 1 primary and 2 replicas, the instance type is m7g.xlarge. The cluster processes 250MB of data per second and to simplify the example 100% of the traffic is read operation. 50% of this traffic crosses AZs at a cost of $0.01 per GB, the monthly cross-AZ data transfer cost would be approximately $3,285. In addition the cost of the cluster is $0.252 per hour per node. Total of $1,088 per month. By implementing AZ affinity routing, you can reduce the total cost from $4,373 to $1,088, as all traffic remains within the same AZ. |
|
|
||
|
|
||
| 2. **Minimize Latency** Distance between AZs within the same region— for example, in AWS, is typically up to 60 miles (100 kilometers)—adds extra roundtrip latency, usually in the range of 500µs to 1000µs. By ensuring requests remain within the same AZ, you can reduce latency and improve the responsiveness of your application. | ||
| **Example:** |
There was a problem hiding this comment.
Suggested change
| **Example:** | |
| **Example:** |
|
|
||
| 2. **Minimize Latency** Distance between AZs within the same region— for example, in AWS, is typically up to 60 miles (100 kilometers)—adds extra roundtrip latency, usually in the range of 500µs to 1000µs. By ensuring requests remain within the same AZ, you can reduce latency and improve the responsiveness of your application. | ||
| **Example:** | ||
| Consider a cluster with three nodes, primary and two replicas. Each node located in different availability zone. The client locate in az-2 as replica-1. |
There was a problem hiding this comment.
Suggested change
| Consider a cluster with three nodes, primary and two replicas. Each node located in different availability zone. The client locate in az-2 as replica-1. | |
| Consider a cluster with three nodes, primary and two replicas. Each node located in different availability zone. The client locate in az-2 as replica-1. |
There was a problem hiding this comment.
Also, wording is a little odd.
Suggested change
| Consider a cluster with three nodes, primary and two replicas. Each node located in different availability zone. The client locate in az-2 as replica-1. | |
| Consider a cluster with three nodes, one primary and two replicas. Each node is located in a different availability zone. The client is located in az-2 along with replica-1. |
stockholmux
approved these changes
Jan 2, 2025
madolson
reviewed
Jan 2, 2025
Comment on lines
+76
to
+90
| For each node, run the following command and change the AZ and routing address as appropriate: | ||
|
|
||
| **Python:** | ||
| ```python | ||
| client.config_set({"availability-zone": az}, | ||
| route=ByAddressRoute(host="address.example.com", port=6379)) | ||
| ``` | ||
| **Java:** | ||
| ```Java | ||
| client.configSet(Map.of("availability-zone", az), new ByAddressRoute("address.example.com", 6379)) | ||
| ``` | ||
| **Node.js:** | ||
| ```javascript | ||
| client.configSet({"availability-zone": az}, { route: {type: "routeByAddress", host:"address.example.com", port:6379}}) | ||
| ``` |
There was a problem hiding this comment.
I don't think I made my comment here clear. I think this is this wrong way to setup configuration, it's almost always done when starting the server and done in a way that is configured. It think it makes more sense to just link to https://valkey.io/topics/valkey.conf/ or skip this all together. Either that, or have them use the CLI.
|
|
||
| 2. **Minimize Latency** Distance between AZs within the same region— for example, in AWS, is typically up to 60 miles (100 kilometers)—adds extra roundtrip latency, usually in the range of 500µs to 1000µs. By ensuring requests remain within the same AZ, you can reduce latency and improve the responsiveness of your application. | ||
| **Example:** | ||
| Consider a cluster with three nodes, primary and two replicas. Each node located in different availability zone. The client locate in az-2 as replica-1. |
There was a problem hiding this comment.
Also, wording is a little odd.
Suggested change
| Consider a cluster with three nodes, primary and two replicas. Each node located in different availability zone. The client locate in az-2 as replica-1. | |
| Consider a cluster with three nodes, one primary and two replicas. Each node is located in a different availability zone. The client is located in az-2 along with replica-1. |
| ``` | ||
| **Java:** | ||
| ```Java | ||
| /// Initialize Valkey client with preference for the client's AZ |
There was a problem hiding this comment.
Suggested change
| /// Initialize Valkey client with preference for the client's AZ | |
| // Initialize Valkey client with preference for the client's AZ |
nit: I don't think triple slashes is the recommended comment.
| }); | ||
| /// Write operation (route to the primary's slot owner) | ||
| await client.set("key1", "val1"); | ||
| /// Get will read from one of the replicas in the same client's availability zone if exits. |
There was a problem hiding this comment.
Suggested change
| /// Get will read from one of the replicas in the same client's availability zone if exits. | |
| /// Get will read from one of the replicas in the same client's availability zone if one exists. |
| ) | ||
|
|
||
| # Determine the client's AZ (this could be fetched from the cloud provider's metadata service) | ||
| client_az = 'AZ-a' |
There was a problem hiding this comment.
Suggested change
| client_az = 'AZ-a' | |
| client_az = 'us-east-1a' |
You inconsistently use us-east-1a as an example and AZ-a, but the former is clearer imo. I think we can be AWS centric since we wrote the blog, but explain how it works generally.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
GLIDE, official open-source Valkey client library, recently added support for a key feature AZ affinity routing, which enables Valkey-based applications to direct calls specifically to server nodes in the same AZ as the client.
In this blog, we dive into AZ affinity routing mechanics, showing how it optimizes application's performance and cost using Valkey GLIDE.
Issues Resolved
Check List
--signoffBy submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.