Diseño de una política de métricas de rendimiento en la nube

Tres pasos proactivos para garantizar el rendimiento de la nube: Supervisión, pruebas y creación de una política.

A menudo, las empresas y los organismos utilizan las métricas de rendimiento para medir cuán bien se desempeña un sistema, pero no tan a menudo las utilizan para medir cuán bien se desempeñan los servicios en la nube. En este artículo, el autor explica por qué es mejor ser proactivo al utilizar las métricas de rendimiento de la nube para solucionar los problemas antes de que puedan producirse fallas en el servicio y proporciona tres pasos proactivos — en el monitoreo del rendimiento, la prueba del rendimiento y el diseño de una política de métricas de rendimiento en la nube — para ayudar a evitar el mal rendimiento en la nube.

Judith M. Myerson, Arquitecta e ingeniera en sistemas, IBM

Judith M. Myerson es una arquitecta e ingeniera en sistemas. Sus áreas de interés incluyen sistemas en toda la empresa, tecnologías de middleware, tecnologías de base de datos, computación en nube, políticas de umbral, industrias, gestión de red, seguridad, tecnologías de RFID, gestión de presentación y gestión de proyectos.



24-12-2012

Desarrolle habilidades de este tema

Este contenido es parte de un knowledge path progresivo para avanzar en sus habilidades. Vea Computación en la nube: Cree una política eficaz para la nube

Este artículo explica por qué es mejor ser proactivo al utilizar las métricas de rendimiento antes de que puedan producirse fallas en el servicio. A continuación, se describen tres pasos proactivos: Supervisión del rendimiento, puesta a prueba del rendimiento y diseño de una política de métricas de rendimiento en la nube.

Las expectativas

Para medir cuán bien se están desempeñando los servicios en la nube, debe focalizarse en tres tipos de expectativas — usuario, desarrollador y encargado de mantenimiento de la tecnología. Miremos por debajo de la interfaz del usuario para descubrir qué están haciendo los desarrolladores y encargados de mantenimiento de la tecnología para hacer que se cumplan esas expectativas.

Expectativas de los usuarios

Es un día tranquilo aquí en el territorio del usuario en la nube. Dado que todo funciona bien, los usuarios pueden esperar encontrar rápidamente elementos (como un cuadro de inicio de sesión) en la aplicación y pueden aumentar y disminuir la aplicación sin emisiones. Ah, y que la aplicación siempre se encuentra disponible. Los usuarios también pueden esperar que el tiempo de descarga sea rápido, la respuesta de la aplicación a las solicitudes del usuario sean rápidas y el proveedor recupere los datos en el trasfondo.

Todos los usuarios están felices. Aquí se clasifica al proveedor con una buena reputación comercial — confiable, rápido, seguro y eficiente. La aplicación está funcionando bien. Los usuarios esperan que los desarrolladores y los encargados de mantenimiento de la tecnología estén utilizando adecuadamente las métricas de rendimiento para garantizar que la aplicación se ejecute sin problemas. Necesitan información de la aplicación para tomar decisiones comerciales importantes o continuar con las operaciones comerciales.

Expectativas de los desarrolladores

Los desarrolladores pueden esperar que todas las aplicaciones que se ejecutan sin problemas en el centro de datos in situ funcionen bien en la nube. Pueden esperar que la aplicación en la nube tenga control de estados (explicaré esto después), que se haya arreglado bien con una nueva versión y que se ejecute con velocidad, responsa rápido a las solicitudes de los datos de los usuarios, que los recursos aumenten o disminuyan paulatinamente y sin problemas.

Todas las expectativas de los usuarios dependen de las expectativas de los usuarios. Quieren que los usuarios estén felices con la aplicación que desarrollan para ellos. Los desarrolladores supervisan y prueban el rendimiento con las métricas aclaradas en una política de medición del servicio en la nube.

Si falta alguna de estas métricas de rendimiento, el desarrollador no tiene forma de chequear cuán bien se desempeña la aplicación en la nube. El mal rendimiento puede resultar de fallas inesperadas en el servicio, lo que deja a los usuarios varados sin la información que necesitan para tomar decisiones comerciales importantes y continuar con su negocio.

Expectativas del encargado de mantenimiento de la tecnología

Generalmente, los encargados del mantenimiento técnico son proveedores o terceras partes para los proveedores. Garantizan que las tecnologías se utilicen de forma adecuada para migrar la aplicación in situ a la nube. Una vez en la nube, los desarrolladores supervisan y prueban el rendimiento con las métricas aclaradas en una política de medición del servicio en la nube.

