Escalar el cliente de la API con conexión múltiple
La solución estándar de cliente de la API de WhatsApp Business se ejecuta en un solo contenedor de Docker. Si quieres dividir la carga y tener varios servidores que envíen y reciban mensajes por WhatsApp, puedes utilizar nuestra solución de conexión múltiple.
La solución de conexión múltiple primero requiere una configuración de alta disponibilidad existente. Consulta la documentación sobre la alta disponibilidad para configurarla y, a continuación, pasa al apartado siguiente.
Información general
Con la alta disponibilidad, un solo 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á trabajo pendiente de envíos de mensajes y la latencia de entrega de mensajes aumentará. Para escalar horizontalmente el cliente de la API de WhatsApp Business, la conexión múltiple admite las particiones para distribuir cargas en varios contenedores de Docker. Actualmente, solo se admite el particionamiento estático con un número de particiones 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 particiones es 1.
En el clúster, existen dos nodos de aplicación principal (CoreApp 1 y CoreApp 3) responsables de enviar y recibir mensajes del servidor de WhatsApp al mismo tiempo. Cada uno de los mensajes pertenecerá únicamente a una partición basada en el identificador del destinatario.
Particionamiento
El cliente de la API de WhatsApp Business utiliza particiones para conseguir la conexión múltiple. En función del número de particiones que configures, la base de datos almacenará un mapa de particiones que determinará a qué partición debe dirigirse un mensaje según el identificador del destinatario (o nombre de usuario de WhatsApp). La función para determinarlo es:
shard_id = hash(recipient-id) % shard-number
Cada partición se asigna a un contenedor de Docker en ejecución (aplicación principal). El nodo de aplicación web sabrá a qué contenedor de Docker debe enviar la solicitud de mensaje según la devolución de esta función. Se recomienda configurar un número de particiones y X equipos para poder tolerar X errores de equipos.
En el diagrama de conexión múltiple de dos particiones anterior, los mensajes se enrutan a CoreApp 1 y CoreApp 3 de acuerdo con la función de creación de particiones. CoreApp 2 es un nodo secundario (está semiactivo), pero no tiene ninguna conexión activa a los servidores de WhatsApp. Supongamos que CoreApp 1 obtiene mensajes de shard=0 y CoreApp 3 para shard=1. Si CoreApp 1 deja de funcionar, solo los mensajes de shard=0 se verán afectados. El sistema seguiría enviando y recibiendo mensajes pertenecientes a shard=1 mediante CoreApp 3. De manera parecida a la alta disponibilidad, Master 1 detectará el error de CoreApp 1 y conmutará por error el tráfico de shard=0 a CoreApp 2. Esta conmutación por error tardará, aproximadamente, 35 segundos.
Configuración de la conexión múltiple
Cuando tengas el clúster configurado de acuerdo con la documentación sobre alta disponibilidad, utiliza la solicitud siguiente para activar la conexión múltiple.
Recuerda que debes tener el número de particiones más X contenedores de Docker de la aplicación principal en ejecución antes de continuar.
La conexión múltiple no garantiza una alta disponibilidad. Para tener alta disponibilidad, debes tener más aplicaciones principales que particiones en ejecución.
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 signo más (+) como una cadena. Por ejemplo: |
| Obligatorio. Número de particiones que quieres tener como un entero. Opciones: |
| Opcional. PIN de 6 dígitos existente para la verificación en dos pasos como una cadena. Por ejemplo: |
| Obligatorio. Con la introducción del parámetro Rellenar este campo permite a las empresas llamar a este extremo en cualquier momento. Antes, las empresas solo podían llamar a este extremo en los siete días posteriores al registro del número de teléfono. Certificado con codificación Base64 asociado al número de teléfono especificado anteriormente. Puedes obtener este certificado a través de Business Manager. Consulta Copia del certificado codificado mediante 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
Recuperación de la información de particiones
Solicitud
GET /v1/account/shards
Respuesta
{
"account": {
"shards": number-of-shards
}
}
Tasas de envío de mensajes
Consulta Referencia, Mensajes, Rendimiento.
Detalles de 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
- Red: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh
La plantilla te permite configurar el número de instancias de contenedor de la aplicación principal que se van a crear. La plantilla crea una instancia de contenedor de aplicación principal adicional para facilitar el intercambio rápido en caso de error de la aplicación principal.
De forma predeterminada, la plantilla crea el siguiente número de instancias por tipo de entorno para la conexión múltiple cuando la alta disponibilidad está activada:
- Producción: 3 instancias de EC2, 3 contenedores web, 2 contenedores de aplicación principal y 3 contenedores maestros
- Revisión: 2 instancias de EC2, 2 contenedores web, 2 contenedores de aplicación principal y 2 contenedores maestros
La plantilla está configurada para escalar automáticamente las plantillas de EC2 en función del uso de memoria. El uso de memoria aumenta (o disminuye) con un aumento (o disminución) del número de instancias de contenedor “activas” de la aplicación principal. De ahí que, al crear más instancias de aplicación principal, las instancias de EC2 se escalen automáticamente en consecuencia. No obstante, la cantidad máxima de instancias de EC2 que se puede crear presenta las limitaciones siguientes:
| Instancias de aplicación principal activas | Instancias de EC2 máximas |
|---|---|
2 | 3 |
4 | 4 |
8 | 5 |
16 | 8 |
32 | 15 |
Tamaño de la instancia de RDS
La tasa y el número de solicitudes a la API de las instancias activas de la aplicación principal determinan el número de conexiones a la base de datos. Con 8 instancias activas de la aplicación principal y una tasa de API de 100 mensajes/segundo, se requieren unas 700 conexiones de base de datos (con SSL desactivado) y unas 1200 conexiones de base de datos (con SSL activado). No obstante, con 32 instancias activas de la aplicación principal y una tasa de API de 250 mensajes/segundo, requiere unas 1700 conexiones de base de datos.
En la versión actual, utilizamos db.m4.2xlarge para 8 instancias activas de la aplicación principal (cifrado de conexiones de base de datos desactivado) y db.m4.4x.large para 32 instancias activas de la aplicación principal (cifrado de conexiones de base de datos activado). En la tabla siguiente se proporcionan instrucciones sobre la selección de clases de la instancia de RDS y el número de conexiones máximas que puede admitir:
| Instancia de RDS | Conexiones máximas de base de datos |
|---|---|
| 318 |
| 636 |
| 1272 |
| 2543 |
| 1212 |
| 2424 |
| 4848 |
| 9696 |
| 19 391 |
| 38 783 |
| 636 |
| 1272 |
| 2543 |
| 5086 |
| 12 716 |
| 20 345 |
| 298 |
| 596 |
| 1192 |
| 2384 |
Configuración
- Las instancias activas de la aplicación principal establecidas en una plantilla solo rigen el número de instancias creadas de la aplicación principal. No obstante, para activarlas, debes utilizar Definición de particiones (documentado en la sección Configuración de la conexión múltiple). El valor de particiones predeterminado es 1.
- Asegúrate siempre de que el número de instancias de la aplicación principal sea mayor o igual que el número de particiones establecido en la API.
- Para aumentar el número de particiones:
- Crea o actualiza la pila con el número deseado de instancias activas de la aplicación principal.
- Una vez realizado este proceso correctamente, utiliza Definición de particiones para activar el mismo número de particiones o instancias activas de la aplicación principal.
- Nota:Definición de particiones hace que todas las instancias de contenedor de la aplicación principal se detengan y reinicien automáticamente. Se producirá un tiempo de inactividad de entre 45 segundos y 1 minuto, aproximadamente, cuando se ejecute Definición de particiones.
- Para reducir el número de particiones:
- Utiliza Definición de particiones para reducir el mismo número de particiones o instancias activas de la aplicación principal.
- Cuando todas las instancias de la aplicación principal se reinicien correctamente, actualiza la pila con el mismo número de instancias activas de la aplicación principal.
- Nota: Al actualizar la pila, es posible que se cierren las instancias actualmente activas de la aplicación principal que sirven a la partición. No obstante, otras instancias activas de la aplicación principal se asignarán en breve. En otras palabras, podría producirse un tiempo de inactividad adicional (de unos 35 segundos) durante este procedimiento.