Acerca de las prácticas de una topología de nube fiable y resistente

La arquitectura de una aplicación fiable en la nube suele ser diferente de la arquitectura de una aplicación tradicional. Si bien históricamente es posible que haya adquirido hardware redundante de gama alta para minimizar la posibilidad de que falle toda una plataforma de aplicaciones, en la nube, es importante reconocer por adelantado que se producirán fallos. En lugar de intentar evitar fallos por completo, el objetivo es minimizar los efectos de un único componente fallido (punto único de fallo o SPOF). Siga estas mejores prácticas para aumentar la fiabilidad en cada paso del proceso de diseño.

Las aplicaciones fiables son:

Resiliente y recupere correctamente de los fallos, y siguen funcionando con un tiempo de inactividad mínimo y pérdida de datos antes de la recuperación completa.
Alta disponibilidad (HA) y ejecución según lo diseñado en un estado correcto sin tiempo de inactividad significativo.
Protegido de fallos de región mediante un buen diseño de recuperación ante desastres (DR).

Comprender cómo funcionan juntos estos elementos y cómo afectan al costo es esencial para construir una aplicación confiable. Puede ayudarle a determinar cuánto tiempo de inactividad es aceptable, el costo potencial para su negocio y qué funciones son necesarias durante una recuperación.

Arquitecto de Fiabilidad

Al crear una aplicación en la nube, utilice lo siguiente para aumentar la fiabilidad.

Defina los requisitos.
Define tus requisitos de disponibilidad y recuperación en función de las cargas de trabajo que traigas a la nube y las necesidades empresariales.
Aplique las mejores prácticas de arquitectura.
Siga prácticas probadas, identifique posibles puntos de fallo en la arquitectura y determine cómo responderá la aplicación al fallo.
Realice pruebas con simulaciones y failovers forzados.
Simule fallos, dispare failovers forzados y pruebe la detección y recuperación de estos fallos.
Despliegue aplicaciones de forma consistente.
Lánzate a producción mediante procesos fiables y repetibles y automatiza siempre que sea posible.
Supervise el estado de la aplicación.
Detecte fallos, supervise indicadores de posibles fallos y evalúe el estado de las aplicaciones.
Gestione fallos y desastres.
Identifique cuándo se produce un fallo y determine cómo abordarlo en función de las estrategias establecidas.

Definir los requisitos

Define tus requisitos de disponibilidad y recuperación en función de las cargas de trabajo que traigas a la nube y las necesidades empresariales.

Tenga en cuenta lo siguiente al identificar las necesidades de su negocio y ajuste su plan de fiabilidad a ellas:

Identificar cargas de trabajo y sus requisitos
Una carga de trabajo es una capacidad o tarea distinta que está separada lógicamente de otras cargas de trabajo, en términos de lógica de negocio y requisitos de almacenamiento de datos. Cada carga de trabajo tiene diferentes requisitos de disponibilidad, escalabilidad, consistencia de datos y recuperación ante desastres.
Determinar patrones de uso
La forma en que se utiliza una aplicación desempeña un papel en los requisitos. Identificar las diferencias en los requisitos durante períodos críticos y no críticos. Por ejemplo, una aplicación que gestiona el procesamiento de fin de mes no puede fallar durante el fin de mes, pero puede manejar el fallo en otras ocasiones. Para garantizar el tiempo de actividad, se pueden agregar componentes adicionales o redundancia durante períodos críticos y eliminarlos cuando ya no agregan valor.
Identificar componentes y rutas críticos
Puede que no todos los componentes del sistema sean tan importantes como otros. Por ejemplo, puede tener un componente opcional que agrega valor incremental, pero que la carga de trabajo se puede ejecutar sin hacerlo si es necesario. Comprenda dónde se encuentran estos componentes y, a la inversa, dónde se encuentran las partes críticas de la carga de trabajo. Esto le ayudará a determinar el alcance de sus métricas de disponibilidad y fiabilidad y a planificar sus estrategias de recuperación para priorizar los componentes de mayor importancia.
Identificar dependencias externas y el efecto del fallo descendente
Si la carga de trabajo depende de servicios externos, un fallo en estas dependencias puede afectar negativamente a la disponibilidad de la carga de trabajo. Implementar métodos de desacoplamiento de la integración para aislar contra fallos descendentes.
Determine los requisitos de disponibilidad de la carga de trabajo
La alta disponibilidad (HA) se define normalmente en términos de un objetivo de tiempo de actividad. Por ejemplo, un destino de alta disponibilidad del 99% significa que un recurso concreto puede no estar disponible durante 3,65 días al año. Oracle Cloud Infrastructure (OCI) está diseñado para proporcionarle un entorno de alta disponibilidad. OCI publica un acuerdo de nivel de servicio (SLA) para cada uno de sus servicios que describe los compromisos de Oracle para el tiempo de actividad y la conectividad con esos servicios, y debe revisarlos para ver cómo coinciden con sus requisitos. Algunos servicios en OCI tienen altos niveles de alta disponibilidad incorporados, en particular los servicios gestionados por Oracle, como la base de datos autónoma. Para garantizar que una arquitectura de aplicación cumple los requisitos de negocio, defina los SLA de destino para cada carga de trabajo, incluidas las dependencias externas. Tenga en cuenta el costo y la complejidad de cumplir los requisitos de disponibilidad, además de las dependencias de aplicaciones.
Establecer las métricas de recuperación: objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO)
El RTO es el tiempo máximo aceptable para que una aplicación no esté disponible después de un incidente de desastre.

