Failsafe: instrucciones para crear arquitecturas de nube resistentes

Actualizado: junio de 2014

Autores: Marc Mercuri, Ulrich Homann, Mark Simms, Jason Wescott y Andrew Townhill

Revisores: Michael Thomassy, Curt Peterson, Stuart Ozer, Fran Dougherty, Tim O’Brien, Hatay Tuna, Patrick Butler Monterde, Mark Kottke, Lewis Curtis, William Bellamy

Fecha de publicación: junio de 2014

Fail-safe sustantivo. Algo diseñado para funcionar automáticamente con el fin de evitar la interrupción de un mecanismo, sistema, etc.

Los usuarios individuales (en el contexto de empleado, ciudadano o consumidor) demandan acceso inmediato a servicios de aplicación, cálculo y datos. El número de personas conectadas y los dispositivos que emplean para conectarse a estos servicios están en continuo crecimiento. En este mundo de servicios siempre disponibles, los sistemas que los respaldan deben estar diseñados para estar disponibles y ser resistentes.

Estos servicios se implementarán en entornos de nube que contienen productos estándar con configuraciones predefinidas. Históricamente, puede que haya adquirido hardware de gama alta para su escalado vertical; sin embargo, en los entornos de nube, deberá escalar horizontalmente. Los costes de estos entornos de nube se mantienen bajos gracias al uso de hardware estándar. Este hardware estándar fallará, por lo que la nube necesita una arquitectura que contemple realmente el error. Históricamente, puede que se haya centrado en la prevención de errores y la optimización del “tiempo promedio entre errores”. En este entorno nuevo, el enfoque se desplaza al “tiempo promedio para la restauración con impacto mínimo”.

Es muy posible que los servicios que desarrolle sean compuestos. Estarán compuestos de una o varias plataformas propias o plataformas de terceros y servicios de proveedor de terceros. Estos servicios se construirán en la infraestructura de nube que fallará. La arquitectura también debe asumir que los servicios que se consumen también fallarán. Igual que en la arquitectura de la infraestructura, el diseño de la arquitectura de la aplicación debe contemplar el error.

La iniciativa Fail-Safe de Microsoft está diseñada para proporcionar una orientación general para la creación de arquitecturas de nube resistentes, orientación para implementar dichas arquitecturas en tecnologías de Microsoft y recetas para implementar estas arquitecturas en escenarios concretos. Los creadores de este documento son miembros de la división Cloud + Enterprise de Microsoft, Trustworthy Computing y los Servicios de consultoría de Microsoft.

Este documento se centra en las consideraciones arquitectónicas para diseñar sistemas escalables y resistentes.

Este documento está organizado en las secciones siguientes:

  • Descomponer la aplicación en cargas de trabajo: definir cómo un enfoque centrado en cargas de trabajo proporciona mejores controles sobre los costes, mayor flexibilidad a la hora de elegir las tecnologías más adecuadas para la carga de trabajo, y hace posible un enfoque más adaptado a la disponibilidad y la resistencia.

  • Establecer un modelo de ciclo de vida: establecer un modelo de ciclo de vida de la aplicación ayuda a definir el comportamiento esperado de una aplicación en producción y proporcionará requisitos y una visión general de la arquitectura global.

  • Establecer un modelo de disponibilidad y un plan: el modelo de disponibilidad identifica el nivel de disponibilidad que se espera para la carga de trabajo. Es fundamental porque informará de muchas de las decisiones que tomará al establecer el servicio.

  • Identificar los puntos de error, los modos de error y los efectos de los errores: para crear una arquitectura resistente, es importante comprender e identificar los puntos y los modos de error. En concreto, realizar un esfuerzo proactivo para entender y documentar qué puede producir una interrupción del sistema establecerá un resumen que se puede usar en el análisis y el planeamiento.

  • Patrones y consideraciones sobre la resistencia: esta sección constituye la mayor parte del documento, y contiene las consideraciones principales relativas a los servicios de cálculo, almacenamiento y plataforma. Estas consideraciones se centran en prácticas demostradas para entregar una aplicación apropiada según las consideraciones clave mediante servicios de cálculo, almacenamiento y plataforma.

  • Diseñar para las operaciones: en un mundo que espera que los servicios estén siempre "disponibles”, es importante que los servicios estén diseñados pensando en las operaciones. En esta sección se examinan prácticas demostradas de diseño pensando en las operaciones que abarcan el ciclo de vida, incluido el establecimiento de un modelo para implementar telemetría con el fin de visualizar la información de telemetría para las operaciones y los desarrolladores.

Las aplicaciones suelen constar de varias cargas de trabajo.

Las distintas cargas de trabajo pueden tener asociados distintos requisitos, niveles de importancia para la empresa y niveles de consideración financiera, y con frecuencia así ocurre. Al descomponer una aplicación en cargas de trabajo, una organización se dota a sí misma de una flexibilidad muy valiosa. Un enfoque centrado en cargas de trabajo proporciona mejores controles sobre los costos, mayor flexibilidad a la hora de elegir las tecnologías más adecuadas para la carga de trabajo, enfoques específicos de la carga de trabajo para la disponibilidad y la seguridad, flexibilidad y agilidad al agregar e implementar nuevas capacidades, etc.

Al pensar en resistencia, a veces resulta útil hacerlo en el contexto de escenarios. Estos son algunos ejemplos de escenarios típicos:

  • Servicio de datos deportivos

    Un cliente ofrece un servicio de datos que proporciona información deportiva. El servicio tiene dos cargas de trabajo principales. La primera proporciona estadísticas sobre el jugador y los equipos. La segunda proporciona puntuaciones y comentarios sobre los partidos que hay en curso actualmente.

  • Sitio web de comercio electrónico

    Una tienda en línea vende mercancías a través de un sitio web según un modelo establecido. La aplicación tiene varias cargas de trabajo, donde las más populares son “buscar y examinar” y “desproteger”.

  • Social

    Un sitio social de alto nivel permite a los miembros de una comunidad participar en experiencias compartidas a través de foros, contenido generado los usuarios y juegos ocasionales. La aplicación tiene varias cargas de trabajo, incluido el registro, buscar y examinar, interacción social, juegos, correo electrónico, etc.

  • Web

    Una organización desea proporcionar una experiencia a los clientes a través de su sitio web. La aplicación debe entregar experiencias tanto en exploradores de PC como en los tipos más frecuentes de dispositivos móviles (teléfono, tableta, etc.). La aplicación tienen varias cargas de trabajo incluido el registro, buscar y examinar, publicación de contenido, comentarios sociales, moderación, juegos, etc.

Veamos más de cerca uno de los escenarios y descompongámoslo en sus cargas de trabajo secundarias. Un sitio web de comercio electrónico podría tener varias cargas de trabajo: examinar y buscar, desprotección y administración, registro de usuarios, contenido generado por los usuarios (análisis y valoraciones), personalización, etc.

He aquí unas definiciones de ejemplo de dos de las cargas de trabajo básicas para el escenario:

  • Examinar y buscar permite a los clientes navegar por un catálogo de productos, buscar artículos concretos y quizás administrar cestas o listas de regalos. Esta carga de trabajo puede tener atributos como acceso de usuarios anónimos, tiempos de respuesta inferiores a un segundo y Caching. Se puede producir una degradación del rendimiento en forma de mayores tiempos de respuesta con una carga inesperada de usuarios o interrupciones tolerantes a las aplicaciones para las actualizaciones del inventario de productos. En esos casos, la aplicación puede elegir seguir ofreciendo información desde la memoria caché.

  • desprotección y administración ayuda a los clientes a realizar, hacer un seguimiento y cancelar pedidos; seleccionar métodos de entrega y opciones de pago; y administrar perfiles. Esta carga de trabajo puede tener atributos como acceso seguro, procesamiento en cola, acceso a puertas de enlace de pago de terceros y conectividad con sistemas locales back-end. Si bien la aplicación puede tolerar un tiempo de respuesta mayor, no puede tolerar la pérdida de pedidos; por tanto, se ha diseñado para garantizar que los pedidos de los clientes se acepten y se capturen siempre, independientemente de que la aplicación pueda procesar o no el pago u organizar la entrega.

Un modelo de ciclo de vida de la aplicación define el comportamiento esperado de una aplicación cuando está operativa. En distintas fases y momentos, una aplicación impondrá diferentes demandas al sistema, ya sea en un nivel funcional o de escala. Los modelos de ciclo de vida lo reflejarán.

Las cargas de trabajo deben tener modelos de ciclo de vida definidos para todos los escenarios pertinentes y aplicables en los niveles apropiados de granularidad. Los servicios pueden tener diferencias de ciclo de vida horarias, diarias, semanales o estacionales que, cuando se modelan, identifican determinados requisitos de capacidad, disponibilidad, rendimiento y escalabilidad a lo largo del tiempo.

Failsafe_03

Figura 1. Ejemplos de ciclo de vida en diferentes sectores y escenarios

Con frecuencia habrá períodos de tiempo con su propio ciclo de vida único como:

  • un máximo relacionado con una punta de demanda durante un período de vacaciones;

  • un aumento de las presentaciones de la declaración de impuestos los días antes de la fecha límite;

  • franjas de tiempo de desplazamientos por la mañana y por la tarde;

  • presentaciones de las revisiones del rendimiento de los empleados al final del año.

Muchas organizaciones comprenden estos tipos de escenarios y los ciclos de vida específicos de cada uno de ellos.

La descomposición permite disponer de varios contratos de nivel de servicio (SLA) internos en el nivel de carga de trabajo. Un ejemplo es la API de datos deportivos con un contrato de nivel de servicio objetivo del 99,99 %. Sin embargo, se puede dividir esta API en dos cargas de trabajo: “Resultados en directo + Comentarios” y “Estadísticas de equipo, jugador y liga”

Para la carga de trabajo “Resultados en directo + Comentarios”, el ciclo de vida tendrá un patrón “activar y desactivar”. Sin embargo, la disponibilidad de “Estadísticas de equipo, jugador y liga” será constante. La descomposición por carga de trabajo permite disponer de un contrato de nivel de servicio adaptado a las necesidades de disponibilidad de la carga de trabajo agregada del servicio compuesto.

Failsafe_12

Ilustración 2

Una vez identificado un modelo de ciclo de vida, el paso siguiente consiste en establecer un modelo de disponibilidad y un plan. Un modelo de disponibilidad para la aplicación identifica el nivel de disponibilidad que se espera para la carga de trabajo. Es fundamental porque informará de muchas de las decisiones que tomará al establecer el servicio.

Se deben tener en cuenta varios aspectos y se pueden tomar varias medidas potenciales.

A la hora de desarrollar el plan de disponibilidad, es importante entender cuál es la disponibilidad deseada para la aplicación, las cargas de trabajo existentes en esa aplicación, y los servicios que se emplean en la entrega de esas cargas de trabajo.

Entender el ciclo de vida de la carga de trabajo le ayudará a elegir el contrato de nivel de servicio que quiere entregar. Puede que no se proporcione un contrato de nivel de servicio públicamente para su servicio. Sin embargo, la arquitectura debe dirigirse a una línea base de disponibilidad que aspirará conseguir.

En función del tipo de solución que esté compilando, habrá diversas consideraciones y opciones para entregar una disponibilidad superior. Los proveedores de servicio comercial no ofrecen contratos de nivel de servicio al 100 % ya que la complejidad y el coste de entregar este nivel de contrato no es viable o no es rentable. La descomposición de la aplicación en el nivel de carga de trabajo permite tomar decisiones e implementar enfoques para la disponibilidad. La entrega de un tiempo de actividad del 99,99 % para toda la aplicación puede ser imposible, pero se puede alcanzar para una carga de trabajo de una aplicación.

Incluso en el nivel de cargas de trabajo, puede decidir no implementar cada opción. Lo que decida implementar o no está determinado por sus requisitos. Independientemente de las opciones que elija, debe tomar una decisión consciente que sea informada y tenga en cuenta todas las opciones.

La autonomía se trata de la independencia y la reducción de dependencias entre los elementos que conforman el servicio como un conjunto. Se debe examinar la dependencia de componentes, datos y entidades externas a la hora de diseñar servicios, creando la funcionalidad relacionada en unidades autónomas dentro del servicio. Esto proporciona agilidad para actualizar versiones de unidades autónomas distintas, un mayor control optimizado sobre la escala de estas unidades autónomas, etc.

Las arquitecturas de carga de trabajo suelen constar de componentes autónomos que no necesitan ninguna intervención manual y que no producen errores cuando las entidades que las que dependen no están disponibles. Las aplicaciones compuestas por elementos autónomos:

  • están disponibles y son operativas

  • son resistentes y se recuperan fácilmente de los errores

  • tienen menos riesgo de estar en estados erróneos

  • son fáciles de escalar mediante replicación

  • es menos probable que necesiten intervenciones manuales

Con frecuencia, estas unidades autónomas aprovecharán la comunicación asincrónica, el procesamiento de datos basado en extracción y la automatización para asegurar un servicio continuado.

De cara al futuro, el mercado evolucionará hasta un punto en el que haya interfaces normalizadas para ciertos tipos de funcionalidad tanto en escenarios verticales como horizontales. Cuando se alcance esta visión futura, un proveedor de servicios podrá implicarse con distintos proveedores e implementaciones potencialmente diferentes que resuelvan el trabajo designado de la unidad autónoma. En el caso de servicios continuos, esto se hará de forma autónoma y se basará en directivas.

Por más que la autonomía sea una aspiración, la mayoría de los servicios tendrán una dependencia en un servicio de terceros, aunque solo sea para el hospedaje. Es imprescindible comprender los SLA de estos servicios dependientes e incorporarlos a su plan de disponibilidad.

