Serverless V2 Cost Reduction Case Study • Aurora Serverless V2 Performance and Scaling • The decision points to consider when adopting Aurora Serverless v2, as well as the features, cost benefits, and disadvantages of Aurora Serverless v2
V2? • Relational Database with on-demand Auto Scaling configuration • High Availability (Same as Aurora Provisioned) • High Durability (Same as Aurora Provisioned) • High Scalability (Hundreds of thousands of transactions) • High cost-effectiveness • Serverless and Provisioned instances can be used together Amazon Aurora Amazon Aurora Auto Scaling CPU, RAM and Network https://docs.aws.amazon.com/ja_jp/AmazonRD S/latest/AuroraUserGuide/Aurora.Overview.html
Capacity Units (ACU): Aurora Serverless V2 Capacity Units 1ACU: 2GB Memory, corresponding CPU, and networking Minimum ACU: 0.5～ Maximum ACU: ～128 Cost(1ACU): USD 0.20/h (ap-northeast-1) Automatically scales between a specified minimum and maximum capacity https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is- generally-available-instant-scaling-for-demanding-workloads/
features • WEB AP • Complex search functions • 500,000 users • 1000～500,000 sign in event per days (Random) • 50,000 system linkage events per hours (Random) • All responses within 3 seconds • Running 24 hours 365 days (Exclude maintenance time) • Built on private cloud (On-premises) Private Cloud Production WEB Servers DB Servers Staging AP Servers WEB Servers DB Servers AP Servers Other linkage Systems
use on weekdays between 9:00 and 5:00, but also used on holidays and at night • Difficult to make necessary predictions, Must meet performance requirements • High availability required (If the system is down, affects other systems.) • High performance required • Take advantage of the scalability and flexibility of the cloud • EC2 can match demand through scaling, but databases must be provisioned for maximum requirements • Not an environment where continuous monitoring and configuration review is easily possible due to 24-hour operation Sample System Usage A B Requirement of Performance Provisioning according to performance requirements is expensive
Lift to AWS • Using Aurora Serverless V2 • Saving over $4,000 per month（Only Database） • Comply with performance and availability requirements AWS Cloud (Production) Virtual private cloud (VPC) Private subnet Private subnet Private subnet Private subnet AP Servers AP Servers Private subnet Private subnet WEB Servers WEB Servers DB#1(Writer) DB#2(Writer) DB#1(Reader) DB#2(Reader) Availability Zone 1 Availability Zone 2 AWS Cloud (Staging) Same on left Aurora Serverless V2 EC2 AutoScaling In order to use resources efficiently when demand is unpredictable, we wanted to scale not only EC2 but also DB according to demand.
Aurora Serverless V2 Cost • In this case, the cost benefit of adopting ServelessV2 is low unless the average ACU used is below 14. • Cost performance of AuroraServelessV2 on a per unit basis is very bad. Provisioned Serverless V2 vCPU Memory CPU:16Core Memory:128GiB 14ACU(28GiB) Instance Type r5.4xlarge Serverless V2 Pricing Model OnDemand - Node 4(8)※MultiAZ 4(8)※MultiAZ Multi-AZ True True Cost(ap-northeast- 1) 16,352.00 USD/Month 16,352.00 USD/Month Cost Performance(USD/ Memory(1GiB)) 15.96USD/GiB 73USD/GiB 0 10 20 30 40 50 60 70 80 Cost Performance(USD/GiB) r5.4xlarge(On-Demand) Serverless V2
enough to look only at cloud usage fees. The following costs should be considered. • Changes to match demand and peak times • Periodic review of instance types • Testing after changes • Making automatic scaling, etc. Aurora Serverless V2 Cover and Cut above the cost
Provisioned Serverless V2 vCPU Memory CPU:16Core Memory:128GiB CPU:16Core Memory:128GiB Min:2ACU(4GiB) Max:64ACU(128 GiB) Instance Type - r5.4xlarge Serverless V2 Pricing Model - OnDemand - Node 4(8)※MultiAZ 4(8)※MultiAZ 4(8)※MultiAZ Multi-AZ - True True Cost(ap- northeast-1) - 16,352.00 USD/Month 4,000～8,000 USD/Month ※Actual value 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 Cost Saving Provisioned Serverless V2 Reduced Over 4,000USD/Month • Initially assumed to use r5.4xlarge instances because it is very close to On-premise instances. • We found that there is a lot of unpredictable load based on the demand for on-premise use, the need to adhere to a defined response time for the maximum request expected, and that the load varies significantly by time. • Our choice to use Aurora allowed us to scale flexibly and saved us about 4,000USD/Month in unnecessary costs.
allow for massive cost savings? Because it fits the following features • Large-scale changes in usage • Must withstand maximum load at all times • Difficult to make necessary predictions • Rarely loaded at peak capacity • Not an environment where continuous monitoring and configuration review is easily possible due to 24-hour operation • Normal low utilization compared to maximum on requirements Sample System Usage A B Requirement of Performance
& Scaling • Scales instantly with the load at the following specified values • Minimum ACU • Depending on the case, you may want to specify a memory size that allows the application to run as required with a minimum load • Smaller is more cost-effective, but is a trade-off for performance and scale-up • Maximum ACU • Specify the maximum request value
& Scaling • ScaleUP • Quickly increase ACU as workload demands begin to reach the writer or reader's current database capacity • Larger instances scale up faster →Set minimum ACU to a value that meets scaling rate requirements • ScaleDown • Scale down incrementally until you reach the capacity you need for your workload →Performance is unlikely to be affected because it does not decrease rapidly https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is- generally-available-instant-scaling-for-demanding-workloads/
ACUUtilization CPUUtilization CommitLatency ReadLatency WriteLatency • Scaled quickly to CPU utilization and experienced no performance or scaling issues • Scaling speed and performance must be tested according to requirements and expected scenarios(You should tune the Minimum ACU and Maximum ACU size according to the test results)
use of Aurora Serverless V2 Low average utilization relative to performance requirements (current situation) Highly difficult to predict load Operational tasks such as scaling are difficult Unacceptable downtime due to scaling Cost reduction through scaling
load constant and does it deviate from the performance requirements? Are there potential changes in performance requirements or resource utilization? Aurora Provisioned Instance (OnDemand) Is the scaling speed of ServelessV2 meeting your requirements and is the range of load variability difficult to predict? Aurora Provisioned Instance (Reserved) Aurora Serverless V2 Is the ServerlessV2 simulated price lower than the provisioned instance price? Is there an operational structure in place that can implement scaling and changes to match the load? If so, is the operational cost lower than the cost of using AuroraServerlesV2? YES YES YES No No Yes No No YES No
Ease of adaptation to demand ServelessV2 Provisioned (On-Demand) Provisioned (Reserved) • Aurora Serverless V2 offers flexible scaling, Depending on the case, large-scale cost reductions are also possible • On the other hand, cost savings are case-by-case • It is difficult to say that cost efficiency is necessarily good, so instance type should be selected according to the case • Operating costs should also be taken into account • Cloud usage fees should be simulated. • Scaling performance should always be tested to meet requirements
Performance Performance Availability Security Speed • Most choices involve trade-offs • There is no one-size-fits-all solution to the problem • Usage, AWS services, and fees are subject to change, so periodic review is important • Let's choose according to the features!
kawakawa2222
cromwellryan
davidbonilla
samanthasiow
wjessup
samlambert
jacobian
caitiem20
colly
destraynor
marcelosomers
trishagee
mongodb
