Cómo diseñar sistemas muy resilientes (aunque no sean a prueba de fallas)

Las fallas son inevitables a largo plazo...

Probando de vuelta que no hay nada infalible, Hotmail, Outlook.com y SkyDrive salieron de servicio por unas horas el 12 marzo afectando a algunos usuarios.

"Heat Spike Caused Microsoft’s SkyDrive and Email Outage"
http://slashdot.org/topic/datacenter/heat-spike-caused-microsofts-skydrive-and-email-outage/


Los tiempos de tener únicamente alta disponibilidad y redundancias se acabaron

En algun momento, la visión de la arquitectura de soluciones informáticas complejas va a ir adoptando estándares y prácticas más realistas que llevar al límite tecnologico la alta disponibilidad y la redundancia. Ello implicando un costo considerablemente alto en esos límites, muchas veces sin retornar realmente beneficios prácticos en igual medida. 

Por ej: Clustering masivo, múltiples datacenters, arquitecturas de hardware redundantes (múltiples equipos de networking, múltiples equipos de storage, virtualización redundante, etc. etc.).

No es que todo lo anterior no sea recomendable de implementar (u obligatorio/mandatorio en muchos casos!), sino que como solución efectiva y concreta a muchos eventos de fallas de sistemas, las mencionadas medidas - en mi experiencia - no sirven más que para tolerar niveles muy bajos de falla. 

Y cuando ocurren fallas grandes en sistemas complejos (produciendo típicamente efectos cascada, dañando sistemas periféricos/secundarios, muy poco relacionados inclusive, con el punto de falla original), la altísima disponibilidad y múltiples niveles de redundancia no llegan a aportar el estado "normal y funcionando" en el sistema, que supuestamente debería haber resultado del adecuado manejo realizado por los múltiples sistemas altamente disponibles y redundantes. De hecho muchos subsistemas altamente disponibles y redundante siguen disponibles y funcionales en esos eventos, pero el sistema en sí, la unión y funcionamiento coordinado de diferentes partes con un objetivo, está fuera de servicio. 

Por ende, elevar masivamente la inversión solamente en sistemas altamente disponibles y redundantes no va a poder aportar realmente y en la práctica la disponibilidad contínua de sistemas críticos complejos durante fallas graves.

Estas ideas igualmente no son nuevas, y son grandemente conocidas por muchos proveedores de sistemas públicos comerciales que basan su modelo de negocio en que esos sistemas estén siempre disponibles para sus clientes.

Por ejemplo: Hotmail, Gmail, Yahoo, Amazon (sus diferentes productos de cloud), Microsoft (sus diferentes productos de cloud), etc.

Justamente en el artículo mencionado al comienzo, un datacenter donde Microsoft tiene localizados muchos de sus servers para Hotmail, Outlook.com y SkyDrive tuvieron que ser - muy probablemente - apagados masiva e imprevistamente. Sin embargo, la mayoría de los usuarios a nivel mundial no notó problema alguno en los servicios.

"How Complex Systems Fail: A WebOps Perspective"
http://www.kitchensoap.com/2009/11/12/how-complex-systems-fail-a-webops-perspective/

"How Complex Systems Fail"
http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf



Fallar constantemente, la nueva visión en el diseño de arquitecturas altamente resilientes

La visión práctica en el diseño de arquitecturas altamente resilientes, capaces de tolerar fallos graves y seguir prestando los servicios que se espera de ellas, desde 2010 en adelante se enfoca en crear sistemas capaces de recuperarse automática o semiautomáticamente, sin dejar de prestar los servicios que se supone debe proveer.

Esto se logra aplicando las diferentes tecnologías, disciplinas y experiencias aprendidas a lo largo de los años: altos niveles de disponibilidad (razonablemente planteados para evitar despilfarro gratuito), altos niveles de redundancia en hardware y software (razonablemente....etc.), sólidos sistemas de backup, monitoreo, políticas de Disaster Recovery, etc. etc.

El nuevo y a veces inesperado componente en el diseño de arquitecturas muy resilientes es el testing proactivo de todos los componentes anteriores.

