Estendi le capacità del tuo client dell'API con Multiconnect

La soluzione client standard dell'API di WhatsApp Business viene eseguita su un singolo contenitore Docker. Se vuoi dividere il carico e predisporre più server per l'invio e la ricezione di messaggi a WhatsApp, puoi utilizzare la nostra soluzione Multiconnect.

Panoramica

Con High Availability, solo un contenitore Docker è responsabile dell'invio e della ricezione di messaggi dai server WhatsApp. Se il traffico dei messaggi supera la capacità massima di trasmissione di un singolo contenitore Docker, si creerà un accumulo di invii di messaggi e la latenza di consegna aumenterà. Per poter estendere le capacità del client dell'API di WhatsApp Business, Multiconnect supporta il partizionamento per distribuire i carichi su più contenitori Docker. Attualmente supportiamo solo il partizionamento statico con un numero di partizioni pari a 1, 2, 4, 8, 16 o 32. High Availability è un caso speciale di Multiconnect dove il numero di partizioni è 1.

Un cluster Multiconnect a 2 partizioni

Nel cluster, sono presenti due nodi Coreapp (CoreApp 1 e CoreApp 3) entrambi responsabili dell'invio e della ricezione di messaggi dal server WhatsApp. Ciascun messaggio apparterrà a un'unica partizione in base all'ID del destinatario.

Partizionamento

Il client dell'API di WhatsApp Business utilizza il partizionamento perché la funzione Multiconnect sia applicabile. A seconda del numero di partizioni configurate, il database memorizzerà una mappa di partizioni che determina la partizione di riferimento di un messaggio in base all'ID del destinatario (o al nome utente di WhatsApp). La funzione per eseguire questa operazione è la seguente:

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

Ogni partizione è mappata a un contenitore Docker in esecuzione (Coreapp). Il Webapp saprà a quale contenitore Docker inviare la richiesta di messaggio in base a quanto restituito da questa funzione. Si consiglia di configurare il numero di partizioni + X macchine in modo da poter tollerare i guasti di X macchine.

Nello schema di Multiconnect a 2 partizioni riportato in alto, i messaggi vengono indirizzati a CoreApp 1 e CoreApp 3 in base alla funzione di partizionamento. CoreApp 2 è secondario: è in esecuzione, ma non ha alcuna connessione attiva ai server di WhatsApp. Si può dedurre che CoreApp 1 ottiene messaggi per shard=0 e che CoreApp 3 ottiene messaggi per shard=1. Se CoreApp 1 smette di funzionare, saranno interessati solo i messaggi per shard=0. Il sistema continua comunque a inviare e ricevere messaggi appartenenti a shard=1 utilizzando CoreApp 3. Analogamente ad High Availability, Master 1 rileverà il fallimento di CoreApp 1 ed eseguirà il failover del traffico di shard=0 verso CoreApp 2. Questo failover impiegherà circa 35 secondi.

Configurazione di Multiconnect

Una volta che hai configurato il tuo cluster secondo la documentazione di High Availability, usa la seguente richiesta per attivare Multiconnect.

Richiesta

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"
}

Parametri

Risposta

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

Recupero delle informazioni sulle partizioni

Richiesta

GET /v1/account/shards

Risposta

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

Tassi di invio dei messaggi

Consulta Riferimento, Messaggi, Prestazioni.

Dettagli sull'implementazione di AWS

URL modello:

• Enterprise: 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
• Network: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

Il modello permette di configurare il numero di istanze di contenitore Coreapp attive da creare. Il modello crea un'ulteriore istanza di contenitore Coreapp per favorire un passaggio rapido in caso di guasto di Coreapp.

Per impostazione predefinita, quando High Availability è abilitato il modello crea il seguente numero di istanze per tipo di ambiente per Multiconnect:

• Produzione: istanze EC2: 3; contenitore Webapp: 3; contenitore Coreapp: 3; contenitore Master: 3
• Staging: istanze EC2: 2; contenitore Webapp: 2; contenitore Coreapp: 2; contenitore Master: 2

Il modello è configurato per scalare automaticamente istanze EC2 a seconda dell'utilizzo della memoria. L'utilizzo della memoria aumenta (o diminuisce) con un aumento (o una riduzione) del numero di istanze contenitore Coreapp "attive". Quindi, quando vengono create più istanze Coreapp, le istanze EC2 si adeguano di conseguenza. Tuttavia, il numero massimo di istanze EC2 che possono essere create è limitato come indicato di seguito:

Dimensioni istanze RDS

Il tasso di richieste API e il numero di istanze Coreapp attive determina il numero di connessioni al database. Con 8 istanze Coreapp attive e un tasso di richieste API di 100 messaggi/secondo, sono necessarie circa 700 connessioni DB (SSL disabilitata) e 1200 connessioni DB (SSL abilitata). Tuttavia, con 32 istanze Coreapp attive e un tasso di richieste API di 250 messaggi/secondo, sono necessarie circa 1700 connessioni DB.

Nella versione attuale, abbiamo usato db.m4.2xlarge per 8 istanze Coreapp attive (crittografia connessione DB disabilitata) e db.m4.4x.large per 32 istanze Coreapp attive (crittografia connessione DB abilitata). La seguente tabella fornisce una guida sulla selezione delle classi di istanza RDS e sul numero di connessioni massime che può supportare:

Configurazione

• Le istanze Coreapp attive impostate in un modello regolano solo il numero di istanze Coreapp create. Tuttavia, per attivarne lo stesso numero, devi usare Set Shards (Imposta partizioni), come descritto nella sezione Configurazione di Multiconnect. Il valore predefinito delle partizioni è 1.
• Assicurati sempre che il numero di istanze Coreapp sia sempre maggiore o uguale al numero di partizioni impostato nell'API.
• Per aumentare il numero di partizioni:

  • Crea o aggiorna lo stack con il numero desiderato di istanze Coreapp attive.
  • Dopo aver completato correttamente l'operazione, usa Set Shards (Imposta partizioni) per attivare lo stesso numero di partizioni/istanze Coreapp attive.
  • Nota:Set Shards (Imposta partizioni) causa l'arresto e il riavvio automatico di tutte le istanze contenitore Coreapp. Ci sarà un tempo di inattività di circa 45 secondi o 1 minuto una volta eseguito Set Shards (Imposta partizioni).
• Per ridurre il numero di partizioni:

  • Usa Set Shards (Imposta partizioni) per ridurre lo stesso numero di partizioni/istanze Coreapp attive.
  • Una volta che tutte le istanze Coreapp saranno state riavviate correttamente, aggiorna lo stack con lo stesso numero di istanze Coreapp attive.
  • Nota: l'aggiornamento dello stack potrebbe terminare le istanze Coreapp attualmente attive che stanno operando con la partizione. Tuttavia, in breve tempo saranno assegnate altre istanze Coreapp attive. In altre parole, potrebbe verificarsi un ulteriore tempo di inattività (circa 35 secondi) durante questa procedura.