Para garantizar un buen rendimiento, es importante mantener la buena reputación comercial del proveedor como confiable, rápido, seguro y eficiente. Si falta alguna de estas métricas de rendimiento, el proveedor no tiene forma de chequear cuán bien se desempeña la aplicación en la nube. El mal rendimiento puede resultar en fallas inesperadas del servicio que dejan a los

  • usuarios varados sin la información que necesitan para tomar decisiones comerciales importantes.
  • Los desarrolladores varados en el medio de la supervisión de la aplicación y las pruebas en la nube.

Escena 1: Pesadilla de fallas en el servicio

Un día en CloudUserLand, los usuarios no pudieron acceder a la aplicación ni obtuvieron respuesta de la aplicación. De repente, encontraron fallas en el servicio. Luego, recibieron un mensaje en su pantalla que decía que el proveedor "se disculpa por no poder proporcionar los servicios dado que se encuentra en un mantenimiento programado".

Furioso por encontrar una solución rápida, el desarrollador se vuelve reactivo, intenta resguardar la reputación del proveedor, pero es en vano. Primero, detiene la producción y simula estar en un mantenimiento programado. Coloca un aviso en los navegadores de los usuarios que dice "Servicio temporalmente interrumpido. Espere". Luego, comienza a trabajar en la aplicación in situ.

Mientras tanto, los usuarios esperan de forma impaciente. En poco tiempo, el usuario pierde la paciencia y solicita la devolución de su dinero por un mal servicio. No puede tomar decisiones comerciales importantes o continuar con la empresa para obtener más ingresos. Algunos se encuentran al límite de perder consumidores o sus reputaciones.

El proveedor, que una vez fue considerado como confiable y eficiente, ahora se considera como no confiable e ineficiente. Después de algunas horas de falta de funcionamiento del servicio, los usuarios cancelan de inmediato las suscripciones con ese proveedor y se dirigen a otro proveedor que tiene una reputación con más trayectoria, lo que proporciona confiabilidad, disponibilidad, seguridad y eficiencia.

A continuación se detalla lo que los expertos en tecnología consideran que está mal:

  • Primero, al desarrollador le resulta difícil ubicar el código que genera el problema del control de estado. La aplicación no respondió correctamente a los estados subsiguientes.
  • Segundo, el desarrollador descubrió muy tarde que la aplicación que funciona perfectamente in situ fue escrita por un desarrollador anterior como una unidad única y prolongada más que, por ejemplo, 500 partes modulares. Cuando el desarrollador actual intenta parchar la aplicación, la nueva versión rompe las funciones en un sitio web en el que se ejecuta una aplicación SaaS. El desarrollador frenéticamente divide el programa en partes modulares (aproximadamente de 10 a 20 para ahorrar tiempo). Cuando intenta parchar uno de los módulos con una nueva versión, descubre que la versión rompe las funciones del sitio web.
  • Tercero, después de que el desarrollador soluciona el problema con la nueva versión, prueba la aplicación en la nube para determinar cuán bien se ubican de forma equivalente los recursos para ejecutar la aplicación. Descubre que el equilibrio de la carga (umbral de recursos) falla debido a que falla un solo recurso que había alcanzado el máximo. Otros recursos que solo alcanzaron el 75 por ciento de su capacidad máxima no podrían controlar las transacciones comerciales desde la instancia de recursos fallida. Esto creó un efecto dominó en los parámetros de rendimiento: el umbral de respuesta y el umbral de solicitud de datos.

Antes de la migración, el desarrollador no habilitó un umbral, entonces cada instancia de recurso se utiliza a un 50 por ciento de su capacidad, por lo que si falla una instancia, las instancias de recursos saludables tomarán el control. No controló para verificar si la aplicación ejecutada en las instancias de recursos saludables respondería rápidamente y si los usuarios hasta el límite especificado en la licencia del usuario pueden acceder de forma concurrente a la aplicación de estado de control.


Escena 2: Proactivo con métricas de rendimiento

Hay tres puntos de contacto cuando puede solucionar estos problemas: Antes de que sucedan, mientras están ocurriendo y después de que suceden. A continuación, explicamos porqué "antes de que sucedan" es la mejor posición para evitar el posible problema.

Acto 1: Rendimiento de la supervisión

