RFC 470: Aurora Serverless v2 support #472
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,173 @@ | ||
| # Aurora Serverless v2 support | ||
|
|
||
| * **Original Author(s):**: @pahud | ||
| * **Tracking Issue**: #470 | ||
| * **API Bar Raiser**: @vinayak-kukreja | ||
|
|
||
| Allow users to create Amazon Aurora Serverless v2 instances with the `aws-rds` module. | ||
|
|
||
| ## Working Backwards | ||
|
|
||
| > This section should contain one or more "artifacts from the future", as if the | ||
| > feature was already released and we are publishing its CHANGELOG, README, | ||
| > CONTRIBUTING.md and optionally a PRESS RELEASE. This is the most important | ||
| > section of your RFC. It's a powerful thought exercise which will challenge you | ||
| > to truly think about this feature from a user's point of view. | ||
| > | ||
| > Choose *one or more* of the options below: | ||
| > | ||
| > * **CHANGELOG**: Write the changelog entry for this feature in conventional | ||
| > form (e.g. `feat(eks): cluster tags`). If this change includes a breaking | ||
| > change, include a `BREAKING CHANGE` clause with information on how to | ||
| > migrate. If migration is complicated, refer to a fictional GitHub issue and | ||
| > add its contents here. | ||
|
|
||
| feat(rds): Aurora Serverless v2 support | ||
|
|
||
| > | ||
| > * **README**: If this is a new feature, write the README section which | ||
| > describes this new feature. It should describe the feature and walk users | ||
| > through usage examples and description of the various options and behavior. | ||
| > | ||
|
|
||
| ## Aurora Serverless v2 support | ||
|
|
||
| Aurora Serverless v2 is an on-demand, autoscaling configuration for Amazon Aurora. | ||
| Aurora Serverless v2 helps to automate the processes of monitoring the workload and | ||
| adjusting the capacity for your databases. Capacity is adjusted automatically based on | ||
| application demand. Read | ||
| [Using Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) | ||
| for more details. | ||
|
|
||
| ### Create a new cluster | ||
|
There was a problem hiding this comment. Can any helper methods make it easier or more clear for the customer to use this resource? There was a problem hiding this comment. As |
||
|
|
||
| Use `DatabaseClusterV2` to create a new cluster with Aurora Serverless V2 support. | ||
| You may specify the `writer` and `readers` instances with the cluster. The instances | ||
| could be either serverless or privisioned. | ||
|
|
||
| ```ts | ||
| new rds.DatabaseClusterV2(stack, 'cluster', { | ||
|
There was a problem hiding this comment. Could you mention the defaults for this API and any validations that would be implemented? What would happen if I do, There was a problem hiding this comment. The minimal required props of this construct would be
check out this POC for more implementation details. There was a problem hiding this comment. Sorry about the confusion. What I meant to ask was what configuration of cluster gets created if we are just relying on defaults? For instance, do we generate 2 provisioned instances in the default scenario I was unable to figure this out in the POC. Could you point me to the implementation and also add that information in the RFC? |
||
| engine, | ||
|
There was a problem hiding this comment. Can we have some validations in place for Serverless V2 instances? I believe these do not work with all versions of database engines. There was a problem hiding this comment. yes we should validate the There was a problem hiding this comment. Great, do you believe we can have others? I remember you mentioned this is limited to certain regions as well? Can these be documented in the RFC? |
||
| vpc, | ||
|
There was a problem hiding this comment. Any defaults for VPC that would make sense for our database here? |
||
| // writer(serverless) | ||
| writer: { serverless: true }, | ||
|
There was a problem hiding this comment. What does There was a problem hiding this comment. The default ACU is defined in the There was a problem hiding this comment. Hmm, could you please tell me why the maximum is 1? I see it can be higher here.
By this you mean the config of There was a problem hiding this comment. Yes we should discuss what is the best defaults of min and max. The minimal possible values from cost-saving perspective is min:0.5 and max:1
With those defaults, the default cluster would have minimal required values with the best cost saving while customers can always specify any higher values as they wish. With that being said, I think the defaults make sense. Thoughts? |
||
| readers: [ | ||
| // reader 1(provisioned) | ||
| { instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.LARGE) }, | ||
| // reader 2(serverless) | ||
| { serverless: true }, | ||
|
Comment on lines
+79
to
+81
There was a problem hiding this comment. This looks odd to me. We have more flexibility provisioning an instance but serverless is just a boolean? Can this experience be modeled to be similar? There was a problem hiding this comment. We need an interface for For a serverless instance, the minimal required property would be I think this could satisfy both serverless and provisioned here but I am open to different design for this interface. There was a problem hiding this comment. I believe there could be an issue with large clusters with our current API with list of readers and writers. For instance, imagine a cluster with 50 readers. Instantiating with current API would look quite large and have redundant information as well. Also, could you tell me what do you mean by custom instance type is not allowed in serverless? From what I understand, we can have ACU's modified for serverless v2 instances? There was a problem hiding this comment. From my current design, if you are creating a large cluster with 50 or more readers, you need to pass a list of instance options to the new DatabaseClusterV2(scope, id, {
writer,
readers: readerList,
}
In serverlessV2, there is no option to specify individual ACU for individual serverless instances. All serverless instances are sharing the same ServerlessV2ScalingConfiguration which is cluster-wise. Behind the scene the serverless instance is literally the CfnDbInstance which does not allow you to specify any specific ACU for it. |
||
| ], | ||
| }); | ||
| ``` | ||
|
|
||
| > * **PRESS RELEASE**: If this is a major feature (~6 months of work), write the | ||
| > press release which announces this feature. The press release is a single | ||
| > page that includes 7 paragraphs: (1) summary, (2) problem, (3) solution, (4) | ||
| > leader quote, (5) user experience, (6) customer testimonial and (7) one | ||
| > sentence call to action. | ||
|
|
||
| --- | ||
|
|
||
| Ticking the box below indicates that the public API of this RFC has been | ||
| signed-off by the API bar raiser (the `api-approved` label was applied to the | ||
| RFC pull request): | ||
|
|
||
| ``` | ||
| [ ] Signed-off by API Bar Raiser @xxxxx | ||
| ``` | ||
|
|
||
| ## Public FAQ | ||
|
|
||
| > This section should include answers to questions readers will likely ask about | ||
| > this release. Similar to the "working backwards", this section should be | ||
| > written in a language as if the feature is now released. | ||
| > | ||
| > The template includes a some common questions, feel free to add any questions | ||
| > that might be relevant to this feature or omit questions that you feel are not | ||
| > applicable. | ||
|
|
||
| ### What are we launching today? | ||
|
|
||
| We are launching the Aurora Serverless v2 support for `aws-rds` that allows users to | ||
| create a new cluster with Serverless v2 support and define serverless or provisioned | ||
| `writer` and `readers` in the new `DatabaseClusterV2` construct. | ||
|
|
||
| ### Why should I use this feature? | ||
|
|
||
| 1. I need to create a cluster with Aurora serverless v2 support. | ||
| 2. I need to create the writer as well as the readers with this cluster. | ||
|
|
||
| ## Internal FAQ | ||
|
|
||
| > The goal of this section is to help decide if this RFC should be implemented. | ||
| > It should include answers to questions that the team is likely ask. Contrary | ||
| > to the rest of the RFC, answers should be written "from the present" and | ||
| > likely discuss design approach, implementation plans, alternative considered | ||
| > and other considerations that will help decide if this RFC should be | ||
| > implemented. | ||
|
|
||
| ### Why are we doing this? | ||
|
|
||
| The existing `aws-rds` module is missing the Aurora Serverless v2 support and we are adding this support into this module. | ||
|
|
||
| ### Why should we _not_ do this? | ||
|
|
||
| > Is there a way to address this use case with the current product? What are the | ||
| > downsides of implementing this feature? | ||
|
|
||
| ### What is the technical solution (design) of this feature? | ||
|
|
||
| We are creating a new `DatabaseClusterV2` L2 construct by extending the `DatabaseClusterBase` class. | ||
| Users that opt-in serverless v2 enabled clusters should use this class to create a new cluster | ||
| as well as writer and reader instances, which could be serverless, porivioned or mixed. | ||
|
Comment on lines
+144
to
+145
There was a problem hiding this comment. How can the user opt-in for this functionality? Is it just by using this construct? There was a problem hiding this comment. Yes. From my current proposed design, the There was a problem hiding this comment. Great, thank you for clarifying. Could you please add this to the RFC too? |
||
|
|
||
| While this new construct addresses the requirement for new clusters with serverless v2 support, | ||
| existing clusters previously created with `DatabaseCluster` construct will not be able to enable the | ||
| serverless v2 support or add any serverless instances into the existing cluster with the new construct. | ||
| To address this concern, we should update the existing `DatabaseCluster` by adding help methods such as | ||
| `addServerlessInstance()` and `addProvisionInstance()`. The existing clusters should be updated by manually | ||
| adding the `serverlessV2Config` property which is mandatory for the serverless v2 cluster. | ||
|
|
||
| ### Is this a breaking change? | ||
|
|
||
| No. As `DatabaseClusterV2` is a new construct, there's no breaking change for that. | ||
|
|
||
| > If the answer is no. Otherwise: | ||
| > | ||
| > Describe what ways did you consider to deliver this without breaking users? | ||
| > | ||
| > Make sure to include a `BREAKING CHANGE` clause under the CHANGELOG section with a description of the breaking | ||
| > changes and the migration path. | ||
|
|
||
| ### What alternative solutions did you consider? | ||
|
|
||
| This RFC addresses two primary senarios for CDK users either creating a new cluster with serverless v2 support or | ||
| modifying the existing one to enable the serverless v2 support. We will split this into multiple small pull requests | ||
| to address those two cases. | ||
|
|
||
| Another alternative to consider is to create a new construct to sastify both cases and eventually deprecate | ||
| the original `DatabaseCluster`. | ||
|
|
||
| ### What are the drawbacks of this solution? | ||
|
|
||
| No major drawbacks of this solution as this is a new construct with no breaking changes and targeting | ||
| serverless v2 clusters only. | ||
|
|
||
| ### What is the high-level project plan? | ||
|
|
||
| 1. We will first create a PR for this new construct. | ||
| 2. Depends on users feedback, optionally create another PR to modify the existing `DatabaseCluster` | ||
| construct to allow existing clusters enable the serverless v2 support. | ||
|
|
||
| ### Are there any open issues that need to be addressed later? | ||
|
|
||
| > Describe any major open issues that this RFC did not take into account. Once | ||
| > the RFC is approved, create GitHub issues for these issues and update this RFC | ||
| > of the project board with these issue IDs. | ||
|
|
||
| ## Appendix | ||
|
|
||
| 1. [Using Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) from Aurora User Guide. | ||
| 2. [AWS::RDS::DBCluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbcluster.html) from cloudformation. | ||
| 3. [feat(aws-rds): support Aurora Serverless v2 cluster and instances #22446](https://github.com/aws/aws-cdk/pull/22446) | ||
| previous closed PR with discussion. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to have helper methods supporting metrics here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As DatabaseClusterV2 extends the DatabaseClusterBase abstract class and implement IDatabaseCluster so all helper methods defined in the base class should be available for DatabaseClusterV2. If we need to add additional helper methods for this new construct we can consider either add in the abstract class or this class. As this is a new construct without breaking changes, I think it's always possible to add any helper methods if necessary but doesn't have to be do that in the first PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And Yes! I will add a section for all known use cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use Cases added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for adding those.
In regards to the helper methods, what I want to convey is to think about how certain functions enable a better customer experience. They can be implemented later but the RFC would be a good place to list them out if any.