Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve scalability of the EC2/Route53 controllers #2029

Open
justinmir opened this issue Apr 1, 2024 · 4 comments
Open

Improve scalability of the EC2/Route53 controllers #2029

justinmir opened this issue Apr 1, 2024 · 4 comments
Labels
enhancement New feature or request stale

Comments

@justinmir
Copy link

Reddit uses provider-aws to primarily manage EC2 and Route53 resources. In the future we may be adopting it for interacting with various AWS managed services. The provider-aws controllers currently manage on the order of several thousand resources each, ~3000+ EC2 instances, and ~6000+ route53 records.

We are currently running provider-aws version 0.46.

What problem are you facing?

At this scale we run into issues with high queue depth in our controllers, even with 20+ active workers (provider-aws --max-reconcile-rate=20).

image
Figure 1: Crossplane controller is unable to work through queue of reconcile requests even with 20 active workers at our scale.

Reconcile times for EC2 instances typically take greater than one second at median and can take up to 6 seconds at p99.
image
Figure 2: Reconcile time for instance resources

Without any jitter, ResourceRecordSet resource observations can cause a backlog that can take up to an hour to resolve. AWS rate limits route53 API requests to 5 requests / second / account, which makes it extremely easy to hit the rate limit when performing observation on route53 resources. These queue depths exist even with poll intervals set to 30 minutes (up from 1 minute) in our fork.

image
Figure 3: Resource record set controller is backlogged during instance observation.

How could Crossplane help solve your problem?

Allow configuring per-resource poll interval / jitter
Introduce jitter in resource record sets, introducing jitter smooths the request rate of the resource due to observations and minimizes the impact of the rate limit. We hard-code jitter in our crossplane provider-aws fork.

image

Reduce reconcile time for EC2 instance resources
Reduce the time spent to perform an EC2 instance observation by: (1) reduce unnecessary API calls for duplicate data, (2) parallelize API calls where possible.

@davimmt
Copy link

davimmt commented Jun 7, 2024

Looking forward mainly for the Route53 Record observation fixes. API calls should be merged into big chunks of ResourceChangeBatches at once.

Using xpkg.upbound.io/upbound/provider-aws-route53:v1.2.1 dealing with hundreds of applications: failed to observe the resource: [{0 reading Route 53 Record (ZONEID_DOMAINNAME_A): Throttling: Rate exceeded status code: 400, request id: RID []}].

Copy link

github-actions bot commented Sep 6, 2024

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

@github-actions github-actions bot added the stale label Sep 6, 2024
@justinmir
Copy link
Author

/fresh

@github-actions github-actions bot removed the stale label Sep 14, 2024
Copy link

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

@github-actions github-actions bot added the stale label Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request stale
Projects
None yet
Development

No branches or pull requests

2 participants