Preparación para la Certificación Microsoft AI-200
Escalar Azure Container Apps con KEDA, cómputo dimensionado y revisiones
Diseña cargas de IA reactivas y eficientes con desencadenadores HTTP, TCP, recursos, colas, eventos, programación y métricas personalizadas, y controla cómo reciben tráfico las revisiones independientes.
Tiempo de estudio sugerido: 90 minutos • Nivel intermedio • Reescritura original completa con versión resumida de cada tema, evaluación comentada y laboratorio KEDA guiado
Por João Ricardo Dutra••Contenido original completo
1. Escalar una carga de IA sin pagar capacidad ociosa
Una plataforma de pedidos afronta picos programados y ráfagas de campañas. La capacidad fija desperdicia dinero de noche y todavía genera lentitud en horas punta. Un mejor diseño separa la síncrona del worker asíncrono y da a cada parte una señal que represente trabajo real.
La meta no es solo crear réplicas: equilibra respuesta , vaciado de cola, reducción a cero, límite de coste y despliegues que no expongan a todos a una revisión sin validar.
Configurar ,, CPU y memoria.
Escalar con colas, eventos, horarios y métricas mediante KEDA.
Elegir CPU, memoria y perfil con evidencia.
Usar modos, etiquetas y pesos sabiendo que cada revisión escala sola.
Resumen del tema
Elige una señal por carga, limita rendimiento y coste y diseña escalado y despliegue como un sistema.
2. Definición de escala: límites, reglas, comportamiento y cobro
declara el escalado horizontal. Los límites acotan réplicas por revisión, las reglas describen demanda y el comportamiento gobierna el tiempo. KEDA convierte señales en una cantidad deseada y cada réplica ejecuta una revisión inmutable.
Partes de la escala.
Parte
Pregunta
Consecuencia
Mínimo
¿Qué queda caliente?
Cero ahorra; uno o más evita arranque en frío.
Máximo
¿Cuál es el techo?
Bajo limita; alto presiona dependencias.
Reglas
¿Qué señal representa trabajo?
,, recursos o eventos.
Comportamiento
¿A qué velocidad cambia?
Sondeo, estabilización y enfriamiento evitan oscilación.
Con entrada y sin regla propia, el valor predeterminado es cero a diez por . Sin entrada, mínimo o desencadenador, puede llegar a cero y no despertar. Cero no genera uso de cómputo; una réplica inactiva en memoria puede tener tarifa reducida.
La decisión combina límites, reglas y tiempo.
Resumen del tema
Los límites contienen capacidad, las reglas detectan trabajo, el comportamiento estabiliza y el mínimo fija la base de disponibilidad y coste.
3. Reglas de concurrencia y
usa solicitudes concurrentes medias en 15 segundos, con objetivo predeterminado de diez por réplica. Un objetivo bajo escala antes; uno alto utiliza más cada réplica y puede elevar latencia. Llega a cero y sirve y web, no trabajos de Apps.
usa conexiones concurrentes y conviene a ,, pools de base de datos y conexiones largas. Al cerrarse, puede volver a cero tras el enfriamiento.
Usa para solicitudes y para conexiones persistentes y calibra con capacidad y latencia reales.
4. Reglas de CPU, memoria y combinación
CPU y memoria son escaladores personalizados KEDA que comparan utilización media con un porcentaje. CPU representa inferencia, imagen y serialización; memoria, caché, agregación y cargas grandes.
No pueden despertar desde cero porque necesitan una réplica para medir. Conserva una o combina con o eventos. Con varias reglas, cualquiera amplía y prevalece la mayor solicitud.
Los recursos protegen cargas intensivas, pero un desencadenador externo permite cero; combina demanda y presión.
5. Sondeo, enfriamiento, estabilización y fórmula
Los escaladores personalizados se consultan cada 30 segundos; y calculan en 15. Enfriamiento y estabilización de reducción son 300 segundos y el aumento no espera. La expansión usa pasos 1, 4, 8, 16 y 32; la reducción puede retirar todo el exceso.
KEDA parte de réplicasDeseadas = techo(métricaActual / objetivo) y aplica límites. Cincuenta mensajes con objetivo cinco piden diez. La espera evita apagar y arrancar ante pausas breves.
Mantén una réplica para latencia estricta.
Permite cero en workers intermitentes que puedan despertar.
Incluye cinco minutos en el ahorro estimado.
Correlaciona señal y réplicas en .
Resumen del tema
El umbral necesita tiempos adecuados: expansión rápida, reducción estable y enfriamiento acorde con el ritmo.
6. Integración KEDA y fuentes nativas de
KEDA reacciona a profundidad de cola, retraso, horario y métricas. La regla aporta tipo, y autenticación sin operar un ScaledObject.
Microsoft mantiene escaladores para ,,,, Analytics y . Los comunitarios amplían el catálogo con soporte variable.
El escalado por eventos transforma trabajo duradero en réplicas y puede volver a cero.
Resumen del tema
KEDA transforma trabajo externo en demanda; prioriza escaladores mantenidos por Microsoft y evalúa los comunitarios.
7. Escaladores de y
observa mensajes activos de una cola o suscripción. queueName o topicName y subscriptionName eligen el backlog; identifica y messageCount fija mensajes por réplica. Cincuenta con objetivo cinco piden diez.
usa accountName, queueName y queueLength sobre el recuento aproximado. Es económico para colas simples. Usa para sesiones, cola de mensajes fallidos, programación, funciones avanzadas o mayor rendimiento.
Elige para mensajería avanzada y para colas simples; calcula el objetivo con tiempo y paralelismo.
8. Particiones de y autenticación segura
mide eventos pendientes entre cada final de partición y el punto de control del grupo consumidor. consumerGroup, unprocessedEventThreshold y checkpointStrategy definen el cálculo; blobMetadata se recomienda con . El paralelismo útil no supera las particiones.
Un secreto de conexión exige rotación. Cuando se admita, usa con el rol mínimo, como Data Receiver. Es la opción de producción recomendada.
Resumen del tema
No superes el paralelismo de particiones y prefiere de privilegio mínimo.
9. Escaladores personalizados y conversión desde KEDA
ScaledObject incluye Apache Kafka, Redis Lists y , Prometheus, Cron, PostgreSQL, MySQL, y de métricas. Comprueba significado, autenticación, , mantenedor y soporte; un escalador externo puede requerir componentes.
Mapea triggers[].type a --scale-rule-type o custom.type.
Mapea a CLI de o .
Sustituye TriggerAuthentication por secretos y auth o .
Mapea mínimos y máximos.
Prueba funciones sin equivalencia exacta.
Resumen del tema
La conversión preserva tipo, , autenticación y límites y valida diferencias de plataforma.
10. Señales de Apache Kafka y Redis
Kafka mide retraso entre offsets finales y confirmados. bootstrapServers, consumerGroup, topic y lagThreshold definen la regla; SASL/PLAIN, SASL/SCRAM o autentican. Más réplicas que particiones no aumentan consumo paralelo.
Redis Lists compara LLEN con listLength. Redis sigue entradas entregadas pero no confirmadas y representa mejor recuperación. Elige variante estándar, o Sentinel.
Resumen del tema
Kafka escala por retraso y Redis por elementos en cola o pendientes; topología y confirmación limitan paralelismo.
11. Línea base Cron y métricas Prometheus
Cron solicita desiredReplicas entre start y end en un timezone. Combínalo con o eventos para anticipar picos y reaccionar a demanda; gana la mayor solicitud.
Prometheus ejecuta PromQL en serverAddress, divide por threshold y usa metricName. Sirve para sesiones, transacciones, o una métrica de negocio más fiel que la concurrencia.
Resumen del tema
Cron anticipa capacidad y Prometheus reacciona a una métrica significativa; combina predicción y reacción.
12. CPU, memoria, fallos y capacidad total
Los recursos son por contenedor y réplica. La memoria GiB debe ser al menos dos veces la CPU. El inicio habitual es 0,25 CPU y 0,5 GiB; Consumption general llega a 4 CPU y 8 GiB por contenedor. Los tienen asignación propia.
Superar memoria reinicia; superar CPU limita y aumenta latencia. Capacidad máxima es recurso por réplica multiplicado por máximo. Réplicas grandes reducen eventos pero tienen pasos gruesos; pequeñas escalan con precisión y más sobrecarga.
Dimensiona por cuellos medidos y multiplica por el máximo para demostrar capacidad y techo de coste.
13. Consumption, Dedicated, Flex, coste y rendimiento
Consumption es , cobra por réplica en ejecución y favorece elasticidad y cero. Dedicated reserva VM para consistencia, más recursos, aislamiento o hardware. La documentación actual añade Flex en : cómputo de un solo inquilino, cobro parecido a consumo, réplicas mayores y sin reducción a cero. Comprueba región y límites.
Empieza con valores predeterminados y prueba modelo y . Aumenta al observar CPU limitada, falta de memoria, latencia o . Mantén mínimo para estricto y mide con . Mil réplicas por revisión es un límite, no un plan.
El cómputo fija rendimiento y cobro; el modo de revisión, cómo las versiones comparten tráfico.
Resumen del tema
Usa Consumption para elasticidad, Dedicated para consistencia y evalúa Flex en con pruebas de carga y coste.
14. Revisiones inmutables y modo único o múltiple
Una revisión es inmutable. Imagen, reglas, entorno y recursos crean otra; secretos, entrada, tráfico, etiquetas, credenciales de registro y modo son de aplicación.
Único es predeterminado: la anterior sirve hasta que la nueva esté lista y pase sondeos. Múltiple conserva varias para canary, azul-verde y A/B y exige gestión explícita.
az containerapp update \
--name order-api --resource-group rg-ai200-scale \
--revision-mode multiple
az containerapp ingress traffic set \
--name order-api --resource-group rg-ai200-scale \
--revision-weight order-api--stable=90 order-api--candidate=10
Resumen del tema
Único automatiza sustitución protegida; múltiple añade coexistencia y exige tráfico, supervisión y limpieza.
15. Pesos, etiquetas y escalado independiente
Los pesos suman 100% y el enrutamiento es probabilístico. Empieza canary con 5% o 10%, observa errores, latencia y réplicas y completa o revierte.
Una etiqueta crea directa para una revisión y es independiente. Empieza con letra, usa minúsculas, números y guiones simples y no supera 64 caracteres. Puede moverse atómicamente.
Cada revisión activa escala con su tráfico y mínimo. Dos al 50/50 pueden costar más que una. Desactiva la antigua; las inactivas no consumen réplicas y quedan hasta el límite de 100.
Resumen del tema
Los pesos controlan la principal, las etiquetas el acceso dirigido y cada revisión activa escala sola; retira capacidad tras el rollout.
16. Laboratorio, evaluación y referencias Microsoft
El ejercicio de 30 minutos despliega una de agente, crea y , configura concurrencia con KEDA, genera carga, observa réplicas y aplica . Requiere suscripción con permisos, plan de pago por la limitación de ACR Tasks con créditos gratuitos, , CLI de reciente y Python 3.12 o superior.
Registra FQDN, revisión y réplicas sanas.
Aplica objetivo y carga paralela.
Correlaciona carga, réplicas, latencia y revisión.
Cambia y valida la nueva revisión.
Elimina recursos desechables y no uses secretos reales.
