ApsaraMQ for RocketMQ:Série 5.x Serverless

Benefícios

As instâncias Serverless do ApsaraMQ for RocketMQ oferecem dimensionamento flexível de recursos e atendem às demandas em diferentes estágios de crescimento do negócio. Os principais benefícios incluem:

• Compatibilidade imediata com as versões open source. Isso permite que você se concentre nas aplicações do negócio sem se preocupar com o tamanho ou a estabilidade dos recursos da instância Serverless. Os desenvolvedores podem focar no código principal do negócio, o que reduz os custos de operações e manutenção (O&M).

• Dimensionamento elástico automático. As instâncias Serverless aplicam políticas de ajuste dinâmico de recursos e escalam automaticamente com base no tráfego em tempo real. As empresas não precisam estimar ou configurar tipos de instância antecipadamente.

• Pagamento conforme o uso real. As cobranças são calculadas com base no consumo efetivo de recursos, como mensagens, recursos de tópico, tráfego de rede e armazenamento. O faturamento é feito por hora, de acordo com o uso dos recursos. Isso implementa de fato o modelo de pagamento conforme o uso, o que ajuda a economizar custos.

Capacidades de elasticidade

As capacidades de elasticidade se dividem em elasticidade sem perdas e elasticidade adaptativa, conforme afetem ou não as requisições de envio e recebimento de mensagens do cliente durante o dimensionamento:

• Elasticidade sem perdas: durante o dimensionamento elástico, as requisições de envio e recebimento de mensagens permanecem sem erros e sem impacto. O limiar inicial de limitação de taxa corresponde ao limiar de elasticidade sem perdas.

• Elasticidade adaptativa: ao ultrapassar o limiar de elasticidade sem perdas, o servidor aplica regras de elasticidade adaptativa com base no tráfego do serviço. Durante o scale-out, o tráfego do serviço é limitado. Após o scale-out, o limiar de limitação de taxa aumenta.

  • O tamanho do incremento de scale-out e scale-in varia conforme o tipo de instância reservada:

    • No modo de capacidade acumulada, o incremento é de aproximadamente 25.000 TPS.

    • No modo de capacidade reservada e elástica, o incremento é aproximadamente igual ao tamanho do tipo de instância reservada.

  • Cada operação de scale-out leva alguns minutos. Tipos de instância reservada maiores demandam mais tempo.

  • O sistema verifica o tráfego da instância em uma janela de aproximadamente 10 minutos. Se o tráfego diminuir, ocorre uma operação de scale-in. Cada operação de scale-in reduz a capacidade em um incremento.

Alocação de TPS reservado

Por padrão, o TPS reservado é distribuído igualmente entre envio e consumo de mensagens (50% cada). Essa proporção não pode ser ajustada automaticamente. Para alterar a proporção, é necessário configurar manualmente o percentual reservado.

Exemplo: se o TPS reservado é 2.000 e a proporção entre envio e consumo é 50:50, o limite de TPS para envio e para consumo de mensagens é de 1.000 em cada caso.

Capacidades das séries

O limiar de elasticidade sem perdas é calculado da seguinte forma:

• Fórmula: limiar de elasticidade sem perdas = tipo de instância reservada + capacidade de elasticidade sem perdas.

• Compartilhada:

  • Acumulada: limiar de elasticidade sem perdas = tipo de instância reservada (0) + capacidade de elasticidade sem perdas (50.000) = 50.000.

  • Reservada e elástica: limiar de elasticidade sem perdas = tipo de instância reservada (1x) + capacidade de elasticidade sem perdas (2x tipo de instância reservada) = tipo de instância reservada x 3.

• Exclusiva:

  • Reservada e elástica: limiar de elasticidade sem perdas = tipo de instância reservada (1x) + capacidade de elasticidade sem perdas (0,5x tipo de instância reservada) = tipo de instância reservada x 1,5.

Impacto do upgrade ou downgrade nos limiares de limitação de taxa