Algo así como la - prehistórica - práctica de que cuando se configuraba dos servers en cluster para probar que iba a funcionar (en serio), se tiraba del cable de power de uno de los nodos para apagarlo y ver cómo reaccionaba el cluster (es decir, el otro nodo). Hoy en día esa práctica está reemplazada por la - mucho más razonable - de apagar/bajar las interfaces de red de un nodo, o a lo sumo, retirar los cables de red de los puertos físicos del server.

El testing de componentes de la arquitectura es similar, pero llevado a una potencia enésima. Se busca apagar/bajar - pseudo-aleatoriamente o aleatoriamente - uno o varios componentes en un sistema complejo. Luego de eso, se observa (examina, documenta, etc.), cómo se comporta el sistema durante esa eventualidad.

Se busca lograr una "arquitectura Rambo" (junto con sus correspondientes sistemas de soporte), capaz de resistir cualquier evento y poder tener éxito (seguir funcionando como se espera), a pesar de cualquier fallo que ocurra.

Después de eso, solamente, se entiende acerca de muchas interacciones inesperadas entre los diferentes componentes del sistema. Y luego se puede re-plantear, re-planificar las medidas de control necesarias para minimizar el fallo, y perseguir efectivamente la posibilidad de que el sistema siga funcionando.

La filosofía de diseño se resume en esta hipótesis (claramente demostrada según muchas opiniones de peso en Internet):

"La mejor manera de evitar fallas es fallar constantemente"

y 

"Todo pasa por una razón, excepto por todas esas cosas que pasan completamente al azar."

Links:


"Highly Available Architecture at Netflix"
http://www.slideshare.net/AmazonWebServices/arc203-netflixha

"Working with the Chaos Monkey"

http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

"5 Lessons We’ve Learned Using AWS"

http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

"Web Operations"
http://en.wikipedia.org/wiki/Web_operations


Bibliografía
* Web Operations, 2010, OReilly

Cómo hace el equipo de Operaciones para detener los problemas en sus vías

Traducción del original:
How the Technical Operations team stops problems in their tracks


Cómo hace el equipo de Operaciones para detener los problemas en sus vías

La semana pasada leías sobre como el equipo de operaciones técnicas de la Fundación Wikimedia ("Ops"), gastó centenares o miles de horas de trabajo para refactorizar y automatizar todos los servicios que provee, para prepararse para la migración de datacenter de Enero. Una recompensa de ese trabajo: nuestros sitios no estuvieron caídos tan a menudo, y cuando lo estuvieron, el downtime fue por buenos motivos.

"Otra cosa que ilustra nuestro crecimiento y madurez es nuestro downtime" dice el ingeniero de Operaciones Peter Youngmeister.

"Algo que es menos visible para la gente fuera de Ops es la clase de downtime que tenemos. Por ejemplo, ya no tenemos más el tipo "Oops, solté un cable" o "Ese server la palmó", porque las cosas son mucho más robustas ahora, mucho más redundantes. Un montón de eso es producto del masivo impulso a la automatización por el que pasamos, el cual nos permite crear redudancia mucho más fácilmente, y nos deja ocupar nuestro tiempo, en vez de estar "apagando incendios".

El ingeniero de la Fundación Wikimedia Roan Kattouw añade "o 'el server DB maestro tiene el disco lleno' - esa ocurrió unas pocas veces años atrás, y ya no ocurre más ahora."

Para arreglar las crisis rápidamente, necesitamos monitoreo: herramientas que automáticamente chequeen por problemas y alerten a nuestros ingenieros cuando algo está roto. En los primeros días de nuestros sitios, simplemente confiabamos en que habría algun sysadmin online y disponible en caso de que alguien notara algun problema y se quejara en IRC. Varios años atrás, comenzamos a usar Nagios para monitoreo y asignamos una rotación de "pagers", para decidir a quien despertar primero en caso de crisis.

Nagios corre test automatizados chequeando el comportamiento de nuestro sitio (como "¿Devuelve el puerto 80 un HTTP 301?"), y chequea ciertos números clave para asegurarse que los valores encontrados están dentro de un rango aceptable (por ejemplo, para testear y ver si nos estamos quedando sin memoria). Si un test falla, Nagios envía alarmas vía emails, IRC y SMS.

El monitoreo nos ayuda a manejar la crisis rápido, pero a menudo no ayuda a resolver el problema en sí.

"Nagios es grandioso para decirte cuando las cosas están rotas, y es basura para decirte por qué", explica Peter. "El trabajo que Asher Feldman ha realizado creando perfilado de datos (data profiling), es más útil".

