Patrones y antipatrones para los Estandares de Desempeño y Disponibilidad

Índice


Disponibilidad

Antipatrones

Puntos de integración

Para garantizar el estado de los servicios web es recomendable eliminar los puntos únicos de fallo. Esto se logra incorporando componentes redundantes (servidores, enrutadores, energía, software, microservicios, refrigeración, IPs, nombre de dominio y otros), para que en caso de catástrofes o incidencias, el componente pueda reemplazar las tareas del otro que hubiese presentado fallas. Es recomendable poner en práctica este punto para que así se tolere la pérdida o desperfectos funcionales de algún componente de la infraestructura.

No siempre es posible eliminar todos los puntos únicos de fallo debido al costo que esto implica (hacer una evaluación de riesgo contra costo); sin embargo, de acuerdo a la criticidad del servicio web, se recomienda contar con un inventario de toda la infraestructura necesaria para el funcionamiento del servicio y evaluar qué componentes son los que tienen más probabilidad de fallo, para comenzar a aplicar la redundancia.

Cabe mencionar que existen arquitecturas de software que facilitan la redundancia de los elementos más utilizados de un servicio web, como los microservicios.

Reacciones en cadena

Fallos en cascada

Usuarios

Hilos bloqueados

Ataques de auto-negación

Efectos de escala

Capacidades desbalanceadas

Respuestas lentas

Conjunto ilimitado de resultados

Patrones

Tiempos de espera

Cortacircuitos

Mamparos

Estado estable

Fallar rápido

Saludo

Arnés de prueba

Es recomendable que los servicios web sean sometidos a un conjunto de pruebas de rendimiento para verificar su escalabilidad, fiabilidad y uso de recursos. Se recomienda utilizar los siguientes tipos:

En base a las mediciones de los resultados de las pruebas de rendimiento (carga y estrés), tomar decisiones en cuanto a los elementos que necesitarán redundancia, ya sean de software o hardware. Además es posible verificar el rendimiento de los servicios web realizando un análisis de los tiempos de respuesta en los registros de eventos.

Herramientas de pruebas de rendimiento:

Locus

Desacoplar Middleware


Desempeño

Antipatrones

Contención de grupo de recursos

Sobreuso de AJAX

Exceso de tiempo en sesiones

Botón de recargar

SQL Manual

Etroficación de la base de datos

Latencia de puntos de integración

Patrones

Grupo de conexiones

Caché

Es necesario identificar los servicios web consumidos con una frecuencia considerablemente alta, estos sean almacenados provisionalmente en una memoria extra para aligerar el proceso de consulta y respuesta en los servidores.

El cacheado se emplea comúnmente en operaciones idempotentes y puede efectuarse dentro del mismo servicio web (cargando datos que se soliciten con frecuencia a una estructura en memoria como redis) o como parte de su arquitectura (un servicio extra entre el cliente y el servicio web como varnish).

La arquitectura REST, al ser multicapa, permite la inclusión de manera sencilla de una caché.

Se recomienda el uso del cacheado en servicios web de lectura que requieran un alto rendimiento (se necesita responder a una alta cantidad de solicitudes al mismo tiempo).

Es importante tomar en cuenta que, en caso de modificación de datos, la caché también debe actualizarse ya que una caché no actualizada respondería con datos incorrectos.

Contenido precomputado

Afinar el recolector de basura