Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Documento de planificación del experimento
Estado estacionario
| Process name (Nombre del proceso) | Sitio de adopción de mascotas |
|---|---|
Arquitectura física |
(Enlace al diagrama de arquitectura). |
Arquitectura lógica |
(Enlace al diagrama lógico). |
Defina el estado estacionario |
El tiempo medio de carga de la página web de adopción de mascotas, medido con Largest Contentful Paint (LCP), es de 2,5 segundos o menos, con una latencia del 99 por ciento (P99) de 4 segundos o menos, con una base de referencia de 5000 usuarios simultáneos. |
Métricas de estado estacionario |
Métrica de LCP capturada en toda la base de usuarios y métricas doradas (latencia, rendimiento, tasas de error, saturación). |
Observabilidad en estado estacionario |
El navegador del usuario capturará el LCP, lo enviará a Amazon CloudWatch y lo inspeccionará con CloudWatch RUM. Durante un período de 60 segundos, se sumarán la media y el tiempo de LCP de 99 pesos para todas las solicitudes de ese período. Las métricas básicas de nivel superior se capturan mediante el uso de. CloudWatch |
Proceso para alcanzar un estado estable |
Grafana K6 se utilizará para crear una carga que simule los niveles normales de tráfico de producción de aproximadamente 5000 usuarios simultáneos. |
Requisitos de observabilidad
Los equipos deberían poder ver lo siguiente:
-
Estado estacionario: ¿Qué se observará para verificar que la aplicación esté en condiciones normales?
-
Condición de fallo: ¿Cómo aparecerá el estado de fallo en el salpicadero? Por ejemplo:
-
Alarmas que deberían activarse
-
Registros que deben generarse
-
-
Impacto de la falla: ¿Qué se debe observar para ver los componentes que se espera que se vean afectados (alcance del impacto)?
-
Recuperación: ¿Cómo se visualizará y medirá la recuperación para captar el MTTR?
-
Depuración: detalles de solución de problemas relacionados con los errores de los experimentos.
La siguiente tabla proporciona sugerencias y ejemplos para un gráfico de requisitos de observabilidad. Debe definir lo que debe observarse en función de su experimento específico.
| ¿Qué hay que observar | Enlace a la herramienta de observabilidad | ¿Qué se está observando |
|---|---|---|
Fuente de entrada |
Cuadro de mandos Grafana K6 |
|
Estado general de la aplicación |
|
|
Estado del flujo de trabajo |
CloudWatch Panel de adopción de mascotas |
Tiempo de LCP, métricas doradas |
Rastros |
Panel de X-Ray sobre adopción de mascotas |
|
Registros |
CloudWatch Registros de adopción de mascotas |
Todos los errores que detecten los pods se enviarán a CloudWatch Logs. |
Definición de experimento
| Nombre del experimento | Amazon EKS PetSite pod CPU stress |
|---|---|
Experimenta con el código fuente |
(Enlace al repositorio de fuentes del experimento). |
Descripción del experimento |
Este experimento explora cómo un aumento en el uso de la CPU del módulo de PetSite aplicaciones afectaría a la experiencia general del cliente. Al inyectar stress de CPU en cada PetSite módulo en ejecución, podremos entender si hay un impacto en los clientes y el alcance de ese impacto. |
Requisitos o parámetros del experimento |
Carga de aplicación: media de producción Selector de etiquetas para cápsulas: |
Duración del experimento |
10 minutos |
Entorno |
Entorno de prueba alfa |
Experimenta con los recursos objetivo |
PetSite pods de aplicaciones |
Experimente la línea base que se introduce mediante la herramienta de generación de carga |
|
Condición de retroceso |
Ninguno |
Hipótesis
| ¿Qué pasaría si | Impact | Recuperación |
|---|---|---|
¿Qué pasaría con el estado estable si los pods de PetSite aplicaciones utilizaran o provocaran un uso de la CPU superior al 60% durante 10 minutos con un tráfico normal a nivel de producción?
|
Los tiempos de LCP se mantendrán por debajo de 2,5 segundos para un P50 de los usuarios con un P99 de 4 segundos o menos. El consumidor debería poder cargar la página de destino. PetSite |
Detección:
Autorreparación:
Recuperación: Cuando el uso de la CPU vuelva a la normalidad, el LCP debería recuperarse automáticamente. |
Proceso de experimentación
Adapte el siguiente step-by-step proceso de ejemplo a su experimento específico:
-
Valide el acceso y la funcionalidad de todos los Amazon CloudWatch, CloudWatch RUM y AWS X-Ray paneles de control.
-
Valide el estado del entorno de la aplicación:
-
Confirme que el clúster de EKS está en buen estado mediante el CloudWatch panel de control.
-
Visite la implementación de la aplicación del sitio de prueba de adopción de mascotas en la URL de ejemplo.
-
-
Inicie una carga para alcanzar un estado estable:
-
Confirme que el generador de carga esté funcionando y enviando 5000 solicitudes por segundo.
-
Espere 5 minutos para que la aplicación alcance su estado estable.
-
Confirme el estado estable de la aplicación mediante el panel de control de CloudWatch RUM.
-
-
Iniciar una falla (experimento):
-
Abre la AWS FIS consola.
-
Ejecuta el pet-adoption-pod-stress experimento.
-
Confirma que el experimento se está ejecutando en la consola.
-
-
Observe el impacto de la falla en su aplicación:
-
Realice capturas de pantalla del CloudWatch RUM y de los CloudWatch paneles de control y anote cualquier dato anómalo.
-
Una vez finalizado el experimento AWS FIS, captura capturas de pantalla adicionales para registrar si la aplicación vuelve al estado estable en ausencia de stress y observa cualquier anomalía en los puntos de datos.
-
Si el estado estable no se reanuda, tome medidas para recuperar la aplicación y registre las medidas adoptadas.
-
-
Valide que el entorno haya vuelto a la normalidad:
-
Revise todas las métricas empresariales, de la experiencia del usuario, de las aplicaciones y de la infraestructura para comprobar que el sistema ha vuelto a un estado conocido. Haga capturas de pantalla del panel de control si resulta útil.
-
Cronología del experimento
Asegúrese de capturar la cronología del end-to-end experimento, empezando por la generación de la carga, la inyección de la falla, la observación del impacto y la recuperación de la aplicación, y finalizando cuando detenga la generación de carga. Esto se ilustra en el siguiente ejemplo.
Resultados del experimento
| ID de ejecución del experimento | Resultados del experimento |
|---|---|
|
(Enlace a los resultados del experimento). |
Defectos identificados
-
El clúster de Kubernetes no detectó el deterioro de la CPU de los PetSite pods, por lo que no programó despliegues adicionales.
-
Como resultado de este experimento, las tasas de error no aumentaron ni 4XX ni 5XX.
-
Tenemos que ajustar la comprobación del estado del módulo para tener en cuenta el impacto en el LCP cuando hay limitaciones de recursos.
