Diseño de experimentos de caos
La aplicación crítica debe ser resistente y estar lista para responder a errores. Pero en la nube es difícil predecir posibles escenarios de error. La ingeniería del caos le permite realizar experimentos de error en un entorno controlado para identificar problemas que podrían surgir durante el desarrollo y la implementación. Inserte deliberadamente errores del mundo real y observe cómo reacciona el sistema.
En esta unidad, se usará Azure Chaos Studio. El servicio le ayudará a medir, comprender y mejorar la resistencia de la aplicación y el servicio en la nube. Estará preparado para responder rápidamente si este error se produce en condiciones adversas en producción.
Análisis del modo de error
Al diseñar un experimento de caos, el primer paso consiste en realizar el análisis del modo de error (FMA) de los componentes de la aplicación para identificar posibles escenarios de error.
Enumere todos los componentes adecuados para un flujo de usuario que deben estar disponibles y funcionales. Por ejemplo, en el flujo de usuario de finalización de la compra se usan Azure App Services, Functions y la base de datos Cosmos DB.
Para cada componente, enumere los posibles casos de error, su impacto y las posibles mitigaciones.
Ahora se verá el resultado de FMA realizado para los componentes del ejemplo de flujo de usuario de pago de Contoso Shoes.
Azure App Service para hospedar la aplicación de front-end
| Riesgo | Impacto | Posible mitigación |
|---|---|---|
| Interrupción de la zona de disponibilidad | Las instancias de esa zona podrían dejar de estar disponibles. No se espera una interrupción completa porque la redundancia de zona está habilitada en el plan de App Service. | Permita la carga adicional en las instancias restantes y proporcione suficiente espacio para este escenario mientras sigue logrando los objetivos de rendimiento. |
| Agotamiento de puertos SNAT | No se pueden crear conexiones salientes. Como resultado, se produce un error en las llamadas de bajada, como las llamadas a la base de datos. | Use puntos de conexión privados para conectarse a los componentes de bajada. |
| Instancia individual que se vuelve incorrecta | El tráfico de usuario enrutado a una instancia incorrecta podría ver un rendimiento deficiente o incluso dejar de funcionar por completo. | La característica de comprobación de estado de App Service hará que las instancias incorrectas se identifiquen y reemplacen de forma automática por instancias nuevas en buen estado. |
Azure Functions para la lógica de finalización de la compra
| Riesgo | Impacto | Posible mitigación |
|---|---|---|
| Rendimiento de arranque lento (esporádico) | Como se usa el plan Consumo de Azure Functions, las instancias nuevas no tendrán garantías de rendimiento. La alta demanda en el servicio (de "vecinos ruidosos") puede provocar que la función de finalización de la compra experimente una larga duración de inicio que afecte a los objetivos de rendimiento. | Actualice al plan Premium de Azure Functions. |
| Interrupción del almacenamiento subyacente | Si la cuenta de almacenamiento subyacente deja de estar disponible, la función dejará de funcionar. | Use un proceso con equilibrio de carga con almacenamiento regional o un proceso con equilibrio de carga con almacenamiento compartido GRS. |
Base de datos de Azure Cosmos DB
| Riesgo | Impacto | Posible mitigación |
|---|---|---|
| Cambio de nombre de una base de datos o colección | Debido a la falta de coincidencia en la configuración, podría haber pérdida de datos. La aplicación no podrá acceder a ningún dato hasta que se actualice la configuración y se reinicien sus componentes. | Evite esta situación mediante el uso de bloqueos de nivel de colección y de base de datos. |
| Interrupción de la región de escritura | Si en la región primaria (o en la de escritura) se produce una interrupción, la cuenta de Azure Cosmos DB promoverá automáticamente una región secundaria como la nueva región de escritura principal cuando la opción de conmutación automática por error (administrada por el servicio) está configurada en la cuenta de Azure Cosmos DB. La conmutación por error se producirá en otra región según el orden de prioridad de regiones que especificó. | Configure la cuenta de base de datos con varias regiones y conmutación automática por error. Si se produce un error, el servicio conmutará por error de forma automática y evitará cualquier problema sostenido en la aplicación. |
| Limitación extensa debido a la falta de unidades de solicitud (RU) | Algunas unidades de escalado se pueden ejecutar de forma activa con el uso de Azure Cosmos DB, mientras que otras todavía pueden atender solicitudes. | Use una mejor distribución de la carga para más unidades de escalado, o bien agregue más RU. |
Diseño de un experimento de caos
Para diseñar un experimento de caos, elija algunos casos de error. La elección se puede basar en la probabilidad de que se produzca el error o del posible impacto.
El objetivo del experimento es validar las medidas de resistencia que ha implementado en la aplicación. Para obtener una hipótesis de ejemplo, imagine que ejecuta la aplicación en App Service con la redundancia de zona habilitada. Si todas las instancias subyacentes de una zona quedan inactivas, espera que la aplicación siga en ejecución.
Use Chaos Studio para insertar los errores en los componentes adecuados. Chaos Studio ofrece una biblioteca de errores entre los que puede elegir. Pero como la biblioteca de errores no lo abarca todo, es posible que tenga que ajustar el escenario. O bien, es posible que necesite buscar más herramientas para ayudarle a insertar el error.
Importante
Con los experimentos, solo debe seleccionar como destino un entorno que no sea de producción. La inserción de errores en el entorno de producción puede ser arriesgada y se necesita experiencia y planificación.
Ejemplo: interrupción y conmutación por error de Azure Cosmos DB
Imagine que elige el escenario de error de "interrupción de la región de escritura" de Azure Cosmos DB que se muestra en la tabla. La hipótesis es: una conmutación por error iniciada por el servicio no debería dar lugar a ningún impacto sostenido en la aplicación. Si esta hipótesis demuestra ser cierta, ha validado que la medida de resistencia de la replicación en varias regiones tiene el efecto positivo deseado en la confiabilidad de la aplicación.
Para simular este error, use el error Azure Cosmos DB de la biblioteca de errores de Chaos Studio.
Este ejemplo es para una conmutación por error de Azure Cosmos DB que se ejecuta durante 10 minutos (PT10M) y en la que se usa West US 2 como la nueva región de escritura. Supone que West US 2 ya se ha configurado como una de las regiones de replicación de lectura.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
Una vez que finalice el experimento, Chaos Studio vuelve a cambiar la región de escritura a su valor original.
Para poder insertar un error en un recurso de Azure, debe habilitar la configuración de los destinos y funcionalidades correspondientes para ese recurso. Este valor controla los errores que se pueden ejecutar en los recursos habilitados para la inserción de errores. Al usar destinos y funcionalidades junto con otras medidas de seguridad, puede evitar la inserción de errores accidental o malintencionada.
Ahora que ha diseñado pruebas de carga y experimentos de caos, debe automatizarlos en las canalizaciones para que se ejecuten de forma coherente y periódica. En la unidad siguiente, obtendrá información sobre cómo agregar las pruebas de las canalizaciones de CI/CD.