El RPO es la duración máxima de la pérdida de datos que es aceptable durante un desastre.

Para obtener estos valores, realice una evaluación de riesgos y asegúrese de comprender el costo y el riesgo de tiempo de inactividad o pérdida de datos en su organización.

Las copias de seguridad incrementales para el almacenamiento proporcionan seguridad frente a la pérdida de datos mediante puntos de recuperación. El período entre cada copia de seguridad limita la cantidad máxima de datos que se pierden después de la restauración a partir de una copia de seguridad.

Por ejemplo, considere el uso de una de las políticas de copia de seguridad predefinidas de Oracle para el almacenamiento de OCI Block Volumes: Bronze, Silver y Gold. Cada política de copia de seguridad consta de programas con una frecuencia de copia de seguridad incremental definida, como mensual, semanal o diaria, y un período de retención definido.
Definición de un desastre
Tener planes y requisitos de recuperación ante desastres bien documentados es importante, pero la naturaleza caótica de tal evento puede crear confusión. Comprenda lo que constituye un desastre para su empresa, identifique los roles clave que se necesitarán durante un desastre y establezca un plan de comunicación bien definido para iniciar una respuesta al desastre.
Considerar costos
Desde la perspectiva de FinOps, considere las implicaciones de costos de diferentes estrategias de confiabilidad. Esto le ayuda a tomar decisiones informadas sobre sus requisitos de disponibilidad y recuperación.

Aplicación de las Mejores Prácticas Arquitectónicas

Al diseñar su arquitectura, céntrese en implementar prácticas que cumplan con los requisitos de su negocio, identifiquen los puntos de fallo y minimicen el alcance de los fallos.

Tenga en cuenta las mejores prácticas siguientes:

Determinar dónde se pueden producir fallos
Analice la arquitectura para identificar los tipos de fallos que puede experimentar la aplicación, los posibles efectos de cada uno y las posibles estrategias de recuperación.
Determine el nivel de redundancia necesario en función de los requisitos de alta disponibilidad y DR.
El nivel de redundancia necesario para cada carga de trabajo depende de las necesidades de su negocio y de los factores que influyen en el costo general de la aplicación.
Diseño para la escalabilidad
Una aplicación en la nube debe poder ampliarse para adaptarse a los cambios de uso. Comience con componentes discretos y diseñe la aplicación para que responda automáticamente a los cambios de carga siempre que sea posible. Tenga en cuenta los límites de escala durante el diseño para que pueda expandirse fácilmente en el futuro.
Utilizar el equilibrio de carga para distribuir solicitudes
El equilibrio de carga distribuye las solicitudes de la aplicación a instancias de servicio en buen estado eliminando las instancias en mal estado de la rotación. La externalización de la información de estado hará que la escala de backend sea transparente para el usuario final. Si se realiza un seguimiento del estado en la sesión, puede que sea necesario mantener el estado.
Cree requisitos de disponibilidad y resiliencia en su diseño
La resiliencia es la capacidad de un sistema para recuperarse de fallos y seguir funcionando. La disponibilidad es la proporción de tiempo que el sistema funciona y funciona. Implante mejores prácticas de alta disponibilidad, como evitar puntos de fallo únicos y descomponer las cargas de trabajo por objetivo de nivel de servicio. Utilice las funciones estándar de la capa de datos, como la continuidad de las aplicaciones y las transacciones asíncronas, para garantizar la disponibilidad y la resiliencia.
Implantar DR
Diseñe su solución para cumplir con los requisitos de RTO y RPO identificados. Asegúrese de que puede poner todos los componentes de su solución de DR en línea dentro de su RTO. Proteja sus datos para que pueda cumplir con su RPO. La forma de almacenar, realizar copias de seguridad y replicar datos es fundamental.
- Realice una copia de seguridad de sus datos
  Incluso con un entorno de DR totalmente replicado, las copias de seguridad regulares siguen siendo críticas. Realice copias de seguridad y valide los datos con regularidad, y asegúrese de que ninguna cuenta de usuario tenga acceso a los datos tanto de producción como de copia de seguridad.
