AURORA Serverless v2

AURORA Serverless v2

Let's see how the search for the concept of serverless has increased in recent years, as we can see in illustration 1...

What is serverless?

Basically serverless means serverless. AWS offers technologies for running code, managing data, and integrating applications, all without having to manage servers. Serverless technologies include automatic scaling, integrated high availability, and a pay-as-you-go billing model to increase agility and optimize costs. These technologies also eliminate infrastructure management tasks, such as capacity provisioning and patching, so you can focus on writing code that works for your customers.

What is Amazon Aurora?

Amazon Aurora is a relational database management system (RDBMS), built for the cloud, with full compatibility with MySQL and PostgreSQL. Aurora gives you commercial database performance and availability for one-tenth of the cost.

What is Amazon Aurora Serverless?

Aurora Serverless v2 is an on-demand automatic scaling configuration for Amazon Aurora Aurora, it helps automate workload monitoring processes and adjust database capacity. Capacity is automatically adjusted based on application demand. You will only be charged for the resources consumed by database clusters. Therefore, Aurora Serverless v2 can help you stay on budget and avoid paying for computing resources you don't use.

Aurora serverless and Aurora provisioned comparison

Amazon Aurora Serverless v2 is good for the most demanding and highly variable workloads. For example, database usage can be intensive for a short period of time, followed by long periods of little activity or no activity at all. Examples are retail, gaming or sports websites with regular promotional events and databases that generate reports when needed. Others are development and test environments and new applications where usage could increase rapidly. For cases like these and many others, properly configuring capacity in advance isn't always possible with the provisioned model. It can also result in higher costs if you are over-provisioned and have capacity that you don't use.
Instead, Aurora provisioned clusters are good for stable workloads. Provisioned clusters allow you to choose a database instance class that has a predefined amount of memory, CPU capacity, I/O bandwidth, and so on. If the workload changes, you will manually modify the writer's class and readers. The provisioned model works well when the capacity of the expected consumption patterns can be adjusted in advance and brief interruptions are accepted while the class of the writer and the readers of the cluster changes.

Aurora Serverless v2 Use Cases

There are many types of workloads that can benefit from Aurora Serverless v2. Aurora Serverless v2 is especially useful in the following use cases:

* Unpredictable workloads: When you run daily workloads that have a sudden and unpredictable increase in activity. An example of this would be a site dedicated to traffic, which experiences a sudden increase in activity when it starts to rain. Another case would be an e-commerce site where traffic increases when special sales or promotions are offered. With Aurora Serverless v2, database capacity automatically scales to meet the needs of peak application loads and decreases again when the increase in activity ends. With Aurora Serverless v2, you no longer have to provision capacity for peaks or average load. You can specify an upper capacity limit to handle the worst situation. That capacity would not be used unless necessary.

The granularity of Aurora Serverless v2's horizontal reduction helps you adapt capacity to the needs of your database. In a provisioned cluster, for vertical scaling, a new database instance must be added. In an Aurora Serverless v1 cluster, vertical scaling requires doubling the number of Aurora capacity units (ACU) for the cluster (for example, 16 to 32 or 32 to 64). Instead, Aurora Serverless v2 can add half an ACU when just a little more capacity is needed. You can add an additional 0.5, 1, 1.5, 2, or half an ACU depending on the additional capacity needed to handle an increased workload. In addition, you can eliminate an additional 0.5, 1, 1.5, 2 or half ACU when the workload decreases and that capacity is no longer needed.

* Multi-tenant applications: With Aurora Serverless v2, there is no need to individually manage database capacity for each application in the fleet. Aurora Serverless v2 manages individual database capacity for you.

You can create a cluster for each tenant. This way, you can use features such as cloning, snapshot restoration, and Aurora global databases to improve high availability and disaster recovery as appropriate for each tenant.

Each tenant can have specific periods of activity and inactivity depending on the time of day, time of year, promotional events, etc. Each cluster can have a wide range of capacity. In this way, clusters with little activity incur the minimum charges for database instances. Any cluster can be scaled vertically quickly to manage periods of high activity.

* New applications: You are deploying a new application and you are not sure what database instance size you need. With Aurora Serverless v2, you can configure a cluster with one or more database instances and have the database automatically scale according to the capacity requirements of the application.

* Development and testing: With Aurora Serverless v2, you can create Aurora Serverless v2 database instances with minimal capacity instead of using database instance classes T. You can set the maximum capacity high enough so that those database instances can continue to run substantial workloads without running out of memory. When the database is not in use, all database instances are scaled vertically to avoid unnecessary charges.

To make it convenient to use Aurora Serverless v2 in development and test environments, the AWS Management Console provides the Easy create direct access to create a new cluster. If you choose the Dev/Test option, Aurora creates a cluster with an Aurora Serverless v2 database instance and a capacity range typical of a development and test system.