En esta sección se identifican los distintos tipos de SLA que pueden ser pertinentes para su servicio. Para cada uno de estos tipos de servicio, existen ciertas consideraciones y métodos clave, así como algunas preguntas que se deben plantear.

Servicios de plataforma en la nube pública

Los servicios suministrados por una plataforma comercial de informática en nube, como proceso o almacenamiento, tienen contratos de nivel de servicio diseñados para atender a multitud de clientes en una escala importante. Por tanto, los SLA para estos servicios no son negociables. Un proveedor puede proporcionar niveles escalonados de servicio con distintos SLA, pero estos niveles no serán negociables. El proveedor de servicio usa niveles escalonados de servicio con distintos contratos de nivel de servicio para entregar una calidad de servicio previsible.

He aquí algunas preguntas que hay que tener en cuenta para este tipo de servicio:

  • ¿Este servicio solo permite un determinado número de llamadas a la API del servicio?

  • ¿Este servicio impone algún límite en cuanto a la frecuencia de llamadas a la API del servicio?

  • ¿Limita el servicio el número de servidores que pueden llamar a la API del servicio?

  • ¿Cuál es la información disponible públicamente sobre el modo en que el servicio entrega su promesa de disponibilidad?

  • ¿Cómo comunica este servicio su estado de mantenimiento?

  • ¿Cuál es el contrato de nivel de servicio (SLA) establecido?

  • ¿Qué servicios de plataforma equivalentes proporcionan otras terceras partes?

Servicios "gratuitos" de terceros

Muchos otros proveedores ofrecen servicios "gratis" a la comunidad. En las organizaciones del sector privado, se hace en gran medida para ayudar a generar un ecosistema de aplicaciones alrededor de su producto o servicio básico. En el caso del sector público, se hace para proporcionar a los ciudadanos y las empresas datos cuya recolección presumiblemente han pagado mediante la financiación del gobierno a través de sus impuestos.

La mayoría de estos servicios no incluirán contratos de nivel de servicio, por lo que su disponibilidad no está garantizada. Cuando se proporcionan SLA, se suelen centrar en las restricciones aplicables al uso de aplicaciones y mecanismos que se emplearán para aplicarlos. Algunos ejemplos de restricciones pueden incluir la limitación o la inclusión en una lista negra de la solución si esta supera un cierto número de llamadas de servicio, un determinado número de llamadas en un periodo de tiempo concreto (x por minuto) o el número de servidores permitidos que llaman al servicio.

He aquí algunas preguntas que hay que tener en cuenta para este tipo de servicio:

  • ¿Este servicio solo permite un determinado número de llamadas a la API del servicio?

  • ¿Este servicio impone algún límite en cuanto a la frecuencia de llamadas a la API del servicio?

  • ¿Limita el servicio el número de servidores que pueden llamar a la API del servicio?

  • ¿Cuál es la información disponible públicamente sobre el modo en que el servicio entrega su promesa de disponibilidad?

  • ¿Cómo comunica este servicio su estado de mantenimiento?

  • ¿Cuál es el contrato de nivel de servicio (SLA) establecido?

  • ¿Se trata de un servicio de pago en el que la funcionalidad y/o los datos necesarios están disponibles a través de varios proveedores de servicios?

  • Si se trata de un servicio de pago, ¿es la interfaz interoperable en otros proveedores de servicios (directamente o a través de una capa de abstracción disponible)?

  • ¿Qué servicios de plataforma equivalentes proporcionan otras terceras partes?

Servicios comerciales de terceros

Los servicios comerciales proporcionados por terceros tienen contratos de nivel de servicio diseñados para atender las necesidades de los clientes de pago. Un proveedor puede proporcionar niveles escalonados de SLA con distintos niveles de disponibilidad, pero estos SLA no serán negociables.

He aquí algunas preguntas que hay que tener en cuenta para este tipo de servicio:

  • ¿Este servicio solo permite un determinado número de llamadas a la API del servicio?

  • ¿Este servicio impone algún límite en cuanto a la frecuencia de llamadas a la API del servicio?

  • ¿Limita el servicio el número de servidores que pueden llamar a la API del servicio?

  • ¿Cuál es la información disponible públicamente sobre el modo en que el servicio entrega su promesa de disponibilidad?

  • ¿Cómo comunica este servicio su estado de mantenimiento?

  • ¿Cuál es el contrato de nivel de servicio (SLA) establecido?

  • ¿Se trata de un servicio de pago en el que la funcionalidad y/o los datos necesarios están disponibles a través de varios proveedores de servicios?

  • Si se trata de un servicio de pago, ¿es la interfaz interoperable en otros proveedores de servicios (directamente o a través de una capa de abstracción disponible)?

  • ¿Qué servicios de plataforma equivalentes proporcionan otras terceras partes?

Servicios en la nube de comunidad

Una comunidad de organizaciones, como una cadena de suministros, puede poner servicios a disposición de las organizaciones miembro.

He aquí algunas preguntas que hay que tener en cuenta para este tipo de servicio:

  • ¿Este servicio solo permite un determinado número de llamadas a la API del servicio?

  • ¿Este servicio impone algún límite en cuanto a la frecuencia de llamadas a la API del servicio?

  • ¿Limita el servicio el número de servidores que pueden llamar a la API del servicio?

  • ¿Cuál es la información disponible públicamente sobre el modo en que el servicio entrega su promesa de disponibilidad?

  • ¿Cómo comunica este servicio su estado de mantenimiento?

  • ¿Cuál es el contrato de nivel de servicio (SLA) establecido?

  • Como miembro de la comunidad, ¿existe la posibilidad de negociar un SLA diferente?

  • ¿Se trata de un servicio de pago en el que la funcionalidad y/o los datos necesarios están disponibles a través de varios proveedores de servicios?

  • Si se trata de un servicio de pago, ¿es la interfaz interoperable en otros proveedores de servicios (directamente o a través de una capa de abstracción disponible)?

  • ¿Qué servicios de plataforma equivalentes proporcionan otras terceras partes?

Servicios en la nube internos de una empresa

Una empresa puede hacer que algunos servicios básicos, como datos del precio de las acciones o metadatos de productos, estén disponibles para sus divisiones y departamento.

He aquí algunas preguntas que hay que tener en cuenta para este tipo de servicio:

  • ¿Este servicio solo permite un determinado número de llamadas a la API del servicio?

  • ¿Este servicio impone algún límite en cuanto a la frecuencia de llamadas a la API del servicio?

  • ¿Limita el servicio el número de servidores que pueden llamar a la API del servicio?

  • ¿Cuál es la información disponible públicamente sobre el modo en que el servicio entrega su promesa de disponibilidad?

  • ¿Cómo comunica este servicio su estado de mantenimiento?

  • ¿Cuál es el contrato de nivel de servicio (SLA) establecido?

  • Como miembro de la organización, ¿existe la posibilidad de negociar un SLA diferente?

  • ¿Se trata de un servicio de pago en el que la funcionalidad y/o los datos necesarios están disponibles a través de varios proveedores de servicios?

  • Si se trata de un servicio de pago, ¿es la interfaz interoperable en otros proveedores de servicios (directamente o a través de una capa de abstracción disponible)?

  • ¿Qué servicios de plataforma equivalentes proporcionan otras terceras partes?

Servicios en la nube internos de una división o departamento

Una división o un departamento de una empresa puede poner servicios a disposición de otros miembros de su organización inmediata.

He aquí algunas preguntas que hay que tener en cuenta para este tipo de servicio:

  • ¿Este servicio solo permite un determinado número de llamadas a la API del servicio?

  • ¿Este servicio impone algún límite en cuanto a la frecuencia de llamadas a la API del servicio?

  • ¿Limita el servicio el número de servidores que pueden llamar a la API del servicio?

  • ¿Cuál es la información disponible públicamente sobre el modo en que el servicio entrega su promesa de disponibilidad?

  • ¿Cómo comunica este servicio su estado de mantenimiento?

  • ¿Cuál es el contrato de nivel de servicio (SLA) establecido?

  • Como miembro de la división, ¿existe la posibilidad de negociar un SLA diferente?

  • ¿Se trata de un servicio de pago en el que la funcionalidad y/o los datos necesarios están disponibles a través de varios proveedores de servicios?

  • Si se trata de un servicio de pago, ¿es la interfaz interoperable en otros proveedores de servicios (directamente o a través de una capa de abstracción disponible)?

  • ¿Qué servicios de plataforma equivalentes proporcionan otras terceras partes?

Los “9 reales” de la disponibilidad de servicios compuestos

El aprovechamiento de servicios existentes puede proporcionar una gran agilidad en la entrega de soluciones para su organización o para la venta comercial. Si bien resulta atractivo, es importante entender realmente los efectos que estas dependencias tienen sobre el SLA global de la carga de trabajo.

La disponibilidad se expresa normalmente como un porcentaje del tiempo de funcionamiento en un año determinado. Este porcentaje de disponibilidad se conoce como el número de "9“. Por ejemplo, 99,9 representa un servicio con “tres nueves” y 99,999 representa un servicio con “cinco nueves”.

 

% de disponibilidad

Tiempo de inactividad por año

Tiempo de inactividad por mes

Tiempo de inactividad por semana

90 % (“un nueve”)

36,5 días

72 horas

16,8 horas

95%

18,25 días

36 horas

8,4 horas

97%

10,96 días

21,6 horas

5,04 horas

98%

7,30 días

14,4 horas

3,36 horas

99 % (“dos nueves”)

3,65 días

7,20 horas

1,68 horas

99.5%

1,83 días

3,60 horas

50,4 minutos

99.8%

17,52 horas

86,23 minutos

20,16 minutos

99,9 % (“tres nueves”)

8,76 horas

43,2 minutos

10,1 minutos

99.95%

4,38 horas

21,56 minutos

5,04 minutos

99,99 % (“cuatro nueves”)

52,56 minutos

4,32 minutos

1,01 minutos

99,999 % (“cinco nueves”)

5,26 minutos

25,9 segundos

6,05 segundos

99,9999 % (“seis nueves”)

31,5 segundos

2,59 segundos

0,605 segundos

99,99999 % (“siete nueves”)

3,15 segundos

0,259 segundos

0,0605 segundos

Hay una idea equivocada frecuente en relación con el número de “9” para un servicio compuesto. En concreto, se suele suponer que si un servicio determinado se compone de 5 servicios, cada uno de ellos con un tiempo de funcionamiento prometido del 99,99 % en sus contratos de nivel de servicio, el servicio compuesto resultante tiene una disponibilidad del 99,99 %. Este no es el caso.

Failsafe_13

Figura 3: Tiempo de inactividad relacionado con los "9" más comunes

El contrato de nivel de servicio compuesto es en realidad un cálculo que tiene en cuenta el tiempo de inactividad por año. Un servicio con un SLA de “cuatro 9” (99,99 %) puede estar hasta 52,56 minutos sin conexión.

La incorporación de 5 servicios con un contrato de nivel de servicio del 99,99 % en un servicio compuesto presenta un riesgo identificado del contrato de nivel de servicio de 262,8 minutos o 4,38 horas. Esto reduce la disponibilidad a un 99,95 % antes de escribir una sola línea de código.

Por lo general no se puede cambiar la disponibilidad de un servicio de terceros. Sin embargo, al escribir el código, puede aumentar la disponibilidad global de su aplicación empleando técnicas como las descritas en este documento.

noteNota
Algunos servicios pueden proporcionar distintos niveles de servicio para diferentes puntos de precio o según las asociaciones empresariales.

Tomemos, por ejemplo, la API de datos deportivos a la que nos hemos referido anteriormente. Los usuarios solo juegan en días determinados y solo durante un número específico de horas. Durante estos períodos, el contrato de nivel de servicio, sería del 100 %. Cuando no hay partidos programados, esta carga de trabajo tiene un contrato de nivel de servicio del 0 %. La carga de trabajo de “Estadísticas de equipo, jugador y liga” tiene un patrón de ciclo de vida más consistente. También existe el requisito de que esta carga de trabajo tenga siempre un contrato de nivel de servicio del 99 %.

Failsafe_14

Ilustración 4

Cuando se aprovechan servicios externos, no se puede subrayar suficientemente la importancia que supone entender los contratos de nivel de servicio, tanto individualmente como su impacto en el servicio compuesto.

Para crear una arquitectura resistente, es importante entenderla. Concretamente, hay que realizar un esfuerzo proactivo por entender y documentar qué puede producir una interrupción del sistema.

La comprensión de los puntos de error y los modos de error de una aplicación y de sus servicios de carga de trabajo relacionados puede permitirle tomar decisiones informadas y dirigidas sobre las estrategias relativas a la resistencia y la disponibilidad.

Los puntos de error son ubicaciones donde los errores pueden provocar la interrupción del servicio. Un foco importante son los elementos de diseño que están sujetos a cambios externos.

He aquí algunos ejemplos de puntos de error:

  • Conexiones de base de datos

  • Conexiones a sitios web

  • Archivos de configuración

  • Claves del Registro

Entre las categorías de puntos de error comunes se incluyen las siguientes:

  • ACL

  • Acceso a bases de datos

  • Acceso a sitios/servicios web externos

  • Transacciones

  • Configuración

  • Capacity

  • Red

Mientras que los puntos de error definen las áreas en las que puede producirse una interrupción del sistema, los modos de error identifican la manera específica en que puede ocurrir un error.

He aquí algunos ejemplos de modos de error:

  • Un archivo de configuración que falta

  • Tráfico importante que supera la capacidad de recursos

  • Una base de datos que alcanza su capacidad máxima

Los efectos de los errores son las consecuencias del error en la función. Infórmese de los efectos de los errores y la frecuencia con la que es probable que se produzcan estos tipos de error. Al hacerlo, puede priorizar cuándo y cómo dirigirse a los puntos y los modos de error de su aplicación o servicio.

