Deinen API-Client mit Multiconnect skalieren

Die Standardversion des WhatsApp Business API-Client wird in einem einzelnen Docker-Container ausgeführt. Wenn du die Last aufteilen möchtest und mehrere Server Nachrichten an WhatsApp senden und empfangen sollen, kannst du zusätzlich unsere Multiconnect-Lösung nutzen.

Übersicht

Bei Hochverfügbarkeit übernimmt ein einzelner Docker-Container das Senden und Empfangen von Nachrichten von WhatsApp-Servern. Wenn der Messaging-Verkehr den Durchsatz eines einzelnen Docker-Containers überschreitet, entsteht ein Überhang an zu sendenden Nachrichten. Gleichzeitig erhöhen sich die Latenzen bei der Zustellung von Nachrichten. Multiconnect unterstützt Sharding, um den WhatsApp Business API-Client zu entlasten. Dabei wird die anfallende Last auf mehrere Docker-Container verteilt. Derzeit wird nur statisches Sharding mit einer Shard-Anzahl von 1, 2, 4, 8, 16 oder 32 unterstützt. Hochverfügbarkeit ist ein Multiconnect-Sonderfall mit der Shard-Anzahl=1.

Multiconnect-Cluster mit zwei Shards

Das Cluster enthält zwei Coreapp-Nodes (CoreApp 1 und CoreApp 3), die gleichzeitig Nachrichten an den WhatsApp-Server senden und von diesem empfangen. Abhängig von der Empfänger-ID gehört jede Nachricht nur zu einem bestimmten Shard.

Sharding

Durch Unterstützung von Sharding erreicht der WhatsApp Business API-Client Multiconnect-Fähigkeit. Entsprechend der Anzahl Shards, die du einrichtest, speichert die Datenbank eine Shard Map. Diese Map bestimmt anhand der Empfänger-ID (bzw. des WhatsApp-Benutzernamens), an welche Shard eine Nachricht übergeben wird. Die Zuordnung erfolgt über folgende Funktion:

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

Jede Shard wird einem aktiven Docker-Container (Coreapp) zugeordnet. Anhand der Rückantwort dieser Funktion weiß Webapp, an welchen Docker-Container die Anfrage gesendet werden soll. Empfohlen wird die Einrichtung von Shard-Anzahl + X Rechnern, um den Ausfall von X Rechnern abfangen zu können.

In dem obigen Multiconnect-Diagramm mit zwei Shards werden Nachrichten entsprechend der Sharding-Funktion an CoreApp 1 und CoreApp 3 gesendet. CoreApp 2 ist ein sekundärer Node. Er ist zwar einsatzbereit, doch besteht keine Verbindung zu den WhatsApp-Servern. Nehmen wir an, CoreApp 1 erhält Nachrichten für shard=0 und CoreApp 3 erhält Nachrichten für shard=1. Wenn CoreApp 1 ausfällt, sind nur Nachrichten für shard=0 betroffen. Das System sendet und empfängt für shard=1 bestimmte Nachrichten weiterhin über CoreApp 3. Ähnlich wie bei Hochverfügbarkeit erkennt Master 1 den Ausfall von CoreApp 1 und leitet den shard=0-Traffic um zu CoreApp 2. Dieses Failover dauert etwa 35 Sekunden.

Einrichten von Multiconnect

Sobald du deinen Cluster gemäß der Dokumentation zu Hochverfügbarkeit eingerichtet hast, kannst du multiconnect mit der folgenden Anfrage aktivieren.

Anfrage

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

Parameter

Antwort

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

Abrufen von Shard-Informationen

Anfrage

GET /v1/account/shards

Antwort

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

Gebühren für das Senden von Nachrichten

Siehe Referenz, Nachrichten, Performance

Details zur AWS-Bereitstellung

Vorlagen-URLs:

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

Mit der Vorlage kannst du die Anzahl der zu erstellenden aktiven Coreapp-Container-Instanzen konfigurieren. Die Vorlage erstellt eine zusätzliche Coreapp-Container-Instanz, um im Falle eines Coreapp-Ausfalls einen schnellen Wechsel zu ermöglichen.

