Faire évoluer votre client d’API avec Multiconnect

La solution standard du client de l’API WhatsApp Business s’exécute sur un seul conteneur Docker. Au cas où vous souhaitez diviser la charge et disposer de plusieurs serveurs qui envoient et reçoivent des messages à WhatsApp, vous pouvez également utiliser notre solution de multiconnexion.

Présentation

Avec la haute disponibilité, un seul conteneur Docker est responsable de l’envoi et de la réception de messages provenant des serveurs WhatsApp. Si le trafic de messagerie dépasse le débit maximal d’un seul conteneur Docker, les envois de messages sont retardés et la latence de remise des messages augmente. Pour faire évoluer le client de l’API WhatsApp Business, la multiconnexion prend en charge le partitionnement afin de répartir les charges sur plusieurs conteneurs Docker. Actuellement, nous ne prenons en charge que le partitionnement statique avec un nombre de partitions égal à 1, 2, 4, 8, 16 ou 32. La haute disponibilité est un cas particulier de multiconnexion où le numéro de partition est 1.

Un cluster multiconnecté à deux partitions

Dans le cluster, deux nœuds Coreapp (CoreApp 1 et CoreApp 3) sont chargés d’envoyer et de recevoir des messages du serveur WhatsApp simultanément. Chaque message n’appartiendra qu’à une seule partition en fonction de l’ID du destinataire.

Partitionnement

Le client de l’API WhatsApp Business utilise le partitionnement pour obtenir la multiconnexion. En fonction du nombre de partitions que vous avez configurées, la base de données stockera une carte de partitions qui détermine la partition à laquelle un message doit être envoyé, en fonction de l’ID du ou de la destinataire (ou du nom d’utilisateur·ice WhatsApp). La fonction pour déterminer ceci est :

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

Chaque partition est associée à un conteneur Docker en cours d’exécution (Coreapp). La Webapp saura à quel conteneur Docker envoyer la demande de message en fonction du retour de cette fonction. Il est recommandé de configurer le numéro de la partition + les ordinateurs X pour pouvoir tolérer les pannes de l’ordinateur X.

Dans le diagramme multiconnecté à deux partitions ci-dessus, les messages sont routés vers CoreApp 1 et CoreApp 3 selon la fonction de partitionnement. CoreApp 2 est secondaire, il est sauvegardé à chaud, mais n’a pas de connexion active aux serveurs WhatsApp. Supposons que CoreApp 1 reçoive des messages pour shard=0 et CoreApp 3 obtient des messages pour shard=1. Si CoreApp 1 tombe en panne, seuls les messages pour shard=0 seront affectés. Le système continue d’envoyer et de recevoir des messages appartenant à shard=1 à l’aide de CoreApp 3. Comme pour la haute disponibilité, Master 1 détecte la défaillance du CoreApp 1 et bascule le trafic shard=0 vers CoreApp 2. Ce basculement prendra environ 35 secondes.

Configuration de Multiconnect

Une fois que votre cluster est configuré conformément aux instructions de la documentation sur la haute disponibilité, utilisez la requête suivante pour activer la multiconnexion.

Requête

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

Paramètres

Réponse

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

Récupération des informations sur les partitions

Requête

GET /v1/account/shards

Réponse

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

Taux d’envoi des messages

Consultez la section Performances de l’article de référence Messages.

Détails du déploiement AWS

URL des modèles :

• Entreprise : https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• Base de données : 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
• Réseau : https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

Le modèle vous permet de configurer le nombre d’instances actives du conteneur Coreapp à créer. Il crée une instance de conteneur Coreapp supplémentaire pour un basculement rapide en cas d’échec du Coreapp.

Lorsque la haute disponibilité est activée, le modèle crée par défaut le nombre d’instances suivant par type d’environnement pour Multiconnect :

• Production : instances EC2 : 3 ; conteneur Web : 3 ; conteneur Coreapp : 3 ; conteneur Maître : 3
• Développement : instances EC2 : 2 ; conteneur Web : 2 ; conteneur Coreapp : 2 ; conteneur Maître : 2

Le modèle est configuré pour une évolution automatique des instances EC2 en fonction du niveau d’utilisation de la mémoire. L’utilisation de la mémoire augmente (ou diminue) avec une augmentation (ou une diminution) du nombre d’instances actives du conteneur Coreapp. C’est pourquoi lors de la création d’instances supplémentaires de Coreapp, les instances EC2 s’adaptent automatiquement en conséquence. Toutefois, le nombre maximal d’instances EC2 pouvant être créées est limité comme suit :

Dimensionnement d’une instance RDS

Le taux de demandes d’API et le nombre d’instances actives de Coreapp déterminent le nombre de connexions à la base de données. Avec huit instances actives de Coreapp et un débit d’API de 100 messages/seconde, environ 700 connexions à la base de données (si SSL est désactivé) ou 1 200 connexions à la base de données (lorsque SSL est activé) sont nécessaires. Toutefois, avec 32 instances actives de Coreapp et un débit d’API de 250 messages/seconde, environ 1 700 connexions à la base de données sont nécessaires.

Dans la version actuelle, nous avons utilisé db.m4.2xlarge pour huit instances actives de Coreapp (chiffrement de la connexion à la base de données désactivé) et db.m4.4x.large pour 32 instances actives de Coreapp (chiffrement de la connexion à la base de données activé). Le tableau suivant donne des indications sur le choix d’une catégorie d’instance RDS et le nombre maximal de connexions qu’elle prend en charge :

Configuration

• Les instances de Coreapp actives dans un modèle ne concernent que le nombre d’instances de Coreapp créées. Toutefois, pour l’activer, Set Shards (Définir les partitions) (documenté dans la section sur la configuration de Multiconnect) doit être utilisé. La valeur par défaut des partitions est 1.
• Veillez toujours à ce que le nombre d’instances de Coreapp soit supérieur ou égal au nombre de partitions défini dans l’API.
• Pour augmenter le nombre de partitions :

  • Créez ou mettez à jour la pile avec le nombre d’instances de Coreapp actives de votre choix.
  • Utilisez ensuite l’option Set Shards (Définir les partitions) pour activer le même nombre d’instances/de partitions de Coreapp actives.
  • Remarque : l’option Set Shards entraîne l’arrêt, puis le redémarrage automatique de toutes les instances de conteneur Coreapp. L’exécution de Set Shards génère une interruption de 45 secondes à 1 minute.
• Pour diminuer le nombre de partitions :

  • Utilisez l’option Set Shards (Définir les partitions) pour réduire le même nombre d’instances/de partitions de Coreapp actives.
  • Une fois que toutes les instances de Coreapp ont redémarré, mettez à jour la pile avec le nombre d’instances de Coreapp actives.
  • Remarque : la mise à jour de la pile risque de mettre fin aux instances de Coreapp actives qui servent la partition. Toutefois, les autres instances de Coreapp actives seront affectées rapidement. En d’autres termes, une interruption supplémentaire d’environ 35 secondes est possible pendant cette procédure.