En este documento se examinarán las consideraciones principales en servicios de proceso, almacenamiento y plataforma. Antes de tratar estos temas, es importante recapitular varios aspectos básicos de la resistencia que pueden afectar y que con frecuencia no se entienden correctamente y/o no se implementan.

Como se ha mencionado anteriormente, una arquitectura resistente debe estar optimizada pensando en la autonomía. Una de las formas de obtener autonomía consiste en realizar una comunicación asincrónica. Una arquitectura resistente debe usar de forma predeterminada la interacción asincrónica y las interacciones sincrónicas solo deben producirse como resultado de una excepción.

Los niveles web sin estado o los niveles web con una memoria caché distribuida pueden proporcionar esto en el front-end de una solución. Las colas pueden proporcionar esta capacidad para la comunicación de la interacción entre servicios de carga de trabajo o para servicios dentro de un servicio de carga de trabajo.

Esto último permite poner en cola los mensajes y que los servicios secundarios puedan recuperarlos. Esto se puede hacer según lógica, tiempo o lógica que tiene en cuenta el volumen. Además de realizar el proceso asincrónico, también permite escalar los niveles “que se insertan” o “que se extraen” de las colas según corresponda.

Un área frecuente donde se producirán errores transitorios es cuando la arquitectura se conecta a un servicio o un recurso como una base de datos. Al usar estos servicios, es una práctica común implementar lógica que presente el concepto de un tiempo de espera. Esta lógica identifica un período de tiempo aceptable en el que se espera una respuesta y generará un error identificable cuando se supere ese período de tiempo. Según la apariencia del error de tiempo de espera, se tomarán las medidas apropiadas en función del contexto en el que se produzca el error. El contexto puede incluir el número de veces que se ha producido este error, el impacto potencial del recurso que no está disponible, las garantías del SLA para el período de tiempo actual para un cliente determinado, etc.

A la hora de diseñar los servicios que entregará su carga de trabajo, debe aceptar y reconocer que se producirán errores y realizar los pasos adecuados para abordarlos.

Una de las áreas frecuentes que hay que abordar son los errores transitorios. Como ningún servicio tiene un tiempo de funcionamiento del 100 %, es realista esperar que quizás no pueda conectarse a un servicio del que dependa una carga de trabajo. La imposibilidad de conectarse o los errores que se perciben en uno de estos servicios puede ser efímeros (menos de un segundo) o permanentes (el cierre de un proveedor).

Degradación correcta

El servicio de carga de trabajo debe aspirar a controlar estos errores transitorios correctamente. Por ejemplo, durante una interrupción de su proveedor de nube Netflix usó una cola de vídeos anterior para los clientes cuando el almacén de datos principal no estaba disponible. Otro ejemplo sería un sitio de comercio electrónico que continúa recopilando pedidos si su puerta de enlace de pagos no está disponible. Esto ofrece la posibilidad de procesar los pedidos cuando la puerta de enlace de pagos vuelva a estar disponible o después de conmutar por error a una puerta de enlace de pagos secundaria.

Consideraciones de nivel superior para la degradación correcta

Al pensar en cómo degradar de forma correcta, tenga en cuenta las siguientes consideraciones clave:

  • Los componentes que no tienen el contexto completo de la solicitud simplemente deben fallar y emitir el mensaje de excepción. Para resolver esto, implemente un disyuntor, que se describe más adelante en este documento, para generar un error inmediato cuando alcance los umbrales del recuento de errores.

  • Los errores que pueden ser transitorios por naturaleza son comunes. Contrólelos empleando el patrón de reintento descrito más adelante en este documento.

  • Es posible que el autor de la llamada pueda corregir algunas de las solicitudes que han dado error reintentando la solicitud con parámetros diferentes o una ruta distinta.

  • Si no es crítico para el escenario que la solicitud sea correcta, gestione el error con una simple omisión.

  • Puede gestionar los errores devolviendo un mensaje de correcto y poniendo en cola las solicitudes con error para procesarlas más tarde cuando el recurso vuelva al estado normal.

  • Es posible que pueda devolver algún elemento que previamente era correcto, por ejemplo, credenciales almacenadas en caché, datos obsoletos de la memoria caché, etc.

  • Puede gestionar algunos errores proporcionando una experiencia que sea prácticamente correcta, por ejemplo, acceso temporal, valores aproximados, mejor aproximación, falta de etiqueta, etc.

  • En lugar de emitir un error, es posible que pueda proporcionar alguna alternativa, por ejemplo, valores aleatorios, derechos anónimos, imágenes predeterminadas, etc.

Consideraciones sobre el control de errores transitorios

Hay varias consideraciones clave sobre la implementación del control de errores transitorios, como se detalla en las próximas secciones.

  • Lógica de reintento

    La forma más sencilla de controlar errores transitorios consiste en reintentar la operación que produjo un error. Si se emplea un servicio comercial de terceros, la implementación de “lógica de reintento” resolverá a menudo este problema.

    Hay que destacar que los diseños deben limitar normalmente el número de veces que se reintentará la lógica. Generalmente, la lógica intentará ejecutar las acciones un número determinado de veces, registrando un error y/o utilizando un servicio o un flujo de trabajo secundario si el error persiste.

  • Tiempo de espera aleatorio exponencial

    Si el resultado del error transitorio se debe a la limitación del servicio debido a una sobrecarga, los intentos reiterados de llamar al servicio solo extenderán la limitación y afectarán a la disponibilidad general.

    Suele ser deseable reducir el volumen de llamadas al servicio para evitar o reducir la limitación. Se suele hacer de forma algorítmica, como reintentar inmediatamente después del primer error, esperar 1 segundo después del segundo error, 5 segundos después del tercer error y así sucesivamente hasta que se restaure el funcionamiento correcto o hasta alcanzar un umbral definido por la aplicación para los errores.

    Este método se denomina “tiempo de espera aleatorio exponencial”.

  • Idempotencia

    Una suposición básica con los servicios conectados es que no estarán disponibles al 100 % y que el control de errores transitorios con lógica de reintento es un enfoque básico de implementación. En caso de que se implemente lógica de reintento, existe la posibilidad de que se envíe más de una vez el mismo mensaje, que los mensajes se envíen fuera de secuencia, etc.

    Las operaciones deben diseñarse de forma que sean idempotentes, asegurándose de que el envío del mismo mensaje varias veces no produzca un almacén de datos inesperado o contaminado.

    Por ejemplo, la inserción de datos desde todas las solicitudes puede dar lugar a que se agreguen varios registros si se llama varias veces a la operación de servicio. Un enfoque alternativo sería implementar el código como una 'upsert' (actualización e inserción) inteligente. Se podría emplear una marca de tiempo o un identificador global para distinguir los mensajes nuevos de los procesados previamente, insertando solo los más recientes en la base de datos y actualizando los registros existentes si el mensaje es más reciente que el que se recibió anteriormente.

  • Comportamiento de compensación

    Además de la idempotencia, otra área que hay que tener en cuenta es el concepto de comportamiento de compensación. En un mundo en el que hay un conjunto cada vez mayor de sistemas conectados y con la aparición de servicios compuestos, es importante entender cómo controlar el comportamiento de compensación.

    Para muchos desarrolladores de aplicaciones de línea de negocio, los conceptos de transacciones no son nuevos, pero el marco de referencia está asociado a menudo a la funcionalidad transaccional expuesta por tecnologías de datos locales y bibliotecas de código relacionadas. Al examinar el concepto en términos de la nube, esta mentalidad necesita tener en cuenta nuevas consideraciones relacionadas con la orquestación de servicios distribuidos.

    Una orquestación de servicios puede abarcar varios sistemas distribuidos, tener una ejecución prolongada y tener estado. La propia orquestación no suele ser sincrónica, puede abarcar varios sistemas y puede tardar desde varios segundos hasta años según el escenario empresarial.

    Por ejemplo, en un escenario de cadena de suministros que puede vincular 25 organizaciones en la misma actividad de carga de trabajo, puede haber un conjunto de 25 o más sistemas interconectados en una o varias orquestaciones de servicios.

    Si se realiza correctamente, los 25 sistemas deben saber que la actividad se realizó correctamente. Para cada punto de conexión de la actividad, los sistemas participantes pueden proporcionar un identificador de correlación para los mensajes que reciben de otros sistemas. Según el tipo de actividad, la recepción de ese identificador de correlación puede convencer al participante de que la transacción se ha completado conceptualmente. En otros casos, al completarse las interacciones de los 25 participantes, se puede enviar un mensaje de confirmación a todos los participantes (ya sea directamente desde un único servicio o mediante los puntos específicos de interacción de orquestación para cada sistema).

    Para controlar los errores en actividades compuestas y/o distribuidas, cada servicio expondría una interfaz y operaciones de servicio para recibir solicitudes de cancelar una transacción determinada por un identificador único. Detrás de la fachada de servicio, existirían flujos de trabajo para compensar la cancelación de esta actividad. Idealmente serían procedimientos automatizados, pero pueden ser tan sencillos como el enrutamiento a una persona de la organización para que lo solucione manualmente.

Un disyuntor es un conmutador que interrumpe automáticamente el flujo de la corriente eléctrica si la corriente supera un límite preestablecido. Los disyuntores se suelen emplear como medida de seguridad cuando una corriente excesiva a través de un circuito podría ser peligrosa. A diferencia de un fusible, un disyuntor se puede restablecer y reutilizar.

Este mismo patrón es aplicable al diseño de software y es especialmente aplicable a los servicios en los que la disponibilidad y la resistencia son consideraciones clave.

En caso de que un recurso no esté disponible, la implementación de un disyuntor de software puede responder con la acción adecuada y responder correctamente.

Un disyuntor tendrá tres estados: cerrado, abierto y semiabierto.

El estado cerrado es el normal para la aplicación o el servicio. Cuando se encuentra en estado Cerrado, las solicitudes se enrutan a través de la ruta estándar. Un contador hace el seguimiento de los índices de error y los evalúa en relación con un umbral. Si este porcentaje de errores cruza el umbral, el disyuntor cambia al estado abierto. Si una llamada a un recurso de base de datos falla después de 100 intentos consecutivos de conexión, probablemente no valga la pena seguir llamando a la base de datos. Se podría desencadenar un disyuntor en ese umbral y tomar las medidas adecuadas.

Cuando está en estado Abierto, el disyuntor enruta las solicitudes a la ruta o rutas de mitigación. Esto podría ser un error inmediato o alguna otra forma de degradación correcta. Cuando cambie al estado Abierto, el disyuntor también iniciará un temporizador. Cuando el temporizador expire, cambiará al estado Semiabierto.

El estado Semiabierto empezará a enrutar un número limitado de solicitudes a través de la ruta normal. Si son correctas, el disyuntor cambia al estado Cerrado. Si este número limitado de solicitudes da error, el disyuntor vuelve al estado Abierto.

Cuando incluya el patrón de disyuntor en la arquitectura, tenga en cuenta lo siguiente:

  • Un disyuntor puede invocar diferentes mitigaciones o diferentes tiempos cuando se encuentra en estado abierto en función del tipo de excepción emitida por la operación.

  • Un disyuntor debe registrar todos los estados de transición. Esto permite a los operadores supervisar el comportamiento de transición y ajustar los temporizadores para evitar casos de estado Abierto prolongados u oscilaciones frecuentes entre los estados Abierto y Semiabierto.

  • En vez de usar un temporizador para la transición de Abierto a Semiabierto, el disyuntor puede probar periódicamente la ruta estándar para determinar si ya ha vuelto a la normalidad.

  • Tenga cuidado al usar un disyuntor cuando se trate de una operación que se dirija a varias particiones. El problema en este caso es que el estado puede darse en el nivel de partición y puede dar lugar a dos escenarios no deseados:

    • mover a un estado Abierto cuando solo falla una partición;

    • mover accidentalmente a un estado Cerrado cuando una o varias particiones son normales.

Una implementación común de este patrón tiene relación con el acceso de base de datos o servicios de datos. Cuando se produjera un error en un tipo y un nivel de actividad establecidos, el disyuntor reaccionaría. Con los datos, esto se debe normalmente a la incapacidad de conectarse a una base de datos o un servicio de datos delante de esa base de datos.

Si no se pudo realizar una llamada a un recurso de base de datos después de 100 intentos consecutivos de conexión, probablemente no valga la pena seguir llamando a la base de datos. Se podría desencadenar un disyuntor en ese umbral y tomar las medidas adecuadas.

En algunos casos, especialmente cuando se trata de conexiones a servicios de datos, esto puede ser el resultado de la limitación de un cliente que supera el número de llamadas permitidas durante de un período de tiempo determinado. El disyuntor puede insertar retrasos entre las llamadas hasta que las conexiones se establezcan correctamente y cumplan los niveles de tolerancia.

En otros casos, puede que el almacén de datos no esté disponible. Si hay disponible una copia redundante de los datos, el sistema puede realizar la conmutación por error a esa réplica. Si no hay una réplica disponible o si el servicio de base de datos está inactivo en todos los centros de datos de un proveedor, se puede adoptar un enfoque secundario. Esto puede incluir la obtención de datos desde una versión de los datos solicitados a través de un proveedor alternativo de servicios de datos. Este origen alternativo puede ser una memoria caché, un tipo de almacén de datos persistente alternativo del proveedor actual de la nube, un proveedor independiente de la nube o un centro de datos local. Cuando esa alternativa no está disponible, el servicio también podría devolver un error reconocible que el cliente pudiera controlar correctamente.

Ejemplo de disyuntor: Netflix