Debería supervisar el rendimiento de las aplicaciones en la nube para detectar problemas antes de que sucedan. De lo contrario, debe otorgar a los usuarios créditos, devoluciones o meses gratuitos de servicio según los términos del Acuerdo de Nivel del Servicio (ANS) ante fallas para proporcionar garantías de disponibilidad de servicios. Cada Acuerdo de Nivel del Servicio (ANS) se mide para los servicios, las transacciones y los servidores basados en las aplicaciones del ANS en cada servidor.

El análisis de registro es la herramienta más popular para supervisar el rendimiento para verificar los tiempos de respuestas y la concurrencia. Puede ser engorroso para ser utilizado al supervisar el rendimiento de varias aplicaciones en muchas ubicaciones.

Una mejor forma de supervisar el rendimiento consiste en configurar un tablero de métricas rendimiento para obtener el corazón del problema en curso. Cuando una de las métricas muestra signos de inclinación hacia resultados negativos, debería poder acceder a las herramientas de métricas de fácil acceso para hacer que identificar de forma proactiva los problemas posibles de la aplicación antes de que las encuentren los usuarios.

Algunas métricas de rendimiento sugeridas incluyen las siguientes:

  • control de estado
  • control de versiones
  • umbral de recursos
  • umbral del usuario
  • umbral de solicitud de datos
  • umbral de respuesta

Métricas del estado de control se refiere a cuán bien responde la aplicación de forma correcta en los estado subsiguientes. Mientas la mayoría de las aplicaciones se encuentran inherentemente en control de estado, nunca sabe cuándo se convierten en inestables.

Métrica de control de versiones hace referencia cuán bien un nuevo diseño evita romper las funciones de la aplicación existente incluso si el estado de control previo de la aplicación respondió de forma correcta desde un estado a otro hasta que finalizan las tareas de la aplicación. Las interrupciones del control de versiones tienen lugar cuando se asignan nombres duplicados de versiones o números a la aplicación.

Umbral de recursos se refiere a cuán bien se equilibra el consumo de recursos de forma dinámica para las aplicaciones en la nube. El nivel del umbral debería encontrarse en o debajo del número máximo de instancias de recursos adicionales que podrían consumirse. Cuando el consumo de recursos excede el nivel del umbral durante un aumento en las demandas de carga de trabajo, se distribuyen las instancias de recursos. Cuando la demanda aumenta o disminuye el nivel del umbral, las instancias de recursos que se crearon se liberan y se les designa otro uso.

El umbral del usuario se refiere a cuán bien puede acceder un usuario de forma concurrente a la aplicación hasta el límite especificado en la licencia del usuario desde el proveedor. Por ejemplo, si una licencia se limita a 3000 usuarios, pero solo permite un máximo de 2500 usuarios para acceder de forma concurrente, entonces el nivel del umbral se establece en 2000 usuarios concurrentes. Si el número de usuarios concurrentes se encuentra por debajo del umbral de la aplicación, la aplicación se encuentra continuamente disponible al asumir que el consumo de recursos y las solicitudes de datos se encuentran por debajo de su nivel respectivo del umbral.

El umbral de solicitud de datos se refiere a las solicitudes de datos que pueden procesarse rápidamente. El nivel del umbral se establece por debajo del número máximo de solicitudes de datos y el tamaño máximo de las solicitudes de datos que los usuarios pueden enviar de forma concurrente. Si la cantidad de solicitudes de datos excede el nivel del umbral, debe aparecer un mensaje que muestre cómo esperan en cola muchas solicitudes de datos para su procesamiento.

El umbral de respuesta se refiere a cuán rápido responde la aplicación a la solicitud de datos del usuario o a una parte de la aplicación para la otra parte. El nivel del umbral se establece por debajo del tiempo de respuesta tolerable máximo.

El umbral de respuesta también se refiere a qué sucede cuando finaliza el servicio proporcionado por la aplicación.

Acto 2: Prueba de rendimiento:

Debe probar el rendimiento antes de que el tablero comience a mostrar los posibles problemas y después de que los encuentre de forma proactiva (antes de que lo haga el usuario). Para hacer esto, necesita más que herramientas de equilibrio. Una mejor forma de probar el rendimiento consiste en utilizar las métricas siguientes:

  • Control de estado
  • Control de versiones
  • Umbral de recursos
  • Umbral del usuario
  • Umbral de solicitud de datos
  • Umbral de respuesta

Control de estado: ¿Cuán bien fluye una aplicación de una tarea a otra? ¿El estado de función se dirige de una tarea (como el uso de una biblioteca proporciona de forma correcta información de identificación) a la tarea siguiente (en la cual el bibliotecario verifica el libro)?

