En una sesión celebrada en la conferencia de Google Cloud Next de 2019 se analizaron algunos problemas comunes que pueden afectar a una aplicación y cómo mitigarlos.
Uno de los mayores problemas de cualquier organización es cuando se cae una aplicación. El tiempo de inactividad puede conducir a una mala experiencia del usuario y, en última instancia, costar el dinero del negocio.
En una sesión informativa durante la conferencia de Google Cloud Next de 2019, el director de ingeniería de fiabilidad del cliente de Google, Luke Stone, explicó algunas de las principales razones del tiempo de inactividad y cómo los desarrolladores y el departamento de TI pueden luchar contra ellos.
VER: El nuevo nivel’Always Free’ de Google le da a su empresa una prueba de sabor de la nube pública
Aquí hay 10 causas comunes del tiempo de inactividad de las aplicaciones y cómo evitarlas.
1. Sobrecarga
La sobrecarga, muy simplemente, es «cuando la demanda excede la capacidad», dijo Stone. Una forma de responder es con trabajo de deslastre de carga para eliminar el exceso de carga antes de que aplaste la aplicación. Cuando esté en su capacidad, devuelva los errores antes de realizar cualquier trabajo. Calcule la capacidad de su servicio y determine lo que puede manejar en el servidor de aplicaciones y, a continuación, envíe un error a cada solicitud que supere ese número.
2. Vecino ruidoso
Los usuarios pueden traer spam, u otra carga de trabajo (copias de seguridad, etc.) puede convertirse en un vecino ruidoso. En este caso, no puede deshacerse de la carga de manera uniforme, ya que afectará injustamente a los usuarios normales. Para tratar con vecinos ruidosos, Stone recomendó poner límites, como límites de solicitud para que cada usuario cancele a los robots de spam y a los malos actores. También puede intentar limitar por dirección IP, pero eso podría afectar a los buenos usuarios. Por lo tanto, asegúrese de que sea configurable para que pueda ayudar fácilmente a las personas que fueron afectadas erróneamente.
3. Puntas de reintento
Cuando empieces a rechazar a los usuarios, empezarán a volver a intentarlo porque no saben por qué fueron rechazados. Los clientes no pueden diferenciar entre una sola falla y un servicio interrumpido. Estos picos de reintento pueden conducir a una falla en cascada, apuntó Stone. Para solucionar esto, implemente un backoff agresivo e intente adivinar cuándo se sobrecargará el servicio para que pueda planificarlo.
4. Mala dependencia
En este número, de repente la dependencia se vuelve muy lenta y las solicitudes se acumulan. Este problema ocurre cuando la entrada y la salida de su aplicación no se están comunicando correctamente. Su cliente debe convertirse en un «conductor defensivo» para que no sobrecargue sus sistemas backend. También se puede abordar este problema con la reducción dinámica de la carga, dijo Stone. En el futuro, la organización debería simular un escenario de desastre con pruebas de carga masivas y repentinas para determinar dónde estarán los puntos débiles.
5. Escalar los límites
Cuando una organización quiere atender más solicitudes, a menudo puede encontrarse con problemas a medida que intenta escalar. Esto puede causar un cuello de botella entre la aplicación que está creando y un servicio (como una API) en el que confía. Para resolver el problema, Google confía en lo que Stone llamó «sharding», donde una carga de trabajo consistente se divide en pequeños trozos que se pueden hacer por separado. Stone recomendó triturar temprano y usar más fragmentos para aumentar la capacidad.
6. Desigualdad de fragmentos
Esto ocurre cuando uno de los fragmentos está más ocupado que los otros, debido a la popularidad o a las manchas calientes, señaló Stone. Para solucionarlo, tendrás que volver a ponerlo, lo que se puede hacer dividiendo los fragmentos que se han hecho demasiado grandes, o usando un mapa de fragmentos para determinar qué fragmentos se convertirán en los más populares. Si es posible, deje los fragmentos no problemáticos en paz cuando los vuelva a endurecer, recomendó Stone.
7. Mascotas
Esto se deriva de la frase «ganado, no mascotas». La muerte de una mascota es triste y difícil de tratar, mientras que la muerte del ganado es el costo de hacer negocios. Una «mascota» es una carga de trabajo o un sistema que tiene demasiada participación humana, o que se considera demasiado importante. Las mascotas deben ser reconocidas y documentadas, para que otras personas, además del «manejador», se sientan alentadas a trabajar en ellas.
8.Mala implementación
Este es el caso número uno de interrupciones en todas las organizaciones en las que Stone ha trabajado, dijo. La mejor técnica para manejar las interrupciones causadas por el despliegue de código defectuoso es tener una buena manera de recuperarse si lo hace. Un proceso de retroceso probado y verdadero ayudará, dijo Stone, pero usted debe saber cuándo se está llevando a cabo una implementación. Además, las implementaciones progresivas pueden ayudar al ser lo suficientemente lentas para detectar problemas que surgen lentamente, señaló Stone. Una buena estrategia de aumento es pasar del 1%, al 5%, al 10%, al 50% y al 100% en etapas.
9. Seguimiento de las lagunas
Muchos usuarios tienen vacíos de monitoreo entre lo que el usuario está experimentando y lo que el sistema les está diciendo. Ciertos problemas, como el número de errores que se están produciendo o la latencia media, pueden ayudar a predecir mejor lo que el usuario está viendo. Si detecta que los usuarios no están satisfechos, puede continuar con la comprobación de la CPU, la RAM, los errores de conexión y otras métricas para intentar determinar qué es lo que está mal.
10. Dominios de fallo
Stone describió los dominios con fallos como un «trozo de su infraestructura que puede fallar al mismo tiempo». Ejemplos de ello serían una VM, una zona determinada o incluso una región determinada. Para mitigar este problema, piense con anticipación y trate de determinar cuáles de estas áreas podrían ser sus dominios de falla y coloque sus copias de seguridad y datos en otro lugar. Sin embargo, estos dominios deben utilizarse para implementaciones y pruebas de desastre, de modo que si el problema es causado por una zona caída, por ejemplo, usted sabe que podría no ser un problema de aplicación.
Boletín de noticias de Data Center Trends
DevOps, virtualización, la nube híbrida, el almacenamiento y la eficiencia operativa son sólo algunos de los temas del centro de datos que destacaremos. Entregado Lunes y Miércoles