Netflix, una empresa de transmisión por secuencias de multimedia, se considera a menudo un buen ejemplo de arquitectura resistente. Al hablar del patrón de disyuntor de Netflix, ese equipo enumera varios criterios incluidos en el disyuntor en su Blog de tecnología de Netflix. Entre ellos se incluyen los siguientes:

  1. Una solicitud al servicio remoto que agota el tiempo de espera.

  2. La cola de grupos de subprocesos y de tareas enlazadas empleados para interactuar con una dependencia de servicio están a una capacidad del 100 %.

  3. La biblioteca cliente usada para interactuar con una dependencia de servicio produce una excepción.

Todos estos factores contribuyen a la tasa de errores total. Cuando la tasa de errores supera los umbrales definidos, el disyuntor se “dispara” y el circuito para ese servicio envía retrocesos inmediatamente incluso sin intentar la conexión al servicio remoto.

En esa misma entrada de blog, el equipo de Netflix afirma que el disyuntor para cada uno de sus servicios implementa un retroceso mediante uno de los tres métodos siguientes:

  1. Retroceso personalizado: una biblioteca cliente del servicio proporciona un método de retroceso invocable o se usan datos disponibles localmente en un servidor de API (por ejemplo, una cookie o una memoria caché local) para generar una respuesta de retroceso.

  2. Error silencioso: un método devuelve un valor NULL al cliente solicitante, que funciona bien cuando los datos que se solicitan son opcionales.

  3. Error rápido: cuando se necesitan datos o no hay disponible un retroceso adecuado, se devuelve una respuesta 5xx al cliente. Este método se centra en mantener los servidores de API en buen estado y permitir una recuperación rápida cuando los servicios afectados vuelvan a estar en línea, pero a cambio afecta negativamente a la experiencia de usuario del cliente.

Para aplicar un SLA, una organización debe abordar cómo tratará su servicio de datos dos categorías de valores atípicos: entidades confianza y actores no válidos.

Entidades de confianza y listas blancas

Las entidades de confianza son las organizaciones con las que la organización podría tener acuerdos especiales y para las que se pueden realizar algunas excepciones a los SLA estándar.

  • Terceros con acuerdos personalizados

    Es posible que algunos usuarios de un servicio deseen negociar términos o directivas especiales de precios. En algunos casos, un elevado volumen de llamadas al servicio de datos puede garantizar un precio especial. En otros casos, la demanda de un servicio de datos determinado puede superar el volumen especificado en los niveles de uso estándar. Esos clientes deben definirse como entidades de confianza para evitar que se marquen involuntariamente como actores no válidos.

  • Listas blancas

    El enfoque típico para tratar las entidades de confianza es establecer una lista blanca. El servicio emplea una lista blanca, que identifica una lista de entidades de confianza, cuando determina qué reglas de negocios debe aplicar al procesar el uso del cliente. La lista blanca se suele elaborar autorizando un intervalo de direcciones IP o una clave de API.

    Al establecer una directiva de consumo, una organización debe identificar si se admiten listas blancas, qué da derecho a un cliente a estar en la lista blanca, cómo agregar un cliente a la lista blanca y en qué circunstancias se quita un cliente de la lista blanca.

  • Controlar actores no válidos

    Si las entidades de confianza se sitúan en un extremo del espectro de clientes, el grupo situado en el extremo opuesto es lo que se denomina “actores no válidos”. Los actores no válidos suponen una carga para el servicio, normalmente por el intento de “consumo excesivo”. En algunos casos, este comportamiento no válido es realmente accidental. En otros casos es deliberado y, en algunos casos poco frecuentes, es malintencionado. Estos actores se etiquetan como “no válidos”, ya que sus acciones (sean deliberadas o no) puedan afectar a la disponibilidad de uno o más servicios.

    La carga de los actores no válidos puede suponer costos innecesarios para el proveedor del servicio de datos y poner en peligro el acceso por parte de los consumidores que siguen fielmente los términos de uso y tienen una expectativa razonable de servicio, según se establece en un SLA. Por tanto, se debe tratar a los actores no válidos de una manera prescrita y coherente. Las respuestas típicas a los actores no válidos son la limitación y las listas negras.

  • Limitación

    Las organizaciones deben definir una estrategia para tratar los picos de uso por parte de los consumidores del servicio de datos. Los aumentos repentinos importantes de tráfico de cualquier consumidor puede imponer una carga inesperada en el servicio de datos. Cuando se produzcan dichos aumentos, la organización podría desear restringir el acceso a ese consumidor durante un período de tiempo determinado. En este caso, el servicio rechaza todas las solicitudes del consumidor durante un período de tiempo, como un minuto, cinco minutos o diez minutos. Durante este tiempo, las solicitudes de servicio de ese consumidor provocan un mensaje de error que indica que se le está limitando por un uso excesivo.

    El consumidor que realiza las solicitudes puede responder en consecuencia, por ejemplo modificando su comportamiento.

    La organización debe determinar si desea implementar la limitación y establecer las reglas de negocios relacionadas. Si determina que se puede limitar a los consumidores, la organización también necesitará decidir qué comportamientos deben desencadenar la respuesta de limitación.

  • Listas negras

    Aunque la limitación debe corregir el comportamiento de los actores no válidos, puede que no siempre sea efectiva. En los casos en los que no funcione, la organización podría prohibir un consumidor. Una lista negra, al contrario que una lista blanca, identifica los consumidores a los que se impide el acceso al servicio. El servicio responderá correctamente a las solicitudes de acceso de los clientes incluidos en una lista negra y de un modo que minimice el uso de los recursos del servicio de datos.

    La lista negra, como ocurre con la lista blanca, se suele elaborar usando una clave de API o un intervalo de direcciones IP.

    Al establecer una directiva de uso, la organización debe especificar qué comportamientos pondrán a un consumidor en la lista negra, cómo se puede apelar la lista negra y cómo se puede quitar un consumidor de la lista negra.

Las personas cometen errores. Tanto si se trata de un desarrollador que realiza un cambio de código que puede tener consecuencias inesperadas como si es un administrador de bases de datos que quita accidentalmente una tabla de una base de datos o una persona de operaciones que realiza un cambio pero no lo documenta, hay numerosas oportunidades para que una persona haga involuntariamente que un servicio sea menos resistente.

Para reducir los errores humanos, un enfoque lógico es reducir la cantidad de seres humanos que participan en el proceso. Mediante la introducción de la automatización, se limita la posibilidad de que algunos deltas ad hoc involuntarios de comportamientos esperados pongan en peligro el servicio.

En la comunidad de DevOps hay un personaje de dibujos animados que dice “Automatizarlo todo”. En la nube, la mayoría de los servicios se exponen a través de una API. Desde las herramientas de desarrollo hasta la infraestructura virtualizada pasando por los servicios de plataforma y las soluciones entregadas como software como servicio, la mayoría de las cosas admiten scripts.

Se recomienda encarecidamente el scripting. El scripting hace que la implementación y la administración sean coherentes y predecibles, y justifica con creces la inversión.

Automatizar la implementación

Una de las áreas fundamentales de la automatización está en la compilación e implementación de una solución. La automatización puede simplificar a un equipo de desarrolladores la prueba e implementación en varios entornos. Tanto el desarrollo como las pruebas, los ensayos, las versiones beta y la producción se pueden implementar con rapidez y coherencia mediante compilaciones automatizadas. La posibilidad de realizar una implementación coherente en varios entornos asegura que lo que hay en producción es representativo de lo que se ha probado.

Considere lo siguiente como “código”: scripts, archivos de configuración y metadatos relacionados con la implementación. El código también incluye la administración de estos artefactos en el control del origen para:

  • documentar los cambios,

  • permitir el control de versiones,

  • proporcionar control de acceso basado en rol,

  • asegurar que se ha hecho copia de seguridad del contenido,

  • proporcionar un único origen de verdad.

Establecer y automatizar un agente de prueba

Las pruebas es otra área que se puede automatizar. Como ocurre con la implementación automatizada, el establecimiento de pruebas automatizadas es valioso como forma de asegurarse de que el sistema es resistente y sigue siendo resistente a lo largo del tiempo. A medida que el código y el uso del servicio evolucionen, es importante seguir realizando todas las prueba adecuadas, tanto funcionalmente como de escala.

Automatizar el archivado y el purgado de datos

Una de las áreas que recibe menos atención es la de archivado y purgado de datos. El volumen de datos está creciendo y continuará creciendo a mayor ritmo y en mayor variedad que en cualquier otro momento de la historia. Según la tecnología de base de datos y los tipos de consultas necesarios, los datos innecesarios pueden reducir el tiempo de respuesta del sistema y aumentar los costos innecesariamente. En el caso de planes de resistencia que incluyan una o varias réplicas de un almacén de datos, quitar todos los datos salvo los necesarios puede acelerar actividades de administración como la copia de seguridad y la restauración de datos.

Identifique los requisitos para su solución en cuanto a los datos necesarios para la funcionalidad básica, los datos necesarios por cuestiones de cumplimiento pero que se pueden archivar, y los datos que ya no son necesarios y se pueden purgar.

Use las API disponibles en los productos y servicios relacionados para automatizar la implementación de estos requisitos.

Al crear una arquitectura resistente, también es importante entender los conceptos de dominios de error y dominios de actualización.

Dominios de error

Los dominios de error restringen la colocación de servicios según límites de hardware conocidos y la probabilidad de que un tipo concreto de interrupción del sistema afecte a un conjunto de equipos. Un dominio de error se define como una serie de equipos que pueden producir errores simultáneamente y generalmente se define mediante propiedades físicas (un bastidor determinado de equipos, una serie de equipos que comparten la misma fuente de alimentación, etc.).

Dominios de actualización

Los dominios de actualización son similares a los dominios de error. Los dominios de actualización definen un conjunto físico de servicios que el sistema actualiza al mismo tiempo. El equilibrador de carga del proveedor de nube debe tener conocimiento de los dominios de actualización para asegurarse de que si se actualiza un dominio concreto, el sistema global siga estando equilibrado y los servicios sigan estando disponibles.

Las actualizaciones pueden producirse en:

  • el nivel de hipervisor (“actualización del SO host”);

  • el nivel del sistema operativo (“actualización del SO invitado”);

  • como resultado de la implementación de una actualización de aplicación o servicio en el entorno.

Según el proveedor de nube y los servicios de plataforma usados, los dominios de error y los dominios de actualización se pueden proporcionar automáticamente, pueden ser algo en lo que su servicio pueda participar mediante las API o pueden necesitar una solución propia o de terceros.

Resistencia durante un error de un dominio de error en una actualización

Aunque los dominios de error y los dominios de actualización son diferentes, hay un escenario en el que intersectan. En este escenario, un error de hardware coloca una máquina virtual fuera de línea mientras se produce una actualización en otra instancia de máquina virtual simultáneamente. En este caso, dos máquinas virtuales estarán fuera de línea. Si una implementación de servicio solo contiene dos máquinas virtuales, el servicio quedará fuera de línea. Tenga esto en cuenta al evaluar el número de instancias que necesita para entregar el contrato de nivel de servicio que quiere.

Las plataformas en la nube proporcionan con frecuencia la capacidad de identificar un nivel de afinidad para un grupo de recursos. Llamamos a estos recursos “grupo de afinidad” o “conjunto de afinidad”. Esto ayuda a la plataforma subyacente a colocar juntos los recursos relacionados y a asignar las instancias entre dominios de error y de actualización.

Las soluciones locales han confiado a menudo en la redundancia como ayuda para lograr disponibilidad y escalabilidad. Desde el punto de vista de la disponibilidad, los centros de datos redundantes ofrecían la posibilidad de aumentar la probabilidad de continuidad empresarial en caso de que se produjeran errores de infraestructura en un centro de datos determinado o en una parte de un centro de datos.

En el caso de aplicaciones con los consumidores repartidos geográficamente, la administración del tráfico y las implementaciones redundantes enrutaban a los usuarios a recursos locales, que a menudo tienen menor latencia.

noteNota
La resistencia de datos, que incluye redundancia, se trata como un tema diferente en la sección Establecer un método de resistencia de datos.

Redundancia y la nube

La redundancia local se ha logrado históricamente mediante conjuntos duplicados de hardware, software y red. En ocasiones se implementa en un clúster en una sola ubicación o distribuido entre varios centros de datos.

Al concebir una estrategia para la nube, es importante racionalizar la necesidad de redundancia en tres vectores. Estos vectores incluyen código implementado dentro del entorno de un proveedor de nube, redundancia de los propios proveedores, y redundancia entre la nube y local.

Redundancia de implementación

Una vez que una organización haya seleccionado un proveedor de nube, es importante establecer una estrategia de redundancia para la implementación dentro del proveedor.