Control de versiones: ¿Cómo se desempeña una nueva versión de la aplicación? ¿Rompe con la lógica de la aplicación?

Umbral de recursos: ¿Cuán bien varias aplicaciones utilizan varios recursos? ¿Cuál es la capacidad de los servidores que están utilizando las instancias de recursos? Cada servidor no debería tener más de 50 por ciento de capacidad; ¿hay suficientes instancias adicionales de recursos durante los aumentos en las cargas de trabajo de la demanda (es decir, por ejemplo, durante la temporada de ofertas de Navidad)?

Umbral del usuario: ¿Cuántos usuarios pueden acceder de forma concurrente a la aplicación? ¿Puede el sistema soportar el estrés de un aumento repentino en la cantidad de usuarios concurrentes?

Umbral de solicitud de datos: ¿Cuántas solicitudes de datos pueden encontrarse en espera y por cuánto tiempo? ¿La fila está moviendo las solicitudes rápidamente?

Umbral de respuesta: ¿Cuán bien responde la aplicación a la solicitud de datos o de un usuario? ¿Qué sucede cuando una tarea en la aplicación expira? ¿Se dirige hacia otra tarea para continuar proporcionando servicio a los usuarios?

Acto 3: Diseño de una política de métricas de rendimiento

Si no puede entender cómo comenzar a diseñar su propia política de métricas de rendimiento, a continuación aparece una lista de verificación de los elementos que deberían incluirse en la política:

  • Propósito: ¿De qué se trata?
  • Alcance: Escriba un límite en torno a la política.
  • Trasfondo: ¿Quién hace qué?
  • Acciones: Prepárese para el trabajo pesado.
  • Restricciones: Trabaje con ellos.

Ahora, para más detalles.

Propósito: ¿De qué se trata?
Para ayudar a los usuarios a conocer de qué se trata la política, determine su propósito. A continuación, hay una plantilla de ejemplo que puede utilizar.

El propósito de esta política consiste en garantizar que todos los tipos de servicio en la nube se basen bien para todas las métricas de rendimiento. Tienen control de estado, control de versiones y cuatro tipos de umbrales: recurso, usuario, solicitud de datos y respuesta.

Alcance: Escriba un límite en torno a la política.
Defina el alcance al incluir un límite en torno a la política. Dentro de este límite, especifique qué tipos de servicios en la nube aloja el proveedores y a los que se suscriben o alquilan los consumidores. Si el proveedor se sale del límite al aceptar el acuerdo del consumidor a cumplir, especifique lo que necesita hacer el proveedor y cómo pueden informar los consumidores los problemas de rendimiento con los componentes de SaaS, PaaS, IaaS por separado o como un conjunto.

A continuación, se incluyen los puntajes sugeridos para cada métrica:

  • Control de estado: 100 por ciento de éxito del estado actual de una tarea que responde en estados subsiguientes.
  • Control de versiones: 100 por ciento de éxito de no romper con la lógica de la aplicación.
  • Umbral de recursos: Hasta un 50 por ciento de la capacidad del servidor a ser ocupada por los recursos de instancias.
  • Umbral de solicitud de datos: Puede poseer una cantidad específica de solicitudes de datos en espera.
  • Umbral del usuario: Hasta el 70 por ciento de los usuarios especificados en la licencia.
  • Umbral de respuesta: Cantidad de segundos de retraso de respuesta no advertido por los usuarios (es decir, cinco segundos).
Trasfondo: ¿Quién hace qué?
Lo primero que quiere saber el usuario es si el proveedor es interno o externo. Lo siguiente que quiere saber es qué herramientas de métricas de rendimiento usará el proveedor para medir cuán bien se desempeña una aplicación in situ en la nube.

Además, el consumidor podría también querer saber cómo se relacionan las métricas de rendimiento con los niveles garantizados de la disponibilidad del servicio, como lo establece el ANS.

