Uso de las métricas empresariales para diseñar aplicaciones de Azure resistentes

Objetivos de disponibilidad de la carga de trabajo

¿Se han definido objetivos de disponibilidad, como Acuerdos de Nivel de Servicio (SLA), indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO), para la aplicación o los escenarios clave?

Comprender las expectativas de disponibilidad del cliente es fundamental para revisar las operaciones generales de la aplicación. Por ejemplo, si un cliente se esfuerza por lograr un SLO de aplicación del 99.999%, el nivel de actividad operativa inherente que necesite la aplicación será mucho mayor que si el objetivo fuera un SLO del 99.9%.

Defina sus propios Acuerdos de Nivel de Servicio para cada carga de trabajo de la solución de forma que pueda determinar si la arquitectura satisface los requisitos empresariales.

Tenga en cuenta el costo y la complejidad

Con todo lo demás igual, es mejor tener una mayor disponibilidad. Sin embargo, cuantos más nueves busque, mayores serán el costo y la complejidad. Un tiempo de actividad del 99.99% se traduce en unos 5 minutos de tiempo de inactividad total al mes. ¿Vale la pena la complejidad y el costo adicionales para llegar a cinco nueves? La respuesta depende de los requisitos del negocio.

Estas son algunas otras consideraciones al definir un Acuerdo de Nivel de Servicio:

• Para lograr cuatro nueves (99.99%), probablemente no pueda confiar en una intervención manual para recuperarse de los errores. La aplicación debe autodiagnosticarse y recuperarse automáticamente.
• Para lograr más de cuatro nueves, es difícil detectar interrupciones del sistema lo suficientemente rápido como para cumplir con el Acuerdo de Nivel de Servicio.
• Piense en la ventana de tiempo con la que se mide que el Acuerdo de Nivel de Servicio. Cuanto menor sea la ventana, más estrictas serán las tolerancias. Probablemente no tenga sentido definir el Acuerdo de Nivel de Servicio en función del tiempo de actividad a cada hora o a diario.
• Tenga en cuenta las medidas MTBF y MTTR. Cuanto mayor sea el Acuerdo de Nivel de Servicio, menos frecuentemente puede estar el sistema fuera de servicio y más rápidamente se debe recuperar.
• Acuerde con sus clientes los objetivos de disponibilidad de cada parte de la aplicación, y documéntelos. De lo contrario, es posible que el diseño no satisfaga las expectativas de los clientes.

Identificación de las dependencias

Realice ejercicios de asignación de dependencias para identificar las dependencias internas y externas. Entre los ejemplos se incluyen las dependencias relacionadas con la seguridad o la identidad, como Active Directory, o servicios de terceros, como un proveedor de pago o un servicio de correo electrónico.

Preste especial atención a las dependencias externas que puedan ser un único punto de error o causar cuellos de botella. Por ejemplo, si una carga de trabajo requiere un tiempo de actividad del 99.99%, pero depende de un servicio con un Acuerdo de Nivel de Servicio del 99.9%, ese servicio no puede ser un único punto de error en el sistema. Una solución es tener una ruta de acceso de reserva en caso de que se produzca un error en el servicio. Como alternativa, tome otras medidas para recuperarse de un error en ese servicio.

En la tabla siguiente se muestra el tiempo de inactividad acumulativo potencial para varios niveles de Acuerdo de Nivel de Servicio.

Identificación de los flujos críticos del sistema

Comprender los flujos críticos del sistema es fundamental para evaluar la eficacia operativa general y debe usarse para informar de un modelo de estado de la aplicación. También puede indicar si las áreas de la aplicación están sobreutilizadas o infrautilizados y deben ajustarse para satisfacer mejor las necesidades empresariales y los objetivos de costos.

Los subsistemas o las rutas de acceso más críticos que recorren la aplicación pueden tener expectativas más altas en cuanto a la disponibilidad, la recuperación y el rendimiento debido a que la funcionalidad y los escenarios empresariales asociados son críticos. Asimismo, ayuda a entender si el costo se verá afectado debido a estas necesidades más elevadas.

Identificación de los componentes menos críticos

Otros componentes o rutas de acceso menos críticos que recorren la aplicación pueden tener expectativas menores en cuanto a la disponibilidad, la recuperación y el rendimiento. Como consecuencia, los componentes menos críticos pueden reducir los costos si elige SKU inferiores con un rendimiento y una disponibilidad menores.

Métricas de recuperación

Para obtener estos valores, realice una valoración de los riesgos y asegúrese de que comprende los costos y los posibles riesgos que puede suponer una pérdida de datos. Estos son requisitos no funcionales de un sistema y deben dictarlos las necesidades empresariales.

• El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable que una aplicación puede no estar disponible después de un incidente.
• El objetivo de punto de recuperación (RPO) es la duración máxima de la pérdida de datos que es aceptable durante un desastre.