Die Vorlage erstellt standardmäßig die folgende Anzahl von Instanzen pro Umgebungstyp für Multiconnect, wenn Hochverfügbarkeit aktiviert ist:

• Produktion: EC2-Instanzen: 3, Web-Container: 3, Coreapp-Container: 3, Master-Container: 3
• Staging: EC2-Instanzen: 2, Web-Container: 2, Coreapp-Container: 2, Master-Container: 2

Die Vorlage ist so konfiguriert, dass EC2-Instanzen je nach Speicherauslastung automatisch skaliert werden. Die Speicherauslastung steigt (oder sinkt) mit der Anzahl der „aktiven“ Coreapp-Container-Instanzen. Wenn also mehr Coreapp-Instanzen erstellt werden, werden die EC2-Instanzen automatisch entsprechend skaliert. Die maximale Anzahl von EC2-Instanzen, die erstellt werden können, ist jedoch wie folgt begrenzt:

Dimensionierung von RDS-Instanzen

Die API-Anforderungsrate und die Anzahl der aktiven Coreapp-Instanzen bestimmen die Anzahl der Verbindungen zur Datenbank. Bei 8 aktiven Coreapp-Instanzen und einer API-Rate von 100 Nachrichten/Sekunde sind etwa 700 DB-Verbindungen (SSL ist deaktiviert) und 1.200 DB-Verbindungen (wenn SSL aktiviert ist) erforderlich. Bei 32 aktiven Coreapp-Instanzen und einer API-Rate von 250 Nachrichten/Sekunde sind jedoch etwa 1.700 DB-Verbindungen erforderlich.

In der aktuellen Version haben wir db.m4.2xlarge für 8 aktive Coreapp-Instanzen (DB-Verbindungsverschlüsselung deaktiviert) und db.m4.4x.large für 32 aktive Coreapp-Instanzen (DB-Verbindungsverschlüsselung aktiviert) verwendet. Die folgende Tabelle bietet eine Orientierung für die Auswahl der RDS-Instanzklasse und die Anzahl der maximalen Verbindungen, die sie unterstützen kann:

Konfiguration

• Aktive Coreapp-Instanzen, die in einer Vorlage festgelegt sind, bestimmen nur die Anzahl der erstellten Coreapp-Instanzen. Um diese zu aktivieren, muss Set Shards (im Abschnitt Einrichten von Multiconnect dokumentiert) verwendet werden. Standardwert für Shards ist 1.
• Achte immer darauf, dass die Anzahl der Coreapp-Instanzen immer größer oder gleich der in der API festgelegten Shard-Anzahl ist.
• So kannst du die Anzahl der Shards erhöhen:

  • Erstelle oder aktualisiere den Stack mit der gewünschten Anzahl von aktiven Coreapp-Instanzen.
  • Verwende anschließend Set Shards, um die gleiche Anzahl an aktiven Coreapp-Instanzen/Shards zu aktivieren.
  • Note:Set Shards führt dazu, dass alle Coreapp-Container-Instanzen angehalten und automatisch neu gestartet werden. Es kommt zu einer Ausfallzeit von etwa 45 Sekunden bis 1 Minute, wenn Set Shards ausgeführt wird.
• So kannst du die Anzahl der Shards verringern:

  • Verwende Set Shards, um die gleiche Anzahl an aktiven Coreapp-Instanzen/Shards zu verringern.
  • Sobald alle Coreapp-Instanzen erfolgreich neu gestartet sind, aktualisiere den Stack mit der gleichen Anzahl an aktiven Coreapp-Instanzen.
  • Hinweis: Die Aktualisierung des Stacks kann dazu führen, dass derzeit aktive Coreapp-Instanzen, die den Shard unterstützen, beendet werden. Weitere aktive Coreapp-Instanzen werden jedoch in Kürze zugewiesen werden. Dabei kann es also zu einer zusätzlichen Ausfallzeit (etwa 35 Sekunden) kommen.