Verificación de conocimientos - Datos y almacenamiento
El portal de clientes de FinCorp sirve vistas de resumen de cuenta e historial de transacciones que se leen con mucha más frecuencia de la que se escriben, todo desde un clúster regulado de Managed PostgreSQL en la capa de datos privados. Un arquitecto propone agregar réplicas de lectura a ese clúster y dirigir el tráfico de informes a un standby. ¿Por qué este es el punto de partida equivocado y cuál es el patrón nativo?
Los standby de Managed PostgreSQL existen para la alta disponibilidad, no para servir tráfico de lectura; no hay réplicas de lectura ni un punto de acceso de solo lectura administrado. El patrón nativo reemplaza la función que falta con una caché de In-Memory DB frente a la capa relacional (la mitad de lectura del patrón sin réplicas de lectura) más el pooler pgbouncer administrado. Las opciones incorrectas inventan un modo que otorga escalabilidad de lectura, malinterpretan el recuento de instancias y malusan las instantáneas, que son imágenes de bloques consistentes ante fallos, no una fuente consistente a nivel de base de datos.
Un arquitecto está diseñando la continuidad de datos para el entorno de FinCorp, que incluye VM migradas, volúmenes de Block Storage, un clúster de Managed PostgreSQL y un clúster de Managed MongoDB. Un compañero de equipo propone un plan único: instalar el agente de Backup Service basado en Acronis en todas las ubicaciones, incluidos los hosts de las bases de datos, para que una sola consola cubra todo el entorno. ¿Cuál es el defecto decisivo?
El límite más importante del módulo es que Backup Service no realiza copias de seguridad de bases de datos administradas; la continuidad de la base de datos se entrega dentro de cada servicio de base de datos mediante PITR y volcado lógico/restauración. Las opciones incorrectas son erróneas en los hechos: la variante de agente externo sí protege VM en las instalaciones y en otras nubes, Backup Service no ofrece copias de seguridad inmutables (la inmutabilidad es una propiedad de bloqueo de objetos de Object Storage) y la clase de almacenamiento no hace que una base de datos sea protegible por el agente.
FinCorp debe mantener su archivo de auditoría de varios años en Object Storage como retención a prueba de manipulación, de solo escritura, que ni siquiera un administrador de contrato pueda acortar o eliminar antes de la fecha de retención. El arquitecto aprovisiona un bucket propiedad de un contrato en una región de Alemania, sube las primeras exportaciones y luego intenta habilitar Object Lock en modo COMPLIANCE. La consola no ofrece ninguna opción para activarlo. ¿Qué salió mal y cuál es el diseño correcto?
Object Lock solo se puede habilitar al crear el bucket y nunca se puede agregar después, y habilitarlo también activa el versionado, y ninguno de los dos es reversible; el modo COMPLIANCE hace que el objeto sea inmutable hasta su fecha de retención, y el período no puede acortarse por nadie. Las opciones incorrectas invierten la relación con el versionado, inventan una ruta solo de API que aún permite la incorporación posterior, e inventan una actualización de GOVERNANCE a COMPLIANCE que no existe.
La transmisión de transacciones de alto volumen de FinCorp fluye a través de Event Streams for Apache Kafka. El requisito es que todos los eventos de una cuenta dada se procesen en el orden en que ocurrieron, mientras que las cuentas diferentes se procesan de forma concurrente, y que las particiones se distribuyan de manera uniforme entre los tres brokers del clúster. ¿Qué diseño de tema satisface las tres restricciones al mismo tiempo?
El orden en Kafka es por partición, por lo que usar el identificador de la cuenta como clave coloca los eventos de cada cuenta en una sola partición, lo que proporciona un orden estricto por clave con concurrencia entre claves; la cantidad de particiones también es el límite superior fijo del paralelismo de los consumidores, y usar un múltiplo de los tres brokers (3, 6, 9) mantiene la distribución uniforme. Una sola partición serializa todas las cuentas y limita el paralelismo a un solo consumidor, 5 no es un múltiplo de tres y abandona el orden por cuenta, e inflar las particiones de forma especulativa multiplica los manejos de archivos, el tráfico de replicación y el tiempo de reequilibrio.
Las bases de datos administradas de FinCorp no exponen un flujo de captura de cambios (change-data-capture) al que los sistemas aguas abajo puedan suscribirse, y sin embargo, el almacén de analítica, el modelo de detección de fraude y un índice de búsqueda necesitan reaccionar a cada cambio. La arquitectura también debe permitir que la capa de IA vuelva a leer el historial de cambios desde una posición confirmada cuando se reentrene un modelo. ¿Qué enfoque es el sustituto nativo en IONOS CLOUD?
Dado que las bases de datos administradas de IONOS CLOUD no exponen ningún flujo de captura de cambios (change-data-capture) suscribible, el patrón nativo invierte la dependencia: la aplicación publica un evento de dominio en Kafka a medida que realiza el cambio, y cada sistema aguas abajo consume ese tema, con grupos de consumidores que rastrean sus propios desplazamientos, de modo que la capa de IA pueda reproducir desde una posición confirmada. Seguir el WAL no es un flujo suscribible admitido, comparar volcados es lento y con pérdida de datos, y MongoDB no tiene replicación de flujos de cambios administrada a un segundo clúster.
FinCorp necesita una copia a largo plazo, con evidencia de manipulación, de sus datos de Managed PostgreSQL que sobreviva fuera del clúster y pueda conservarse durante años, de forma independiente a la ventana de recuperación en un punto en el tiempo de 7 días del propio clúster. ¿Qué composición cumple con esto respetando los límites de la plataforma?
PITR está limitado por una ventana y vinculado al almacén de copias de seguridad propio del clúster, por lo que la copia portátil y a largo plazo proviene de un volcado lógico (pg_dump) enviado a Object Storage, donde el bloqueo de objetos en modo COMPLIANCE añade la evidencia de manipulación que el servicio de base de datos no proporciona por sí mismo. Extender PITR mantiene la copia no portátil y vinculada al clúster, las instantáneas son imágenes de bloques consistentes ante fallos y no copias de seguridad consistentes con la base de datos, y Backup Service no realiza copias de seguridad de bases de datos administradas en absoluto.