Limitar a una llamada de ACS vía websocket por réplica de ACA.

Hola Miguel Jiménez,

Gracias por publicar su pregunta en el portal de preguntas y respuestas de Microsoft

Este comportamiento es esperado Azure Communication Services (ACS) no proporciona ningún mecanismo integrado para sesiones permanentes o enrutamiento compatible con réplicas cuando se conecta de nuevo a la instancia de Azure Container App (ACA). Una vez que se responde a la llamada, ACS usa la dirección URL de devolución de llamada que proporciona y establece una conexión WebSocket, que puede llegar a cualquier réplica de ACA detrás del equilibrador de carga.

Si necesita **una llamada activa por réplica de **ACA, ACS no admite directamente las sesiones permanentes o los encabezados de afinidad de conexión. Sin embargo, existen algunos patrones confiables para lograr una distribución de carga determinista,

Enfoques recomendados para equilibrar n llamadas entre n réplicas.

1. Usar un coordinador de carga externo

• Puede introducir una capa de coordinación ligera, por ejemplo, una función de Azure o un coordinador respaldado por Redis que realice un seguimiento de las réplicas de ACA que tienen actualmente llamadas WebSocket activas.
• Cada réplica registra su estado (disponible u ocupado) con este coordinador. Cuando ACS inicia una nueva llamada, el coordinador selecciona una réplica disponible y emite un redireccionamiento 302 o proporciona una dirección URL de devolución de llamada única que apunta a esa réplica específica.
• Este enfoque garantiza que ACS se conecte directamente a la instancia correcta, lo que le brinda un control total sobre la distribución de llamadas y evita llamadas perdidas o reintentos innecesarios.

2.Reconocimiento de réplicas con variables de entorno

• Si las réplicas de ACA se escalan horizontalmente y se pueden identificar de forma única (por ejemplo, mediante variables de entorno como HOSTNAME o metadatos de un sidecar de Dapr), puede almacenar su estado en un back-end compartido, como Redis o Cosmos DB.
• Cuando llega una nueva solicitud de llamada, cada réplica comprueba si ya tiene una sesión activa. Si está ocupado, la réplica puede devolver una respuesta HTTP 503 (servicio no disponible), lo que solicita a ACS que vuelva a intentar otra instancia.
• Si bien este método puede funcionar, se basa en la lógica de reintento de ACS y puede introducir condiciones de carrera, lo que lo hace menos confiable que usar un mecanismo de coordinación o redireccionamiento dedicado.

3.Instancia dedicada por llamada (si el escalado lo permite)

• Si el número de llamadas simultáneas es relativamente bajo, puede configurar reglas de escalado de revisión de ACA o usar KEDA con un escalador externo para aprovisionar exactamente una réplica por llamada entrante.
• Con esta configuración, cada llamada se asigna automáticamente a una instancia dedicada, lo que proporciona un claro aislamiento de recursos y evita la contención entre llamadas simultáneas.

Espero que esto ayude, hágamelo saber si tiene alguna pregunta

Hi Miguel Jimenez, Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this. 

Hi, solution 1 and 3 are very interesting. Could I have more detailed information about those tools?

Hola Miguel Jiménez,

Seguro

Puede usar una función de Azure como servicio de coordinación para administrar qué réplica de Azure Container Apps (ACA) controla cada llamada entrante de Azure Communication Services (ACS).

• Cree un servicio de coordinación (podría ser una función de Azure (desencadenador HTTP) que mantenga el estado de cada réplica de ACA (available / busy).
• Cada réplica registra y actualiza su estado en un almacén compartido (por ejemplo, Azure Redis Cache, Cosmos DB o Azure Table Storage).
• Cuando ACS inicia una nueva llamada, el coordinador selecciona una réplica disponible y emite una redirección HTTP 302 o devuelve una URL de devolución de llamada que apunta a esa réplica.
• Esto garantiza que ACS se conecte directamente a la instancia de contenedor correcta.
• Evita llamadas perdidas o conexiones duplicadas durante el escalado automático de ACA.

Use reglas de escalado de revisión de KEDA (escalador automático controlado por eventos de Kubernetes) o ACA para que cada nuevo evento de llamada (desde ACS o desde otro lugar) desencadene una nueva réplica. Uso de reglas de escalado de ACA

1. Defina una regla de escalado personalizada en el YAML de Container App o a través de Azure Portal.
2. Conecte la lógica de escalado a un origen de eventos externo (por ejemplo, Azure Service Bus, Event Grid o Storage Queue).
3. Configure la métrica de destino para que un evento = una réplica.
4. Cuando se inicia una llamada → ACA se escala horizontalmente, cuando finaliza → ACA se reduce horizontalmente automáticamente.

Consulte para obtener más información: Escalado en Azure Container Apps | Aprendizaje de Microsoft

Espero que esto ayude, hágamelo saber si tiene alguna pregunta

¿Pero desde ese servicio de coordinación se puede apuntar a una réplica u otra? Habíamos intentado apuntar a las réplicas con url y el ACA no lo permite, hay que apuntar al contenedor y el decide a qué réplica va.