Scalability and Performance ( RDS)

Introduction to Amazon RDS

When it comes to databases, we experience a lot of pain points be it hard to keep on running, requiring constant patching, high licensing costs, endless data optimization, and full-time DBAs(Database Administrators) are one of the pain points that you might experience when working with traditional databases.

When it comes to migrating these traditional databases to the AWS cloud, the cloud database eliminates the hardware maintenance costs and enables high availability, automated backups along with improved performance offering Provisioned IOPS or PIOPS for achieving fast, consistent and predictable Input/Output performance. With RDS, you can easily set up, operate as well as scale a traditional relational database in the AWS cloud. Its cost-efficient, scalable and resizeable capacity for the industry-standard relational database helps to manage common database administration tasks. You can also manage all these tasks within just a few clicks.

Features of AWS RDS

With AWS RDS, users can maintain, build as well as scale the relational database in the cloud ecosystem. AWS RDS offers freedom for various types of DB instances to air you with multiple databases engines ( such as SQLServer, MySQL, PostgreSQL, and AWS’s Aurora ) to run on. Various aspects of managing the relational databases can be prioritized by the instances for operations like memory capacity, performance during traffic spikes as well as bandwidth availability.

Let us, deep dive, into below listed few of the key features offered by AWS RDS:

Lower Administrative Burden: AWS RDS offers less pain for any administrative activity that needs to be performed as it makes it very convenient to use the AWS RDS capabilities either via the AWS Management Console, the AWS RDS Command Line Interface, or via easy API calls for a production-ready relational database that too within minutes.

AWS RDS Optimized Reads: Professionally designed for providing fast database performance where you can seamlessly query up to 50% faster in AWS RDS for the MySQL database at no extra cost incurred.

Optimized Writes for AWS RDS: Built above the AWS Nitro System, with AWS RDS your write transaction throughput is drastically increased by up to 2x for MySQL at no extra cost suitable for consumers with write-intensive database workloads like gaming, tradings, and digital payment systems, etc.

Automatic Software Patching: Ensuring your deployment is always updated with the latest patches, AWS RDS comes in handy where you can also exert any control for validating whether the database instance is properly patched or not.

Performance: Performance with the General Purpose (SSD) Storage, you get a consistent baseline for 3 IOPS per provisioned GB which offers the capability to burst up to 3,000 IOPS above the baseline for typically the broad range of database workloads. While with the Provisioned IOPS (SSD) Storage you can optimize faster, consistent and predictable delivery. You can provide as high as up to 40,000 IOPS per database instance depending on the database workload.

For more information on AWS RDS features, you can visit the AWS RDS FEATURES where you can explore the features more in-depth.

Scaling AWS RDS

We often hear of scaling when we talk about any architecture which can handle and manage the flexibility to increase and decrease the system while the traffic on that system increases. We often require the concept of scaling when our database cannot keep up with throughput demands from the users. With AWS RDS we get both scaling options, that is,

• Vertical Scaling
• Horizontal Scaling

Vertical Scaling: We can define vertical scaling which is required when the instance size could be changed to handle a larger number of Input/Output per second (IOPS) operations, with higher throughput, or a lower latency value. When you had overprovisioned the instance, you can also scale down the instance size when needed.

Horizontal Scaling: We can define horizontal scaling which is required when you need the addition of read replicas to alleviate traffic pressuring the existing primary instance. Here, the read requests are purposely diverted to one of the other replicas for increasing the throughput of the instance.

It is important to note that with horizontal scaling, the write capacity is more complex, where no internal methods are readily available. The users can only employ techniques such as sharding, which must involve custom, and external development. When that's not possible, the vertical scaling write capacity is the go-to scaling option for the same scenario.

The scaling which we learned above, can be done either manually or automatically. Let us discuss each in detail.

Scaling Manually:

The manual scaling can be done with the help of AWS CLI for modifying the settings specifically for a database instance. For this, you could check either the existing instance settings via the AWS CLI which could help you determine if the existing instance were sufficient for the needs or not. The database instance can be modified for scaling the instance when the changes are required.

These changes related to scaling the RDS instance can also be done manually via the AWS console. In the console, you can see the existing instance settings so that you can scale as and when required. You can too modify the instance type, and size, along with the allocated storage via the AWS console. The changes can also occur immediately via using the console, or at a later time. This feature is available as scaling can sometimes also lead to an outage of the database when the process is still running.

Scaling Automatically:

When it comes to scaling the databases automatically, the AWS RDS also includes the ability to autoscale the database's storage size. Here, the users can also set a desired maximum storage size, along with the AWS-managed RDS that shall detect when the size of the storage is getting limited depending upon the currently available storage. Once analyzed, the AWS RDS automatically increases the storage size upon meeting the defined preset conditions.

Based on the workload requirements, the auto-scaling feature is only available with Amazon Aurora. The number of Aurora replicas in the cluster is automatically adjusted to maintain the overhead workload. Depending on the present minimum and maximum capacity, scaling occurs where a cooldown period also exists between two scales. It recommended implementing a feedback DevOps loop where ever automatic vertical scaling must be applied. You can also tune and adjust the setting for the metrics to detect when the database capacity is limiting. If a change in the instance is required to prevent outages, a command can be triggered using external platforms that can apply autoscaling via the external platforms, commands can be triggered for applying autoscaling when the change in the instance is required for preventing any outages.

Considerations for Scaling Amazon AWS RDS

Now we shall be discussing the Important consideration to be taken care of, for scaling AWS RDS.

• You need to make sure only minimum disruption for the platform happens before you need to scale the RDS instance. During a database upgrade, if you require to change the instance type, then it might also lead to a temporary outage. Some existing features of RDS could also be used to minimize the outage time or schedule the scaling for a routine maintenance window.
• The instance type and storage allocation are separate settings in RDS. Changing your instance type will not change the amount of allocated storage and vice versa. Before scaling, developers must determine what is needed for both of these parameters and update accordingly.
• Always be aware of any commercial database license, before any scaling can be applied to the instance. If you use commercial engines like SQL Server or Oracle, then this license must be cross-checked. The licenses are typically used by the commercial engined to restrict the available CPU sockets or cores. The scaling may also not take effect if you scale beyond the license.
• Downtime is significantly minimized while upgrades are going on if you implement the Multi-Availability Zone environment. It so happens because you first need to update the standby database, and then the primary database gets updated when any failover mechanism gets pointed to the standby. This in a way, limits the time that the users shall also foresee a delay or failure concerning the upgrade.