Capítulo 1. Comprender, medir y mejorar tu disponibilidad
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
A nadie le importa que tu sistema tenga grandes prestaciones si no puede utilizarlo.
Uno de los temas más importantes en la arquitectura de sistemas escalables es la disponibilidad. Aunque hay algunas empresas y algunos servicios para los que es razonable y esperable un cierto tiempo de inactividad, la mayoría de las empresas no pueden tener ningún tiempo de inactividad sin que ello afecte a la satisfacción de sus clientes y, en última instancia, a los resultados de la empresa.
Las siguientes son preguntas fundamentales que todas las empresas deben plantearse al determinar lo importante que es la disponibilidad del sistema para ellas mismas y para sus clientes. Son estas preguntas, y las inevitables respuestas a las mismas, las que constituyen el núcleo de por qué la disponibilidad es crítica para las aplicaciones a gran escala.
- ¿Por qué comprarte a ti?
¿Por qué debería alguien comprar tu servicio si no está operativo cuando lo necesita?
- ¿Qué piensan tus clientes?
¿Qué piensan o sienten tus clientes cuando necesitan utilizar tu servicio y no está operativo?
- ¿Cómo haces felices a los clientes?
-
¿Cómo puedes contentar a tus clientes, hacer que tu empresa gane dinero y cumplir tus promesas y requisitos empresariales si tu servicio no funciona?
Mantener a tus clientes contentos y comprometidos con tu sistema sólo es posible si tu sistema está operativo. Existe una correlación directa y significativa entre la disponibilidad del sistema y la satisfacción del cliente.
La alta disponibilidad es un componente tan crítico de la construcción de sistemas altamente escalables que dedicaremos una cantidad significativa de tiempo al tema en este libro. ¿Cómo se construye un sistema (un servicio, una aplicación o un entorno) que tenga una alta disponibilidad incluso cuando se le somete a una amplia gama de demandas?
Disponibilidad frente a fiabilidad
Disponibilidad y fiabilidad son dos conceptos similares pero muy diferentes. Es importante comprender la diferencia entre ellos.
La fiabilidad, en nuestro contexto, se refiere generalmente a la calidad de un sistema. Típicamente, significa la capacidad de un sistema para funcionar sistemáticamente según las especificaciones. Hablas de software como fiable si supera sus conjuntos de pruebas y hace en general lo que crees que debe hacer. La fiabilidad responde a la pregunta:
"¿Es correcta la respuesta a mi consulta?"
La disponibilidad, en nuestro contexto, se refiere generalmente a la capacidad de tu sistema para realizar las tareas que es capaz de hacer. ¿Existe el sistema? ¿Está operativo? ¿Responde? Si la respuesta es "sí", está disponible. La disponibilidad responde a las preguntas:
"¿Recibo una respuesta?"
"¿La respuesta llegó a tiempo?"
Como puedes ver, la disponibilidad y la fiabilidad son muy similares. Es difícil que un sistema esté disponible si no es también fiable, y es difícil que un sistema sea fiable si no está también disponible.
Más formalmente, esto es lo que queremos decir cuando utilizamos estos términos:
- Fiabilidad
La capacidad de tu sistema para realizar las operaciones que debe realizar sin cometer errores.
- Disponibilidad
La capacidad de tu sistema de estar operativo cuando sea necesario para realizar esas operaciones.
Un sistema que suma 2 + 3 y obtiene 6 tiene una fiabilidad deficiente. Un sistema que suma 2 + 3 y nunca devuelve ningún resultado tiene una disponibilidad deficiente. La fiabilidad puede solucionarse a menudo mediante pruebas. La disponibilidad suele ser mucho más difícil de solucionar.
Puedes introducir un error de software en tu aplicación que haga que 2 + 3 produzcan la respuesta 6. Esto puede detectarse y corregirse fácilmente en un conjunto de pruebas.
Sin embargo, imagina que tienes una aplicación que produce de forma fiable el resultado 2 + 3 = 5. Ahora imagina que ejecutas esta aplicación en un ordenador que tiene una conexión de red defectuosa. ¿Cuál es el resultado? Ejecutas la aplicación, y a veces devuelve 5, y a veces no devuelve nada. La aplicación puede ser fiable, pero no está disponible.
Nos centraremos casi exclusivamente en la arquitectura de sistemas de alta disponibilidad. Supondremos que tu sistema es fiable, supondremos que sabes construir y ejecutar conjuntos de pruebas, y hablaremos de fiabilidad sólo cuando tenga un impacto directo en la arquitectura de tu sistema o en su disponibilidad.
¿Qué causa la escasa disponibilidad?
¿Qué hace que una aplicación que antes funcionaba bien empiece a mostrar una disponibilidad deficiente? Hay muchas causas posibles:
- Agotamiento de recursos
Aumenta el número de usuarios o incrementa la cantidad de datos en uso en un sistema y tu aplicación puede ser víctima del agotamiento de recursos, lo que se traducirá en una aplicación más lenta y sin capacidad de respuesta.
- Cambios imprevistos basados en la carga
El aumento de la popularidad de tu aplicación puede requerir cambios en el código y la aplicación para gestionar el aumento de carga. Estos cambios, a menudo aplicados con rapidez y en el último minuto, con poca o ninguna previsión o planificación, aumentan la probabilidad de que se produzcan problemas.
- Mayor número de piezas móviles
A medida que una aplicación gana popularidad, a menudo es necesario asignar cada vez más desarrolladores, diseñadores, probadores y otras personas para que trabajen en ella y la mantengan. Este mayor número de personas que trabajan en la aplicación crea un gran número de partes móviles, ya sean nuevas funciones, cambios en las funciones o simplemente mantenimiento general de la aplicación. Cuantos más individuos trabajen en la aplicación, más partes móviles habrá en ella y mayor será la posibilidad de que se produzcan malas interacciones en ella.
- Dependencias externas
Cuantas más dependencias tenga tu aplicación de recursos externos, como servicios SaaS, infraestructura o servicios basados en la nube, más expuesta estará a problemas de disponibilidad causados por esos recursos.
- Deuda técnica
El aumento de la complejidad de las aplicaciones suele aumentar la deuda técnica (es decir, la acumulación de cambios de software deseados y correcciones de errores pendientes que suelen acumularse con el tiempo a medida que una aplicación crece y madura). La deuda técnica aumenta la probabilidad de que se produzca un problema.
Todas las aplicaciones de rápido crecimiento tienen uno, algunos o todos estos problemas. Por ello, pueden empezar a surgir problemas potenciales de disponibilidad en aplicaciones que antes funcionaban a la perfección. Los problemas pueden aparecer sigilosamente, o pueden empezar de repente, sin previo aviso.
Pero la mayoría de las aplicaciones en crecimiento acabarán teniendo problemas de disponibilidad.
Los problemas de disponibilidad te cuestan dinero, cuestan dinero a tus clientes y te cuestan la confianza y la fidelidad de tus clientes. Tu empresa no puede sobrevivir mucho tiempo si tienes constantemente problemas de disponibilidad.
Construir aplicaciones diseñadas para escalar significa construir aplicaciones diseñadas para una alta disponibilidad.
Medir la disponibilidad
Medir la disponibilidad es importante para mantener tu sistema altamente disponible. Sólo midiendo la disponibilidad puedes comprender el rendimiento actual de tu aplicación y examinar cómo cambia su disponibilidad con el tiempo.
El mecanismo más extendido para medir la disponibilidad de una aplicación web es calcular el porcentaje de tiempo que está accesible para su uso por los clientes. Podemos describirlo mediante la siguiente fórmula para un periodo determinado:
Porcentaje de disponibilidad del sitio = total_segundos_en_periodo - segundos_sistema_desactivo / total_segundos_en_periodo
Veamos un ejemplo. Supongamos que durante el mes de abril, tu sitio web estuvo caído dos veces; la primera vez estuvo caído 37 minutos, y la segunda vez estuvo caído 15 minutos. ¿Cuál es la disponibilidad de tu sitio web?
En el ejemplo siguiente puedes ver que basta una pequeña interrupción para que repercuta en tu porcentaje de disponibilidad:
Número total de segundos de bajada = (37 + 15) × 60 = 3.120 s
Número total de segundos en un mes = 30 días × 86.400 s/día = 2.592.000 s
Porcentaje de disponibilidad del sitio = total_segundos_en_periodo - segundos_sistema_desactivo / total_segundos_en_periodo
Porcentaje de disponibilidad del emplazamiento = 2.592.000 s - 3.120 s / 2.592.000 s
Porcentaje de disponibilidad del sitio = 99,8795
La disponibilidad de tu sitio es del 99,8795%.
Los Nueve
A menudo oirás describir la disponibilidad como "los nueves". Es una forma abreviada de indicar altos-porcentajes de disponibilidad. La Tabla 1-1 ilustra su significado. Una aplicación con una disponibilidad de "2 nueves" debe estar disponible el 99% del tiempo. Esto significa que en un mes normal puede estar inactiva 432 minutos y seguir cumpliendo el objetivo del 99% de disponibilidad. En cambio, una aplicación de "4 nueves" debe estar disponible el 99,99% del tiempo, lo que significa que puede estar inactiva sólo 4 minutos en un mes normal.
| Nueves | Porcentaje | Interrupción mensual |
|---|---|---|
| 2 nueves | 99% | 432 minutos |
| 3 nueves | 99.9% | 43 minutos |
| 4 nueves | 99.99% | 4 minutos |
| 5 nueves | 99.999% | 26 segundos |
| 6 nueves | 99.9999% | 2,6 segundos |
En el ejemplo anterior, vemos que el sitio web se ha quedado justo por debajo de la métrica de los 3 nueves (99,8795% frente a 99,9%). Para un sitio web que mantiene 5 nueves de disponibilidad, sólo puede haber 26 segundos de inactividad al mes.
¿Cuál es un número de disponibilidad razonable para considerar tu sistema de alta disponibilidad? Es imposible dar una respuesta única a esta pregunta, porque depende drásticamente de tu sitio web, de las expectativas de tus clientes, de las necesidades de tu empresa y de las expectativas de tu negocio. Tienes que determinar por ti mismo qué número es necesario para tu negocio.
A menudo, para las aplicaciones web básicas, 3 nueves se considera una disponibilidad aceptable. Utilizando la Tabla 1-1, esto equivale a 43 minutos de inactividad al mes.
Los cortes programados siguen siendo cortes
No te engañes pensando que tu sitio tiene una alta disponibilidad cuando no es así. El mantenimiento planificado y regular que implica que tu aplicación no esté disponible sigue contando para la disponibilidad.
He aquí un comentario que escucho a menudo: "Nuestra aplicación nunca falla. Eso se debe a que realizamos regularmente el mantenimiento del sistema. Programando ventanas de mantenimiento semanales de dos horas y realizando el mantenimiento durante estas ventanas, mantenemos alta nuestra disponibilidad."
¿Mantiene este grupo una alta disponibilidad de su aplicación?
Averigüémoslo:
Porcentaje de disponibilidad del sitio = horas_totales_en_periodo - horas_sistema_desactivo / horas_totales_en_periodo
horas_en_semana = 7 días × 24 horas = 168 horas
horas_no_disponibles_cada_semana = 2 horas
Disponibilidad del sitio (sin fallos) = 168 horas - 2 horas / 168 horas = 98,8%.
Disponibilidad del sitio (sin fallos) = 98,8%.
Sin tener ni un solo fallo de su aplicación, lo mejor que puede conseguir esta organización es un 98,8% de disponibilidad. Esto no llega ni a 2 nueves de disponibilidad (98,8% frente a 99%).
El mantenimiento planificado perjudica casi tanto como las interrupciones no planificadas. Si tu cliente necesita que tu aplicación esté disponible y no lo está, tu cliente tiene una experiencia negativa. No importa si has planificado o no la interrupción.
La disponibilidad en cifras
Medir la disponibilidad es importante para mantener tu sistema altamente disponible, ahora y en el futuro. En esta sección se ha tratado un mecanismo habitual para medir la disponibilidad y se han proporcionado algunas directrices sobre lo que se considera una disponibilidad razonable.
Mejorar tu disponibilidad cuando decae
Tu aplicación está operativa y en línea. Tus sistemas están en marcha y tu equipo funciona con eficacia. Todo parece ir bien. Tu tráfico aumenta constantemente y tu organización de ventas está muy contenta. Todo va bien.
Entonces se produce un pequeño desliz. Tu sistema sufre una interrupción imprevista. Pero no pasa nada; tu disponibilidad ha sido fantástica hasta ahora. Una pequeña interrupción no es gran cosa. Tu tráfico sigue aumentando. Todo el mundo se encoge de hombros: fue "una de esas cosas".
Luego vuelve a ocurrir: otra interrupción. Uy. Bueno, vale. En general, seguimos bien. No hay que alarmarse; sólo fue otra "de esas cosas".
Luego otro apagón...
Ahora tu director general está un poco preocupado. Los clientes empiezan a preguntar qué está pasando. Tu equipo de ventas empieza a preocuparse.
Luego otro apagón...
De repente, tu sistema, antes estable y operativo, se está volviendo cada vez menos estable; tus interrupciones llaman cada vez más la atención.
Ahora tienes verdaderos problemas.
¿Qué ha pasado? Mantener tu sistema en alta disponibilidad es una tarea de enormes proporciones. ¿Qué haces si la disponibilidad empieza a decaer? ¿Qué haces si la disponibilidad de tu aplicación ha caído o empieza a caer, y necesitas mejorarla para mantener satisfechos a tus clientes ?
Saber qué puedes hacer cuando tu disponibilidad empieza a decaer te ayudará a evitar caer en un círculo vicioso de problemas. ¿Qué puedes hacer para evitar que decaiga tu disponibilidad? Algunas cosas clave son
-
Mide y controla tu disponibilidad actual
-
Automatiza tus procesos manuales
-
Automatiza tus procesos de Implementación
-
Mantener y seguir todas las configuraciones en un sistema de gestión
-
Permitir cambios y experimentos rápidos, con una capacidad de retroceso fácil si se produce un problema
-
Intenta mejorar continuamente tus aplicaciones y sistemas
-
Mantente al tanto de la disponibilidad como cuestión fundamental a medida que tu aplicación cambia y crece
En los siguientes apartados se detallan más estos pasos clave.
Mide y controla tu disponibilidad actual
Para comprender lo que está ocurriendo con tu disponibilidad, primero debes medir cuál es tu disponibilidad actual. Hacer un seguimiento de cuándo está o no disponible tu aplicación te proporciona un porcentaje de disponibilidad que puede mostrar cómo te estás comportando durante un periodo de tiempo concreto. Puedes utilizarlo para determinar si tu disponibilidad está mejorando o flaqueando.
Debes monitorizar continuamente tu porcentaje de disponibilidad e informar de los resultados con regularidad. Además de esto, superpón eventos clave en tu aplicación, como cuándo realizaste cambios y mejoras en el sistema. Así podrás ver si existe una correlación en el tiempo entre los eventos del sistema y los problemas de disponibilidad. Esto puede ayudarte a identificar los riesgos para tu disponibilidad.
A continuación, debes comprender cómo se puede esperar que funcione tu aplicación desde el punto de vista de la disponibilidad. Una herramienta que puedes utilizar para ayudarte a gestionar la disponibilidad de tu aplicación son los niveles de servicio. Se trata simplemente de etiquetas asociadas a los servicios que indican lo crítico que es un servicio para el funcionamiento de tu empresa. El uso de niveles de servicio os permite a ti y a tus equipos distinguir entre los servicios de misión crítica y los que son valiosos pero no esenciales. Hablaremos más a fondo de los niveles de servicio en el Capítulo 7.
Por último, crea y mantén en una matriz de riesgos. Con esta herramienta, puedes obtener visibilidad de la deuda técnica y el riesgo asociado presentes en tu aplicación. Las matrices de riesgo se tratan con más detalle en el Capítulo 9.
Ahora que tienes una forma de hacer un seguimiento de tu disponibilidad y una forma de identificar y gestionar tus riesgos, querrás revisar tus planes de gestión de riesgos periódicamente.
Además, debes crear y aplicar planes de mitigación para reducir los riesgos de tu aplicación. Esto te proporcionará un conjunto concreto de tareas que tú y tus equipos de desarrollo podéis poner en práctica para abordar las partes más arriesgadas de tu aplicación. Esto se trata en detalle en el Capítulo 9.
Automatiza tus procesos manuales
Para mantener la alta disponibilidad de , necesitas eliminar incógnitas y variables. Realizar operaciones manuales es una forma habitual de insertar resultados variables y/o desconocidos en tu sistema.
Nunca debes realizar una operación manual en un sistema de producción.
Cuando realizas un cambio en tu sistema, éste puede mejorarlo o ponerlo en peligro. Utilizar sólo tareas repetibles te proporciona lo siguiente:
-
La capacidad de probar una tarea antes de implementarla. Probar lo que ocurre cuando realizas un cambio concreto es fundamental para evitar errores que provoquen interrupciones.
-
La capacidad de ajustar la tarea para que realice exactamente lo que quieres que haga. Esto te permite implementar mejoras en el cambio que vas a hacer antes de realizarlo realmente.
-
La posibilidad de que la tarea sea revisada por un tercero. Esto aumenta la probabilidad de que la tarea no tenga efectos secundarios inesperados.
-
La posibilidad de poner la tarea bajo control de versiones. Los sistemas de control de versiones te permiten determinar cuándo se modifica la tarea, quién lo hace y por qué motivos.
-
La posibilidad de aplicar la tarea a recursos relacionados. Hacer un cambio en un único servidor que mejore su funcionamiento es estupendo. Poder aplicar el mismo cambio a todos los servidores afectados de forma coherente hace que la tarea sea aún más útil.
-
La capacidad de hacer que todos los recursos relacionados actúen de forma coherente. Si realizas continuamente cambios "puntuales" en recursos como los servidores, éstos empezarán a desviarse y a actuar de forma diferente unos de otros. Esto dificulta el diagnóstico de los servidores problemáticos, porque no habrá una línea de base de expectativas operativas que puedas utilizar para comparar.
-
La capacidad de implementar tareas repetibles. Las tareas repetibles son tareas auditables. Las tareas auditables son tareas que puedes analizar posteriormente por su impacto, positivo o negativo, en el sistema en su conjunto.
Hay muchos sistemas para los que nadie tiene acceso al entorno de producción. Punto. El único acceso a la producción es a través de procesos y procedimientos automatizados. Los propietarios de estos sistemas bloquean así sus entornos específicamente por las razones antes mencionadas.
En resumen, si no puedes repetir una tarea, no es una tarea útil. Hay muchos lugares en los que añadir repetibilidad a los cambios te ayudará a mantener estables tu sistema y tu aplicación. Esto incluye la aplicación de cambios en la configuración del servidor, la realización de ajustes de rendimiento, el reinicio de servidores, el reinicio de trabajos y tareas, el cambio de reglas de enrutamiento y la actualización e implementación de paquetes de software. A continuación veremos algunos ejemplos de tareas repetibles que deberías emplear.
Implementaciones automatizadas
Automatizando las implementaciones de , garantizas que los cambios de se apliquen de forma coherente en todo tu sistema, y que puedas aplicar cambios similares más adelante con resultados conocidos. Además, las reversiones a estados buenos conocidos son más fiables con sistemas de implementación automatizados.
Gestión de la configuración
En lugar de "retocar una variable de configuración" en el núcleo de un servidor, utiliza un proceso para aplicar el cambio de forma automatizada.
Como mínimo, escribe un script que realice el cambio y, a continuación, comprueba ese script en tu sistema de gestión de cambios de software. Esto te permitirá realizar el mismo cambio en todos los servidores de tu sistema de manera uniforme. Además, cuando necesites añadir un nuevo servidor a tu sistema o sustituir uno antiguo, tener una configuración conocida que se pueda aplicar mejora la probabilidad de que puedas añadir el nuevo servidor a tu sistema de forma segura, con un impacto mínimo.
Pero aún mejor -y coherente con las buenas prácticas modernas de gestión de la configuración- es emplear un concepto llamado Infraestructura como Código. La Infraestructura como Código consiste en describir tu infraestructura en una especificación estándar legible por máquina y luego pasar esa especificación a través de una herramienta de infraestructura que creará y/o actualizará tu infraestructura y tu configuración para que coincidan con la especificación. Herramientas como Puppet y Chef pueden facilitar la gestión de este proceso.
A continuación, toma esta especificación y compruébala en tu sistema de control de versiones, de modo que los cambios en la especificación puedan rastrearse igual que se rastrean los cambios en el código. Al ejecutar la especificación a través de la herramienta de infraestructura cada vez que se realice un cambio en la especificación, se actualizará tu infraestructura activa para que coincida con la especificación.
Si alguien necesita hacer un cambio en la infraestructura o en su configuración, debe hacer el cambio en la especificación, comprobar el cambio en el control de versiones y, a continuación, "desplegar" el cambio mediante la herramienta de infraestructura para actualizar tu infraestructura activa para que coincida. De este modo, puedes:
-
Asegúrate de que todos los componentes de la infraestructura tienen una configuración coherente, conocida y estable.
-
Realiza un seguimiento de todos los cambios en la infraestructura para poder revertirlos si es necesario, o utilizarlos para ayudar en la correlación con los eventos y cortes del sistema.
-
Permite un proceso de revisión por pares, similar a un proceso de revisión de código, para garantizar que los cambios en tu infraestructura son correctos y apropiados.
-
Permite crear entornos duplicados para ayudar en las pruebas, la puesta en escena y el desarrollo con un entorno idéntico al de producción.
Este mismo tipo de proceso se aplica a todos los componentes de la infraestructura. Esto incluye no sólo los servidores y la configuración de su sistema operativo, sino también otros componentes de la nube, VPC, equilibradores de carga, conmutadores, enrutadores, componentes de red y aplicaciones y sistemas de monitoreo.
Para que la gestión de la Infraestructura como Código sea útil, debe emplearse para todos los cambios del sistema, todo el tiempo. Nunca es aceptable saltarse el sistema de gestión de la infraestructura para hacer un cambio, sean cuales sean las circunstancias. Jamás.
Te sorprendería la cantidad de veces que he recibido un correo electrónico de actualización operativa que decía algo así como: "Anoche tuvimos un problema con uno de nuestros servidores. Llegamos a un límite en el número máximo de archivos abiertos que el servidor podía manejar. Así que ajusté la variable del núcleo y aumenté el número máximo de archivos abiertos, y el servidor vuelve a estar operativo".
Es decir, funciona correctamente hasta que alguien sobrescribe accidentalmente el cambio porque no había documentación al respecto. O hasta que uno de los otros servidores que ejecutan la aplicación tenga el mismo problema pero no se le haya aplicado este cambio .
O alguien hace otro cambio, que rompe la aplicación porque es incoherente con el cambio no documentado que acabas de hacer.
La coherencia, la repetibilidad y la atención inquebrantable a los detalles son fundamentales para que funcione un proceso de gestión de la configuración. Y un proceso de gestión de la configuración estándar y repetible, como el que describimos aquí, es fundamental para mantener la alta disponibilidad de tu sistema escalado.
Experimentos de cambio y cambios de alta frecuencia
Otra ventaja de tener un proceso altamente repetible y automatizado para hacer cambios y actualizaciones en tu sistema es que te permite experimentar con los cambios. Supón que tienes un cambio de configuración que quieres hacer en tus servidores y que crees que mejorará su rendimiento en tu aplicación. Utilizando un proceso automatizado de gestión de cambios, puedes hacer lo siguiente:
-
Documenta el cambio que propones.
-
Revisa el cambio con personas que sepan y puedan aportar sugerencias y mejoras.
-
Prueba el cambio en servidores de un entorno de pruebas o de ensayo.
-
Implementa tus cambios de forma rápida y sencilla.
-
Examina rápidamente los resultados. Si el cambio no ha tenido los resultados deseados, puedes retroceder rápidamente a un estado bueno conocido.
Las claves para aplicar este proceso son disponer de un proceso de cambio automatizado con capacidad de retroceso, y tener la capacidad de realizar pequeños cambios en tu sistema con facilidad y frecuencia.1 Lo primero te permite hacer cambios de forma coherente; lo segundo te permite experimentar y revertir los experimentos fallidos con un impacto mínimo o nulo en tus clientes.
Pruebas automatizadas de sanidad del cambio
Al tener un proceso automatizado de cambio e implementación,2 puedes implementar una prueba de sanidad automatizada de todos los cambios. Puedes utilizar una aplicación de pruebas de navegador para aplicaciones web o utilizar un sistema de monitoreo sintético para simular la interacción del cliente con tu aplicación.
Cuando estés listo para desplegar un cambio en producción, puedes hacer que tu sistema de implementación despliegue primero automáticamente el cambio en un entorno de pruebas o de ensayo. A continuación, puedes hacer que estas pruebas automatizadas se ejecuten y validen que los cambios no han roto tu aplicación.
Si esas pruebas se superan, podrás implementar automáticamente el cambio de forma coherente en tu entorno de producción. Dependiendo de cómo estén construidas tus pruebas, también deberías poder ejecutarlas regularmente en tu entorno de producción para validar que ningún cambio rompe nada allí.
Automatizando todo el proceso, puedes aumentar tu confianza en que un cambio no tendrá un impacto negativo en tus sistemas de producción.
Mejora tus sistemas
Ahora que tienes un sistema para monitorear la disponibilidad, una forma de rastrear los riesgos y las mitigaciones en tu sistema, y una forma de aplicar cambios consistentes a tu sistema de forma fácil y segura, puedes centrar tus esfuerzos en mejorar la disponibilidad de tu aplicación en sí.
Revisa periódicamente tu matriz de riesgos y tus planes de recuperación. Haz que su revisión forme parte de tu proceso postmortem. Ejecuta proyectos diseñados para mitigar los riesgos identificados en tu matriz. Despliega esos cambios de forma automatizada y segura, utilizando las pruebas de cordura comentadas anteriormente. Examina cómo la mitigación ha mejorado tu disponibilidad. Continúa el proceso hasta que tu disponibilidad alcance el nivel que deseas y necesitas.
Mantente al tanto de la disponibilidad en tu aplicación cambiante y en crecimiento
A medida que tu sistema crezca, tendrás que gestionar demandas de tráfico y datos cada vez mayores. Gran parte del contenido de este libro está diseñado para ayudarte a abordar los problemas de disponibilidad y escalabilidad de la aplicación a medida que ésta crece y cambia. En particular, la gestión de errores y fallos a escala se trata en el Capítulo 2. Los niveles de servicio, que puedes utilizar en para identificar los servicios clave que afectan a la disponibilidad, se tratan en el Capítulo 7. Y la gestión de los acuerdos de nivel de servicio (ANS) se trata en el Capítulo 8.
Normalmente, tu aplicación cambiará continuamente. Por ello, tus riesgos, mitigaciones, contingencias y planes de recuperación deben cambiar constantemente.
Saber qué puedes hacer cuando tu disponibilidad empieza a decaer te ayudará a evitar caer en un círculo vicioso de problemas.
Cinco enfoques para mejorar la disponibilidad de las aplicaciones
Construir una aplicación escalable que tenga alta disponibilidad no es fácil y no se consigue automáticamente. Pueden surgir problemas de forma inesperada que pueden hacer que tu aplicación, que funciona estupendamente, deje de funcionar para todos o algunos de tus clientes.
Estos problemas de disponibilidad suelen surgir de las áreas que menos te esperas, y algunos de los problemas de disponibilidad más graves pueden tener su origen en fuentes extremadamente benignas.
Nadie puede prever de dónde vendrán los problemas, y por muchas pruebas que se hagan no se encontrarán todos los problemas. Muchos de ellos son problemas sistémicos, no meros problemas de código.
Para encontrar estos problemas de disponibilidad, tenemos que dar un paso atrás y echar un vistazo sistémico a tu aplicación y a cómo funciona. Aquí tienes cinco cosas en las que puedes y debes centrarte cuando construyas un sistema para asegurarte de que, a medida que su uso aumente, la disponibilidad siga siendo alta:
-
Construye pensando en el fracaso
-
Piensa siempre en escalar
-
Mitigar el riesgo
-
Monitorea la disponibilidad
-
Responder a los problemas de disponibilidad de forma predecible y definida
Veamos cada uno de ellos por separado.
Enfoque nº 1: Construir pensando en el fracaso
Como dice Werner Vogels, CTO de Amazon: "Todo falla todo el tiempo". Planifica que tus aplicaciones y servicios fallen. Ocurrirá. Ahora, enfréntate a ello.
Suponiendo que tu aplicación falle, ¿cómo fallará? Cuando construyas tu sistema, ten en cuenta los problemas de disponibilidad durante todos los aspectos de su diseño y construcción.
Diseño
¿Qué construcciones y patrones de diseño has considerado o estás utilizando que te ayudarán a mejorar la disponibilidad de tu software?
Utilizar construcciones y patrones de diseño, como la simple captura de errores en lo más profundo de tu aplicación, la lógica de reintento y los disyuntores, te permite detectar los errores cuando han afectado al subconjunto más pequeño de funcionalidad disponible. Esto te permite limitar el alcance de un problema y hacer que tu aplicación siga proporcionando capacidades útiles aunque parte de la aplicación esté fallando.
Dependencias
¿Qué haces cuando falla un componente del que dependes? ¿Cómo vuelves a intentarlo? ¿Qué haces si el problema es un fallo irrecuperable (duro), en lugar de un fallo recuperable (blando)?
Los patrones disyuntores son especialmente útiles para gestionar fallos de dependencia, porque pueden reducir el impacto que un fallo de dependencia tiene en tu sistema. Sin un disyuntor, puedes disminuir el rendimiento de tu aplicación debido a un fallo de dependencia (por ejemplo, porque se necesita un tiempo de espera inaceptablemente largo para detectar el fallo). Con un disyuntor, puedes "rendirte" y dejar de utilizar una dependencia hasta que estés seguro de que se ha recuperado.
Clientes
¿Qué haces cuando un componente cliente de tu sistema se comporta mal? ¿Puedes gestionar una carga excesiva en tu sistema? ¿Puedes limitar el tráfico excesivo? ¿Puedes gestionar la entrada de datos basura? ¿Qué pasa con los datos excesivos?
A veces, los ataques de denegación de servicio pueden proceder de fuentes "amistosas". Por ejemplo, un cliente de tu aplicación puede ver un repentino aumento de actividad que requiera un incremento significativo del volumen de peticiones a tu aplicación. Otra posibilidad es que un fallo en la aplicación de tu cliente haga que éste llame a tu aplicación a un ritmo inaceptablemente alto. ¿Qué haces cuando ocurre esto? ¿El aumento repentino del tráfico hace que tu aplicación se caiga? ¿O puedes detectar este problema y estrangular la tasa de peticiones, limitando o eliminando el impacto en tu aplicación?
Enfoque nº 2: Piensa siempre en la ampliación
Que tu aplicación funcione ahora no significa que vaya a funcionar mañana. La mayoría de las aplicaciones web tienen patrones de tráfico crecientes. Un sitio web que genera una cierta cantidad de tráfico hoy podría generar mucho más tráfico antes de lo que prevés. Cuando construyas tu sistema, no lo construyas para el tráfico de hoy; constrúyelo para el tráfico de mañana.
Concretamente, esto podría significar:
-
Arquitecto en la posibilidad de aumentar el tamaño y la capacidad de tus bases de datos.
-
Piensa en qué límites lógicos existen para el escalado de tus datos. ¿Qué ocurre cuando tu base de datos llega al límite de sus capacidades? Identifica y elimina estos límites antes de que tu uso se acerque a ellos.
-
Construye tu aplicación de modo que puedas añadir fácilmente servidores de aplicaciones adicionales. Esto suele implicar ser observador de dónde y cómo se mantiene el estado y de cómo se enruta el tráfico.
-
Redirige el tráfico estático a proveedores sin conexión. Esto permite que tu sistema se ocupe sólo del tráfico dinámico para el que está diseñado. El uso de redes externas de distribución de contenidos (CDN) no sólo puede reducir el tráfico que debe gestionar tu red, sino que también permite que las eficiencias de escala que proporcionan las CDN hagan llegar ese contenido estático a tus clientes con mayor rapidez.
-
Piensa si determinadas piezas de contenido dinámico pueden generarse realmente de forma estática. A menudo, el contenido que parece dinámico es en realidad en su mayor parte estático, y la escalabilidad de tu aplicación puede aumentar haciendo que este contenido sea estático. Estos datos "dinámicos que pueden ser estáticos" a veces están ocultos donde no te lo esperas.
Foco nº 3: Mitigar el riesgo
Mantener un sistema altamente disponible requiere eliminar el riesgo del sistema. A menudo, la causa del fallo de un sistema podría haberse identificado como riesgo antes de que se produjera realmente el fallo. Identificar el riesgo es un método clave para aumentar la disponibilidad. Todos los sistemas tienen riesgo. Hay riesgo de que:
-
Un servidor se bloqueará
-
Una base de datos se corrompe
-
Una respuesta devuelta será incorrecta
-
La conexión de red fallará
-
Un software recién implementado fallará
Mantener un sistema disponible requiere eliminar riesgos. Pero a medida que los sistemas se complican cada vez más, esto resulta cada vez menos posible. Mantener disponible un gran sistema consiste más en gestionar cuál es tu riesgo, cuánto riesgo es aceptable y qué puedes hacer para mitigarlo.
A esto lo llamamos gestión de riesgos. Hablaremos ampliamente de la gestión de riesgos en el Capítulo 9. La gestión de riesgos está en el corazón de la construcción de sistemas de alta disponibilidad.
Parte de la gestión del riesgo es la mitigación del riesgo. La mitigación del riesgo consiste en saber qué hacer cuando se produce un problema para reducir su impacto en la medida de lo posible. La mitigación consiste en asegurarse de que tu aplicación funcione tan bien y tan completamente como sea posible, incluso cuando fallen los servicios y los recursos. La mitigación del riesgo requiere pensar en las cosas que pueden ir mal y elaborar un plan ahora para que seas capaz de manejar la situación cuando se produzca.
El recuadro anterior es un ejemplo de mitigación de riesgos; el proceso de identificar el riesgo, determinar qué hacer y aplicar esas mitigaciones es la gestión de riesgos .
Este proceso a menudo descubrirá problemas desconocidos en tu aplicación que querrás solucionar inmediatamente en lugar de esperar a que se produzcan. También puede crear procesos y procedimientos para gestionar modos de fallo conocidos, de modo que el coste de ese fallo se reduzca en duración o gravedad.
La disponibilidad y la gestión del riesgo van de la mano. Construir un sistema de alta disponibilidad consiste en gran medida en gestionar el riesgo.
Foco nº 4: Monitorizar la disponibilidad
No puedes saber si hay un problema en tu aplicación a menos que puedas ver un problema. Asegúrate de que tu aplicación está correctamente instrumentada para que puedas ver cómo funciona desde una perspectiva externa, así como mediante el monitoreo interno.
Un monitoreo adecuado depende de las particularidades de tu aplicación y de tus necesidades, pero suele conllevar algunas de las siguientes capacidades:
- Monitoreo de servidores
Para monitorear la salud de tus servidores y asegurarte de que siguen funcionando eficientemente.
- Monitoreo de cambios en la configuración
Para monitorizar la configuración de tu sistema e identificar si los cambios en tu infraestructura afectan a tu aplicación y cuándo.
- Monitoreo del rendimiento de las aplicaciones
Para mirar dentro de tu aplicación y tus servicios y asegurarte de que funcionan como esperas.
- Pruebas sintéticas
Examinar en tiempo real cómo funciona tu aplicación desde la perspectiva de tus usuarios, para detectar los problemas que puedan ver los clientes antes de que los vean realmente.
- Alerta
Informar al personal adecuado cuando se produzca un problema para que pueda resolverse rápida y eficazmente, minimizando el impacto en tus clientes.
Hay muchos buenos sistemas de monitoreo disponibles, tanto gratuitos como de pago. Personalmente recomiendo New Relic. Proporciona todas las funciones de monitoreo y alerta antes mencionadas. Como oferta de Software como Servicio (SaaS), puede satisfacer tus necesidades de monitoreo a prácticamente cualquier escala que requiera tu aplicación.
Cuando hayas empezado a monitorizar tu aplicación y tus servicios, empieza a buscar tendencias en su rendimiento. Cuando hayas identificado las tendencias, puedes buscar valores atípicos y tratarlos como posibles problemas de disponibilidad. Puedes utilizar estos valores atípicos haciendo que tus herramientas de monitoreo te envíen una alerta cuando se identifiquen, antes de que tu aplicación falle. Además, puedes hacer un seguimiento a medida que crece tu sistema y asegurarte de que tu plan de escalabilidad seguirá funcionando.
Establece objetivos operativos internos y privados para las comunicaciones entre servicios, y monitorízalos continuamente. De este modo, cuando veas un problema relacionado con el rendimiento o la disponibilidad, podrás diagnosticar rápidamente qué servicio o sistema es el responsable y abordar el problema. Además, puedes ver los "puntos calientes" -áreas en las que tu rendimiento no es lo que podría ser- y poner en marcha planes de desarrollo para solucionar estos problemas.
Objetivo nº 5: Responder a los problemas de disponibilidad de forma predecible y definida
Los sistemas de monitoreo son inútiles a menos que estés preparado para actuar ante los problemas que surjan. Esto significa que te avisen cuando surjan problemas para que puedas actuar. Además, debes establecer procesos y procedimientos que tu equipo pueda seguir para ayudar a diagnosticar los problemas y solucionar fácilmente las situaciones de fallo más comunes.
Por ejemplo, si un servicio deja de responder, puedes tener un conjunto de remedios para intentar que responda. Esto podría incluir tareas como ejecutar una prueba para ayudar a diagnosticar dónde está el problema, reiniciar un demonio que se sabe que provoca que el servicio deje de responder, o reiniciar un servidor si todo lo demás falla. Disponer de procesos estándar para manejar los escenarios de fallo habituales reducirá el tiempo que tu sistema no está disponible. Además, estos procesos pueden proporcionar información de diagnóstico de seguimiento útil a tus equipos de ingeniería para ayudarles a deducir la causa raíz de dolencias comunes.
Cuando se activa una alerta para un servicio, los propietarios de ese servicio deben ser los primeros alertados. Al fin y al cabo, ellos son los responsables de solucionar cualquier problema con su servicio. Sin embargo, es posible que otros equipos que estén estrechamente relacionados con el servicio en problemas y dependan de él también quieran ser alertados de los problemas cuando se produzcan. Por ejemplo, si un equipo hace uso de un servicio concreto, puede que quiera saber cuándo falla ese servicio para poder ser más proactivo a la hora de mantener activos sus sistemas durante la interrupción del servicio dependiente.
Estos procesos y procedimientos estándar deben formar parte de un manual de soporte en línea disponible para todos los miembros del equipo que se ocupen de la responsabilidad de guardia. Estos artefactos de soporte también deben contener listas de contactos de propietarios de servicios y sistemas relacionados, así como contactos a los que llamar para escalar el problema si no es posible una solución sencilla. Hay aplicaciones SaaS disponibles que pueden automatizar la gestión y el versionado de estos documentos de soporte y hacer que estén disponibles bajo demanda durante los eventos.
Todos estos procesos, procedimientos y manuales de apoyo deben prepararse con antelación para que, durante una interrupción, tu personal de guardia sepa exactamente qué hacer en distintas circunstancias para restablecer las operaciones rápidamente. Estos procesos y procedimientos son especialmente útiles porque las interrupciones suelen producirse en momentos inoportunos, como en mitad de la noche o los fines de semana, momentos en los que tu equipo de guardia puede no rendir al máximo de su eficiencia mental. Estas recomendaciones ayudarán a tu equipo a tomar medidas más inteligentes y seguras para restablecer el estado operativo de tu sistema.
Estar preparado
Nadie puede prever dónde y cuándo se producirán los problemas de disponibilidad. Pero puedes suponer que ocurrirán, sobre todo a medida que tu sistema se adapte a las mayores demandas de los clientes y a aplicaciones más complejas. Estar preparado de antemano para gestionar los problemas de disponibilidad es la mejor forma de reducir la probabilidad y la gravedad de los problemas. La información de este capítulo, incluidos los cinco focos de atención, ofrece una estrategia sólida para mantener la alta disponibilidad de tus aplicaciones.
Get Arquitectura a escala, 2ª edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
