En este documento del Google Cloud framework de Well-Architected: perspectiva de servicios financieros (FS) se proporciona una descripción general de los principios y las recomendaciones para diseñar, implementar y operar cargas de trabajo de FS confiables en Google Cloud. En el documento, se explora cómo integrar prácticas avanzadas de confiabilidad y observabilidad en tus planos de arquitectura. Las recomendaciones de este documento se alinean con el pilar de confiabilidad del framework de Well-Architected.
Para las instituciones financieras, una infraestructura confiable y resiliente es una necesidad empresarial y un imperativo regulatorio. Para garantizar que las cargas de trabajo de FS en Google Cloud sean confiables, debes comprender y mitigar los posibles puntos de falla , implementar recursos de forma redundante y planificar la recuperación. La resiliencia operativa es un resultado de la confiabilidad. Es la capacidad de absorber interrupciones, adaptarse a ellas y recuperarse de ellas. La resiliencia operativa ayuda a las organizaciones de FS a cumplir con los estrictos requisitos reglamentarios. También ayuda a evitar daños intolerables a los clientes.
Los componentes básicos clave de la confiabilidad en Google Cloud son las regiones, las zonas y los diversos alcances de ubicación de los recursos de la nube: zonal, regional, multirregional y global. Puedes mejorar la disponibilidad mediante el uso de servicios administrados, la distribución de recursos, la implementación de patrones de alta disponibilidad y la automatización de procesos.
Requisitos reglamentarios
Las organizaciones de FS operan bajo estrictos mandatos de confiabilidad de agencias reguladoras como el Sistema de la Reserva Federal en EE.UU., la Autoridad Bancaria Europea en la UE y la Autoridad de Regulación Prudencial en el Reino Unido. A nivel mundial, los reguladores enfatizan la resiliencia operativa, que es fundamental para la estabilidad financiera y la protección del consumidor. La resiliencia operativa es la capacidad de resistir las interrupciones, recuperarse de manera eficaz y mantener los servicios críticos. Esto requiere un enfoque armonizado para administrar los riesgos tecnológicos y las dependencias de terceros.
Los requisitos reglamentarios en la mayoría de las jurisdicciones tienen los siguientes temas comunes:
- Ciberseguridad y resiliencia tecnológica: Fortalecimiento de las defensas contra las ciberamenazas y garantía de la resiliencia de los sistemas de TI.
- Administración de riesgos de terceros: Administración de los riesgos asociados con la externalización de servicios a proveedores de tecnología de la información y la comunicación (TIC).
- Continuidad empresarial y respuesta ante incidentes: Planificación sólida para mantener las operaciones críticas durante las interrupciones y recuperarse de manera eficaz.
- Protección de la estabilidad financiera: Garantizar la solidez y la estabilidad del sistema financiero general.
Las recomendaciones de confiabilidad de este documento se asignan a los siguientes principios básicos:
- Prioriza las implementaciones multizona y multirregión.
- Elimina los puntos únicos de fallo (SPOFs).
- Comprende y administra la disponibilidad agregada.
- Implementa una estrategia de DR sólida.
- Aprovecha los servicios administrados.
- Automatiza los procesos de aprovisionamiento y recuperación de la infraestructura.
Prioriza las implementaciones multizona y multirregión
Para las aplicaciones de servicios financieros críticos, te recomendamos que uses una topología multirregión que se distribuya en al menos dos regiones y en tres zonas dentro de cada región. Este enfoque es importante para la resiliencia ante las interrupciones zonales y regionales. Las reglamentaciones suelen prescribir este enfoque, ya que, si se produce una falla en una zona o región, la mayoría de las jurisdicciones consideran que una interrupción grave en una segunda zona es una consecuencia plausible. La lógica es que, cuando falla una ubicación, la otra puede recibir una cantidad excepcionalmente alta de tráfico adicional.
Considera las siguientes recomendaciones para generar resiliencia ante las interrupciones zonales y regionales:
- Prefiere los recursos que tengan un alcance de ubicación más amplio. Cuando sea posible, usa recursos regionales en lugar de zonales, y usa recursos multirregionales o globales en lugar de recursos regionales. Este enfoque ayuda a evitar la necesidad de restablecer las operaciones mediante copias de seguridad.
- En cada región, aprovecha tres zonas en lugar de dos. Para controlar las conmutaciones por error, aprovisiona en exceso la capacidad en un tercio más que la estimación.
- Minimiza los pasos de recuperación manual mediante la implementación de implementaciones activo-activo como los siguientes ejemplos:
- Las bases de datos distribuidas, como Spanner, proporcionan redundancia y sincronización integradas en todas las regiones.
- La función de HA de Cloud SQL proporciona una topología casi activo-activo, con réplicas de lectura en todas las zonas. Proporciona un objetivo de punto de recuperación (RPO) entre regiones que está cerca de 0.
- Distribuye el tráfico de usuarios en todas las regiones mediante Cloud DNS y, luego, implementa un balanceador de cargas regional en cada región. Un balanceador de cargas global es otra opción que puedes considerar según tus requisitos y la criticidad. Si deseas obtener más información, consulta Beneficios y riesgos del balanceo de cargas global para implementaciones multirregionales.
- Para almacenar datos, usa servicios multirregionales como Spanner y Cloud Storage.
Elimina los puntos únicos de fallo
Distribuye los recursos en diferentes ubicaciones y usa recursos redundantes para evitar que cualquier punto único de fallo (SPOF) afecte a toda la pila de aplicaciones.
Considera las siguientes recomendaciones para evitar los SPOFs:
- Evita implementar un solo servidor de aplicaciones o base de datos.
- Asegúrate de que se vuelvan a crear automáticamente las VMs con errores mediante el uso de grupos de instancias administrados (MIGs).
- Distribuye el tráfico de manera uniforme entre los recursos disponibles mediante la implementación del balanceo de cargas.
- Usa configuraciones de HA para bases de datos como Cloud SQL.
- Mejora la disponibilidad de los datos mediante el uso de discos persistentes regionales con replicación síncrona.
Si deseas obtener más información, consulta Diseña una infraestructura confiable para las cargas de trabajo en Google Cloud.
Comprende y administra la disponibilidad agregada
Ten en cuenta que la disponibilidad general o agregada de un sistema se ve afectada por la disponibilidad de cada nivel o componente del sistema. La cantidad de niveles en una pila de aplicaciones tiene una relación inversa con la disponibilidad agregada de la pila. Considera las siguientes recomendaciones para administrar la disponibilidad agregada:
Para calcular la disponibilidad agregada de una pila de varios niveles, usa la fórmula disponibilidad_nivel1 × disponibilidad_nivel2 × disponibilidad_nivelN.
En el siguiente diagrama, se muestra el cálculo de la disponibilidad agregada para un sistema de varios niveles que consta de cuatro servicios:
En el diagrama anterior, el servicio de cada nivel proporciona una disponibilidad del 99.9%, pero la disponibilidad agregada del sistema es inferior al 99.6% (0.999 × 0.999 × 0.999 × 0.999). En general, la disponibilidad agregada de una pila de varios niveles es inferior a la disponibilidad del nivel que proporciona la menor disponibilidad.
Cuando sea posible, elige la paralelización en lugar del encadenamiento. Con los servicios paralelizados, la disponibilidad de extremo a extremo es mayor que la disponibilidad de cada servicio individual.
En el siguiente diagrama, se muestran dos servicios, A y B, que se implementan con los enfoques de encadenamiento y paralelización:
En los ejemplos anteriores, ambos servicios tienen un ANS del 99%, lo que genera la siguiente disponibilidad agregada según el enfoque de implementación:
- Los servicios encadenados producen una disponibilidad agregada de solo el 98% (.99 × .99).
- Los servicios paralelizados producen una disponibilidad agregada más alta del 99.99% porque cada servicio se ejecuta de forma independiente y los servicios individuales no se ven afectados por la disponibilidad de los otros servicios. La fórmula para los servicios paralelizados agregados es 1 − (1 − A) × (1 − B).
Elige Google Cloud servicios con ANS de tiempo de actividad que puedan ayudar a cumplir con el nivel requerido de tiempo de actividad general para tu pila de aplicaciones.
Cuando diseñes tu arquitectura, considera las concesiones entre la disponibilidad, la complejidad operativa, la latencia y el costo. Aumentar la cantidad de nueves de disponibilidad suele costar más, pero hacerlo te ayuda a cumplir con los requisitos reglamentarios.
Por ejemplo, una disponibilidad del 99.9% (tres nueves) significa un posible tiempo de inactividad de 86 segundos en un día de 24 horas. Por el contrario, el 99% (dos nueves) significa un tiempo de inactividad de 864 segundos durante el mismo período, que es 10 veces más tiempo de inactividad que con tres nueves de disponibilidad.
Para los servicios financieros críticos, las opciones de arquitectura pueden ser limitadas. Sin embargo, es fundamental identificar los requisitos de disponibilidad y calcularla con precisión. Realizar esta evaluación te ayuda a evaluar las implicaciones de tus decisiones de diseño en tu arquitectura y presupuesto.
Implementa una estrategia de DR sólida
Crea planes bien definidos para diferentes situaciones de desastre, incluidas las interrupciones zonales y regionales. Una estrategia de recuperación ante desastres (DR) bien definida te permite recuperarte de una interrupción y reanudar las operaciones normales con un impacto mínimo.
DR y alta disponibilidad (HA) son conceptos diferentes. Con las implementaciones en la nube, en general, la DR se aplica a las implementaciones multirregionales y la HA se aplica a las implementaciones regionales. Estos arquetipos de implementación admiten diferentes mecanismos de replicación.
- HA: Muchos servicios administrados proporcionan replicación síncrona entre zonas dentro de una sola región de forma predeterminada. Estos servicios admiten un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) de cero o casi cero. Esta compatibilidad te permite crear una topología de implementación activo-activo que no tenga ningún SPOF.
- DR: Para las cargas de trabajo que se implementan en dos o más regiones, si no usas servicios multirregionales o globales, debes definir una estrategia de replicación. Por lo general, la estrategia de replicación es asíncrona. Evalúa con atención cómo afecta esta replicación al RTO y al RPO de las aplicaciones críticas. Identifica las operaciones manuales o semiautomatizadas que son necesarias para la conmutación por error.
Para las instituciones financieras, la elección de la región de conmutación por error puede estar limitada por las reglamentaciones sobre la soberanía y la residencia de los datos. Si necesitas una topología activo-activo en dos regiones, te recomendamos que elijas servicios multirregionales administrados, como Spanner y Cloud Storage, en especial cuando la replicación de datos es fundamental.
Ten en cuenta las siguientes recomendaciones:
- Usa servicios de almacenamiento multirregionales administrados para los datos.
- Toma instantáneas de los datos en discos persistentes y almacénalas en ubicaciones multirregionales.
- Cuando uses recursos regionales o zonales, configura la replicación de datos en otras regiones.
- Para validar que tus planes de DR sean eficaces, pruébalos con regularidad.
- Ten en cuenta el RTO y el RPO, y su correlación con la tolerancia al impacto que estipulan las reglamentaciones financieras en tu jurisdicción.
Si deseas obtener más información, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube.
Aprovecha los servicios administrados
Siempre que sea posible, usa servicios administrados para aprovechar las funciones integradas de copias de seguridad, HA y escalabilidad. Considera las siguientes recomendaciones para usar servicios administrados:
- Usa servicios administrados en Google Cloud. Proporcionan HA respaldada por ANS. También ofrecen mecanismos de copia de seguridad integrados y funciones de resiliencia.
- Para la administración de datos, considera servicios como Cloud SQL, Cloud Storage, y Spanner.
- Para el procesamiento y el alojamiento de aplicaciones, considera los grupos de instancias administrados (MIGs) de Compute Engine y los clústeres de Google Kubernetes Engine (GKE). Los MIGs regionales y los clústeres regionales de GKE son resilientes a las interrupciones zonales.
- Para mejorar la resiliencia ante las interrupciones regionales, usa servicios multirregionales administrados.
- Identifica la necesidad de planes de salida para los servicios que tienen características únicas y define los planes requeridos. Los reguladores financieros, como la FCA, la PRA y la EBA, exigen que las empresas tengan estrategias y planes de contingencia para la recuperación de datos y la continuidad operativa si finaliza la relación con un proveedor de servicios en la nube. Las empresas deben evaluar la viabilidad de la salida antes de celebrar contratos de nube y deben mantener la capacidad de cambiar de proveedor sin interrupciones operativas.
- Verifica que los servicios que elijas admitan la exportación de datos a un formato abierto como CSV, Parquet y Avro. Verifica si los servicios se basan en tecnologías abiertas, como la compatibilidad de GKE con el formato de Open Container Initiative (OCI) o Cloud Composer compilado en Apache Airflow.
Automatiza los procesos de aprovisionamiento y recuperación de la infraestructura
La automatización ayuda a minimizar los errores humanos y a reducir el tiempo y los recursos necesarios para responder a los incidentes. El uso de la automatización puede ayudar a garantizar una recuperación más rápida ante fallas y resultados más coherentes. Considera las siguientes recomendaciones para automatizar la forma en que aprovisionas y recuperas recursos:
- Minimiza los errores humanos mediante el uso de herramientas de infraestructura como código (IaC), como Terraform.
- Reduce la intervención manual mediante la automatización de los procesos de conmutación por error. Las respuestas automatizadas también pueden ayudar a reducir el impacto de las fallas. Por ejemplo, puedes usar Eventarc o Workflows para activar automáticamente acciones correctivas en respuesta a los problemas observados a través de los registros de auditoría.
- Aumenta la capacidad de tus recursos de nube durante la conmutación por error mediante el uso del ajuste de escala automático.
- Aplica automáticamente políticas y protecciones para los requisitos reglamentarios en toda tu topología de nube durante la implementación del servicio mediante la adopción de la ingeniería de plataformas.