Acciones: Prepárese para el trabajo pesado.
A continuación presentamos algunas sugerencias para las acciones a realizar:
  • Acción 1. Diríjase a las herramientas de métricas especificadas en la política de métricas de computación en la nube.
  • Acción 2. Indique si supervisar o probar el rendimiento 24 horas.
  • Acción 3. Requiere programas de capacitación en supervisión y pruebas de rendimiento con herramientas de métricas.
  • Acción 4. Proporcione un aviso anticipado sobre el mantenimiento o las actualizaciones programadas para la gestión del acceso del usuario, las tecnologías de protección de datos y las máquinas virtuales.
  • Acción 5. Envíe un aviso a los consumidores sobre las acciones proactivas planeadas a tomarse sobre el uso de métricas de rendimiento.
  • Acción 6. Envíe copias a los consumidores de la política de métricas de rendimiento de computación en la nube para su revisión y preguntas a resolver antes de que el consumidor se registre para obtener un servicio en la nube.
  • Acción 7. Configure un tablero de métricas de rendimiento para obtener el centro de un problema cuando sucede.
Restricciones: Trabaje con ellos.
Habrá algunas restricciones en su camino, por ejemplo:
  • Cuestiones de prioridad de servicio para diferentes grupos de consumidores según los roles asignados por la organización para los consumidores. Un usuario final con privilegios administrativos, incluido el uso de registros para supervisar el rendimiento, tiene una prioridad más alta sobre el usuario final que no lo tienen al acceder en la aplicación SaaS.
  • Excepciones del servicio a las métricas de rendimiento y el ANS. Le doy una clave: El corte accidental de ópticas que no se encuentran dentro del control directo del proveedor, del mantenimiento programado (planeado y no planeado), y los cambios de comportamiento proactivos a las aplicaciones que migran desde la oficina a la nube.
  • Penalidades al servicio cuando el rendimiento del sistema disminuye de forma significativa desde el nivel garantizado de la disponibilidad del servicio. Proporcione al consumidor el derecho a obtener créditos, rembolsos o meses libres siempre y cuando la falla en garantizar el servicio no sea una excepción al servicio. Especifique en una cláusula de salida sobre el proceso de hacer cumplir el derecho del consumidor a finalizar el servicio en la nube.

Cuando encuentra restricciones que lo bloquean, lo mejor es trabajar con ellos. Primero, puede usar restricciones para mejorar la postura de seguridad para la política de las métricas de rendimiento. En segundo lugar, si alguna de las métricas de rendimiento no son satisfactorias, tenga preparados los remedios para proteger al consumidor si el rendimiento del sistema disminuye de los niveles garantizados de disponibilidad del servicio.


Escena 3: ¿Qué hay si pierde su oportunidad para ser proactivo?

¿Qué sucede si pierde su oportunidad para ser proactivo? ¿Debería actuar diferente al escenario discutido previamente, la pesadilla de las fallas en el servicio? Las reparaciones sobre la marca no siempre funcionan; emparchar un módulo podría fallas, al igual que el equilibrio de la carga. Los parámetros de rendimiento, incluido el recurso, el usuario, la solicitud de datos y los umbrales de respuesta no se encontraban en su lugar.

Aquí hay algunas acciones a las que podría recurrir:

  • Aplicación de copias de seguridad, sistema y datos en una ubicación remota (muy importante en un plan de recuperación de desastres en caso de un terremoto).
  • Utilice un sistema de recuperación de fallos para garantizar que los servidores tomen el control de la aplicación y las transacciones de servidores con fallas.
  • Interprete el ANS para proporcionar a los consumidores créditos, reembolsos y meses libres por las fallas en garantizar la disponibilidad del servicio.

Después de que las copias de seguridad se recuperan rápidamente, el mecanismo de recuperación de fallas tiene lugar y el proveedor aplica los términos del ANS sobre las fallas para cumplir con la disponibilidad del servicio, debería comenzar a prepararse para realizar una supervisión proactiva — el rendimiento de las pruebas y el diseño de una política a poner en práctica.


En conclusión

Necesita un poco de planeamiento para ser proactivo con las métricas de rendimiento de computación en la nube: Tiene que decidir cómo debería supervisarse y probarse el rendimiento, y cómo diseñar sus métricas de rendimiento para tomar en cuenta los servicios de computación en la nube.

Los desarrolladores y los encargados del mantenimiento técnico deben comunicarse con los usuarios del servicio en la nube sobre cómo esperan que se desempeñe el servicio en la nube, entonces los problemas de rendimiento pueden encontrarse antes de que sucedan.

Como con todo lo demás en la vida, lo más importante para hacer como consumidor en la nube es obtener una copia de la política de las métricas de rendimiento de computación en la nube por parte del proveedor para revisar y resolver su posición sobre cualquier cuestión que tenga antes de negociar con el proveedor.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=853052
ArticleTitle=Diseño de una política de métricas de rendimiento en la nube
publish-date=12242012