Llegamos a ustedes gracias a:



Reportajes y análisis

5 lecciones del error de la nube S3 de Amazon

Y cómo prepararse para el siguiente

[05/03/2017] De acuerdo con Catchpoint, la plataforma de monitoreo de Internet, el Servicio de Almacenamiento Simple (S3) de Amazon Web Services experimentó una interrupción de tres horas con 39 minutos el martes, que tuvo un efecto dominó sobre otros servicios de nube de Amazon y sobre muchos sitios de Internet que dependen de la famosa plataforma de nube.

"S3 es como aire en la nube", señala Dave Bartoletti, analista de Forrester; cuando cae muchos sitios web no pueden respirar. Sin embargo, las interrupciones y los errores son un hecho en la nube. Bartoletti añade que no hay razón alguna para asustarse: "esta no es una tendencia", anota. "S3 ha sido tan confiable, tan segura, ha sido un activo muy valioso de la nube de Amazon".

Esta semana debería ser vista como una llamada de atención para asegurarse que sus aplicaciones basadas en la nube estén listas para la próxima vez que haya algún problema con la nube. Aquí les dejamos cinco consejos para prepararse para una interrupción de la nube:

No ponga todos sus huevos en una sola canasta

Este consejo significa diferentes cosas para los distintos usuarios, pero la idea central es que, si implementa una aplicación o un pedazo de dato en algún punto de la nube, no será tolerante a las fallas. Lo que determinará la cantidad de canastas en las que tiene que distribuir sus cargas de trabajo, será qué tan disponible quiere que esté su aplicación. Hay varias opciones:

* AWS recomienda dispersar las cargas de trabajo en muchas Zonas de Disponibilidad. Cada una de las 16 regiones que conforman AWS están divididas en, por lo menos, dos y a veces hasta cinco Zonas de Disponibilidad. Cada una de ellas está destinada a estar aislada de las que se encuentran en la misma región. AWS proporciona conexiones de baja latencia entre sus Zonas de Disponibilidad en la misma región, creando así la manera más básica de distribuir las cargas de trabajo.

* Para una mayor protección, los usuarios pueden distribuir sus aplicaciones a lo largo de muchas regiones.

* La máxima protección requiere implementar la aplicación a lo largo de múltiples proveedores; por ejemplo, usar Microsoft Azure, Google Cloud Platform o algún recurso de infraestructura interno o alojado como copia de seguridad.

Bartoletti dice que los diferentes clientes tienen distintos niveles de urgencia para hacer esto. Si confía en la nube para hacer dinero para su negocio o es esencial para la productividad, será mejor que se asegure de que sea tolerante a las fallas y esté altamente disponible. Si, por el contrario, lo usa para hacer copias de seguridad de archivos a los que no accede con frecuencia, quizá será capaz de vivir con las interrupciones ocasionales.

Fallas de identidad lo antes posible

La clave para responder a una falla de la nube es saber cuándo sucede. AWS tiene una serie de maneras de hacer esto. Una de las más básicas es usar algo que se llama Health Checks, que proporciona un enfoque personalizado del estado de los recursos de AWS utilizados por cada cuenta. CloudWatch de Amazon puede ser configurado para que realice un seguimiento automático de la disponibilidad del servicio, monitorear los archivos de registro, crear alarmas y reaccionar ante las fallas. Un precursor importante de este trabajo es tener un análisis exhaustivo de lo que es un comportamiento "normal" para que las herramientas de nube de AWS puedan detectar el comportamiento "anormal".

Una vez que un error es identificado, hay un rango de reacciones de efectos dominó que tienen que ser preconfigurados para responder de manera correcta ante la situación (mire más arriba en las multi zonas de disponibilidad, multi región o multi nube). Los equilibradores de carga pueden estar en su lugar para redireccionar el tráfico, y los sistemas de respaldo pueden comenzar a tener un efecto si es que han sido configurados para eso (vea más abajo).

Construya sistemas redundantes desde el principio

No sería muy útil tratar de responder a una interrupción en tiempo real. La preparación previa a ésta lo salvará cuando inevitablemente llegue. Hay dos maneras básicas de construir redundancia en los sistemas de nube:

* Standby: Cuando ocurre una falla, la aplicación automáticamente la detecta y conmuta en un sistema de respaldo redundante. En este caso, el sistema de respaldo puede estar apagado, pero listo para funcionar cuando un error sea detectado. Una alternativa es que la copia de respaldo de espera pueda estar ejecutándose ociosamente en segundo plano todo el tiempo (esto cuesta más, pero reduce el tiempo de conmutacion por error). La desventaja de estos enfoques "standby" o de espera, es que podría haber un retraso entre que un error es detectado y cuando se inicia el sistema de conmutación por error.

* Redundancia activa: Para (teóricamente) evitar el tiempo de inactividad los usuarios pueden diseñar su aplicación para que tenga redundancia activa. En este escenario, la aplicación está distribuida a través de múltiples recursos redundantes: cuando uno falla el resto de recursos absorbe una mayor proporción de la carga de trabajo. Puede utilizarse una técnica de fragmentación en la que los servicios se dividen en componentes. Digamos, por ejemplo, que una aplicación se ejecuta en ocho instancias de máquinas virtuales -esas pueden dividirse en cuatro grupos de dos cada una y el tráfico puede ser balanceado entre ellas. Si un fragmento se cae, los otros tres pueden recoger el tráfico.

Haga una copia de seguridad de los datos

Una cosa es tener sistemas redundantes y otra realizar copias de seguridad de sus datos. Eso hubiera sido especialmente importante en la interrupción de esta semana, porque primero impactó el servicio de almacenamiento más popular de Amazon, S3. AWS tiene muchas maneras de respaldar los datos de manera nativa:

* Replicación síncrona: Es un proceso en el cual una aplicación solo reconoce una transacción (tal como subir un archivo a la nube o introducir información en una base de datos) si ha sido replicada en una ubicación secundaria. La desventaja de este enfoque es que puede introducir latencia para esperar a que ocurra la replicación secundaria, y para que el sistema primario obtenga confirmación. Cuando la latencia no es una prioridad, este enfoque es muy bueno.

* Replicación asíncrona: Este proceso desacopla el nodo primario de las réplicas, lo cual es bueno para los sistemas que necesitan capacidades de escritura de baja latencia. Los usuarios deberían estar dispuestos a comprometer alguna pérdida reciente de transacciones durante una falla en este escenario.

* Replicación basada en Quorum: Es una combinación de replicación síncrona y asíncrona que establece una cantidad mínima de información que necesita ser respaldada para que una transacción califique.

Para determinar la mejor forma de construir sistemas redundantes y respaldar los datos, los clientes deberían considerar su objetivo de punto de recuperación (RPO) y su objetivo de tiempo de recuperación (RTO) deseados.

Pruebe su sistema

¿Por qué esperar que una interrupción ocurra para ver si su sistema es resistente a la falla? Pruébelo antes. Puede sonar loco, pero los mejores arquitectos de nube están dispuestos a matar nodos enteros, servicios, Zonas de Disponibilidad e incluso enteras, para ver si su aplicación lo puede soportar. "Debería estar golpeando constantemente su propio sitio", dice Bartoletti. Netflix tiene herramientas de código abierto llamadas Chaos Monkey y Chaos Gorilla, que son parte de su ejército simio y que pueden, de manera automática, matar ciertos sistemas internos para probar su tolerancia a errores. ¿Funcionan? Esta semana, Netflix no reportó ningún problema con su servicio.

Para más información relacionada a las mejores prácticas de AWS en la arquitectura para la tolerancia ante fallas, revise este AWS Whitepaper.