Si se implementa como plataforma como servicio (PaaS), gran parte de esto lo puede controlar la plataforma subyacente. En un modelo de infraestructura como servicio (IaaS), gran parte de esto no es cierto.

  • Implementar el número de roles en un centro de datos

    La forma más sencilla de redundancia es implementar la solución en varias instancias dentro de un solo proveedor de nube. Con la implementación en varias instancias, la solución puede limitar el tiempo de inactividad que se produciría si solo se implementara un nodo.

    En muchos entornos de plataforma como servicio, se supervisa el estado de la máquina virtual que hospeda el código y las máquinas virtuales que se han detectado que no están en buen estado se pueden reemplazar automáticamente con un nodo en buen estado.

  • Implementar en varios centros de datos

    Si bien la implementación de varios nodos en un único centro de datos proporcionará beneficios, las arquitecturas deben tener en cuenta que un centro de datos entero podría no estar disponible. Aunque no suele ocurrir, eventos como desastres naturales, guerras, etc. podrían dar lugar a una interrupción del servicio en una ubicación geográfica determinada.

    Para cumplir el SLA, puede ser conveniente implementar la solución en varios centros de datos del proveedor de nube seleccionado. Hay varias formas de lograrlo, como se identifica a continuación.

    1. Implementaciones totalmente redundantes en varios centros de datos

      La primera opción es una solución totalmente redundante en varios centros de datos junto con un proveedor de administración del tráfico. Una consideración clave de este enfoque será el impacto sobre los costos relacionados con el proceso para este tipo de redundancia, que aumentará en un 100 % por cada implementación en un centro de datos adicional.

    2. Implementación parcial en centros de datos secundarios para lograr conmutación por error

      Otro enfoque consiste en realizar una implementación parcial en un centro de datos secundario de menor tamaño. Por ejemplo, si la configuración estándar usara 12 instancias de proceso, el centro de datos secundario contendría una implementación con 6 instancias de proceso.

      Este enfoque, junto con la administración del tráfico, permitiría la continuidad empresarial con un servicio degradado después de un incidente que solo afectara al centro principal.

      Debido a las pocas veces que un centro de datos entero queda sin conexión, se ve a menudo como un enfoque rentable de ejecución, especialmente si una plataforma permite a la organización incorporar fácilmente nuevas instancias en el segundo centro de datos.

    3. Implementaciones divididas en varios centros de datos con nodos de copia de seguridad

      En ciertas cargas de trabajo, especialmente en las de los servicios financieros, se debe procesar una cantidad considerable de datos en una ventana de tiempo corta e inamovible. En estas circunstancias, el trabajo se realiza en ráfagas más cortas y los costos de la redundancia garantizan la obtención de resultados dentro de esa ventana.

      En estos casos, el código se implementa en varios centros de datos. El trabajo se divide y se distribuye entre los nodos para su procesamiento. En caso de que un centro de datos deje de estar disponible, el trabajo previsto para ese nodo se entrega al nodo de copia de seguridad, que completará la tarea.

    4. Implementaciones en varios centros de datos con ajuste de tamaño por centro de datos según la geografía

      Este enfoque emplea implementaciones redundantes que existen en varios centros de datos, pero su tamaño se ajusta correctamente según la escala de una audiencia geográficamente pertinente.

Redundancia del proveedor

Si bien la redundancia orientada al centro de datos es buena, los contratos de nivel de servicio están en el nivel de servicio frente al nivel del centro de datos. Muchos servicios comerciales actuales implementarán nuevas versiones a un “segmento” de producción para validar el código en producción. Sin embargo, existe la posibilidad de que los servicios que un proveedor entrega dejen de estar disponibles en varios o en todos los centros de datos.

Según los SLA de una solución, puede ser conveniente incorporar también redundancia del proveedor. Para eso, se deben identificar los productos o los servicios en la nube que se pueden implementar en la nube y que funcionarán en varias plataformas de nube. Por ejemplo, Microsoft SQL Server se puede implementar en una máquina virtual dentro de ofertas de infraestructura como servicio de la mayoría de los proveedores.

En el caso de los servicios suministrados en la nube, esto es más complejo ya que no hay interfaces estándar, incluso para servicios básicos como el cálculo, el almacenamiento, las colas, etc. Si se desea redundancia del proveedor para estos servicios, solo se suele lograr mediante una capa de abstracción. Una capa de abstracción puede proporcionar suficiente funcionalidad para una solución, pero no se innovará tan rápidamente como los servicios subyacentes y puede impedir que una organización adopte fácilmente nuevas características ofrecidas por un proveedor.

Si se pueden garantizar servicios redundantes del proveedor, pueden estar en uno de varios niveles: una aplicación entera, una carga de trabajo o un aspecto de una carga de trabajo. En el nivel adecuado, evalúe la necesidad de servicios de proceso, datos y plataforma, y determine cuáles deben ser realmente redundantes y cuáles se pueden controlar mediante métodos para proporcionar una degradación adecuada.

Redundancia local

Si bien depender de un proveedor de nube puede tener sentido desde el punto de vista fiscal, puede haber algunas consideraciones empresariales que requieran redundancia local con fines de cumplimiento y/o de continuidad empresarial.

Según los SLA de una solución, puede ser conveniente incorporar también redundancia local. Para eso, se deben identificar los productos o los servicios en la nube que se pueden implementar en la nube privada y que funcionarán en varios tipos de nube. Como ocurre en el caso de redundancia del proveedor, Microsoft SQL Server es un buen ejemplo de un producto que se puede implementar de forma local o en una oferta de IaaS.

Para los servicios suministrados en la nube, esto es más complejo porque no suele haber equivalentes locales con simetría de interfaz y de capacidad.

Si se necesitan localmente servicios redundantes del proveedor, puede estar en uno de varios niveles: una aplicación entera, una carga de trabajo o un aspecto de una carga de trabajo. En el nivel adecuado, evalúe la necesidad de servicios de proceso, datos y plataforma, y determine cuáles deben ser realmente redundantes y cuáles se pueden controlar mediante métodos para proporcionar una degradación adecuada.

Métodos de configuración de la redundancia

Al identificar los métodos de configuración de la redundancia, también se aplican las clasificaciones que existían antes de la nube. En función de los tipos de servicios empleados en la solución, parte de esto lo puede controlar la plataforma subyacente automáticamente. En otros casos, esta capacidad se controla mediante tecnologías como Windows Fabric.

  1. Active/active: el tráfico destinado a un nodo con error se pasa a un nodo existente o a una carga equilibrada entre los nodos restantes. Normalmente solo es posible cuando los nodos usan una configuración de software homogénea.

  2. Activo/pasivo: proporciona una instancia totalmente redundante de cada nodo, que solo se pone en línea cuando se produce un error en el nodo principal asociado. Esta configuración es la que necesita normalmente más hardware adicional.

  3. N+1: proporciona un único nodo adicional que se pone en línea para asumir el rol del nodo en el que se ha producido el error. En el caso de una configuración de software heterogénea en cada nodo principal, el nodo adicional debe ser capaz universalmente de suponer cualquiera de los roles de los nodos principales de los que es responsable. Se refiere normalmente a los clústeres que tienen varios servicios que se ejecutan simultáneamente; en el caso de un único servicio, esto degenera en activo/pasivo.

  4. N+M: en aquellos casos en los que un solo clúster administra muchos servicios, tener solo un nodo dedicado para la conmutación por error quizás no proporcione suficiente redundancia. En esos casos, se incluye y hay disponible más de un (M) servidores en espera. El número de servidores en espera es un equilibrio entre los requisitos de costo y confiabilidad.

  5. N a 1: permite que el nodo en espera de conmutación por error se convierta en el nodo activo temporalmente, hasta que el nodo original se pueda restaurar o volver a poner en línea; en ese momento se deben conmutar por recuperación los servicios o las instancias a ese nodo para restaurar la alta disponibilidad.

  6. N a N: N a N, que es una combinación de activo/activo y de N+M, redistribuye los servicios, las instancias o las conexiones del nodo con error entre los nodos activos restantes, lo que elimina (como ocurre en activo/activo) la necesidad de un nodo 'en espera', pero presenta una necesidad de capacidad adicional en todos los nodos activos.

Tanto si el tráfico siempre se distribuye geográficamente como si se enruta a centros de datos diferentes para satisfacer escenarios de continuidad empresarial, la funcionalidad de administración del tráfico es importante para asegurarse de que las solicitudes a su solución se están enrutando a las instancias adecuadas.

Es importante destacar que establecer una dependencia de un servicio de administración del tráfico presenta un punto único de error. Es importante investigar el SLA del servicio de administración del tráfico principal de la aplicación y determinar si sus requisitos garantizan una funcionalidad alternativa de administración del tráfico.

Si bien muchas aplicaciones de nube de gran escala han realizado un buen trabajo de particionamiento de su capa web, no lo han hecho tan bien al escalar su capa de datos en la nube. Con una diversidad cada vez mayor de dispositivos conectados, el nivel de datos generados y consultados está creciendo hasta unos niveles nunca vistos en la historia. Por ejemplo, ahora se considera razonable la necesidad de poder admitir 500.000 nuevos usuarios por día.

Tener una estrategia de particionamiento es especialmente importante en varias dimensiones, incluidos el almacenamiento, la consulta o el mantenimiento de esos datos.

Descomposición y particionamiento

Debido a las ventajas y los inconvenientes de las distintas tecnologías, es frecuente aprovechar las tecnologías más óptimas para la carga de trabajo concreta.

Tener una solución descompuesta por cargas de trabajo le ofrece la posibilidad de elegir las tecnologías de datos óptimas para una carga de trabajo concreta. Por ejemplo, un sitio web puede emplear almacenamiento en tablas para el contenido de un individuo y usar particiones en el nivel de usuario para mejorar la respuesta. Esas filas de tabla se pueden agregar periódicamente en una base de datos relacional con fines de informes y análisis.

Las estrategias de particionamiento pueden variar, y a menudo lo harán, en función de las tecnologías elegidas.

Al definir la estrategia, también es importante identificar los valores atípicos que pueden requerir una estrategia modificada o paralela. Por ejemplo, si desarrolla un sitio de red social, un usuario normal podría tener 500 conexiones, mientras que una celebridad podría tener 5.000.000.

Si el sitio espera 100.000 usuarios, y las celebridades constituyen menos de 50.000, la estrategia de partición principal se optimizará para el usuario típico. Las celebridades se gestionarán de manera diferente. Aunque agrupe un gran número de usuarios en una sola partición, puede asignar una celebridad a una partición propia.

Descripción de las 3 V

Para elaborar correctamente una estrategia de particionamiento, una organización debe entenderla primero.

Las 3 V, que popularizó Gartner, se centran en tres aspectos diferentes de los datos. Entender la relación entre las 3 V y los datos le ayudará a tomar una decisión informada sobre las estrategias de particionamiento.

  • Volumen

    El volumen hace referencia al tamaño de los datos. El volumen tiene impactos muy reales sobre la estrategia de particionamiento. Las limitaciones de volumen de una tecnología de datos específica puede forzar el particionamiento debido a limitaciones de tamaño, velocidades de consulta en el volumen, etc.

  • Velocidad

    La velocidad se refiere a la tasa a la que crecen los datos. Probablemente ideará una estrategia de particionamiento diferente para un almacén de datos de crecimiento lento que para uno que necesite dar cabida a 500.000 usuarios nuevos por día.

  • Variedad

    La variedad se refiere a los distintos tipos de datos que son pertinentes para la carga de trabajo. Ya se trate de datos relacionales, pares de clave-valor, perfiles de medios sociales, imágenes, archivos de audio, vídeos u otros tipos de datos, es importante entenderlos. De esta forma puede elegir la tecnología de datos adecuada y tomar decisiones informadas sobre la estrategia de particionamiento.

Crear particiones horizontales

Probablemente el enfoque más popular para el particionamiento de datos sea el particionamiento horizontal. Cuando se realiza el particionamiento horizontal, se toma una decisión sobre los criterios para crear varias particiones en un almacén de datos. Cada partición contiene todo el esquema y los criterios controlan la colocación de los datos en las particiones adecuadas.

Según el tipo de datos y el uso de los datos, se puede hacer de varias maneras. Por ejemplo, una organización podría elegir particionar sus datos según el apellido del cliente. En otro caso, la partición podría centrarse en la fecha, creando particiones según el intervalo de calendario correspondiente de hora, día, semana o mes.

Diagrama de particionamiento horizontal

Figura 5: Ejemplo de particionamiento horizontal por apellido

Particionamiento vertical

Otro enfoque es el particionamiento vertical. Este enfoque optimiza la colocación de los datos en almacenes diferentes y suele estar relacionado con la variedad de los datos. En la figura 5 se muestra un ejemplo en el que los metadatos sobre un cliente se colocan en un almacén, mientras que las miniaturas y las fotografías se colocan en almacenes diferentes.

El particionamiento vertical puede producir almacenamiento y entrega optimizados de los datos. En la figura 5, por ejemplo, si no se muestra a menudo la fotografía para un cliente, devolver 3 megabytes por registro puede agregar costos innecesarios en un modelo de pago por uso.

Diagrama de particionamiento vertical

Figura 6: Ejemplo de particionamiento vertical.

Particionamiento híbrido

En muchos casos será adecuado establecer una estrategia de particionamiento híbrido. Este enfoque ofrece las eficiencias de ambos enfoques en una única solución.

En la figura 6 se muestra un ejemplo, donde el particionamiento vertical visto anteriormente se aumenta para aprovechar el particionamiento horizontal de los metadatos del cliente.

Diagrama de particionamiento horizontal

Figura 7: Ejemplo de particionamiento horizontal.

El corazón de la informática en nube es la red. La red es fundamental porque proporciona el tejido o la red troncal para que los dispositivos se conecten a servicios y para que los servicios se conecten a otros servicios. En toda aplicación FailSafe hay que tener en cuenta tres límites de red.