- Seleccionar métodos de replicación para los datos de la aplicación
  Los datos de la aplicación se almacenan en varios almacenes de datos y pueden tener diferentes requisitos de disponibilidad. Evalúe los métodos y las ubicaciones de replicación para cada tipo de almacén de datos para asegurarse de que cumplan con los requisitos de alta disponibilidad y el RPO.
- Comprender las implicaciones del failover y su efecto en la preparación ante desastres
  ¿Necesitará instanciar otra región para la replicación a fin de cumplir los requisitos de las cargas de trabajo? ¿Tendrá que preocuparse por la coherencia de los datos tras el failback?
- Documentar y probar los procesos de failover y failback
  Documente claramente las instrucciones para realizar una conmutación por error en un nuevo almacén de datos y pruébelas regularmente para asegurarse de que sean precisas y fáciles de seguir.
- Asegúrese de que su plan de recuperación de datos cumple con su RTO
  Asegúrese de que su estrategia de copia de seguridad y replicación proporcione tiempos de recuperación de datos que cumplan con su RTO, así como con su RPO. Tenga en cuenta todos los tipos de datos que utiliza la aplicación, incluidos los datos de referencia, los archivos y las bases de datos.

Prueba periódica con simulaciones y failovers forzados

Las pruebas de fiabilidad requieren medir el rendimiento de la carga de trabajo de extremo a extremo en condiciones de fallo que solo se producen de forma intermitente.

Probar escenarios de fallos comunes disparando fallos reales o simulándolos
Utilice las pruebas de inyección de fallos para probar escenarios comunes (incluidas combinaciones de fallos) y el tiempo de recuperación.
Identificar fallos que solo se producen bajo carga
Pruebe la carga máxima, utilizando datos de producción o datos sintéticos lo más cercanos posible a los datos de producción, para ver cómo se comporta la aplicación en condiciones reales.
Ejecutar simulacros de recuperación ante desastres
Tenga un plan de recuperación ante desastres y pruébelo periódicamente para asegurarse de que funciona.
Realizar pruebas de failover y failback
Asegúrese de que los servicios dependientes de la aplicación realizan un failover y un failback en el orden correcto.
Ejecutar pruebas de simulación
La prueba de escenarios de la vida real puede resaltar los problemas que deben abordarse. Los escenarios deben ser controlables y no disruptivos para el negocio. Informar la gestión de los planes de pruebas de simulación.
Sondeos de estado de prueba
Configure sondeos de estado para equilibradores de carga y gestores de tráfico para comprobar los componentes críticos del sistema. Probarlos para asegurarse de que responden adecuadamente.
Sistemas de supervisión de pruebas
Asegúrese de que los sistemas de supervisión informen de forma fiable información crítica y datos precisos para ayudar a identificar posibles fallos.
Incluir servicios de terceros en escenarios de prueba
Pruebe posibles puntos de fallo debido a una interrupción del servicio de terceros, además de la recuperación.
Aprenda de los problemas encontrados durante las pruebas
Si las pruebas revelan problemas o lagunas, asegúrese de que se identifican y se abordan mediante la adición de supervisión adicional o el ajuste de los procesos operativos.

Despliegue de aplicaciones de forma consistente

El despliegue incluye el aprovisionamiento de servicios y recursos de Oracle Cloud Infrastructure (OCI), el despliegue de código de aplicación y la aplicación de valores de configuración. Una actualización puede implicar las tres tareas o un subconjunto de ellas.

Automatice el proceso de despliegue de aplicaciones
Automatice tantos procesos como sea posible. Si es posible, se deben eliminar las implementaciones manuales en producción, aunque esto puede ser aceptable en entornos más bajos para promover la velocidad y la flexibilidad.
Aproveche la automatización para probar su código antes del despliegue
Las pruebas de bugs, vulnerabilidades de seguridad, funcionalidad, rendimiento e integraciones son fundamentales para minimizar los problemas que detectan los usuarios finales. Las pruebas fallidas deben evitar que el código se libere en producción.
Diseña tu proceso de lanzamiento para maximizar la disponibilidad
Si el proceso de versiones requiere que los servicios se desconecten durante el despliegue, la aplicación no estará disponible hasta que vuelvan a estar en línea. Aproveche las funciones de ubicación temporal y producción de la plataforma. Si es posible, libere nuevos despliegues en un subjuego de usuarios para supervisar los fallos de la primera hora.
Tener un plan de rollback para el despliegue
Diseñar un proceso de rollback para volver a la última versión correcta conocida y minimizar el tiempo de inactividad si falla un despliegue. La automatización del rollback tras un despliegue fallido puede evitar un tiempo de inactividad innecesario.
Despliegues de log y auditoría
Si utiliza técnicas de despliegue en área temporal, más de una versión de la aplicación se está ejecutando en producción. Implante una estrategia de registro sólida para capturar la mayor cantidad de información específica de la versión posible.
Documentar el proceso de liberación de solicitud
Defina y documente claramente el proceso de liberación, y asegúrese de que esté disponible para todo el equipo de operaciones.

