AWS RDS Proxy review

41PFKRsyHbL._SL500_AA300_RDS Proxy has just recently became generally available and I decided to make a small test, since our company needs connection pooling and is very zero downtime oriented. We were thinking of running our own EC2 instances with SQL Proxy in the past, but now that this service became available on AWS it was a no-brainer to try it out.

Benefits of AWS RDS Proxy

Pooling
Probably one of most important features is, it maintains a pool of connections to your RDS database. This reduces stress on database CPU and memory resources, since constant establishing of new connections is quite heavy operation. It will share infrequent used connections so that we can avoid having a lot of idle connections to our database, which are doing nothing.

Failover
In my opinion the most important feature of RDS Proxy would be reducing failover times of aurora database. As AWS states, these times could be improved by up to 66%.

IAM
Enforcing IAM controls for connecting to database is one of the features RDS Proxy provides and it is fully optional. If you don’t like that, you can still use Secrets Manager to specify credentials with which users can connect to the database.

Managed by AWS
Nice feature of RDS proxy is also that it is fully managed by AWS, so security patches, scaling and managing of the RDS instances is done by AWS. You just need to set it up, provide it credentials and point it to a specific RDS database. It will give you back the endpoint for connecting and you can replace the hostname for connecting in your application with the provided one and it should work without any need for code change.

Seamless integration
As this is seamless integration, it is fully compatible with protocols of the database engines.

Failover test

For my failover test I spawned application server on EC2 instance and an Aurora RDS cluster with two instances:

Screenshot 2020-07-25 at 18.54.16

I created a script:

#!/bin/bash
HOST=$1
while true; do echo -n "$1:"; mysql -s -N -h $1 -p'passwordhere' -u app -e "select now()"; done

I started the script one endpoint connecting to DB through RDS Proxy endpoint and one through cluster endpoint Aurora Cluster provides. After spam of connections constantly doing “select now()” I pressed failover on our Aurora writer and these are the results:

Screenshot 2020-07-25 at 19.06.36

On left you can see script running through RDS Proxy and on right you can see normal cluster endpoint. RDS Proxy took aproximately 2 seconds to failover and start working again, while normal endpoint was still spamming the errors, trying to connect.

Here is the tail of the right side for a normal cluster endpoint:

Screenshot 2020-07-25 at 19.06.55

As you can see endpoint downtime was from 17:05:34 to 17:05:41 and resulted in a lot of errors. Total downtime was 7 seconds.

Result is pretty self explanatory, RDS Proxy still isn’t perfect, but for sure helps with Aurora failovers. Downtimes are 3 times lower than they would be without using it.

Connection pooling test

For this test I created an RDS Proxy that actually has 2% of utilization of max connections. This means only small portion of connections will remain idle and open from RDS to the proxy. To stress test it I added a small php script that imitates slow execution of the code before closing the connection to the database:

// Cluster
$host = "app.cluster-ciuqnljnt0bc.eu-west-2.rds.amazonaws.com";
// Proxy
//$host = "app-stress.proxy-ciuqnljnt0bc.eu-west-2.rds.amazonaws.com";

$link = mysqli_connect($host, 'app', 'application123');

if (!$link) {
die('Could not connect: ' . mysqli_error());
}

if ($result = $link -> query("SELECT * FROM my_app.long_history")) {
  echo "Returned rows are: " . $result -> num_rows . "
";
  $result -> free_result();
}

sleep(2);

echo 'Executed successfully';
mysqli_close($link);

This code is pretty simple, so it doesn’t need much explanation, except that sleep(2) is actually an imitation of “slow executing code”. For example: Usually when you are doing transactions, you pull some data from database, make some modifications to it and do another action like save it or update some other table / field and this processing part is imitated with this sleep(2).

Stress test of the script was done with Apache Benchmark, basically just throwing 200 concurrent connections to this php file which is being served on the web by Apache webserver.

While the stress test was running, I was spamming show processlist and the number of connections stayed at 20, so AWS RDS Proxy was reusing the idle connections successfully.

Screenshot 2020-07-25 at 19.35.54

Repeating the same test with direct Aurora cluster endpoint, the connections on database were totally different:

Screenshot 2020-07-25 at 19.38.23

As you can see, this time connections were constantly rising and they stopped at around 220 connections after a while.

Bottom line is, AWS Proxy successfully opened the needed connections and was trying to utilise them to the fullest, so no re-authentication and establishing of new connections to the database was needed. It did exactly as stated by AWS.

Conclusion

Using AWS RDS Proxy helps a lot if you have many connections spamming your database. The failover downtime reductions is just a bonus. I would suggest you to use it, but only if your underlying application programming language does not support connection pooling on its own.

Leave a Reply

help-hint.png
Purpose of the commenting system is to share your experience. I encourage you to post feedback with your own suggestions, ideas or optimizations regarding the topic of a blog post. What commenting system isn't for, is asking questions about similar issues of yours and requesting support for it. Blog post is provided as is and I am not here to solve all your problems. Please bear that in mind and try to avoid posting such comments. I do take privilege to remove comment from my blog for any reason whatsoever. Usually I do it when I sense a comment was posted only for spam/seo reasons or is out of blog post's topic. Thank you for reading this, now you may continue :)
 

Your email address will not be published. Required fields are marked *