Si el valor de MTTR de cualquier componente crítico de una configuración de alta disponibilidad supera el RTO del sistema, un error en el sistema podría provocar una interrupción inaceptable del negocio. Es decir, no podrá restaurar el sistema dentro del RTO que se ha definido.

Métricas de disponibilidad

Use estas medidas para planear la redundancia y determinar los Acuerdos de Nivel de Servicio de los clientes.

• El tiempo medio para la recuperación (MTTR) es el tiempo medio que se tarda en restaurar un componente después de un error.
• El tiempo medio entre errores (MTBF) es la duración que se puede esperar razonablemente de un componente entre dos interrupciones.

Descripción de los Acuerdos de Nivel de Servicio

En Azure, el Acuerdo de Nivel de Servicio explica los compromisos de Microsoft en cuanto a tiempo de actividad y conectividad. Si el Acuerdo de Nivel de Servicio para un servicio determinado es del 99.9%, significa que debe esperar que el servicio esté disponible un 99.9% del tiempo. Los diferentes servicios tienen distintos Acuerdos de Nivel de Servicio.

El Acuerdo de Nivel de Servicio de Azure también incluye disposiciones para obtener un crédito de servicio si no se cumple, junto con las definiciones específicas de disponibilidad de cada servicio. Ese aspecto del Acuerdo de Nivel de Servicio actúa como una directiva de cumplimiento.

El ejemplo del estimador del Acuerdo de Nivel de Servicio muestra cómo calcular el SLA de su arquitectura.

Acuerdos de Nivel de Servicio compuestos

Los Acuerdos de Nivel de Servicio compuestos comprenden los distintos servicios que permiten el uso de una aplicación, cada uno con distintos niveles de disponibilidad. Por ejemplo, considere una aplicación web de App Service que escribe en Azure SQL Database. En el momento de la publicación, estos servicios de Azure son los que tienen los siguientes Acuerdos de Nivel de Servicio:

• Aplicaciones web de App Service = 99.95%
• SQL Database = 99.99%

¿Cuál es el tiempo de inactividad máximo que se esperaría para esta aplicación? Si se produce un error en cualquiera de los servicios, se produce un error en toda la aplicación. La probabilidad de que se produzca un error en cada servicio es independiente, por lo que el Acuerdo de Nivel de Servicio compuesto para esta aplicación es del 99.95% × 99.99% = 99.94%. Esto es menor que los Acuerdos de Nivel de Servicio individuales, lo cual no es sorprendente, porque una aplicación que depende de varios servicios tiene más puntos de error posibles.

Puede mejorar el Acuerdo de Nivel de Servicio compuesto mediante la creación de rutas de reserva independientes. Por ejemplo, si SQL Database no está disponible, coloque las transacciones en una cola para procesarlas más adelante.

Con este diseño, la aplicación sigue estando disponible, aunque no pueda conectarse a la base de datos. Sin embargo, se produce un error si la base de datos y la cola fallan al mismo tiempo. El porcentaje de tiempo previsto para un error simultáneo es 0.0001 × 0.001, por lo que el Acuerdo de Nivel de Servicio compuesto para esta ruta combinada es:

• Base de datos o cola = 1.0 − (0.0001 × 0.001) = 99.99999%

El Acuerdo de Nivel de Servicio compuesto total es:

• Aplicación web y (base de datos o cola) = 99.95% × 99.99999% = \~99.95%

Este enfoque tiene sus ventajas e inconvenientes. La lógica de aplicación es más compleja, está pagando por la cola y tiene que considerar los problemas de coherencia de los datos.

Acuerdos de Nivel de Servicio para implementaciones en varias regiones

Los Acuerdos de Nivel de Servicio para implementaciones en varias regiones requieren una técnica de alta disponibilidad para implementar la aplicación en más de una región y usar Azure Traffic Manager para conmutar por error si se produce un error de la aplicación en alguna de ellas.

El Acuerdo de Nivel de Servicio compuesto para una implementación en varias regiones se calcula del siguiente modo:

• N es el Acuerdo de Nivel de Servicio compuesto para la aplicación implementada en una región.
• R es el número de regiones en las que se implementa la aplicación.

La probabilidad de que la aplicación produzca un error en todas las regiones al mismo tiempo es ((1 − N) \^ R). Por ejemplo, si el Acuerdo de Nivel de Servicio para una sola región es del 99.95%:

• El Acuerdo de Nivel de Servicio combinado para dos regiones = (1 − (1 − 0.9995) \^ 2) = 99.999975%
• El Acuerdo de Nivel de Servicio combinado para cuatro regiones = (1 − (1 − 0.9995) \^ 4) = 99.999999%

El Acuerdo de Nivel de Servicio para Traffic Manager también es un factor. La conmutación por error no es instantánea en las configuraciones activo-pasivo, lo que puede dar lugar a un tiempo de inactividad durante ese proceso. Consulte Supervisión de puntos de conexión y de Traffic Manager.