A continuación se explican estos límites de red, usando Azure como ejemplo para proporcionar contexto:

  1. Los límites de rol se conocen tradicionalmente como niveles. Los ejemplos típicos son un nivel web o un nivel de lógica de negocios. Si consideramos Azure como ejemplo, presentó formalmente los roles como parte de su diseño básico para proporcionar compatibilidad con la infraestructura para la naturaleza de niveles múltiples de las aplicaciones distribuidas modernas. Azure garantiza que las instancias de rol pertenecientes al mismo servicio se hospedan dentro del ámbito de un solo entorno de red y las administra un solo controlador de tejido.

  2. Los límites de servicio representan las dependencias de funcionalidad proporcionada por otros servicios. Algunos ejemplos comunes son un entorno SQL para el acceso a bases de datos relacionales y un Service Bus para la compatibilidad con la mensajería de publicación y suscripción (pub/sub). Dentro de Azure, por ejemplo, los límites de servicio se aplican en toda la red: no se proporcionará ninguna garantía de que una dependencia de servicio forme parte del mismo entorno de red o controlador de tejido. Esto puede ocurrir, pero la hipótesis de diseño para cualquier aplicación responsable debe ser que toda dependencia de servicio esté en otra red diferente administrada por un controlador de tejido distinto.

    Diagrama de instancias de rol de servicios en la nube
    Ilustración 8

  3. Los límites de extremo son externos a la nube. Incluyen cualquier extremo usuario, que normalmente se supone que es un dispositivo, que se conecte a la nube para usar servicios. En esta parte del diseño se deben realizar unas consideraciones especiales debido a la naturaleza variable y no confiable de la red. Los límites de rol y los límites de servicio están dentro de los límites del entorno de la nube y se puede suponer un cierto nivel de confiabilidad y de ancho de banda. En el caso de las dependencias externas, no se puede realizar ninguna hipótesis de ese tipo y hay que prestar una atención adicional a la capacidad del dispositivo de usar servicios, lo que significa datos e interacciones.

    Por su propia naturaleza, la red presenta una latencia a medida que pasa información de un punto de la red a otro. Para proporcionar una buena experiencia tanto a los usuarios como a los servicios o los roles dependientes, la arquitectura y el diseño de las aplicaciones deben buscar maneras de reducir la latencia y de administrar explícitamente la latencia inevitable. Una de las formas más habituales de reducir la latencia consiste en evitar llamadas de servicios que impliquen la red; el acceso local a datos y servicios es un método fundamental para reducir la latencia y proporcionar una capacidad de respuesta mayor. El uso de datos y servicios locales también proporciona otra capa de seguridad frente a errores; siempre y cuando las solicitudes del usuario o de la aplicación se puedan atender desde el entorno local, no hay necesidad de interactuar con otros roles o servicios, lo que elimina la posibilidad de que un componente dependiente no esté disponible como un punto de error.

Almacenamiento en caché

Caching es una técnica que se puede usar para mejorar las velocidades de acceso a datos cuando no es posible almacenar datos localmente. Caching se emplea en la mayoría de los servicios en la nube hoy en día. Como indica la definición proporcionada en Wikipedia, una memoria caché proporciona acceso a local a datos que las aplicaciones solicitan repetidamente. Caching se basa en dos aspectos:

  • Los patrones de uso de los datos por parte de los usuarios y las aplicaciones dependientes son principalmente de solo lectura. En determinados escenarios como los sitios web de comercio electrónico, el porcentaje de acceso de solo lectura (denominado a veces exploración) es de hasta el 95 % de todas las interacciones de los usuarios con el sitio.

  • El modelo de información de la aplicación proporciona una capa adicional de información semántica que admite la identificación de datos singulares estables que resultan óptimos para Caching.

Caching de dispositivos

Si bien no es el foco de la iniciativa FailSafe, el Caching de dispositivos es uno de los modos más eficaces de aumentar la facilidad de uso y la solidez de los dispositivos y las aplicaciones de servicio. Existen numerosas formas de proporcionar servicios de almacenamiento en caché en el nivel del dispositivo o del cliente, que van desde la especificación HTML5 que proporciona capacidades de Caching nativas implementadas en todos los exploradores estándar hasta instancias locales de base de datos como SQL Server Compact Edition o similares.

Caching distribuido

El Caching distribuido es un conjunto eficaz de capacidades, pero su propósito no es sustituir una base de datos relacional u otro almacén persistente; en su lugar, su objetivo es aumentar la capacidad de respuesta de las aplicaciones distribuidas que por naturaleza están centradas en la red y, por tanto, son sensibles a la latencia. Una ventaja colateral del Caching es la reducción del tráfico al almacén de datos persistente, lo que reduce al mínimo las interacciones con el servicio de datos.

  • Modelos de información optimizados para Caching

    noteNota
    Gran parte del contenido de esta sección está basado en el gran trabajo realizado por Pat Helland cuando pensaba en los datos en el mundo de la arquitectura orientada a los servicios. Puede leer todo el artículo en Microsoft Developer Network.

    Los datos almacenados en caché son por naturaleza datos obsoletos; es decir, datos que no están necesariamente actualizados. Un buen ejemplo de datos almacenados en memoria caché, aunque de un dominio muy diferente, es un catálogo de productos que se envía a miles de hogares. Los datos usados para elaborar el catálogo de productos estaban actualizados cuando se creó el catálogo. Una vez iniciado el proceso de impresión, los datos (por la propia naturaleza del tiempo transcurrido durante el proceso de producción del catálogo) quedaron obsoletos. Como los datos almacenados en memoria caché están obsoletos, los atributos de los datos con respecto a la estabilidad y la singularidad son fundamentales en el diseño de Caching:

    • Estabilidad: datos que tienen una interpretación inequívoca a través del espacio y el tiempo. Esto significa a menudo valores de datos que no cambian. Por ejemplo, la mayoría de las empresas nunca reciclan las identificaciones de cliente o los números de SKU. Otra técnica para crear datos estables es la incorporación de fechas de expiración a los datos existentes. El ejemplo anterior del catálogo de productos impreso es un buen ejemplo. Normalmente, los minoristas aceptan pedidos de cualquier catálogo durante 2 períodos de publicación. Si se publica un catálogo cuatro veces al año, los datos del catálogo de productos son estable durante 6 meses y se pueden usar para tareas de procesamiento de información como realización y cumplimentación de pedidos.

      Los datos estables se denominan a menudo datos de referencia o datos maestros. En la iniciativa FailSafe se usará el término datos de referencia porque es un término más inclusivo semánticamente que datos maestros. En muchas empresas, los datos maestros tienen un significado muy específico y son más reducidos que los datos de referencia.

    • Singularidad: datos que se pueden aislar mediante la asociación con instancias identificables de forma única con actualizaciones de baja o ninguna simultaneidad. Veamos el ejemplo de una cesta de la compra. Aunque la cesta de la compra se actualizará claramente, las actualizaciones se realizan relativamente con poca frecuencia y se pueden aislar completamente del almacenamiento, así como desde la perspectiva de procesamiento.

      Los datos aislables como se ha descrito anteriormente se denominan datos de actividad o datos de sesión.

      Teniendo en cuenta estos dos atributos, surge el esquema siguiente:

      Diagrama de tipos de datos
      Ilustración 9

  • Modelado de información

    Muchos arquitectos o desarrolladores de aplicaciones piensan en los modelos de objeto o de entidad cuando piensan en el modelado de información. Si bien los modelos de objeto o de entidad forman parte de la ciencia del modelado de información, un modelo de información para una aplicación FailSafe incluye mucho más. 

    Una primera visión de los procesos de pensamiento necesarios para el mundo distribuido actual centrado en la estabilidad y la singularidad. Otro elemento clave es entender cómo se emplean los datos en la interacción con el usuario o con el dispositivo, o como parte de los procesos de negocio que se van a implementar. El modelado orientado a objetos debe formar parte del diseño de la información de varias maneras:

    • Ocultar información: ocultar o no proporcionar acceso a información que no es útil para el usuario o para el proceso de negocio es una de las mejores formas de evitar conflictos con datos de recursos o compartidos que se almacenan y se administran en una base de datos relacional.

      Un buen ejemplo de cómo se usa la ocultación de información para mejorar la simultaneidad es la diferencia entre un sistema ERP típico y la forma en que Amazon.com administra la mayoría de los escenarios de inventario. En una implementación típica de un sistema ERP, la tabla de inventario es una de las tablas más congestionadas o activas (si se da por supuesto una aplicación de base de datos relacional). Normalmente la aplicación ERP intenta bloquear el inventario hasta que el usuario haya finalizado la transacción, proporcionando el recuento exacto del inventario a la aplicación en el momento en que comienza la transacción comercial. Algunos sistemas, como SAP, evitan el bloqueo de base de datos pero adquieren un bloqueo de aplicación en su sistema de puesta en cola. Se han desarrollado muchas técnicas en la capa de base de datos para ayudar a evitar esta congestión: control de simultaneidad optimista, lecturas de datos sucios, etc. Ninguna de ellas funciona realmente de forma limpia y todas tienen efectos secundarios. En algunos escenarios se desea bloquear la tabla, pero deben ser escasos y separados en el tiempo.

      Amazon.com solucionó el problema de una forma mucho más sencilla: ofreció al usuario un objetivo de nivel de servicio (SLO) en el que el usuario podía participar y aceptar o rechazar. El SLO se expresaba principalmente como "disponible normalmente en N horas"; el usuario no veía el número real de libros disponibles u otros artículos, pero a pesar de todo se proporcionaba información acerca de la disponibilidad. No se necesitaba ningún bloqueo de la base de datos; de hecho, no se necesitaba ninguna conectividad con bases de datos en absoluto. Si el sistema no pudiera cumplir el SLO, enviaría una disculpa al comprador (normalmente por correo electrónico) y proporcionaría un SLO actualizado.

    • Recursos fungibles: El diccionario define fungible de esta forma: 'fungible (especialmente tratándose de mercancías) es de una naturaleza o clase que se puede cambiar o reemplazar libremente, en su totalidad o parcialmente, por otra cosa de naturaleza o clase similar". La idea, una vez más con el objetivo de reducir la fricción del acceso a datos compartidos, es usar el modelado de información para proporcionar una manera de que el usuario interactúe con una instancia fungible de datos en lugar de con una instancia específica. Un buen ejemplo de ello es la reserva de una habitación de hotel. Se puede expresar mucha especificidad, como el número de camas, si tiene vista al mar, si es de fumador o de no fumador, etc., sin hacer referencia nunca a la habitación '123'. Con este tipo de modelado, es perfectamente viable almacenar en memoria caché información sobre grupos de datos fungibles, ejecutar el proceso de negocios en el grupo y, solo después de que finalice el proceso de registro, asignar una habitación determinada de ese grupo. También son perfectamente viables modelos híbridos de quitar una habitación determinada de un grupo una vez que comienza el proceso de registro.

  • Administrar la memoria caché

    Almacenar en memoria caché la información correcta en el momento adecuado es una parte fundamental de una estrategia correcta de Caching. Existen numerosas técnicas para cargar la memoria caché: una buena información general se describe en “Caching in the Distributed Environment”. Además, en las próximas secciones se describen algunas consideraciones sobre el diseño de aplicaciones FailSafe que dependen de Caching distribuido.

    • Datos de referencia: si se produce un desastre en el entorno de hospedaje (controlador de tejido o centro de datos), la aplicación se moverá a otro entorno. En caso de que una instancia activa de la aplicación ya esté activa (diseño activo-activo), la probabilidad de que la memoria caché ya contenga mucha información pertinente (especialmente datos de referencia) es alta. En caso de que se active una nueva instancia de la aplicación, no habrá información en los nodos de memoria caché. Debe diseñar la aplicación para que en caso de que se produzca un error de caché, cargue automáticamente los datos deseados. En el caso de una instancia nueva, puede tener una rutina de inicio que cargue de forma masiva los datos de referencia en la memoria caché. Es conveniente tener una combinación de ambos, ya que los usuarios pueden estar activos en cuanto la infraestructura de la nube ofrezca la aplicación.

    • Datos de actividad: las técnicas básicas descritas para los datos de referencia son válidas también para los datos de actividad. Sin embargo, hay una variación específica de los datos de actividad. Se supone que los datos de referencia están disponibles en cualquier almacén persistente de la aplicación. Como cambiará con menos frecuencia, la sincronización no debe suponer ningún problema, aunque es necesario tenerla en cuenta. Sin embargo, los datos de actividad, que se actualizan en aislamiento y con poca frecuencia, serán más volátiles que los datos de referencia. Idealmente, la memoria caché distribuida conserva los datos de actividad con frecuencia y replica los datos entre las diversas instancias de la aplicación. Preste atención para asegurarse de que los intervalos de persistencia y de sincronización estén suficientemente espaciados como para evitar la contención pero lo suficientemente cercanos como para reducir al mínimo una posible pérdida de datos.

Un malentendido frecuente es la relación, concretamente las áreas de responsabilidad, entre la plataforma y la aplicación. Una de las áreas donde esto es más problemático es en lo que se refiere a los datos.

Mientras una plataforma como Azure cumplirá las promesas de almacenar varias copias de los datos (y en algunos servicios irá tan lejos como para proporcionar redundancia geográfica), los datos almacenados están controlados por la aplicación, la carga de trabajo y sus servicios de componente. Si la aplicación realiza una acción que daña sus datos de aplicación, la plataforma almacena varias copias.

Al establecer los modos de error y los puntos de error, es importante identificar las áreas de la aplicación que pueden producir daños en los datos. Como el punto de origen puede variar desde código no válido hasta mensajes dudosos para el servicio, es importante identificar los modos de error y los elementos de error relacionados.