Como lo explica Roan "Perfilado de datos es el acto de generar datos sobre 'Cuanto tiempo ha gastado la gran tarea X en realizar la subtarea Y' La razón para ello es que:

1) Uno de esos pequeños Ys podría en realidad no ser tan pequeño y ser un problema
2) Por la regla de 80-20, para algunos Ys, la optimización tendrá un impacto mayor, así que hace falta encontrarlos.

El perfilado de datos genera conocimiento acerca del comportamiento de nuestros sistemas, así los ingenieros pueden entender mejor como debería estar funcionando el cluster, y ofrece tips para resolver problemas.

Nosotros usamos dos sistemas de perfilado para obtener datos en tiempo-serie: Ganglia a nivel de host, y Graphite a nivel de aplicación. (conseguíte un login al Labs para ver Graphite). En los pasados dos años, configuramos Ganglia para cubrir muchos más datos, y en 2012 empezamos a usar Graphite. A mejores datos, se vuelve más útil para la resolución de problemas, y el Director de Operaciones CT Wook regularmente revisa el dashboard para ir viendo problemas por venir y alertar a su equipo. Esto reduce los downtimes.

Por ejemplo, en una página de Ganglia, previamente solo teníamos acceso a datos de host: espacio libre en disco, carga, etc. Recientemente añadimos datos específicos de Apache, como request por segundo y número de threads idle. Esta información adicional ayuda a los sysadmins en la resolución de problemas. "Uno puede verlo y hacer mejore deducciones que solo 'Oops, el server tiene mucha carga'," explica Peter.

Como la "puppetización", las mejoras en perfilado fueron una inversión del equipo de Operaciones. "Hay un plugin para Ganglia que arma estadísticas de performance de Apache. Me costó horas configurarlo totalmente, Pero, de vuelta, es pensar hacia adelante, una deuda que debemos honrar, en vez de insultarnos a nosotros mismos cuando no esté allí - esa información - cuando la necesitemos. Es un emprendimiento masivo decidir hacer las cosas del Modo Correcto, configurar una plataforma, en vez de hacer millones de cosas de 'una-sola-vez'."

Mientras que la "puppetización", mejora del monitoreo y perfilado, preparaban para la migración de datacenter, el equipo de Operaciones tuvo que diferir otros trabajos no urgentes. "Ops era menos capaz de dar soporte a muchos equipos", dice Peter, "por ejemplo, Recolección de Fondos solo tenía unos cuantos servers y podían hacer con ellos lo que quisieran, a diferencia de cómo es ahora donde Jeff Green (un ing. de operaciones), está trabajando en armar un asombroso sistema, PCI-compliant a tiempo completo. O Análisis era muy independiente/sin respaldo, porque había tan pocas horas/hombre para darles soporte que no estaban siquiera manteniendo el sitio activo..creo que el ensamble del EQIAD (el datacenter de Virginia), es muy demostrativo de la deuda técnica que tenía Ops."

Ahora Peter mira hacia adelante viendo a Wikimedia "instalar más datacenter, dramáticamente más rápido". El equipo de Operaciones está en preparativos para adicionar un datacenter en la costa oeste de Norteamérica. El Site Architech Asher Feldman ve un "arco continuado de refinamiento" en el futuro del equipo, en vez de "desafíos que terminan para ser reemplazados por nuevos desafíos". "Los desafíos en hacer escalar MediaWiki no van a dejar de existir a corto plazo, tampoco la necesidad de modernización incremental de la arquitectura en múltiples niveles". Por ejemplo, Ops necesita continuamente "puppetizar" ciertos servicios; algunos módulos también necesitan manifiestos Puppet tuneados para funcionar, no solo en el site principal, sino también en los Wikimedia Labs.

Podés chequear los objetivos del equipo de Operaciones para 2012-2013 y leer sobre lo que viene a continuación (incluyendo mejoras en búsquedas y seguridad).

Sumana Harihareswara, Engineering Community Manager

Copyright notes: NOLA Hackathon 20 by Ben Hartshorne, under CC-BY-SA 3.0 Unported, from Wikimedia Commons, Eqiadwmf 9045 by Rob Halsell, under CC-BY-SA 3.0 Unported, from Wikimedia Commons