Modern cloud services aim to allocate resources if and only if the customers use these resources to optimize quality of service and operational cost efficiency. Recent approaches have evolved from merely reactive policies to proactive decision making. These approaches leverage not only the current resource demand but also the predicted future demand to make more informed resource allocation decisions for each database. We define a proactive resource allocation policy and design a distributed infrastructure that enables proactive resource allocation capabilities for millions of serverless Azure SQL databases that are currently deployed worldwide. Our solution finds near-optimal middle ground between high availability of resources, low operational costs, and low computational overhead of the proactive policy. Given the size and scope of our analysis, we believe that our conclusions and lessons learned generalize to latency-sensitive cloud services in other companies. In fact, we have applied the proactive policy to optimize resource allocation for Azure AI Search and achieved similar results.
Status
Deployed WW for Azure SQL Database Serverless
Impact
- To guarantee high quality of service, we reduce delays in resource availability on login. To this end, we predict login patterns per database and proactively activate resources ahead of predicted customer activity. 80% of logins after idle intervals are proactive and correct. Vast majority of long-lived databases benefit from proactive activation.
- To reduce the operational costs, we deactivate the resources during predicted long idle intervals. These resources are reused to serve current workloads of active databases.
- To minimize the overhead of frequent scaling operations, we avoid deactivating resources during short idle intervals. To keep the computational and storage overhead low, we tightly couple the pause\resume history storage and analytics with each database. The latency of proactive decisions stays within one second, while the size of pause\resume history is within a few kilobytes per database.