Solución en el nivel de aplicación

  • Idempotencia

    Una suposición básica con los servicios conectados es que no estarán disponibles al 100 % y que el control de errores transitorios con lógica de reintento es un enfoque básico de implementación. En caso de que se implemente lógica de reintento, existe la posibilidad de que se envíe más de una vez el mismo mensaje, que los mensajes se envíen fuera de secuencia, etc.

    Las operaciones deben diseñarse de forma que sean idempotentes, asegurándose de que el envío del mismo mensaje varias veces no produzca un almacén de datos inesperado o contaminado.

    Por ejemplo, la inserción de datos desde todas las solicitudes puede dar lugar a que se agreguen varios registros si se llama varias veces a la operación de servicio. Un enfoque alternativo sería implementar el código como una "upsert" (actualización e inserción) inteligente, que realiza una actualización si un registro existe o una inserción si no existe. Se podría emplear una marca de tiempo o un identificador global para distinguir los mensajes nuevos de los procesados previamente, insertando solo los más recientes en la base de datos y actualizando los registros existentes si el mensaje es más reciente que el que se recibió anteriormente.

  • Actividades de carga de trabajo y comportamiento de compensación

    Además de la idempotencia, otra área que hay que tener en cuenta es el concepto de comportamiento de compensación.

    Un ejemplo real del comportamiento de compensación es cuando se devuelve un producto que se pagado con una tarjeta de crédito. En este escenario, un cliente visita una tienda, proporciona una tarjeta de crédito y se aplica un cargo a la cuenta de la tarjeta de crédito del cliente. Si el cliente devuelve el producto al vendedor, se evalúa una directiva y, si la devolución cumple la directiva, el vendedor emite un crédito por el importe de la compra a la cuenta de la tarjeta de crédito del cliente.

    En un mundo en el que hay un conjunto cada vez mayor de sistemas conectados y con la aparición de servicios compuestos, es importante entender cómo controlar el comportamiento de compensación.

    Para muchos desarrolladores de aplicaciones de línea de negocio, los conceptos de transacciones no son nuevos, pero el marco de referencia está asociado a menudo a la funcionalidad transaccional expuesta por tecnologías de datos locales y bibliotecas de código relacionadas. Al examinar el concepto en términos de la nube, esta mentalidad necesita tener en cuenta nuevas consideraciones relacionadas con la orquestación de servicios distribuidos.

    Una orquestación de servicios puede abarcar varios sistemas distribuidos, tener una ejecución prolongada y tener estado. La propia orquestación no suele ser sincrónica y puede tardar desde varios segundos hasta años según el escenario empresarial.

    En un escenario de cadena de suministros, puede vincular 25 organizaciones en la misma actividad de carga de trabajo. Por ejemplo, puede haber un conjunto de 25 o más sistemas interconectados en una o varias orquestaciones de servicios.

    Si se realiza correctamente, los 25 sistemas deben saber que la actividad se realizó correctamente. Para cada punto de conexión de la actividad, los sistemas participantes pueden proporcionar un identificador de correlación para los mensajes que reciben de otros sistemas. Según el tipo de actividad, la recepción de ese identificador de correlación puede convencer al participante de que la transacción se ha completado conceptualmente. En otros casos, al completarse las interacciones de los 25 participantes, se puede enviar un mensaje de confirmación a todos los participantes (ya sea directamente desde un único servicio o mediante los puntos específicos de interacción de orquestación para cada sistema).

    Para controlar los errores en actividades compuestas y/o distribuidas, cada servicio expondría una interfaz y operaciones de servicio para recibir solicitudes de cancelar una transacción determinada por un identificador único. Detrás de la fachada de servicio, existirían flujos de trabajo para compensar la cancelación de esta actividad. Idealmente serían procedimientos automatizados, pero pueden ser tan sencillos como el enrutamiento a una persona de la organización para que lo solucione manualmente.

Copias de seguridad

Además de la solución en el nivel de aplicación para evitar daños en los datos, también se establecen soluciones para proporcionar opciones si la solución de la aplicación no es correcta.

Los procesos para crear y restaurar copias de seguridad del almacén de datos, ya sea en su totalidad o en parte, deben formar parte del plan de resistencia. Si bien los conceptos de copia de seguridad y restauración de datos no son nuevos, hay nuevas variaciones de ellos en la nube.

A la hora de definir la estrategia de copia de seguridad se deben comprender los requisitos empresariales para la restauración de datos. Si un almacén de datos resulta dañado o se queda sin conexión debido a un desastre, debe saber qué tipo de datos se debe restaurar, el volumen que hay que restaurar y el ritmo necesario para la empresa. Esto afectará al plan de disponibilidad global y debe regir su planeamiento de copia de seguridad y restauración.

  • Bases de datos relacionales

    La copia de seguridad de bases de datos relacionales no es nada nuevo. Muchas organizaciones cuentan con herramientas, métodos y procesos para la copia de seguridad de datos con el fin de satisfacer las necesidades de recuperación ante desastres o de cumplimiento. En muchos casos, las herramientas, los métodos y los procesos tradicionales se pueden usar con poca o ninguna modificación. Además, se pueden considerar alternativas nuevas o variables, como hacer copia de seguridad de los datos y almacenar una copia en el almacenamiento de blobs basado en la nube.

    A la hora de evaluar los procesos y las herramientas existentes, es importante evaluar cuál es el enfoque adecuado para la solución basada en la nube. En muchos casos, se aplicarán uno o varios de los métodos enumerados a continuación para solucionar distintos modos de error.

    1. Copia de seguridad total: es una copia de seguridad de un almacén de datos en su totalidad. Las copias de seguridad totales deben realizarse según una programación dictada por el volumen y la velocidad de datos. Una copia de seguridad total es todo el conjunto de datos necesarios para cumplir el contrato de nivel de servicio del servicio. Los mecanismos para este tipo de copia de seguridad suelen estar disponibles a través del proveedor de base de datos o de servicios de base de datos o de su ecosistema de proveedores.

    2. Un momento dado: una copia de seguridad de un momento dado es una copia de seguridad que refleja un momento dado en el tiempo de la existencia de la base de datos. Por ejemplo, si por la tarde se produjera un error que dañara el almacén de datos, se podría restaurar una copia de seguridad de un momento dado realizada al mediodía para minimizar el impacto sobre el negocio.

      Dado el nivel cada vez mayor de conectividad entre individuos, la expectativa de conectar con su servicio a cualquier hora del día convierte en una necesidad la capacidad de restaurar rápidamente a un momento dado reciente.

    3. Sincronización: además de las copias de seguridad tradicionales, otra opción es la sincronización de datos. Los datos se pueden almacenar en varios centros de datos, por ejemplo, con una sincronización periódica de datos de un centro de datos a otro. Además de proporcionar datos sincronizados en soluciones que emplean la administración del tráfico como parte de un plan de disponibilidad normal, también se puede usar para conmutar por error a un segundo centro de datos si surge algún problema de continuidad empresarial.

      Debido a la conectividad constante de usuarios que consumen servicios, cada vez es menos aceptable el tiempo de inactividad para diversos escenarios y la sincronización puede ser un enfoque deseable.

      Los patrones para la sincronización pueden incluir los siguientes:

      - de un centro de datos a otro de un proveedor de nube determinado

      - de un centro de datos a otro entre proveedores de nube

      - de un centro de datos local a otro centro de datos de un proveedor de nube determinado

      - de un centro de datos a la sincronización de dispositivos para segmentos de datos específicos del cliente

  • Bases de datos relacionales particionadas

    Para muchos, el cambio a la nube se debe a una necesidad de facilitar escenarios de un gran número de usuarios y mucho tráfico como los relacionados con las aplicaciones móviles o sociales. En estos casos, el patrón de aplicación implica a menudo pasar del modelo de una base de datos única a varias particiones de base de datos que contienen una parte del conjunto de datos global y están optimizadas para el funcionamiento a gran escala. Un proyecto reciente de red social creado en Azure empezó con un total de 400 particiones de bases de datos.

    Cada partición es una base de datos independiente, y la arquitectura y la administración deben facilitar copias de seguridad totales, copias de seguridad de un momento dado y la restauración de copias de seguridad tanto para particiones individuales como un conjunto de datos completo que incluya todas las particiones.

  • Almacenes de datos NoSQL

    Además de para los almacenes de datos relacionales, se deben considerar directivas de copia de seguridad también para los almacenes de datos "no solo SQL" o NoSQL. La forma más popular de bases de datos NoSQL que proporcionan los proveedores de nube principales sería una forma de almacenamiento de alta disponibilidad de pares de clave-valor, a la que se hace referencia a menudo como almacén de tabla.

    Los almacenes NoSQL pueden ser de alta disponibilidad. En algunos casos también serán redundantes geográficamente, lo que puede ayudar a prevenir la pérdida de datos en caso de que se produzca un error grave en un centro de datos determinado. Estos almacenes no suelen proporcionar protecciones frente a la sobrescritura de aplicaciones o la eliminación de contenido accidental. Los servicios de plataforma como el almacenamiento de blobs no administran automáticamente los errores de aplicación o del usuario; por tanto, se debe evaluar una estrategia de copia de seguridad.

    Mientras que las bases de datos relacionales tienen normalmente herramientas existentes ya establecidas para realizar copias de seguridad, muchos almacenes NoSQL no disponen de ellas. Un enfoque arquitectónico popular consiste en crear una copia duplicada de los datos en un almacén NoSQL de réplica y usar algún tipo de tabla de búsqueda para identificar qué filas del almacén de origen se han colocado en el almacén de réplica. Para restaurar los datos se usaría esta misma tabla, leyendo de la tabla para identificar el contenido del almacén de réplica disponible que se va a restaurar.

    Según la importancia de la continuidad empresarial, esta réplica se puede hospedar con el mismo proveedor de nube, en el mismo centro de datos y/o en el mismo almacén de datos NoSQL. También puede residir en otro centro de datos, en otro proveedor de nube y/o en otra variante diferente del almacén de datos NoSQL. La elección de la ubicación estará influida en gran medida por el SLA deseado del servicio de carga de trabajo y cualquier otra consideración relacionada sobre el cumplimiento de normativas.

    Un factor que hay que tener en cuenta es el costo, concretamente en lo que respecta a la entrada y salida de datos. Los proveedores de nube pueden proporcionar libre circulación de datos dentro de sus centros de datos y permitir el paso gratuito de datos en su entorno. Ningún proveedor de nube ofrece salida gratuita de datos, y el costo que supone mover datos a un proveedor secundario de plataforma de nube podría suponer costos significativos en la escala.

    noteNota
    La tabla de búsqueda se convierte en un punto de error potencial y una réplica de ella debe formar parte de la planeación de la resistencia.

  • Almacenamiento de blobs

    Como ocurre con los almacenes de datos relacionales y NoSQL, una idea equivocada frecuente es que las características de disponibilidad implementadas para una oferta de almacenamiento de blobs eliminará la necesidad de implementar una directiva de copia de seguridad.

    El almacenamiento de blobs también puede ser redundante geográficamente pero, como se ha explicado anteriormente, esto no protege frente a los errores de aplicación. Los servicios de plataforma como el almacenamiento de blobs no administran automáticamente los errores de aplicación o del usuario; por tanto, se debe evaluar una estrategia de copia de seguridad.

    Las estrategias de copia de seguridad pueden ser muy similares a las empleadas para los almacenes NoSQL. Debido al tamaño potencialmente grande de los blobs, el costo y el tiempo necesario para mover datos serán partes importantes de una estrategia de copia de seguridad y restauración.

  • Restaurar copias de seguridad

    La mayoría de la gente ya debe haber oído el cuento con moraleja de la organización que establecía y seguía diligentemente las directivas de copia de seguridad pero nunca había probado la restauración de los datos. En el fatídico día en que se produjo un desastre, fueron a restaurar la copia de seguridad de la base de datos y descubrieron que habían configurado la copia de seguridad incorrectamente y las cintas que habían estado enviando fuera de sus instalaciones durante años no contenían la información que necesitaban.

    Cualesquiera que sean los procesos de copia de seguridad que se implanten, es importante probarlos para asegurarse de que los datos se pueden restaurar correctamente y de que la restauración se realiza a tiempo y con un impacto empresarial mínimo.

Las Redes de entrega de contenido (CDN) son una manera popular de proporcionar disponibilidad y mejorar la experiencia del usuario para los archivos que se solicitan con frecuencia. El contenido de una CDN se copia a un nodo local la primera vez que se usa y, después, se ofrece desde ese nodo local en las solicitudes subsiguientes. El contenido expirará después de un período de tiempo designado, tras el cual se debe volver a copiar el contenido al nodo local en la siguiente solicitud.

El uso de una CDN proporciona varios beneficios, pero también agrega una dependencia. Como ocurre con cualquier dependencia, la solución de un error de servicio se debe revisar de forma proactiva.

Uso adecuado de una CDN

Una idea equivocada frecuente es que las CDN son la solución para todo. En un escenario, un cliente estaba seguro de que era la solución correcta para una tienda en línea de libros electrónicos. No lo era. ¿Por qué? En un catálogo de un millón de libros, hay un pequeño subconjunto de los libros que se solicitan con frecuencia (los "éxitos") y una retahíla muy larga de libros que se solicitarían con muy poca previsibilidad. Los títulos solicitados con frecuencia se copiarían al nodo local en la primera solicitud y proporcionarían una escala local rentable y una experiencia agradable del usuario. Para la cola larga, casi cada solicitud se copia dos veces (a una vez al nodo local y después al cliente) porque las solicitudes poco frecuentes hacen que el contenido expire periódicamente. Esto es una prueba de que una CDN tendrá el efecto contrario al deseado: una solución más lenta y más costosa.

En muchos casos, las operaciones de una solución no se pueden planear hasta más adelante en el ciclo de vida. Para compilar aplicaciones verdaderamente resistentes, se deben diseñar pensando en las operaciones. El diseño para las operaciones incluirá normalmente actividades clave como establecer un modelo de mantenimiento, capturar información de telemetría, incorporar servicios y flujos de trabajo de supervisión de estado, y convertir estos datos en procesables tanto por parte de operaciones como de los desarrolladores.

Los equipos de desarrollo suelen pasar por alto y a veces omitir completamente el "estado" de la aplicación. Como resultado, los servicios entran a menudo en producción con dos estados conocidos: en funcionamiento o inactivo. Los diseñadores de servicios resistentes deben desarrollar modelos de estado que definan los criterios de estado de la aplicación, el estado correcto disminuido, el error y las dependencias de estado correcto.

