Volumetrías de referencia

Anjana Data Platform (ADP) necesita cinco servicios que no forman parte de la plataforma y que usted debe contratar y operar si elige tener ADP en modalidad “On Premise/Self Hosted: PostgreSQL, MongoDB, Valkey, RabbitMQ y almacenamiento de objetos (S3).

Esta página le dice qué contratar. No necesita hacer cálculos: identifique su situación en el paso 1 y lea las tablas del paso 2.

Paso 1. Identifique su perfil

Elija la fila que mejor describa su situación actual o prevista para los próximos 12 meses.

Dos advertencias importantes al elegir:

No use la plantilla de su organización como referencia. Lo que cuenta son las personas que van a usar la plataforma de forma habitual, no las que teóricamente tendrían acceso. Una organización de 60.000 empleados que abre la plataforma de gobierno y Marketplace a toda la plantilla suele tener unos pocos miles de usuarios habituales, no 60.000. Dimensionar sobre la cifra teórica multiplica el coste sin ningún beneficio.

Si duda entre dos perfiles, elija el mayor. La diferencia de coste entre perfiles contiguos es pequeña y le evita una ampliación temprana.

Paso 2. Contrate según su perfil

Anjana recomienda contratar estos servicios en modalidad gestionada con su proveedor de nube (no instalarlos y mantenerlos usted). Obtiene soporte del fabricante, parcheo de seguridad, copias de seguridad automáticas y sustitución automática de nodos averiados. Esta es, con diferencia, la recomendación de mayor impacto de esta página: para una plataforma de esta criticidad, el valor está en no tener que operar la base de datos, más que en la redundancia.

La instalación propia está soportada por ADP, pero el mantenimiento queda íntegramente de su lado.

MongoDB

Sobre los 3 nodos. No es una recomendación de alta disponibilidad, sino la unidad mínima con la que trabajan los servicios gestionados de MongoDB: un despliegue de 2 nodos pierde la capacidad de escritura ante la caída de cualquiera de ellos, por lo que no es una opción intermedia real. En entornos de desarrollo, preproducción y en el perfil XS, un solo nodo es perfectamente válido.

Sobre el disco. Es muy superior al volumen de datos real de forma deliberada: debe alojar los registros de replicación, los diarios de transacciones, los logs y el espacio temporal de las operaciones de mantenimiento. No lo reduzca.

Sobre la memoria. ADP almacena en MongoDB un volumen de datos pequeño, de unos cientos de megabytes incluso en despliegues extensos. La memoria de la tabla no responde al volumen de datos, sino a las conexiones concurrentes y a los mínimos habituales del mercado. No necesita ampliarla porque crezca su catálogo.

PostgreSQL

PostgreSQL es la base de datos transaccional del núcleo de ADP: autorización de usuarios, motor de workflows, catálogo de activos, búsqueda y auditoría, consola de administración y acuerdos de intercambio de datos. Junto con MongoDB, es el componente cuya indisponibilidad afecta directamente a la consulta del catálogo y a los flujos de gobierno.

Sobre el standby. A partir del perfil S, active la réplica síncrona (Multi-AZ): a diferencia de MongoDB, PostgreSQL solo necesita un segundo nodo para lograr conmutación automática sin perder capacidad de escritura.

Sobre el disco. Igual que en Mongo, el arranque en 20 GB con autoescalado a 50 GB es intencionadamente holgado: el volumen de datos real de ADP en Postgres es pequeño incluso en despliegues extensos.

Sobre la memoria. La memoria de la tabla responde a las conexiones concurrentes de los distintos servicios de ADP que comparten esta base de datos, no al volumen de datos — igual que en MongoDB, no la reduzca.

Valkey

Es el único de los tres servicios que crece con el número de usuarios. Antes de cerrar el tipo de instancia, compruebe que puede ampliarse al doble de memoria sin cambiar de familia ni de región: así podrá absorber el crecimiento de usuarios sin migrar el servicio.

