ApsaraMQ for RocketMQ 5.x Serverless instances automatically scale resources based on your service payload. Resources are allocated and billed according to actual usage, which helps you save costs. This topic describes the benefits, scenarios, and working principles of Serverless instances.
Benefits
ApsaraMQ for RocketMQ Serverless instances provide flexible resource scaling to meet your business needs at different stages of growth. The core benefits are as follows:
Ready to use and compatible with open source versions. The instances are application-centric, which means you do not need to manage their resource scale or stability. This lets developers focus on core business code and reduces your operations and maintenance (O&M) costs.
Adaptive elasticity. Serverless instances use a dynamic resource adjustment policy to automatically scale resources based on real-time service payloads. You do not need to estimate and configure the instance type in advance.
Pay for what you use. Billing is based on your actual usage of resources, such as message volume, topic resources, network traffic, and storage. Fees are settled hourly based on resource usage. This pay-as-you-go model helps you save costs.
Elasticity capabilities
Elasticity capabilities are categorized as lossless or adaptive based on whether client message requests are affected during elastic scaling:
Lossless elasticity: During elastic scaling, message requests are unaffected. The initial value for the throttling threshold is the lossless elasticity throttling threshold.
Adaptive elasticity: When service traffic exceeds the lossless elasticity throttling threshold, the server executes adaptive elasticity rules. During a scale-out, service traffic is throttled. After the scale-out is complete, the throttling threshold increases.
The scale-out or scale-in step size varies based on the reserved specification:
For the cumulative usage capacity mode, the step size is approximately 25,000 TPS.
For the reserved + elastic capacity mode, the step size is approximately the size of the reserved specification.
Each scale-out takes several minutes. The larger the reserved specification, the longer the operation takes.
Instance traffic is checked in a window of approximately 10 minutes. If instance traffic decreases, a scale-in operation is performed. Each scale-in reduces the capacity by one step size.
Series capabilities
Item | Shared | Dedicated | |
Cumulative usage | Reserved + elastic | Reserved + elastic | |
Deployment mode | Physically shared; logically single-tenant | Physically shared; logically single-tenant | Physically dedicated, exclusive physical nodes |
Capacity mode |
|
|
|
Lossless elasticity |
|
|
|
Adaptive elasticity | Supported | Supported | Not supported |
Maximum throttling threshold | min(300,000, Reserved specification × 10) | min(300,000, Reserved specification × 10) | Reserved specification × 1.5 |
The lossless elasticity throttling threshold is calculated as follows:
Formula: Lossless elasticity throttling threshold = Reserved specification + Lossless elasticity capability.
Shared:
Cumulative usage: Lossless elasticity throttling threshold = Reserved specification (0) + Lossless elasticity capability (50,000) = 50,000.
Reserved + elastic: Lossless elasticity throttling threshold = Reserved specification (1×) + Lossless elasticity capability (2× reserved specification) = Reserved specification × 3.
Dedicated:
Reserved + elastic: Lossless elasticity throttling threshold = Reserved specification (1×) + Lossless elasticity capability (0.5× reserved specification) = Reserved specification × 1.5.
Effects of upgrades and downgrades on the throttling threshold
After you upgrade or downgrade an instance by changing its reserved specification size, the new throttling threshold for the instance is: MAX(Current throttling threshold, Lossless elasticity throttling threshold of the instance after the upgrade or downgrade). This means the threshold is set to the greater of the current throttling threshold and the lossless elasticity throttling threshold of the instance after the change.
Serverless instance architecture
ApsaraMQ for RocketMQ 5.x Serverless instances use multitenancy resource fencing to ensure that different instances do not interfere with each other.
All technical components of ApsaraMQ for RocketMQ are deployed in containers. This approach leverages the scalability of the cloud to flexibly allocate underlying computing, storage, and network resources.
Therefore, ApsaraMQ for RocketMQ Serverless instances can quickly respond to changes in resource requirements from each tenant. This enables seamless elastic scaling to meet your business needs.
Limits
Serverless instances are currently available only in the following regions: China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Shenzhen), China (Chengdu), Singapore, Germany (Frankfurt), and US (Virginia). Support for additional regions will be available soon.
Billing description
For information about the billing rules for Serverless instances, see Billing of Serverless instances.