Ejercicio: Creación de un modelo de estado de la aplicación
Contoso Shoes necesita una forma de detectar, diagnosticar y predecir problemas en esta arquitectura. Nuestro objetivo es crear un modelo de estado que sea mensurable a través de un estado de mantenimiento aplicado a los flujos de usuario y del sistema. Queremos identificar posibles puntos de error antes de que puedan provocar una interrupción.
Estado actual y problema
Hasta ahora, hemos agregado una API de comprobación de estado y hemos creado funcionalidades de varias regiones en la arquitectura. Sin embargo, no hay ninguna manera de obtener información sobre la topología compleja que incluye los flujos de usuario y del sistema. Esta carencia debe subsanarse para que el equipo de SRE pueda identificar y resolver problemas rápidamente.
En un incidente ocurrido hace poco, el equipo fue incapaz de ver el impacto en cascada de un problema originado en un componente de API que afectaba a sus dependencias de la plataforma. Se desperdició mucho tiempo en solucionar el problema porque no había forma de localizar el componente en estado incorrecto. Esta ineficiencia acabó prolongando los tiempos de inactividad, lo que provocó pérdidas económicas para la empresa.
Especificación
Diseñe un modelo de estado que muestre la relación entre todos los componentes de la arquitectura, incluidos los componentes de la aplicación y las dependencias de la plataforma. Tenga en cuenta los elementos que existen en el flujo de solicitud, como la puerta de enlace, el proceso, las bases de datos, el almacenamiento, las memorias caché, etc. Incluya también aquellos componentes que suelan estar fuera del flujo de solicitud, por ejemplo, los artefactos de Open Container Initiative (OCI), los almacenes secretos o los servicios de configuración, entre otros. Todos los servicios de Azure deben estar configurados para enviar datos de diagnóstico.
Agregue un receptor de datos unificado a la arquitectura para recopilar datos de varios orígenes.
Defina un estado de mantenimiento general según las métricas y los registros históricos agregados. Represente el estado en uno de los tres estados de mantenimiento siguientes: incorrecto, degradado y correcto.
Visualice el estado de mantenimiento de todos los componentes de una jerarquía que representa a todos los flujos.
Enfoque recomendado
Para empezar con el diseño, recomendamos hacer lo siguiente.
Importante
El modelado del estado es una tarea exhaustiva. El enfoque proporcionado en esta sección está concebido como ayuda para empezar. Sea exhaustivo al aplicar el modelo a todos los flujos funcionales y no funcionales en el diseño crítico para obtener una vista holística del sistema.
1: Inicio del modelado de estado
Este ejercicio es teórico. El modelado de estado en una actividad de diseño de arriba abajo en la que necesitaremos una lista completa de los componentes usados en la arquitectura. Esta lista debe incluir todos los componentes de la aplicación y los servicios de Azure.
Coloque esos componentes en un gráfico de dependencias que muestre una vista jerárquica de la solución. La capa superior contiene los flujos de usuario que realizan el seguimiento de la solicitud del usuario final y hacia el sitio web, así como los flujos en el nivel de API de la aplicación. La capa inferior contiene los flujos del sistema de los servicios de Azure. Asigne dependencias también entre los recursos de Azure.
El gráfico tendrá una apariencia similar a la siguiente:
Compruebe su progreso: Estado de la aplicación en capas
2: Definición de las puntuaciones de estado
Recopile métricas y umbrales de métricas de cada componente y, a continuación, decida el valor en el que el componente debe considerarse como correcto, degradado o incorrecto. Esa decisión debe venir marcada por el rendimiento previsto y por los requisitos empresariales no funcionales. Clasifique las métricas del siguiente modo:
Métricas de la aplicación: puntos de datos del código de la aplicación, como el recuento de excepciones.
Métricas de servicio: puntos de datos de los servicios de Azure, como las unidades de transacción de base de datos (DTU) en uso.
Métricas de la solución: puntos de datos de nivel de solución, como el tiempo de procesamiento completo de una solicitud.
Este es un ejemplo de Azure App Services.
| Servicios de aplicaciones | Estado de mantenimiento |
|---|---|
| Tiempo de respuesta < 200 msErrores de servidor HTTP < 2 |  |
| Tiempo de respuesta < 500 msErrores de servidor HTTP < 2 |  |
| Tiempo de respuesta > 500 msErrores de servidor HTTP > 2 |  |
3: Definición de un estado de mantenimiento general
Defina un estado general en cada flujo de usuario y del sistema. Deberá agregar el estado de mantenimiento de los componentes individuales que participan en ese flujo.
Supongamos que un flujo del sistema consta de un componente de aplicación, un plan de Azure App Service y App Services.
| API | Plan de App Service | Servicios de aplicaciones | Estado de mantenimiento |
|---|---|---|---|
| Latencia máxima < 30 ms | % de CPU < 70 % Longitud de cola HTTP < 5 | Tiempo de respuesta < 200 msErrores de servidor HTTP < 2 | |
| Latencia máxima < 30 ms | % de CPU < 90 % Longitud de cola HTTP < 5 | Tiempo de respuesta < 500 msErrores de servidor HTTP < 2 | |
| Latencia máxima > 30 ms | % de CPU > 90 %Longitud de cola HTTP > 5 | Tiempo de respuesta > 500msErrores de servidor HTTP > 2 | |
La puntuación de estado de un flujo de usuario debe representarse con la puntuación más baja de todos los componentes asignados. En el caso de los flujos del sistema, pondere de manera oportuna en función de la importancia empresarial. Entre ambos flujos, deben tener prioridad los flujos de usuario importantes económicamente u orientados al cliente.
Compruebe su progreso: Ejemplo: Modelo de estado en capas
4: Recopilación de datos de supervisión
Necesitaremos un receptor de datos unificado en cada región que recopile los registros y las métricas de todos los servicios de aplicación y plataforma implementados como parte de la marca regional. Necesitaremos otro receptor donde almacenar las métricas emitidas desde recursos globales, como Azure Front Door y Cosmos DB.
Opciones de tecnología
- Se usa Azure Application Insights para recopilar toda la telemetría de la aplicación.
- Los registros de Azure Monitor recopilan los datos enviados por Application Insights y las métricas de plataforma de los servicios de Azure.
- Se usa Azure Log Analytics como almacén central de los registros y las métricas de todos los componentes de la aplicación y la infraestructura.
Compruebe su progreso: Receptor de datos unificado para realizar análisis correlacionados
5: Configuración de consultas para supervisar datos
El Lenguaje de consulta Kusto (KQL) se integra bien con Log Analytics. Implemente consultas KQL personalizadas como funciones para recuperar datos de Azure Monitor.
Almacene las consultas personalizadas en el repositorio de código para que se importen y apliquen automáticamente como parte de las canalizaciones de integración continua y entrega continua (CI/CD).
6: Visualización del estado de mantenimiento
El gráfico de dependencias con las puntuaciones de estado se puede visualizar como un semáforo. Use herramientas como los paneles de Azure, Monitor Workbooks o Grafana. Este es un ejemplo:
Compruebe su progreso: Visualización
7: Configuración de alertas de los cambios de estado
Los paneles se deben usar con alertas para prestar atención inmediata a los problemas.
Si el estado de mantenimiento de un componente cambia a degradado o a incorrecto, el operador debe recibir una notificación inmediata. Configure las alertas en el nodo raíz, ya que cualquier cambio en este nodo indica un estado incorrecto en los recursos o flujos de usuario subyacentes.
Compruebe su progreso: Alertas
Comprobar el trabajo
Vea esta demostración sobre la supervisión y el modelado de estado. ¿Cubre el diseño todos los aspectos?
- ¿Tiene un receptor de datos unificado para realizar análisis correlacionados?
- ¿Ha incluido los registros de aplicaciones, las métricas de la plataforma y los puntos de datos de la solución?
- ¿Ha configurado paneles para visualizar el estado de mantenimiento de todos los componentes?
- ¿Ha tenido en cuenta los puntos de error en cada servicio (o parte de ese servicio) que podrían provocar una interrupción o impedirle realizar tareas de escalado, implementación o supervisión?
- ¿Ha tenido en cuenta los paquetes de consulta para capturar consultas clave que ayuden a evaluar los problemas con mayor rapidez?
- ¿Fue útil la API de comprobación de estado en este modelo? ¿Tuvo que modificar esa API para adaptarla mejor al modelo de estado?