I am very happy to talk about the new options available for running a relational database on the cloud and the serverless approach on AWS at the next DevOps Berlin tech event organized by Amsource Technology on June 5th. More information on the Eventbrite page
The abstract of my talk:
From AWS to Google Cloud, the major cloud providers offer different options to run a MySQL or a MySQL compatible database on the cloud. You can spin up virtual machines and configure your own cluster or rely on managed services with the ability to modify or scale vertically a database with the click of a button. The new trend is serverless (relational) databases that offer both traditional interfaces and HTTP API access. Can serverless databases be the future? Is Amazon Aurora Serverless really serverless?
Thanks Jack and Amsource Technology for the invitation and looking forward to see you in Berlin!
Cross Zone Load Balancing is one of the less known and most confusing options of the different load balancers on AWS. Until 2013 the choice was simple, Amazon offered only one load balancer as a service – the Classic Load Balancer – and there was no option to perform Cross Zone Load Balancing. No feature, no doubts, no extra costs.
“With cross-zone load balancing, (…) each load balancer node distributes requests evenly across the registered instances in all enabled Availability Zones. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its Availability Zone only.”
What is the default for the Cross Zone Load Balancing?
Unfortunately the default is different on every load balancer and not very intuitive. As for AWS documentation:
Classic Load Balancer: with the API or CLI, cross-zone load balancing is disabled by default. With the AWS Management Console, the option to enable cross-zone load balancing is selected by default.
Application Load Balancer: cross-zone load balancing is always enabled
Network Load Balancer: cross-zone load balancing is disabled by default. You can enable or disable cross-zone load balancing at any time.
Should I always enable it?
There are many documents and posts on the benefits of enabling cross-zone load balancing. And if you have only one target in every Availability Zone, it is usually an easy choice . But what are the main reasons to disable it or keep it disabled?
Maybe you want to minimise the latency between your load balancer and the application nodes and have all the traffic in the subnet. Or you take advantage of the SSL termination on the load balancer and you do not want to manage not encrypted traffic across data centres and different subnets. Or maybe you want simply to save a few dollars.
Do I pay extra for Cross Zone Load Balancing?
You do not pay for the the feature itself but you might pay for the generated regional data transfer. The voice that in your billing ends up under
$0.010 per GB - regional data transfer - in/out/between EC2 AZs or using elastic IPs or ELB
and that can end in significant charges if you manage large binaries on your load balancers. According to the AWS FAQ, the cost varies according to the specific service.
Q: Am I charged for regional AWS data-transfer for cross-zone load balancing in Application Load Balancer? A: No. Since cross-zone load balancing is always on with Application Load Balancer, you are not charged for this type of regional data transfer.
Q: Am I charged for regional AWS data-transfer when I enable cross-zone load balancing in Network Load Balancer? A: Yes, you will be charged for regional data transfer between Availability Zones with Network Load Balancer when cross-zone load balancing is enabled
Q: Am I charged for regional AWS data-transfer when I enable cross-zone load balancing in Classic Load Balancer? A: No, you are not charged for regional data transfer between Availability Zones when you enable cross-zone load balancing for your Classic Load Balancer.
Cross Zone Load Balancing is a very useful feature and you likely end up enabling it in many common scenarios. But it is vital to understand the default values and the implications according to the specific AWS service you choose.
Going off the beaten track and the most popular conferences in Western Europe lets you have a different prospective, meet very skilled DevOps and challenge your technical knowledge. Very glad to talk about “MySQL on the cloud, from virtual machines to serverless options” at the DevOpsConf Russia in Moscow.
Architectures on the cloud: from traditional deployments to serverless architectures is the title of my talk at the SFI in Krakow. Looking forward to April 5th and a great conference in Poland! The full abstract is available here.
Since 3 years ago, RDS offers the option of running a MySQL database using the T2 instance type, currently from db.t2.micro to db.t2.large. These are low-cost standard instances that provide a baseline level of CPU performance – according to the size — with the ability to burst above the baseline using a credit approach.
You can find more information on the RDS Burst Capable Current Generation (db.t2) here and on CPU credits here.
What happens when you run out of credits?
There are two metrics you should monitor in CloudWatch, the CpuCreditUsage and the CpuCreditBalance. When your CpuCreditBalance approaches zero, your CPU usage is going to be capped and you will start having issues on your database.
It is usually better to have some alarms in place to prevent that, either checking for a minimum number of credits or spotting a significant drop in a time interval. But what can you do when you hit the bottom and your instance remains at the baseline performance level?
How to recover from a zero credit scenario?
The most obvious approach is to increase the instance class (for example from db.t2.medium to db.t2.large) or switch to a different instance type, for example a db.m4 or db.c3 instance. But it might not be the best approach when your end users are suffering: if you are running a Multi-AZ database in production, this is likely not the fastest option to recover, as it first requires a change of instance type on the passive master and then a failover to the new master.
You can instead try a simple reboot with failover: the credit you see on CloudWatch is based on current active host and usually your passive master has still credits available as it is usually less loaded than the master one. As for the sceenshot above, you might gain 80 credits without any cost and with a simple DNS change that minimizes the downtime.
Do I still need to change the instance class?
Yes. Performing a reboot with failover is simply a way to reduce your recovery time when having issues related to the capped CPUs and gain some time. It is not a long term solution as you will most likely run out of credits again if you do not change your instance class soon.
To summarize, triggering a failover on a Multi-AZ RDS running on T2 is usually a faster way to gain credits than modifying immediately the instance class.