La réplica evita que una avería expulse a todos los usuarios de su sesión. Si prefiere un solo nodo por coste, es una opción admisible siempre que acepte ese efecto.

RabbitMQ

En la versión actual de ADP, RabbitMQ solo interviene al dar de alta un nuevo idioma de traducción. No participa en la operación diaria de la plataforma, por lo que su tamaño no depende del perfil.

Un solo servidor es suficiente, incluido producción: una avería solo pospone el alta de un idioma, que es una operación administrativa y planificable. Solo tiene sentido plantearse un clúster si su política corporativa exige alta disponibilidad homogénea en todos los componentes. Tenga en cuenta que los tipos de instancia más pequeños no suelen admitir clúster, por lo que esa opción implica subir de gama sin que la capacidad lo requiera.

Almacenamiento de objetos (S3)

Anjana Data Platform usa almacenamiento de objetos (S3 o equivalente) para activos de interfaz, documentos de acuerdos de intercambio de datos, ficheros importados por los conectores, contenido de texto enriquecido del catálogo, definiciones y logs de workflows, copias de seguridad y logs de plataforma.

A diferencia de los demás servicios, el almacenamiento de objetos no requiere dimensionamiento previo: escala automáticamente con el uso y se factura por consumo. No hay tabla de perfiles para este servicio.

Recomendaciones:

• Active políticas de ciclo de vida (lifecycle) en los buckets de logs y copias de seguridad, con expiración o transición a almacenamiento de menor coste, según su política de retención. Sin esta configuración, esos buckets crecen sin límite.

• Fuerce acceso solo por HTTPS/TLS.

• Active cifrado en reposo.

• Mantenga buckets separados por entorno — preproducción y producción no deben compartir bucket.

Paso 3. Aplique estas recomendaciones de configuración

Son independientes del perfil y se aplican en todos los casos.

Disponibilidad

• Reparta los nodos en dos zonas de disponibilidad. Es suficiente para ADP; no necesita una tercera.

• En producción, MongoDB, Valkey y PostgreSQL (a partir del perfil S) no deberían desplegarse en un solo nodo: participan en la operación diaria y, además de la disponibilidad, un despliegue redundante le permite aplicar mantenimientos sin interrumpir el servicio.

• Pruebe la conmutación automática antes de dar por aceptado el despliegue. No basta con configurarla.

• Las ventanas de mantenimiento fuera de horario laboral son perfectamente aceptables para ADP. No necesita contratar niveles de servicio que las eviten.

Crecimiento

• Active el escalado automático de almacenamiento en MongoDB.

• En PostgreSQL, active el escalado automático de almacenamiento, igual que en MongoDB.

• En Valkey, fije un límite de memoria explícito en torno al 75 % de la memoria del nodo y una política de expulsión. Consulte con Anjana la política concreta: la plataforma mantiene en Valkey información que no debe expulsarse.

Copias de seguridad

• MongoDB: copia diaria automática con retención de 7 días es suficiente. La recuperación a un punto en el tiempo es un extra que puede activar si su proveedor la incluye, pero ADP no la requiere: el volumen de cambios entre copias es reducido y recuperable.

• PostgreSQL: copia diaria automática con retención de 7 días es suficiente, igual que en MongoDB.

• Valkey y RabbitMQ: no requieren estrategia de copia específica.

Seguridad

• Todos los servicios en red privada, sin acceso público.

• Cifrado en tránsito (TLS) y en reposo.

• Credenciales gestionadas en un servicio de secretos, con rotación periódica.

Entornos

• Aprovisione preproducción y producción por separado. No comparta instancias de MongoDB, PostgreSQL ni de RabbitMQ entre entornos.

• En preproducción y desarrollo puede usar un solo nodo en todos los servicios.

Antes de contratar, verifique

• Que la modalidad y el tipo de instancia elegidos están disponibles en su región (no todas las opciones lo están en todas las regiones).

• Que la versión que ofrece su proveedor es compatible con su versión de ADP y no está próxima a su fin de soporte.