Após o upgrade ou downgrade do tipo de instância reservada, o limiar de limitação de taxa da instância é calculado como: MAX(current rate limiting threshold, lossless elasticity rate limiting threshold after upgrade or downgrade). Esse valor representa o maior valor entre o limiar atual de limitação de taxa e o limiar de elasticidade sem perdas após o upgrade ou downgrade.

Arquitetura das instâncias Serverless

As instâncias Serverless do ApsaraMQ for RocketMQ 5.x utilizam isolamento de recursos multi-tenant. Isso garante que as operações de negócio entre instâncias não interfiram umas nas outras.

O ApsaraMQ for RocketMQ containeriza todos os componentes técnicos. Aproveitando a natureza escalável da nuvem, aloca de forma flexível os recursos subjacentes de computação, armazenamento e rede.

Assim, as instâncias Serverless do ApsaraMQ for RocketMQ respondem rapidamente às mudanças na demanda de recursos de cada locatário. Elas realizam dimensionamento elástico contínuo no modo Serverless, atendendo de forma flexível e precisa às necessidades do seu negócio.

Limites

Atualmente, as instâncias Serverless suportam apenas as seguintes regiões: China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Shenzhen), China (Chengdu), Singapore, Germany (Frankfurt) e US (Virginia). Outras regiões serão disponibilizadas gradualmente.

Acesso à rede

Para comunicação dentro da mesma VPC, é necessário ativar o PrivateLink para instâncias Serverless. A arquitetura de rede das instâncias Serverless utiliza o PrivateLink para implementar comunicação segura e estável por rede privada.

Suporte a protocolo

As instâncias Serverless suportam apenas conexões pelo protocolo TCP. O acesso via API HTTP pela rede pública não é suportado.

Faturamento

Para as regras específicas de faturamento das instâncias Serverless, consulte Faturamento de instâncias Serverless.

FAQ

O console das instâncias Serverless do ApsaraMQ for RocketMQ suporta o envio de mensagens ordenadas ou mensagens com atributos personalizados?

O recurso Quick Experience no console das instâncias Serverless atualmente suporta apenas o envio de mensagens normais. A definição de atributos personalizados pelo usuário não é suportada. Se você precisar enviar mensagens ordenadas ou mensagens com atributos personalizados, utilize o SDK.

A atualização para LiteTopic (tópico leve) afeta a funcionalidade dos tópicos normais existentes?

A adição da tag version_capability:lite-topic não afeta a funcionalidade dos tópicos normais existentes. Os tópicos leves coexistem com os tópicos normais como contêineres secundários. Os tipos de tópicos existentes (mensagens normais, ordenadas e transacionais) e a lógica de consumo permanecem inalterados. A atualização adiciona apenas recursos específicos dos tópicos leves, como criação dinâmica, expiração automática e consumo ordenado por fila única.

O ApsaraMQ for RocketMQ 4.x ou 5.x Serverless é mais econômico para desenvolvimento e depuração?

(Recomendado) Use o 5.x Serverless. O ApsaraMQ for RocketMQ 4.x Standard Edition é cobrado com base no uso de recursos de tópico e nas chamadas de API. O ApsaraMQ for RocketMQ 5.x suporta faturamento conforme o uso com Serverless e TPS elástico. Armazenamento e computação são cobrados com base no uso real, o que evita desperdício de recursos. A arquitetura elástica também é mais adequada para cenários com tráfego flutuante, reduzindo custos de longo prazo.

Como posso controlar os custos ao migrar do AWS SQS para o ApsaraMQ for RocketMQ Serverless?

Para atingir custos comparáveis ao AWS SQS, use uma instância standard. Se utilizar uma instância Serverless, adapte sua aplicação para usar o SDK gRPC, utilize acesso por rede privada para evitar custos de tráfego de Internet e mantenha o tamanho das mensagens em até 4 KB.

Quando as instâncias Serverless suportarão a visualização de dados de clientes online?

As instâncias Serverless do ApsaraMQ for RocketMQ têm previsão de concluir uma atualização unificada neste mês (até o dia 25) para suportar a visualização de dados de clientes online. Os usuários serão notificados uma semana antes da atualização.