Add ClientID round-robin support to StoreBroker Proxy #114
Assignees
Labels
Comments
HowardWolosky
added a commit
to hwbackup/StoreBroker
that referenced
this issue
Aug 24, 2018
The Store API has two different rate limiters in place
with corresponding error codes:
429 - API rate limiter - a ClientId can't make more than
60 queries per minute
403 - API quota limiter - a ClientId can't make more than
60,000 queries per day
For organizations that have many StoreBroker clients,
it is quite possible that 429 errors may happen fairly
frequently (along with the occasional 403's on really bad
days).
To avoid this, the Proxy is gaining the concept of
load balancing (from the API/Client Id perspective) by
enabling administrators to configure a TenantId to have
as many ClientId's as they'd like -- the Proxy will use
a "round robin" approach and simply cycle through all
configured ClientId's for a given TenantId/EndpointType
combination upon each request.
As more StoreBroker clients are added within an organization,
the Proxy administrator can simply add in additional ClientId's
as needed. This change will be completely transparent to all
clients, and help ensure reliable API execution that doesn't
hit any rate or quota limiters.
Resolves Issue microsoft#114 - Add ClientID round-robin support to StoreBroker Proxy
HowardWolosky
added a commit
to hwbackup/StoreBroker
that referenced
this issue
Aug 24, 2018
The Store API has two different rate limiters in place
with corresponding error codes:
429 - API rate limiter - a ClientId can't make more than
60 queries per minute
403 - API quota limiter - a ClientId can't make more than
60,000 queries per day
For organizations that have many StoreBroker clients,
it is quite possible that 429 errors may happen fairly
frequently (along with the occasional 403's on really bad
days).
To avoid this, the Proxy is gaining the concept of
load balancing (from the API/Client Id perspective) by
enabling administrators to configure a TenantId to have
as many ClientId's as they'd like -- the Proxy will use
a "round robin" approach and simply cycle through all
configured ClientId's for a given TenantId/EndpointType
combination upon each request.
As more StoreBroker clients are added within an organization,
the Proxy administrator can simply add in additional ClientId's
as needed. This change will be completely transparent to all
clients, and help ensure reliable API execution that doesn't
hit any rate or quota limiters.
Resolves Issue microsoft#114 - Add ClientID round-robin support to StoreBroker Proxy
HowardWolosky
added a commit
to hwbackup/StoreBroker
that referenced
this issue
Sep 1, 2018
The Store API has two different rate limiters in place
with corresponding error codes:
429 - API rate limiter - a ClientId can't make more than
60 queries per minute
403 - API quota limiter - a ClientId can't make more than
60,000 queries per day
For organizations that have many StoreBroker clients,
it is quite possible that 429 errors may happen fairly
frequently (along with the occasional 403's on really bad
days).
To avoid this, the Proxy is gaining the concept of
load balancing (from the API/Client Id perspective) by
enabling administrators to configure a TenantId to have
as many ClientId's as they'd like -- the Proxy will use
a "round robin" approach and simply cycle through all
configured ClientId's for a given TenantId/EndpointType
combination upon each request.
As more StoreBroker clients are added within an organization,
the Proxy administrator can simply add in additional ClientId's
as needed. This change will be completely transparent to all
clients, and help ensure reliable API execution that doesn't
hit any rate or quota limiters.
Resolves Issue microsoft#114 - Add ClientID round-robin support to StoreBroker Proxy
Also, some additional headers need to be proxied to the API.
Clients are able to provide the "MS-CorrelationId" and "MS-Client-RequestId"
headers in their requests, and when specified, these should be proxied
directly to the API.
We also want to return back any header that includes the word
"retry" in it, as the API may start to use those to indicate how
long we should wait before retrying the same request.
Finally, we want to provide a default value for the return message's
ContentType in the event that the API is incorrectly returning back
a message without one specified (in this scenario, we'll default to
`text/plain`) (an issue that has occurred in the past).
HowardWolosky
added a commit
that referenced
this issue
Sep 1, 2018
The Store API has two different rate limiters in place
with corresponding error codes:
429 - API rate limiter - a ClientId can't make more than
60 queries per minute
403 - API quota limiter - a ClientId can't make more than
60,000 queries per day
For organizations that have many StoreBroker clients,
it is quite possible that 429 errors may happen fairly
frequently (along with the occasional 403's on really bad
days).
To avoid this, the Proxy is gaining the concept of
load balancing (from the API/Client Id perspective) by
enabling administrators to configure a TenantId to have
as many ClientId's as they'd like -- the Proxy will use
a "round robin" approach and simply cycle through all
configured ClientId's for a given TenantId/EndpointType
combination upon each request.
As more StoreBroker clients are added within an organization,
the Proxy administrator can simply add in additional ClientId's
as needed. This change will be completely transparent to all
clients, and help ensure reliable API execution that doesn't
hit any rate or quota limiters.
Resolves Issue #114 - Add ClientID round-robin support to StoreBroker Proxy
Also, some additional headers need to be proxied to the API.
Clients are able to provide the "MS-CorrelationId" and "MS-Client-RequestId"
headers in their requests, and when specified, these should be proxied
directly to the API.
We also want to return back any header that includes the word
"retry" in it, as the API may start to use those to indicate how
long we should wait before retrying the same request.
Finally, we want to provide a default value for the return message's
ContentType in the event that the API is incorrectly returning back
a message without one specified (in this scenario, we'll default to
`text/plain`) (an issue that has occurred in the past).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Store API limits an individual ClientId to 20,000 - 30,000 requests/24 hours.
If a proxy is serving enough customers, it's possible that the proxy might hit that limit and thus all users might be blocked until the cool-off period expires.
A potential workaround is to create multiple ClientId/ClientSecrets associated with the same Tenant, and have the proxy automatically rotate between them, round-robin style, opaque to clients (so that clients don't have to change anything on their end).
This would require changing the configuration schema that is used for the proxy, and then altering the logic used for retrieving the correct access token.
The text was updated successfully, but these errors were encountered: