¿Cuál es una buena estrategia para mantener mi sitio en línea cuando S3 se desconecta?

¿Cuál es una buena estrategia para mantener mi sitio en línea cuando S3 se desconecta?

Si S3 US East 1 se desconecta, ¿cómo debo configurar / estructurar mi aplicación para evitar que desconecte todo mi sitio?

¿Cuáles son las mejores estrategias para diversificar en este tipo de situación?

En marzo de 2015, Amazon AWS anunció que admite la replicación S3 en todas las regiones. Cuando una determinada región en S3 se desconecta, puede servir archivos desde su espejo en otra región.

^{fuente: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

La práctica de mantener su infraestructura en línea haciendo un cambio a otra región es compleja, pero S3 es un componente relativamente pequeño y simple. Netflix tiene un gran artículo sobre su experiencia con Chaos Gorilla.

Esto también se aplica a la degradación del servicio, como una mayor latencia. No solo cuando un servicio del que depende está completamente fuera de línea. Netflix también tiene un artículo sobre esto: Chaos Engineering Upgraded .

Lo que está pidiendo es, básicamente, alta disponibilidad. Para que un sistema esté altamente disponible, necesita tres cosas:

1. Eliminar puntos únicos de falla
2. Un mecanismo para cambiar de un punto final a otro
3. Una forma de detectar fallas

Eliminar puntos únicos de falla

En el caso de S3, el punto n. ° 1 se aborda, como señaló Evgeny, mediante la replicación entre regiones de S3 .

Sin embargo, la replicación no es instantánea y querrá verificar si desea que la replicación de su aplicación sea consciente o no. En el caso de una interrupción, es posible que algo que se escribió en su depósito de origen aún no haya llegado (no se haya replicado) al depósito de destino. Tienes que pensar cómo manejaría la aplicación tal escenario. Eso realmente depende del tipo de datos, lo que se está haciendo con ellos y (potencialmente) los usuarios finales o las expectativas de la administración.

Un mecanismo para cambiar de un punto final a otro

Para S3, eso significa que, en caso de una interrupción, desea que la aplicación deje de leer y escribir desde / hacia el depósito A y utilice el depósito B en su lugar.

Cómo lograr esto es, hasta donde yo sé, depende de usted por ahora. Algunos otros servicios de AWS ofrecen fallas completamente transparentes, pero no estoy al tanto de tal cosa para S3 en este momento.

Hay varias formas de lograr esto. Un ejemplo es usar un proxy que enrutará el tráfico al depósito apropiado. Durante una interrupción, debe actualizar / cambiar el proxy para enrutar el tráfico a un depósito no afectado por la interrupción. Otro ejemplo sería hacer que la configuración de su aplicación sea dinámica y almacenarla en un almacén de valores clave. Si la aplicación lee la tienda KV para propiedades actualizadas con la frecuencia suficiente, puede cambiar desde donde lee y escribe (Spring Cloud tiene soporte para un escucha "EnvironmentChange", por ejemplo).

Una forma de detectar fallas

Bueno, ese es fácil, creo. Simplemente configure un ciclo de escritura + lectura y alerta tan pronto como algo no esté bien :)

Notas de cierre

• Si su solicitud está escribiendo en el bucket, debe pensar en lo que sucedería en el caso de una conmutación por error. ¿Han llegado todas las escrituras al depósito de destino (y se nota)? ¿Puede permitir escrituras en el depósito de destino (convirtiéndolo en el nuevo "primario")? Una planificación cuidadosa evitará escenarios de cerebro dividido o actualizaciones perdidas.
• Dependiendo de su SLA, es posible que desee que los puntos # 2 y # 3 sean automáticos o automáticos. Eso requiere planificación, herramientas y pruebas adicionales, pero los guiones bien escritos siempre reaccionarán más rápido y de manera más predecible que los humanos (las fallas también tienen el molesto hábito de suceder en medio de la noche cuando la intervención humana es algo peligroso.
• Vale la pena mencionar que incluso la replicación entre regiones no elimina por completo los puntos únicos de falla. Claro, si una región baja, estás cubierto. Pero, ¿qué sucede si ocurre un corte de AWS en todo Estados Unidos? Azure tuvo un corte parcial pero global el año pasado y uno en 2014 también.