ApsaraMQ for RocketMQ:5.x Serverless Series

Benefits

ApsaraMQ for RocketMQ Serverless instances offer flexible resource scaling capabilities. They meet resource demands across various stages of business growth. Key benefits include the following:

• Out-of-the-box compatibility with open source versions. This lets you focus on business applications without concerns about Serverless instance resource size or stability. Developers can then concentrate on core business code development, which reduces enterprise operations and maintenance (O&M) costs.

• Automatic elastic scaling. Serverless instances employ dynamic resource adjustment policies, automatically scaling based on real-time service traffic. Enterprises do not need to estimate or configure instance types in advance.

• Pay-as-you-go based on actual usage. Fees are calculated based on your actual usage of resources, such as messages, topic resources, network traffic, and storage. Fees are settled hourly based on resource usage. This truly implements pay-as-you-go billing, which helps save costs.

Elasticity Capabilities

Elasticity capabilities are divided into lossless elasticity and adaptive elasticity, depending on whether they affect client message sending or receiving requests during scaling:

• Lossless elasticity: During elastic scaling, message sending and receiving requests remain error-free and unaffected. The initial rate limiting threshold is the lossless elasticity rate limiting threshold.

• Adaptive elasticity: After exceeding the lossless elasticity rate limiting threshold, the server-side further applies adaptive elasticity rules based on service traffic. During scale-out, service traffic is rate-limited. After scale-out, the rate limiting threshold increases.

  • The scale-out and scale-in step size varies based on the reserved instance type:

    • For the cumulative capacity mode, the step size is approximately 25,000 TPS.

    • For the reserved and elastic capacity mode, the step size is approximately the size of the reserved instance type.

  • Each scale-out operation takes minutes. Larger reserved instance types require more time.

  • The system checks instance traffic within an approximately 10-minute window. If instance traffic decreases, a scale-in operation occurs. Each scale-in operation reduces capacity by one step.

Reserved TPS allocation

By default, reserved TPS is allocated equally between message sending and consuming (50% each). This ratio cannot be adjusted automatically. To modify the ratio, you must manually configure the reserved percentage.

Example: If the reserved TPS is 2,000 and the send-to-consume ratio is 50:50, the TPS limit for both message sending and consuming is 1,000 respectively.

Series Capabilities

The lossless elasticity rate limiting threshold is calculated as follows:

• Formula: Lossless elasticity rate limiting threshold = Reserved instance type + Lossless elasticity capability.

• Shared:

  • Cumulative: Lossless elasticity rate limiting threshold = Reserved instance type (0) + Lossless elasticity capability (50,000) = 50,000.

  • Reserved and Elastic: Lossless elasticity rate limiting threshold = Reserved instance type (1x) + Lossless elasticity capability (2x reserved instance type) = Reserved instance type x 3.

• Exclusive:

  • Reserved and Elastic: Lossless elasticity rate limiting threshold = Reserved instance type (1x) + Lossless elasticity capability (0.5x reserved instance type) = Reserved instance type x 1.5.

Impact of Upgrade or Downgrade on Rate Limiting Thresholds

After upgrading or downgrading the reserved instance type, the instance's rate limiting threshold is calculated as: MAX(current rate limiting threshold, lossless elasticity rate limiting threshold after upgrade or downgrade). This value represents the greater of the current rate limiting threshold and the lossless elasticity rate limiting threshold after the upgrade or downgrade.

Serverless Instance Architecture

ApsaraMQ for RocketMQ 5.x Serverless instances utilize multi-tenant resource isolation. This ensures that business operations across instances do not interfere with each other.

ApsaraMQ for RocketMQ containerizes all technical components. Leveraging the scalable nature of the cloud, it flexibly allocates underlying compute, storage, and network resources.

Therefore, ApsaraMQ for RocketMQ Serverless instances rapidly respond to changes in resource demands from each tenant. They achieve seamless elastic scaling in Serverless mode, which flexibly and precisely meets your business needs.

Limits

Serverless instances currently support the following regions only: China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Shenzhen), China (Chengdu), Singapore, Germany (Frankfurt), and US (Virginia). Other regions will be made available gradually.

Network access

To communicate within the same VPC, you must activate PrivateLink for Serverless instances. The network architecture of Serverless instances relies on PrivateLink to implement secure and stable private network communication.

Protocol support

Serverless instances support TCP protocol connections only. HTTP API access over the public network is not supported.

Billing

For specific billing rules for Serverless instances, see Serverless Instance Billing.

FAQ

Does the ApsaraMQ for RocketMQ Serverless instance console support sending ordered messages or messages with custom attributes?

The Quick Experience feature on the Serverless instance console currently supports sending only normal messages. Setting user-defined custom attributes is not supported. If you need to send ordered messages or messages with custom attributes, use the SDK instead.

Does upgrading to LiteTopic (lightweight topic) affect existing normal topic functionality?

Adding the version_capability:lite-topic tag does not affect existing normal topic functionality. Lightweight topics coexist with normal topics as secondary containers. Existing topic types (normal, ordered, and transactional messages) and consumption logic remain unchanged. The upgrade only adds features specific to lightweight topics, such as dynamic creation, automatic expiration, and single-queue ordered consumption.

Is ApsaraMQ for RocketMQ 4.x or 5.x Serverless more cost-effective for development and debugging?

(Recommended) Use 5.x Serverless. ApsaraMQ for RocketMQ 4.x Standard Edition is billed based on topic resource usage and API calls. ApsaraMQ for RocketMQ 5.x supports pay-as-you-go billing with Serverless and elastic TPS. Storage and compute are billed based on actual usage, which avoids resource waste. The elastic architecture is also better suited for scenarios with fluctuating traffic, reducing long-term costs.

How can I control costs when migrating from AWS SQS to ApsaraMQ for RocketMQ Serverless?

To achieve costs comparable to AWS SQS, use a standard instance. If you use a Serverless instance, adapt your application to use the gRPC SDK, use private network access to avoid Internet traffic fees, and keep message sizes at or below 4 KB.

When will Serverless instances support viewing online client data?

ApsaraMQ for RocketMQ Serverless instances are scheduled to complete a unified upgrade this month (by the 25th) to support viewing online client data. Users will be notified one week before the upgrade.