search

Azure / azure-cosmos-dotnet-v3

.NET SDK for Azure Cosmos DB for the core SQL API
MIT License
724 stars 481 forks source link

PreferredLocations list generated by SDK for EUAP regions is unexpected #3603

Open camillemarie opened 1 year ago

camillemarie commented 1 year ago

Describe the bug

When I set ApplicationRegion to East US 2 EUAP, the first 3 PreferredLocations generated by the SDK are other Canary regions, but then the rest of the list is in a seemingly random order. Is there a reason for this?

To Reproduce

  1. Set ApplicationRegion to East US 2 EUAP.
  2. Check the PreferredLocations generated by the SDK

Expected behavior The SDK-generated PreferredLocations would list regions in order of expected network latency from the ApplicationRegion.

Actual behavior

  1. The SDK generates the following PreferredLocations list: ["East US 2 EUAP","Central US EUAP","East US SLV","West US 2","Qatar Central","South Africa North","South Africa West","South Central US","Southeast Asia","South India","Sweden Central","Sweden South","Switzerland North","Switzerland West","UAE Central","UAE North","UK South","UK West","Norway West","USDoD East","USGov Arizona","USGov Texas","USGov Virginia","USNat East","USNat West","USSec East","USSec West","USSec West Central","West Central US","West Europe","West India","West US","West US 3","USDoD Central","North Europe","North Central US","Australia Central 2","Australia East","Australia Southeast","Brazil South","Brazil Southeast","Canada Central","Canada East","Central India","Central US","China East","China East 2","China East 3","China North","China North 2","Norway East","China North 3","East US","East US 2","France Central","France South","Germany Central","Germany North","Germany Northeast","Germany West Central","Japan East","Japan West","Jio India Central","Jio India West","Korea Central","Korea South","East Asia","Australia Central"]
  2. Because our cosmos db account doesn’t have any replicas in EUAP regions, all requests go the West US 2.

Environment summary SDK Version: 2.18.0. Will try to repro on 3.31.0 shortly. Cosmos DB account regions: [ "East US 2", "Central US", "West Europe", "Southeast Asia", "Brazil South", "Australia East", "Japan East", "West US 2", "North Europe", "West US", "East US", "North Central US", "South Africa North", "Central India", "UAE North", "Germany West Central", "East Asia", "South Central US", "Sweden Central", "UK South" ]

kirankumarkolli commented 1 year ago

@camillemarie it's an interesting scenario where compute and storage are in different environments.

Our current PreferredRegions population assumes that compute also will be in the same environment and for all other environments-regions it assumes equidistant.

ealsur commented 1 year ago

@camillemarie Based on https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.cosmos.cosmosclientoptions.applicationregion?view=azure-dotnet#remarks this list is then intersected with the account regions.

Which is the impact or problem you are facing with this configuration? Which is the region you'd expect your request to go to?

camillemarie commented 1 year ago

@ealsur The impact is that request latency is higher than expected because requests go from our app in East US 2 EUAP => West US 2 replica, when they could go to the East US 2 replica instead. We've worked around this by hardcoding the ApplicationRegion in East US 2 EUAP to East US 2 for now.

Canary doesn't have the same reliability guarantees as the other public Azure regions, but I wouldn't consider it a fully different environment in the same way that Fairfax or Mooncake are different environments. I can see the argument to prefer Canary regions for Canary apps, but the Public regions should be in order instead of considered equidistant. i.e. East US 2 EUAP => [East US 2 EUAP, Central US 2 EUAP, East US SLV, East US 2, East US, etc]