Ampliar o cliente de API com a multiconexão

A solução-padrão do cliente da WhatsApp Business API é executada em um único contêiner do Docker. Caso você queira dividir a carga e contar com vários servidores enviando e recebendo mensagens ao WhatsApp, use a nossa solução de multiconexão.

Visão geral

Com a alta disponibilidade, apenas um contêiner do Docker é responsável por enviar e receber mensagens dos servidores do WhatsApp. Se o tráfego de mensagens ultrapassar a taxa de transferência de dados máxima de um contêiner do Docker, haverá uma fila de envios, aumentando a latência da entrega de mensagens. Para a ampliação do cliente da WhatsApp Business API, a multiconexão é compatível com o uso de fragmentação para distribuir cargas em diversos contêineres do Docker. Atualmente, oferecemos compatibilidade apenas com a fragmentação estática, com uso de 1, 2, 4, 8, 16 ou 32 fragmentos. A alta disponibilidade é um caso especial de multiconexão em que o número de fragmentos é 1.

Um cluster de multiconexão com 2 fragmentos

No cluster, há dois nós Coreapp (CoreApp 1 e CoreApp 3) responsáveis por enviar e receber mensagens do servidor do WhatsApp ao mesmo tempo. Cada mensagem pertencerá a somente um fragmento com base na identificação do destinatário.

Fragmentação

O cliente da WhatsApp Business API usa fragmentação para obter multiconexão. Dependendo do número de fragmentos configurado, o banco de dados armazenará um mapa de fragmentos que determina qual fragmento deve receber uma mensagem com base no ID do destinatário (ou nome de usuário do WhatsApp). A função para determinar isso é:

shard_id = hash(recipient-id) % shard-number

Cada fragmento é mapeado para um contêiner do Docker em execução (Coreapp). O Webapp saberá para qual contêiner Docker enviar a solicitação de mensagem com base no que essa função retornar. Recomenda-se configurar o número de fragmentos + X máquinas para que seja possível suportar X falhas de máquina.

No diagrama de multiconexão de dois fragmentos acima, as mensagens são encaminhadas para CoreApp 1 e CoreApp 3 com base na função de fragmentação. CoreApp 2 é secundário. Ele está receptivo, mas não tem conexões ativas com os servidores do WhatsApp. Suponha que CoreApp 1 receba mensagens para shard=0, e CoreApp 3 receba mensagens para shard=1. Se CoreApp 1 expirar, apenas as mensagens para shard=0 serão afetadas. O sistema ainda enviaria e receberia mensagens que pertencem a shard=1 usando CoreApp 3. Assim como a alta disponibilidade, o Master 1 detectará a falha do CoreApp 1 e fará failover do tráfego de shard=0 para CoreApp 2. Esse failover levará aproximadamente 35 segundos para ser ativado.

Como configurar a multiconexão

Depois de configurar o seu cluster de acordo com a Documentação de alta disponibilidade, use a seguinte solicitação para ativar a multiconexão.

Solicitação

POST /v1/account/shards
{
    "cc": "country-code",
    "phone_number": "phone-number",
    "shards": 1 | 2 | 4 | 8 | 16 | 32,
    "pin": "pin",
    "cert": "verified-name-cert-in-base64"
}

Parâmetros

Resposta

201 Created   : You successfully changed shard number 
403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it

Como recuperar informações de fragmento

Solicitação

GET /v1/account/shards

Resposta

{
  "account": {
      "shards": number-of-shards 
  }
}

Taxas de envio de mensagem

Confira Referência, mensagens, desempenho.

Detalhes de implantação da AWS

URLs de modelo:

• Empresa: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• DB: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_db.yml?versionId=3.vthzENa7qUOuZrozcX9hDk9n8.kdTg
• Lambda: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_lambda.yml?versionId=gqIhZaXkX_NylKaPJMDBlQNk9.Pl_34b
• Rede: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

O modelo permite que você configure o número de instâncias de contêiner ativas do Coreapp a serem criadas. O modelo cria uma instância de contêiner adicional do Coreapp para ajudar na troca rápida no caso de falha do Coreapp.

Quando a alta disponibilidade estiver habilitada, o modelo criará por padrão a seguinte quantidade de instâncias por tipo de ambiente para multiconexão:

• Produção – instâncias de EC2: 3; contêiner da web: 3; contêiner do Coreapp: 3; contêiner mestre: 3
• Preparo – instâncias de EC2: 2; contêineres da web: 2; contêiner do Coreapp: 2; contêiner mestre: 2

O modelo é configurado para dimensionamento automático de instâncias de EC2 dependendo da utilização da memória. A utilização da memória aumenta ou diminui conforme o número de instâncias de contêiner “ativas” do Coreapp. Assim, quando mais instâncias do Coreapp forem criadas, as instâncias de EC2 serão dimensionadas de forma automática e correspondente. No entanto, o número máximo de instâncias de EC2 passíveis de criação é limitado da seguinte maneira:

Tamanho da instância RDS

A taxa de solicitações de API e o número de instâncias ativas do Coreapp determinam o número de conexões ao banco de dados. Com oito instâncias ativas do Coreapp e uma taxa de API de 100 mensagens/segundo, é necessário ter cerca de 700 conexões de DB (SSL desabilitado) e 1.200 conexões de DB (com SSL desabilitado). No entanto, com 32 instâncias ativas do Coreapp e uma taxa de API de 250 mensagens por segundo, é necessário ter cerca de 1.700 conexões de DB.

Na versão atual, usamos db.m4.2xlarge para oito instâncias ativas do Coreapp (criptografia de conexão de DB desabilitada) e db.m4.4x.large para 32 instâncias ativas do Coreapp (criptografia de conexão de DB desabilitada). A tabela a seguir fornece orientação sobre a seleção de classe de instância de RDS e sobre o número máximo de conexões aceito:

Configuração

• As instâncias ativas do Coreapp definidas em um modelo regem apenas o número de instâncias do Coreapp criadas. No entanto, para ativá-las, é necessário usar a opção Definir fragmentos (documentada na seção Configuração da multiconexão). O valor padrão dos fragmentos é 1.
• O número de instâncias do Coreapp deve sempre ser maior ou igual ao número de fragmentos definidos na API.
• Para aumentar o número de fragmentos:

  • Crie ou atualize a pilha com o número desejado de instâncias ativas do Coreapp.
  • Depois, use Definir fragmentos para ativar o mesmo número de instâncias/fragmentos ativos do Coreapp.
  • Observação: Definir fragmentos causa a interrupção e reinicialização automática de todas as instâncias de contêiner do Coreapp. Haverá um tempo de inatividade de cerca de 45 segundos a um minuto após a execução de Definir fragmentos.
• Para diminuir o número de fragmentos:

  • Use Definir fragmentos para reduzir o mesmo número de instâncias/fragmentos ativos do Coreapp.
  • Após a reinicialização bem-sucedida de todas as instâncias do Coreapp, atualize a pilha com o mesmo número de instâncias ativas do Coreapp.
  • Observação: a atualização da pilha pode encerrar as instâncias ativas do Coreapp que estejam servindo o fragmento. No entanto, outras instâncias ativas do Coreapp serão atribuídas em breve. Em outras palavras, pode haver um tempo de inatividade adicional (cerca de 35 segundos) durante o procedimento.