Ampliar el cliente de la API con conexión múltiple
La solución estándar del cliente de la API de WhatsApp Business funciona en un único contenedor de Docker. Si quieres dividir la carga y hacer que varios servidores envíen y reciban mensajes de WhatsApp, puedes usar nuestra solución de conexión múltiple.
La solución de conexión múltiple requiere que, primero, haya una configuración de alta disponibilidad. Sigue la documentación sobre alta disponibilidad para configurarla y continúa con los siguientes pasos.
Información general
Con la opción de alta disponibilidad, solo un contenedor de Docker es responsable de enviar y recibir mensajes de los servidores de WhatsApp. Si el tráfico de mensajes supera el volumen máximo de un solo contenedor de Docker, habrá un retraso en el envío de mensajes y aumentará la latencia de entrega de mensajes. A fin de expandir el cliente de la API de WhatsApp Business, la opción de conexión múltiple admite la fragmentación para distribuir las cargas en varios contenedores de Docker. Actualmente, solo admitimos la fragmentación estática con un número de fragmentos de 1, 2, 4, 8, 16 o 32. La alta disponibilidad es un caso especial de conexión múltiple, donde el número de fragmentos es 1.
En el clúster, hay dos nodos de la aplicación principal (CoreApp 1 y CoreApp 3) que son responsables de enviar y recibir mensajes del servidor de WhatsApp al mismo tiempo. Cada mensaje pertenecerá únicamente a un fragmento basado en el identificador del destinatario.
Fragmentación
El cliente de la API de WhatsApp Business utiliza la fragmentación para lograr una conexión múltiple. En función del número de fragmentos que configures, la base de datos almacenará un mapa de fragmentos que determina a qué fragmento se debe dirigir un mensaje según el identificador del destinatario (o el nombre de usuario de WhatsApp). La función para determinarlo es la siguiente:
shard_id = hash(recipient-id) % shard-number
Cada fragmento se asigna a un contenedor de Docker en ejecución (aplicación principal). La app web sabe a qué contenedor de Docker debe enviar la solicitud de mensaje en función de la devolución de esta función. Te recomendamos configurar el número de fragmento + X máquinas para poder tolerar X fallas de máquina.
En el diagrama anterior, de conexión múltiple de dos fragmentos, los mensajes se direccionan a CoreApp 1 y a CoreApp 3 según la función de fragmentación. CoreApp 2 es secundaria: funciona, pero no tiene conexión activa con los servidores de WhatsApp. Supongamos que CoreApp 1 recibe mensajes para shard=0 y CoreApp 3 recibe mensajes para shard=1. Si CoreApp 1 deja de funcionar, esto solo afectará a los mensajes de shard=0. El sistema aún enviaría y recibiría mensajes pertenecientes a shard=1 mediante CoreApp 3. De forma similar a la alta disponibilidad, Master 1 detecta la falla de CoreApp 1 y conmuta el tráfico de shard=0 a CoreApp 2. Esta conmutación por error demorará aproximadamente 35 segundos.
Configuración de la conexión múltiple
Una vez que hayas configurado tu clúster de acuerdo con la documentación sobre alta disponibilidad, usa la siguiente solicitud para activar la conexión múltiple.
Recuerda que debes tener la cantidad de fragmentos + X contenedores de Docker de la app principal en ejecución antes de continuar.
La conexión múltiple no garantiza la alta disponibilidad. Para tener alta disponibilidad, ejecuta más apps principales que fragmentos.
Solicitud
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
| Nombre | Descripción |
|---|---|
| Obligatorio. Código de país del número de teléfono registrado para este cliente de la API de WhatsApp Business como una cadena. Por ejemplo: |
| Obligatorio. Número de teléfono registrado para este cliente de la API de WhatsApp Business sin el código de país ni el símbolo más (+) como cadena. Por ejemplo: |
| Obligatorio. Cantidad de fragmentos que quieres tener como número entero. Opciones: |
| Opcional. El PIN de 6 dígitos existente para la verificación de dos pasos como una cadena. Por ejemplo: |
| Obligatorio. Con la introducción del parámetro Si se completa este campo, las empresas pueden llamar a este punto de conexión en cualquier momento. Antes, las empresas solo podían llamar a este punto de conexión en un plazo de 7 días después del registro de su número de teléfono. Un certificado con codificación Base64 asociado al número de teléfono que se especificó anteriormente. Puedes obtener este certificado mediante el administrador comercial. Consulta Copiar el certificado con codificación Base64 para obtener más información. Notas:
Si no se proporciona el parámetro |
Respuesta
201 Created : You successfully changed shard number 403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it
Recuperar información de fragmentos
Solicitud
GET /v1/account/shards
Respuesta
{
"account": {
"shards": number-of-shards
}
}
Tarifas de envío de mensajes
Consulta Referencia, Mensajes, Rendimiento.
Detalles de la implementación de AWS
URL de las plantillas:
- Empresa: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
- Base de datos: 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
- Redes: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh
La plantilla te permite configurar la cantidad de instancias de contenedor de la app principal activas que se crearán. La plantilla crea una instancia de contenedor de la app principal adicional para ayudar en el cambio rápido en caso de error de la app principal.
De forma predeterminada, la plantilla crea la siguiente cantidad de instancias por tipo de entorno para la conexión múltiple cuando la alta disponibilidad está activada:
- Producción: instancias de EC2: 3, contenedor web: 3, contenedor de la app principal: 3, contenedor maestro: 3
- Preparación: instancias de EC2: 2, contenedor web: 2, contenedor de la app principal: 2, contenedor maestro: 2
La plantilla está configurada para aumentar automáticamente las instancias de EC2 según el uso de la memoria. El uso de la memoria aumenta (o disminuye) con un aumento (o disminución) de la cantidad de instancias de contenedor de la app principal "activas". Por lo tanto, cuando se crean más instancias de la app principal, las instancias de EC2 aumentan automáticamente como consecuencia. Sin embargo, la cantidad máxima de instancias de EC2 que pueden crearse tiene los siguientes límites:
| Instancias de la app principal activas | Instancias máximas de EC2 |
|---|---|
2 | 3 |
4 | 4 |
8 | 5 |
16 | 8 |
32 | 15 |
Dimensionamiento de instancias de RDS
La tasa de solicitudes de API y la cantidad de instancias activas de la app principal determinan la cantidad de conexiones a la base de datos. Con 8 instancias activas de la app principal y una tasa de API de 100 mensajes por segundo, requiere alrededor de 700 conexiones a la base de datos (SSL está desactivado) y 1.200 conexiones a la base de datos (cuando SSL está activado). Sin embargo, con 32 instancias activas de la app principal y una tasa de API de 250 mensajes por segundo, requiere alrededor de 1.700 conexiones a la base de datos.
En la versión actual, usamos db.m4.2xlarge para 8 instancias activas de la app principal (cifrado de la conexión a la base de datos desactivado) y db.m4.4x.large para 32 instancias activas de la app principal (cifrado de la conexión de la base de datos activado). La siguiente tabla es una guía sobre la selección de la clase de instancia de RDS y la cantidad máxima de conexiones que puede admitir:
| Instancia de RDS | Conexiones de base de datos máximas |
|---|---|
| 318 |
| 636 |
| 1.272 |
| 2.543 |
| 1.212 |
| 2.424 |
| 4.848 |
| 9.696 |
| 19.391 |
| 38.783 |
| 636 |
| 1.272 |
| 2.543 |
| 5.086 |
| 12.716 |
| 20.345 |
| 298 |
| 596 |
| 1.192 |
| 2.384 |
Configuración
- Las instancias de la app principal activas configuradas en una plantilla solo rigen la cantidad de instancias de la app principal creadas. Sin embargo, para activar la misma cantidad, se debe usar Configurar fragmentos (como se explica en la sección Configuración de la conexión múltiple). El valor predeterminado de fragmentos es 1.
- Siempre asegúrate de que la cantidad de instancias de la app principal sea mayor o igual que la cantidad de fragmentos establecidas en la API.
- Para aumentar la cantidad de fragmentos:
- Crea o actualiza la pila con la cantidad deseada de instancias activas de la app principal.
- Luego, utiliza Establecer fragmentos para activar la misma cantidad de fragmentos o instancias activas de la app principal.
- Nota:Establecer fragmentos detiene y reinicia automáticamente todas las instancias de contenedor de la app principal. Cuando se ejecute Establecer fragmentos, habrá un tiempo de inactividad de entre 45 segundos y 1 minuto.
- Para disminuir la cantidad de fragmentos:
- Usa Establecer fragmentos para reducir la misma cantidad de fragmentos o instancias activas de la app principal.
- Una vez que las instancias de la app principal se reinicien correctamente, actualiza la pila con la misma cantidad de instancias activas de la app principal.
- Nota: Es posible que, al actualizar la pila, finalicen las instancias activas de la app principal que procesan los fragmentos. Sin embargo, se asignarán otras instancias activas de la app principal a la brevedad. Es decir, podría producirse un tiempo de inactividad adicional (de alrededor de 35 segundos) durante este procedimiento.