Proceso para cargas de trabajo de SaaS en Azure
La aplicación de software como servicio (SaaS) debe ejecutarse en una plataforma de proceso. Al igual que otros componentes de la arquitectura, debe cumplir los requisitos empresariales y diseñarse según el modelo de negocio. La elección de la plataforma de proceso es una decisión de diseño significativa. La decisión afecta al aislamiento, el rendimiento y la resistencia de los clientes, y la plataforma de proceso influye en cómo toda la solución SaaS puede escalar y crecer.
En este artículo se describen las consideraciones para elegir el modelo de hospedaje, los aspectos operativos de ese modelo y cómo optimizar las opciones de tecnología para ayudarle a cumplir los acuerdos de nivel de servicio (SLA) y los objetivos de nivel de servicio (SLO).
Selección de una plataforma de proceso
Elegir la plataforma de proceso adecuada para la carga de trabajo de SaaS es importante, pero la abundancia de opciones disponibles puede hacer que la elección se sienta abrumadora. La mejor plataforma depende de factores como la arquitectura de la aplicación, la escala, las necesidades de rendimiento y el modelo de aislamiento de inquilinos. Es posible que lo que sea óptimo para una aplicación no sea para otra.
Consideraciones de diseño
Modelo de hospedaje. Azure ofrece varios modelos de hospedaje, principalmente infraestructura como servicio (IaaS) y plataforma como servicio (PaaS), cada uno con sus propias ventajas y desventajas. Evalúe los requisitos de la aplicación y elija el modelo más adecuado.
IaaS proporciona máquinas virtuales (VM) y control total sobre ellas, incluidas las redes y el almacenamiento. Sin embargo, requiere administrar y aplicar revisiones, lo que puede ser de uso intensivo. Algunos ejemplos son los conjuntos de escalado de máquinas virtuales y los clústeres de Azure Kubernetes Service (AKS).
PaaS permite implementar aplicaciones sin administrar la infraestructura subyacente. Incluye características integradas para el escalado automático y el equilibrio de carga. Algunos ejemplos son App de Azure Service y Azure Container Apps.
Los servicios paaS ofrecen menos control en comparación con IaaS, lo que puede ser problemático si la aplicación necesita una configuración específica. Por ejemplo, la aplicación podría ejecutarse en un sistema operativo que el servicio PaaS no admite.
Tipo de carga de trabajo. Algunas plataformas están especializadas para cargas de trabajo específicas, mientras que otras son versátiles. Por ejemplo, App Service está diseñado para aplicaciones web, mientras que AKS es más de uso general. Puede hospedar aplicaciones web, cargas de trabajo de IA y tareas de proceso por lotes.
Desarrollar experiencia en equipo. Los cambios grandes pueden ser difíciles si el equipo no tiene experiencia con la nueva plataforma. Evalúe las aptitudes de su equipo y adíquelas a sus requisitos de plataforma. Comience con una plataforma sencilla y evolucione gradualmente su arquitectura en lugar de saltar directamente a una opción más avanzada.
Por ejemplo, si va a compilar una aplicación en contenedor, comience con Container Apps para facilitar la administración. A medida que sus necesidades crecen más complejas, puede realizar la transición a AKS cuando obtenga una mejor comprensión de la plataforma a lo largo del tiempo.
Sobrecarga de administración. Las plataformas de proceso equilibran la sobrecarga y el control. Una mayor responsabilidad de administración se ha alejado del equipo significa menos control sobre la plataforma.
Por ejemplo, IaaS ofrece un alto control sobre las máquinas virtuales, pero conlleva una sobrecarga significativa. Si la aplicación se implementa en el entorno de un cliente, es posible que tenga acceso limitado para las operaciones de administración. Evalúe si estas ventajas son aceptables y factibles.
Requisitos de rendimiento. Comprenda los requisitos de rendimiento de la aplicación mediante el modelado de CPU, memoria, red, incluidos el ancho de banda y la latencia, la GPU y las necesidades de disponibilidad. También debe considerar el crecimiento futuro. Use esta información para elegir los recursos de proceso adecuados, como la serie y el tamaño de las máquinas virtuales. Es posible que también tenga que seleccionar regiones específicas que admitan series de máquinas virtuales concretas para cumplir los requisitos especializados.
Requisitos de confiabilidad. Tenga en cuenta las características de confiabilidad de la plataforma de proceso y asegúrese de que cumplen los objetivos de confiabilidad. Es posible que tenga que usar niveles de servicio específicos para tener varias instancias de la solución o implementar en zonas de disponibilidad para mejorar la confiabilidad.
Consulte Recomendaciones de RE:04 para definir destinos de confiabilidad.
Seguridad y cumplimiento de aplicaciones. Evalúe las características de seguridad y las certificaciones de cumplimiento de cada plataforma de proceso para asegurarse de que satisfacen sus necesidades. Por ejemplo, si necesita supervisar y filtrar el tráfico saliente, es posible que tenga que elegir niveles o servicios de proceso específicos.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Evalúe los requisitos de rendimiento de proceso mediante la estimación de las dimensiones de CPU, memoria, red y escala de GPU. Realice pruebas de carga para recopilar datos más precisos para informar al ejercicio de modelado. |
Estas tareas le ayudan a seleccionar el ajuste de tamaño adecuado para la plataforma de proceso y escalar adecuadamente cuando aumenta la carga en el sistema. |
| Evalúe la competencia de su equipo y comience con la plataforma menos compleja que satisfaga sus necesidades o una con la que el equipo ya esté familiarizado. | Asegúrese de que las operaciones más fluidas y evite sobrecargar al equipo eligiendo una plataforma de proceso con la que estén familiarizados. |
| Sea flexible en su diseño. Aspira a una solución que puede iterar con el tiempo para adaptarse a los requisitos empresariales y técnicos en constante evolución. | La flexibilidad le permite adaptarse más fácilmente a los cambios y mejoras a lo largo del tiempo. Puede responder eficazmente a las necesidades empresariales y técnicas en constante evolución. |
| Evalúe el costo total de propiedad (TCO), incluidos los costos de funcionamiento de la solución. | Tiene una comprensión clara de los costos, que es fundamental para planear el modelo de precios y garantizar operaciones rentables. |
| Evalúe si necesita usar plataformas de proceso específicas debido a la pila de tecnología. Algunas plataformas de proceso son más adecuadas para determinados lenguajes de programación, herramientas y sistemas operativos. Esfuércese por usar plataformas que admitan de forma nativa sus opciones tecnológicas. | Evite el costo de rediseñar la arquitectura, lo que podría incluir la migración a una nueva plataforma. |
| Evalúe las características de confiabilidad de la plataforma y factorice las garantías del proveedor de servicios en la nube en los SLO. | Puede reducir el riesgo de interrupciones localizadas del centro de datos mediante la planeación de características de confiabilidad y el uso de zonas de disponibilidad si están disponibles. |
Modelo de arrendamiento y aislamiento
El modelo de negocio de SaaS determina si hospeda recursos para los clientes o los administra en el entorno del cliente. La mayoría de los proveedores de SaaS hospedan recursos en nombre de sus clientes, lo que permite flexibilidad en el diseño de la plataforma de proceso. Aísle las cargas de trabajo de los clientes de forma eficaz para optimizar la eficiencia de los costos sin poner en peligro la experiencia o el rendimiento del cliente.
Consideraciones de diseño
Planee el modelo de arrendamiento. El modelo de inquilino determina el uso compartido de recursos entre los clientes y está influenciado por los modelos de precios y de negocio. Los modelos de inquilino único tienen mayores costos por cliente en comparación con los modelos totalmente multiinquilino. Los precios deben reflejar estas diferencias.
Requisitos del cliente. Algunos clientes pueden tener necesidades específicas para la residencia de datos, garantías de rendimiento o cumplimiento de seguridad. Si estos requisitos necesitan niveles de aislamiento más altos de los habituales, considere cómo reflejar el aumento de los costos en el modelo de negocio.
Problema de vecino ruidoso. Tenga en cuenta el problema de vecino ruidoso al compartir recursos entre inquilinos. Los recursos de proceso se ven afectados más. Para obtener más información, consulte Antipatrón vecino ruidoso.
Al elegir un modelo de arrendamiento, equilibre el ahorro de costos del uso compartido de recursos con la necesidad de garantizar el rendimiento del cliente. Los recursos de uso compartido excesivo o permitir un consumo excesivo pueden degradar la experiencia del cliente.
Compensación: rendimiento y costo. Compartir recursos entre los clientes puede ser rentable, pero si algunos clientes usan más recursos de lo esperado, este enfoque puede degradar el rendimiento de otros. Para evitar esto, implemente la gobernanza de recursos adecuada para asegurarse de que el uso del inquilino permanece dentro de los límites esperados.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Evalúe las características de aislamiento de la plataforma de proceso para asegurarse de que cumple los requisitos del modelo de arrendamiento. | Para evitar volver a trabajar la plataforma, compruebe primero la configuración crítica. |
| Aplique el modelo de aislamiento. Tenga cuidado con los recursos compartidos, como las memorias caché de disco local, la memoria del sistema y las memorias caché externas, ya que pueden filtrar accidentalmente datos entre inquilinos si no se administran correctamente. Para requisitos de aislamiento elevados, aplique el aislamiento dentro de la plataforma de proceso y en la aplicación. |
El aislamiento seguro reduce el riesgo de pérdida de datos entre inquilinos, un incidente de seguridad grave. |
| Implemente la gobernanza y la supervisión de recursos, con visibilidad de las métricas de nivel de cliente. Supervise proactivamente el consumo de recursos de cada cliente para detectar y mitigar los problemas ruidosos de los vecinos. |
Evita que los problemas afecten a otros clientes mediante la supervisión del consumo de recursos y la mitigación temprana de los problemas. |
Configuración de la escalabilidad y la rentabilidad
Los clientes pueden usar la aplicación con diferentes perfiles de rendimiento. Esperan que la aplicación controle las crecientes demandas de los usuarios, los datos a gran escala y las cargas de trabajo complejas sin poner en peligro la velocidad y el rendimiento. La arquitectura del sistema debe garantizar la escalabilidad y el rendimiento óptimo, independientemente de si administra cientos o millones de usuarios, a la vez que equilibra las necesidades y los costos de rendimiento.
Para más información sobre la administración de costos, consulte Facturación y administración de costos para cargas de trabajo de SaaS en Azure.
Consideraciones de diseño
Estrategias de escalado horizontal y vertical. Los enfoques de escalado horizontal y vertical son viables para controlar el aumento de la carga. El enfoque que use depende de la capacidad de la aplicación para escalar entre varias instancias.
- El escalado horizontal implica agregar más instancias de nodos de proceso. La arquitectura necesita un equilibrador de carga para distribuir el tráfico entrante entre varios servidores o instancias.
- El escalado vertical implica aumentar los recursos, como la CPU y la memoria, en un solo servidor. Use este enfoque para las aplicaciones con estado que no necesitan almacenes de estado externos, como las memorias caché. El escalado vertical puede provocar interrupciones breves del servicio y tener un límite de recursos en un solo servidor.
Consulte Recomendaciones de PE:05 para el escalado y la creación de particiones.
Escalado automático. Los sistemas necesitan controlar eficazmente distintos niveles de demanda. A medida que aumenta el tráfico de usuario, los recursos de la aplicación deben escalar verticalmente para mantener el rendimiento. Cuando la demanda disminuye, los recursos se reducen verticalmente para controlar los costos sin afectar a la experiencia del usuario. Factores como el uso de cpu, la hora del día o las solicitudes entrantes guían estos ajustes. El escalado automático ayuda a equilibrar el rendimiento y el costo y mitiga el impacto de la alta demanda en otros inquilinos.
Consulte Recomendaciones de RE:06 para el escalado confiable.
Planeamiento de capacidad y asignación de proceso. La incorporación de nuevos clientes a la carga de trabajo de SaaS consume capacidad de recursos. Incluso si se escala vertical o horizontalmente, finalmente alcanza los límites, como las restricciones de red o almacenamiento, en la escalabilidad de la solución.
Nota:
El patrón Stamps de implementación permite implementar varias instancias independientes de la solución. Proporciona otra dimensión de escalado. Es fundamental comprender la capacidad de cada sello para determinar cuándo implementar más. Este concepto también se conoce como empaquetado de cubos.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Elija el escalado horizontal a través del escalado vertical. El escalado horizontal suele ser menos complejo, más confiable y rentable que el escalado vertical. | El escalado horizontal suele ser más sencillo, más confiable y rentable, lo que le permite escalar a un grado mayor que el escalado vertical. |
| Realice pruebas de carga. | La simulación del uso puede ayudarle a identificar cuellos de botella y umbrales de escalado antes de implementar en producción. |
| Defina el umbral de escalado para implementar una nueva marca en lugar de escalar horizontal o verticalmente. Para el escalado rentable sin pérdida de rendimiento, comprima los inquilinos en los pocos recursos posibles. |
Está mejor preparado para controlar el crecimiento más allá de la infraestructura actual. |
| Implemente el escalado automático, siempre que sea posible. Establezca reglas de escalado automático para reflejar la carga de la aplicación con precisión. | Para optimizar el rendimiento y el costo, aumente y reduzca los recursos según sea necesario. |
| Supervise y evalúe los patrones de uso de los clientes. | Sabe cuándo ajustar la infraestructura para aumentar el rendimiento o optimizar los costos. |
| Implemente mecanismos de almacenamiento en caché, siempre que sea posible. | Se reduce la carga potencial de procesamiento en la capa de proceso. |
| Use alertas de costos. | Las advertencias le ayudan a detectar problemas de alto uso y control de costos al principio. |
| Use reservas de Azure para los clientes que tienen compromisos a largo plazo y un uso de proceso garantizado durante ese período completo. | Maximiza la eficiencia del costo en la capacidad reservada. |
Diseño para lograr resistencia
La resistencia de la capa de proceso desempeña una gran parte en la estrategia general de resistencia. La aplicación debe tolerar y recuperarse de errores comunes de forma automática y sin problemas, sin impacto en el usuario.
Consideraciones de diseño
Requisitos de confiabilidad. Establezca requisitos claros de confiabilidad. Estos requisitos incluyen destinos internos o SLO, y compromisos de cliente, o acuerdos de nivel de servicio, que a menudo especifican objetivos de tiempo de actividad como el 99,9 % al mes.
Consulte Recomendaciones de RE:04 para definir destinos de confiabilidad.
Estrategia de implementación. Los recursos en la nube se implementan en regiones geográficas específicas. En Azure, las zonas de disponibilidad son conjuntos de centros de datos aislados dentro de una región. Para lograr resistencia, implemente aplicaciones en varias zonas de disponibilidad. La implementación entre regiones o proveedores de nube mejora la resistencia, pero agrega complejidad operativa y de costos.
Consulte Recomendaciones de RE:05 para usar regiones y zonas de disponibilidad.
Cargas de trabajo sin estado. Para implementar aplicaciones resistentes, normalmente es necesario ejecutar copias redundantes en diferentes ubicaciones. Esta tarea puede ser difícil para las cargas de trabajo con estado, que necesitan mantener el estado de sesión. Apunte a crear cargas de trabajo sin estado siempre que sea posible.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Controle los errores transitorios en la aplicación. | Aumente la disponibilidad recuperando rápidamente de problemas menores. |
| Elija aplicaciones sin estado. Si la aplicación debe tener estado, use un mecanismo de almacenamiento de estado externo como una memoria caché para almacenar el estado. | Se evita la pérdida de estado causada por la falta de disponibilidad de una instancia, como durante el equilibrio de carga erróneo o durante una interrupción. |
| Uso de zonas de disponibilidad. | Para aumentar la resistencia, se mitigan las interrupciones localizadas del centro de datos. |
| Diseñe una arquitectura multirregional cuando haya justificación comercial para hacerlo. | Cumple los requisitos de tiempo de actividad elevados y admite a los usuarios en diferentes regiones. |
| Realice la ingeniería del caos. | Comprenda mejor dónde están los puntos de error y puede corregirlos antes de que se produzca una interrupción. |
| Limite el uso de componentes que comparten varios sellos. | Elimina puntos únicos de error y reduce el posible área de impacto para una interrupción. |
Recursos adicionales
Multiinquilino es una metodología empresarial básica para diseñar cargas de trabajo de SaaS. En estos artículos se proporciona más información sobre las consideraciones sobre la plataforma de proceso:
Paso siguiente
Obtenga información sobre las consideraciones de red para las cargas de trabajo de SaaS.