Switching Ameba's Aurora MySQL to I/O Optimized cut our costs in half.
#SRGThe Service Reliability Group primarily provides comprehensive support for the infrastructure surrounding our media services, focusing on improving existing services, launching new ones, and contributing to open-source software (OSS).
This article summarizes how we were able to reduce our database costs by approximately half by utilizing Aurora I/O Optimized.
I hope this is of some help.
First, let's look at the results of switching on Ameba.What is Aurora I/O Optimized?Check in Cost Explorer whether it's better to switch to I/O Optimized.Calculation results under provisional conditionsLet's try displaying the cost breakpoint for I/O volume using a Datadog graph.Switch to I/O OptimizedIn conclusion
First, let's look at the results of switching on Ameba.
We switched the Aurora MySQL cluster used by a certain microservice at Ameba to I/O Optimized at the end of October.
The following is a graph showing the costs of the Aurora MySQL cluster in question over the past four months.
You can see that the expenses in November were halved compared to the expenses from August to October.
What is Aurora I/O Optimized?
This is the new pricing structure for Aurora cluster storage announced by Amazon in May 2023.
To useAurora MySQL version 3.03.1 or laterIt must be the correct version.
Aurora's standard pricing structure includes the following three costs:
I/Oオペレーション量の費用Since I/O costs are charged per million requests, it was difficult to estimate the exact amount in advance.
Switching to Aurora I/O Optimized will eliminate I/O costs, allowing for more accurate cost estimates.
Furthermore, cost optimization is possible by switching to a different cluster that is currently experiencing high I/O costs.
RDS Aurora pricing tableI will quote some of the specifications from there.
Since there are no I/O charges, the instance and storage costs are set at a higher price.
の増額)As mentioned on the release page for this feature, it's important to note that applying this I/O Optimized setting to an Aurora cluster with relatively low I/O activity may actually increase your costs.
Check in Cost Explorer whether it's better to switch to I/O Optimized.
You can use Cost Explorer to determine whether you should switch an active cluster to I/O Optimized mode.
First, by properly setting the cost allocation tags in Cost Explorer, you will be able to check the cost for each cluster.
Next, open Cost Explorer and set the filter menu on the right side as follows:
Date range:Period to compare
Particle size:By month
dimension:Usage type
service:Relation Database Service(RDS)
tag:[Name tag of the cluster whose costs you want to check]
Applying this filter will display a graph like the one below, allowing you to see the amount and breakdown of your RDS costs.
Furthermore, you can narrow down the usage fees for Aurora storage in the Tokyo region by using the "Usage Type" filter.
APN1-Aurora:StorageIOUsage(IOs)APN1-Aurora:StorageUsage(GB-Month)
The charges displayed here are for I/O and storage usage.
The higher the proportion of I/O charges in your overall RDS billing costs, the more likely it is that switching to Aurora I/O Optimized would be beneficial.
Calculation results under provisional conditions
Since I cannot show you the actual costs in your environment, I have calculated the costs using Aurora MySQL under the following conditions.
| Region | Tokyo Region |
|---|---|
| Instance type | db.r6g.xlarge |
| Number of operating units | 3 units |
| Cluster storage usage | 500GB |
| Total average monthly RDS costs | 3,300 USD |
| Of which, the average monthly I/O fee | 1,900 USD |
RDS instance pricing table for the relevant specifications
| Standard rate (per hour) | I/O Optimized (per hour) | |
|---|---|---|
| r6g.xlarge | 0.627USD | 0.815USD |
RDS storage charges
| Standard rate (monthly) | I/O Optimized (monthly fee) | |
|---|---|---|
| Storage fees | 0.12USD / GB | 0.27USD / GB |
In this cluster3,300 USD per monthRDS costs are incurred,Of that, 1,900 USD was for I/O fees.That's the assumption.
If you switch to I/O Optimized, the calculation will be as follows:
The I/O Optimized rate for db.r6g.xlarge is 0.815 USD per hour, so the cost for three servers would be 1,760 USD, as calculated below.
Using 500GB of storage, the cost is $60 USD, calculated at the I/O Optimized storage rate of $0.27 USD/GB.
The total cost, including instance and storage fees, comes to 1,820 USD.
Since it's I/O Optimized, the price includes I/O charges.
In other words, under this assumption, switching to I/O Optimized means,
It is possible to reduce the monthly RDS cost from $3,300 USD to $1,820 USD, saving $1,480 USD per month.
This is what we were able to estimate.
Let's try displaying the cost breakpoint for I/O volume using a Datadog graph.
Mr. Nakajima, who wrote the article on mob cost analysis for the CA SRE Advent Calendar.I was taught how to display the monthly I/O volume and the cost break-even point for I/O Optimized in a Datadog graph.
In this graph example, we assume a configuration of "three db.r6g.large instances with a full year's worth of reserved instances paid in advance."
In this example, it's immediately clear that, given the I/O volume over the past month, switching to I/O Optimized would likely be cheaper.
Conversely, if the results are as shown in the graph below, it becomes clear that switching to I/O Optimized would be more expensive.
This graph can be reproduced by editing the following JSON as needed.
The following section, which draws the cost break-even point, requires you to calculate the monthly instance cost for the cluster yourself.
Switch to I/O Optimized
You can change the settings on the configuration screen for the target RDS cluster from the console.
Since "Standard" is currently selected, select and apply "Aurora I/O Optimization".
This change can be applied online with virtually no downtime.
Other points to note are as follows:
スタンダード から I/O Optimizedへの変更は30日間に1回まで
I/O Optimized から スタンダードへの変更はいつでも可能
NVMeベースのDBインスタンスの場合はダウンタイムが伴う再起動が必要な場合がある
Please refer to the official documentation for more details.
In conclusion
At Ameba, we've been working on upgrading to Aurora MySQL version 3 since last year, and with that upgrade, we've finally been able to use Aurora I/O Optimized.
In this case, we were able to cut costs in half, but the effect will vary depending on your I/O usage, so please try calculating it for your own environment!
SRG is looking for new team members.
If you are interested, please contact us here.