*Mixed-use applications: Let's say you have an online transaction processing (OLTP) application, but you periodically experience peaks in query traffic. If you specify promotion levels for Aurora Serverless v2 database instances in a cluster, you can configure the cluster so that the reader database instances can be scaled regardless of the writer database instance to handle the additional load. When peak usage decreases, the reader's database instances are scaled back to match the capacity of the writer's database instance.

* Capacity planning: Suppose you normally adjust database capacity or verify optimal database capacity for the workload by modifying the database instance classes of all database instances in a cluster. With Aurora Serverless v2, you can avoid this administrative burden. To determine the appropriate minimum and maximum capacity, you can run the workload and check how much the database instances actually scale.

You can modify existing database instances from provisioned to Aurora Serverless v2 or from Aurora Serverless v2 to provisioned. In these cases, there is no need to create a new cluster or a new database instance.
With an Aurora global database, you may not need as much capacity for secondary clusters as in the primary cluster. You can use Aurora Serverless v2 database instances in secondary clusters. In this way, cluster capacity can be scaled vertically if a secondary region is promoted that takes charge of the application workload.

Aurora Serverless v2 benefits

Aurora Serverless v2 is intended for variable or “peak” workloads. With such unpredictable workloads, you might struggle to plan when to change database capacity. You might also have problems making capacity changes quickly enough using known mechanisms, such as adding database instances or changing classes of database instances. Aurora Serverless v2 provides the following benefits to help with these use cases:

* Easier capacity management than provisioned capacity: Aurora Serverless v2 reduces the effort of planning database instance sizes and changing the size of database instances as the workload changes. It also reduces the effort to maintain consistent capacity for all database instances in a cluster.

* Faster and easier scaling during busy periods: Aurora Serverless v2 scales memory and computing capacity as needed, without interrupting customer transactions or general workload. The ability to use reader database instances with Aurora Serverless v2 helps you take advantage of horizontal scaling in addition to vertical scaling. The ability to use Aurora's global databases allows you to spread the Aurora Serverless v2 reading workload across multiple AWS Regions. This capability is more practical than the scaling mechanisms of provisioned clusters. It's also a faster and more granular method than the scaling capabilities of Aurora Serverless v1.

* Cost-effective during periods of low activity: Aurora Serverless v2 helps you avoid overprovisioning database instances. Aurora Serverless v2 adds resources in granular increments when you scale database instances vertically. You only pay for the database resources you consume. Aurora Serverless v2 resource usage is measured per second. This way, when a database instance shrinks, the reduction in resource usage is immediately recorded.

* Higher feature parity with provisioning: You can use many Aurora features with Aurora Serverless v2 that aren't available for Aurora Serverless v1. For example, with Aurora Serverless v2, you can use reader database instances, global databases, AWS Identity and Access Management (IAM) database authentication, and Performance Insights. You can also use many more configuration parameters than with Aurora Serverless v1.
In particular, with Aurora Serverless v2, you can take advantage of the following features of provisioned clusters:

* Database instances: Aurora Serverless v2 can take advantage of reader database instances to scale horizontally. When a cluster contains one or more reader database instances, the cluster can fail immediately if there are problems with the writer's database instance. This is a capability that isn't available with Aurora Serverless v1.

* Multi-AZ clusters: You can distribute Aurora Serverless v2 database instances in a cluster across multiple Availability Zones (AZ). Setting up a multi-AZ cluster helps ensure business continuity even in the rare cases where there are problems affecting an entire AZ. This is a capability that isn't available with Aurora Serverless v1.

* Global databases: You can use Aurora Serverless v2 in combination with Aurora global databases to create additional read-only copies of the cluster in other AWS Regions for disaster recovery purposes.

* RDS Proxy: You can use the Amazon RDS proxy to allow applications to group and share database connections to improve their scalability.

* Scaling faster, more granular, and less disruptive than with Aurora Serverless v1: Aurora Serverless v2 can scale faster. Scaling can change capacity by as little as 0.5 ACU, instead of doubling or halving the number of ACUs. Scaling usually occurs without interrupting processing. Scaling doesn't involve an event that you need to consider, as with Aurora Serverless v1. Scaling can be done while the SQL statements are being executed and the transactions are open, without the need to wait for a point of silence.

Manually managing database capacity can consume valuable time and cause inefficient use of database resources. With Aurora Serverless, you simply need to create a database, specify the desired database capacity range, and connect the applications. You pay per second of database capacity usage when database capacity is active. In addition, you can migrate between standard and serverless configurations with a few steps from the Amazon Relational Database Service (Amazon RDS) administration console.

Contact us for any questions or comments you may have.

Source: https://aws.amazon.com/es/rds/aurora/serverless/