Control del Estado de la Aplicación

Implante mejores prácticas para la supervisión y las alertas en su aplicación para que pueda detectar fallos y alertar a un operador para que los corrija.

Implantar el rastreo alrededor de llamadas de servicio
Los datos de rendimiento base pueden ayudar a proporcionar datos de tendencia que se pueden utilizar para identificar de forma proactiva los problemas de rendimiento antes de que afecten a los usuarios.
Implantar sondeos de estado
Ejecútelos regularmente desde fuera de la aplicación para identificar la degradación del estado y el rendimiento de la aplicación. Estos sondeos deben ser más que solo pruebas de página estática, deben reflejar el estado holístico de la aplicación.
Compruebe flujos de trabajo de larga ejecución
La detección temprana de problemas puede minimizar la necesidad de realizar un rollback de todo el flujo de trabajo o ejecutar varias transacciones de compensación.
Mantenga logs de sistema, aplicación y auditoría
Utilice un servicio de registro centralizado para almacenar los logs.
Configuración de un sistema de alerta temprana
Identifique los indicadores clave de rendimiento (KPI) del estado de una aplicación, como las excepciones transitorias y la latencia de llamadas remotas, y defina los valores de umbral adecuados para cada una de ellas. Envíe una alerta a las operaciones cuando se alcance el valor de umbral.
Entrenar a varios operadores para supervisar la aplicación y realizar pasos de recuperación manual
Asegúrese de que siempre haya al menos un operador entrenado activo.

Gestión de fallos y desastres

Cree un plan de recuperación y asegúrese de que abarca la restauración de datos, las interrupciones de red, los fallos de servicio dependientes y las interrupciones del servicio en toda la región. Considera tus máquinas virtuales, almacenamiento, bases de datos y otros servicios de OCI en tu estrategia de recuperación.

Planificar la gestión de incidentes
Defina roles y responsabilidades claros para la gestión de incidentes a fin de mantener los servicios en ejecución o restaurarlos lo más rápido posible.
Documente y pruebe su plan de recuperación ante desastres
Escriba un plan de recuperación ante desastres que refleje el impacto empresarial de los fallos de la aplicación. Automatice el proceso de recuperación tanto como sea posible y documente los pasos manuales. Pruebe regularmente su proceso de recuperación ante desastres para validar y mejorar el plan.
Conocer los roles clave necesarios para la coordinación de DR
Asegúrese de que los esfuerzos de recuperación ante desastres estén bien coordinados y de que se dé prioridad a las aplicaciones en función del valor de negocio.
Prepararse para el fallo de la aplicación
Prepárese para una serie de fallos, incluidos los que se manejan automáticamente, los que dan como resultado una funcionalidad reducida y los que hacen que la aplicación deje de estar disponible. La aplicación debe informar a los usuarios de los problemas temporales.
Recuperación de datos dañados
Si se produce un fallo en un almacén de datos, compruebe si hay inconsistencias de datos cuando el almacén vuelva a estar disponible, especialmente si los datos se han replicado. Restaurar datos dañados a partir de una copia de seguridad.
Recuperarse de una interrupción de red
Es posible que pueda utilizar datos almacenados en caché para ejecutarlos localmente con una funcionalidad de aplicación reducida. De lo contrario, considere el tiempo de inactividad de la aplicación o la conmutación por error a otra región. Almacene los datos en una ubicación alternativa hasta que se restaure la conectividad.
Recuperación de un fallo de servicio dependiente
Determine qué funcionalidad aún está disponible y cómo debe responder la aplicación.
Recuperación de una interrupción del servicio en toda la región
Las interrupciones del servicio en toda la región son poco comunes, pero debe contar con una estrategia para abordarlas, especialmente para aplicaciones críticas. Es posible que pueda volver a desplegar la aplicación en otra región o redistribuir el tráfico.
Aprender de las pruebas de DR y mejorar los procesos
Asegúrese de que se capturen los problemas detectados durante las pruebas de DR y de que los planes para solucionarlos se aborden en pruebas o failovers futuras.