El desarrollo proactivo de un modelo de estado resume los modos y los puntos de error, forzando a los desarrolladores a identificar y estudiar escenarios condicionales en las fases de diseño de la aplicación. Para hacer operativo un modelo de estado, un servicio debe ser capaz de comunicar su estado. Debe contar con una forma mediante programación de propagar esta información, proporcionar una interfaz para consultar interactivamente ese estado de mantenimiento, proporcionar mecanismos (o enlaces a mecanismos existentes) mediante los cuales los administradores puedan supervisar el estado de la aplicación en tiempo real y establecer mecanismos a través de los cuales los administradores puedan ofrecer la "medicina correctora", cuando sea necesario, para devolver la aplicación a un estado correcto.

Definir características

Para un servicio o una aplicación determinados, se deben realizar diagnósticos para identificar los puntos de datos y los intervalos de valores que indican al menos tres categorías de estados: correcto, correcto disminuido e incorrecto. Esta información se puede emplear para automatizar la recuperación automática de los servicios.

Definir interfaces

Con los estados de mantenimiento definidos, un servicio debe exponer interfaces relacionadas con el mantenimiento. Estas interfaces proporcionarán las siguientes categorías de operaciones.

  • Emitir el estado correcto a los servicios asociados suscritos

    Un servicio debe emitir información de estado correcto a los servicios asociados suscritos. Este estado de mantenimiento debe ser conciso, con un nivel elevado de diagnósticos de estado y básicos.

    El servicio debe ofrecer la posibilidad de que un servicio asociado se suscriba a los mensajes de estado. La entrega de mensajes de estado puede realizarse mediante rutas de acceso adecuadas para la solución. Una ruta de acceso puede hacer que el servicio ponga las actualizaciones del estado de mantenimiento en una cola que los suscriptores puedan recuperar.

    Un método alternativo consiste en permitir que los suscriptores proporcionen un extremo en el que se exponga una interfaz conocida de informe de estado. Cuando la información de estado cambie, puede emitir información a los suscriptores en los extremos proporcionados.

  • Exponer interfaces para entregar datos de telemetría

    La telemetría es excelente para las operaciones, ya que ayuda a identificar el estado actual de la aplicación y/o los servicios en varios niveles. También puede ayudar a identificar rápidamente que ocurre algo atípico en el entorno. Esto proporciona una vista bastante detallada del servicio y se expone al personal de operaciones, los servicios y los paneles del proveedor de servicios.

    Para las operaciones, las métricas de telemetría pueden incluir por ejemplo el porcentaje de CPU, los errores, las conexiones y las colas promedio para los distintos roles, servicios y aplicaciones compuestas basadas en servicios.

    La telemetría específica de la aplicación no suele habilitarse automáticamente y la propia plataforma la supervisa directamente, por lo que tanto el servicio como la aplicación deben habilitar la telemetría.

  • Exponer interfaces para interrogar al servicio sobre información adicional de diagnóstico de estado

    Idealmente, un servicio debe proporcionar también interfaces para consultar información adicional de diagnóstico de estado. Los servicios de suscriptor, en función de la información de alto nivel recibida en el estado de mantenimiento, pueden solicitar información adicional para determinar una ruta con su relación con el servicio que proporciona sus detalles de estado.

    Concretamente, si el servicio parece estar en un estado deficiente, la información adicional puede permitir que un servicio usuario tome una decisión de seguir usando el servicio o de conmutar por error a un proveedor alternativo.

  • Exponer interfaces para solucionar el estado del servicio en el nivel de servicio y de aplicación

    Si el consumidor de la información de estado es un servicio interno o relacionado, quizás desee permitir que el propio servicio corrija los problemas conocidos. Igual que ocurre con la medicina humana, el conocimiento del estado del servicio evolucionará con el tiempo y los datos de estado pueden conducir a distintos tratamientos.

    Un servicio debe exponer una interfaz para permitir la entrega de ese tratamiento. En su forma más simple, esto puede ir desde desencadenar un reinicio hasta volver a crear la imagen de un servicio para conmutar por error a un proveedor de datos o de servicios interno.

    Comprender el estado de un servicio puede permitir que el proveedor de servicios identifique rápidamente si un servicio está en un estado incorrecto. Las operaciones automatizadas pueden proporcionar soluciones rápidas, coherentes y preceptivas de problemas conocidos y hacer que el servicio se recupere automáticamente. En esta sección se examinan con más detalle los distintos aspectos del estado.

Telemetría es “el proceso de usar equipo especial para tomar mediciones de alguna cosa (como la presión, la velocidad o la temperatura) y enviarlas por radio a otro lugar”.

Es importante que recopile datos de telemetría de su servicio. La telemetría se categoriza con frecuencia en uno de cuatro tipos: usuario, negocio, aplicación e infraestructura.

La telemetría de usuario se dirige al comportamiento de un usuario individual como objetivo. Proporciona un entendimiento del comportamiento de un usuario y, como resultado, puede facilitar la entrega de una experiencia individualizada.

La telemetría de negocio contiene datos relacionados con actividades de negocio e indicadores clave de rendimiento (KPI) para el negocio. Pueden ser ejemplos de telemetría de negocio el número de usuarios activos únicos en un sitio, el número de vídeos vistos, etc.

La telemetría de aplicación contiene detalles sobre el estado, el rendimiento y la actividad de la capa de aplicación y su servicios dependientes. La telemetría de aplicación contiene detalles, por ejemplo, de llamadas e inicios de sesión de clientes de datos, excepciones, llamadas de API, sesiones, etc.

La telemetría de infraestructura incluye detalles sobre el estado de la infraestructura del sistema subyacente. Puede incluir datos sobre recursos como la CPU, la memoria, la red, la capacidad disponible, etc.

Al identificar qué datos se recopilan y cómo recopilarlos, es importante comprender los datos y lo que tiene previsto hacer con ellos.

En primer lugar, determine si la finalidad de los datos que se recopilan es informar o iniciar una acción. La pregunta correspondiente es “¿con qué rapidez debo reaccionar?” ¿Usará los datos en casi tiempo real para posiblemente iniciar una acción? ¿O usará los datos en un informe de tendencias un mes tras otro? La respuesta a estas preguntas informará del enfoque de telemetría y las tecnologías usadas en la arquitectura.

A continuación, identifique el tipo de pregunta o preguntas que tiene previsto aplicar a los datos de telemetría que está recopilando. Usará la telemetría para responder a preguntas conocidas o para la exploración. Por ejemplo, para un negocio, los KPI son respuestas a preguntas conocidas. Sin embargo, un fabricante que quiere explorar datos de dispositivo para ver patrones que dan como resultado errores se aventura en lo desconocido. Para el fabricante, los errores se derivan de uno o varios elementos del sistema. El fabricante realiza su exploración y requerirá datos adicionales.

Cuando use la telemetría para alcanzar un claro entendimiento, debe considerar el tiempo requerido para conseguirlo. En algunos casos, usará la telemetría para detectar un pico en la lectura del sensor de un dispositivo que tiene una ventana de segundos o minutos. En otros casos, puede usar la telemetría para identificar semana tras semana el aumento de usuarios para un sitio web que tiene una ventana mucho más larga.

Finalmente, considere la cantidad de datos que puede recopilar desde un origen de señal dentro del período de tiempo para alcanzar un claro entendimiento. Debe conocer la cantidad de la señal de origen que necesita. A continuación puede determinar el mejor modo de particionar la señal y establecer la combinación apropiada de cálculo local y global.

Otra consideración es cómo registrar la secuencia de eventos en la telemetría. Muchas organizaciones usarán de forma predeterminada las marcas de tiempo. Sin embargo, las marcas de tiempo pueden ser un reto porque los relojes de los servidores en los centros de datos no son coherentes. Aunque la hora puede sincronizarse periódicamente, existe evidencia documentada de que los relojes de los servidores se desvían (lentamente son más imprecisos). Este desvío da lugar a cambios que pueden perjudicar el análisis efectivo. En los escenarios que requieren precisión, considere soluciones alternativas, como utilizar una implementación de reloj de vectores.

Después de identificar un enfoque de telemetría, avance hasta la caracterización de la señal.

Puede clasificar la señal como continua o discreta. Un ejemplo de señal continua son los datos de eventos en tiempo real. Las entradas de archivo de registro forman parte de una señal discreta.

Para satisfacer las necesidades de su enfoque, debe identificar la cantidad de datos que hay en la señal. Si la información es continua, debe establecer una frecuencia de muestreo. Si es discreta, debe identificar los registros que se van mantener o filtrar.

También debe identificar el tipo de acceso. En algunos casos, será apropiado insertar los datos de telemetría. En otros casos, recuperará los datos de telemetría mediante extracción.

En los sistemas más evolucionados, puede encontrar que el entendimiento alcanzado a partir de la telemetría insertada existente puede dar lugar a la extracción de destino para información adicional. Por ejemplo, si la telemetría insertada indica un estado poco óptimo, puede recuperar datos de diagnóstico adicionales mediante extracción.

Todos los datos recopilados pueden ser importantes bajo determinadas condiciones, pero no siempre se deben enviar todos los datos de telemetría. En función del tipo de telemetría y la cantidad de datos necesarios para alcanzar el entendimiento, es posible que pueda recuperar cantidades inferiores de datos. Puede usar el cálculo local para generar agregados, muestreos o subconjuntos y enviar estos datos al servicio. Si los datos que recibe de la telemetría estándar indican un estado poco óptimo, por ejemplo, el servicio puede solicitar datos adicionales.

Al desarrollar una estrategia de telemetría, considere qué directivas son apropiadas. La telemetría requiere disponer de conectividad, y se genera un coste al enviar datos a través de esa conexión. Cree directivas que tengan en cuenta el contexto, la conectividad y el coste, y ajuste la telemetría según corresponda.

Las políticas deben tener en cuenta el contexto del estado actual para determinar qué telemetría es apropiada enviar en este momento. El entendimiento alcanzado a partir de la telemetría recibida previamente y las necesidades de negocio asociadas informan al contexto. Este contexto ayuda a dirigir y clasificar por orden de prioridad la recopilación de la telemetría.

Estos dispositivos pueden tener tipos de conectividad variados (WiFi, LTE, 4G, 3G, etc.), y esa conectividad puede ser variable. La conectividad del dispositivo en este momento es importante para determinar qué datos se deben transmitir. En los escenarios en los que la conectividad no es confiable o en los que las velocidades de conectividad son lentas, la directiva puede clasificar por orden de prioridad la telemetría transmitida.

La conectividad se proporciona con frecuencia a un coste. Las directivas tendrán en cuenta si actualmente una conexión es de uso medido o no. Si se trata de una conexión de uso medido, las directivas identificarán los costes asociados y, si están disponibles, los límites de uso. Muchos dispositivos usan diferentes tipos de conexiones durante el curso de un día. Puede clasificar por orden de prioridad telemetría específica en función del coste de su entrega o cancelar la clasificación.

Con frecuencia las diferentes audiencias introducirán y visualizarán datos de telemetría. Las operaciones y los desarrolladores son dos audiencias para los que la visualización es importante. Sin embargo, tal como se indica abajo, las necesidades de cada audiencia requieren diferentes niveles de granularidad.

La visualización del estado de operaciones de nivel superior y los datos de telemetría de nivel inferior es importante para el personal de Operaciones. Las notificaciones automatizadas se enviarán en función de los datos de telemetría. Sin embargo, las operaciones querrán un panel que ayude a visualizar el rendimiento actual e histórico del servicio.

Para aplicaciones de escala importante, esta información puede ayudar a identificar un problema actual rápidamente y predecir un problema futuro. También puede ayudar a las operaciones a identificar los impactos potenciales y las causas raíz.

Diagrama del panel de rendimiento

Ilustración 10

El diagrama anterior de un sitio social grande examina el porcentaje de CPU promedio de roles de API, los errores de la API, los usuarios que hay en línea, las conexiones web activas, el porcentaje de CPU de roles web, los errores web, las conexiones web por cable, las conexiones web agrupadas, la cola de aplicaciones web y las conexiones web por software.

La telemetría y el tipo de informes que se muestran son especialmente útiles en aquellos casos en que las operaciones pueden solucionar los errores sin modificar el código de los propios servicios. Algunos ejemplos de actividades que las operaciones pueden realizar pueden incluir la implementación de más roles y el reciclado de instancias.

Puede usar la visualización de datos de telemetría históricos y en tiempo real para:

  • solucionar problemas,

  • postmortems realizados para problemas de sitios activos,

  • formación de nuevos empleados de Operaciones.

Además del personal de operaciones, los desarrolladores de software son consumidores importantes de los datos de telemetría. Puede que los errores no estén relacionados con el entorno operativo sino con el código de aplicación subyacente. Tener un panel de telemetría para los desarrolladores les permite tomar acciones orientadas.

A continuación se muestran dos instantáneas de una utilidad de ejemplo que se ha creado para un solo propósito. El panel proporciona detalles sobre el número de errores, las categorías a las que pertenecen los errores y datos específicos relacionados con cada una de esas categorías. Esto incluye datos de examen entre los que se incluye el número total de errores, el número total de instancias de rol que experimentan errores y el número total de bases de datos con error.

Diagrama del panel

Ilustración 11

Diagrama del panel

Ilustración 12

En el caso de sitios grandes con millones de usuarios conectados, habrá un número mayor de errores y puede ser perfectamente aceptable. Tener un panel centrado en los desarrolladores que interprete la telemetría puede ayudar a identificar si hay algún problema realmente, si conviene participar y el lugar del código donde se producen los problemas.

Vea también

Mostrar: