Unidad 2.4: Arquitectura de costos y FinOps

Introducción

El costo de la nube en IONOS CLOUD no es un problema de facturación que se resuelve a posteriori; es una propiedad arquitectónica que se decide en el momento del diseño, cuando se elige una clase de cómputo, un nivel de almacenamiento, una estrategia de escalado y un plazo de compromiso. Cada uno de estos elementos es una palanca, y difieren enormemente en magnitud: la elección de contención de cómputo puede modificar la factura más que todas las ajustes de los paneles de control combinados. Por lo tanto, FinOps en este contexto es en gran medida arquitectura, con una capa operativa delgada de asignación y alertas por encima. Esta unidad recorre las palancas en orden de impacto, establece cómo los Savings Plans comprometen el gasto de manera correcta, y termina construyendo la única barrera de protección bien documentada, una alerta de costos, en el Data Center Designer.

1. Contención de cómputo: la primera palanca de costos

La decisión de costo individual más importante es cómo una carga de trabajo comparte la CPU física. Compute Engine ofrece dos clases de uso de CPU: servidores Dedicated Core, donde el núcleo es Exclusivo para la VM, y servidores vCPU, donde el núcleo está Compartido con otros inquilinos. Los núcleos compartidos son más económicos y son adecuados para cargas de trabajo intermitentes, tolerantes a la latencia o no productivas. Los núcleos exclusivos cuestan más y son adecuados cuando el rendimiento debe ser predecible o cuando el aislamiento es en sí mismo un requisito, lo cual es frecuente en un entorno regulado.

Aquí es donde la sobreprovisión deliberada se convierte en un costo de control justificado en lugar de un desperdicio. Para los hosts regulados dentro del alcance de FinCorp, la tenencia única y el rendimiento predecible son entradas de cumplimiento y de riesgo, por lo que pagar por núcleos dedicados (y provisionar margen por encima de la línea base medida) compra aislamiento y estabilidad que un ahorro por núcleos compartidos comprometería. La disciplina consiste en ser deliberado: sobreprovisionar los hosts que tienen obligaciones de cumplimiento o de rendimiento, y usar núcleos compartidos en todos los lugares donde la carga de trabajo tolere la contención. Tenga en cuenta también que VM Auto Scaling crea nuevas réplicas a partir de una plantilla de réplica de tiempo de diseño, por lo que una capa que debe escalar automáticamente tiene su forma de cómputo por réplica, y por lo tanto su costo por réplica, fija en el tiempo de diseño, lo que integra la decisión de elasticidad en la decisión de costos.

2. Jerarquización del almacenamiento según el patrón de acceso

El costo del almacenamiento se determina al ajustar la jerarquía al patrón de acceso, y las tres jerarquías de almacenamiento en bloque tienen puntos de precio sustancialmente diferentes. Los precios publicados por GB y mes son:

Dos restricciones determinan la elección más allá del precio. En primer lugar, el umbral de rendimiento de SSD: tanto los volúmenes SSD Standard como SSD Premium requieren un tamaño mínimo de 100 GB para alcanzar el rendimiento completo. Por lo tanto, un volumen SSD de tamaño insuficiente paga precios de SSD sin ofrecer el rendimiento de SSD, lo cual es un desperdicio común y evitable en discos de bases de datos. En segundo lugar, el almacenamiento en bloque no es el lugar adecuado para datos masivos o de archivo; Object Storage es la jerarquía correcta para copias de seguridad, archivos de auditoría, conjuntos de datos y datos fríos, y es donde se encuentra el archivo Object-Lock de la Unidad 2.3. El patrón consiste en colocar los datos activos y sensibles a la latencia en SSD de tamaño adecuado, los datos de capacidad en HDD y todo lo que sea masivo o de archivo en Object Storage.

3. Escalado vertical frente a escalado horizontal basado en caché para la capa de datos

La capa de datos presenta una estructura de costos distintiva porque la plataforma no cuenta con réplicas de lectura (Unidad 1.3 y Módulo 5). Las dos formas de gestionar la carga de lectura creciente tienen economías muy diferentes. El escalado vertical consiste en adquirir una instancia de base de datos más grande, lo que aumenta un costo predecible y permanente, y eventualmente alcanza límites máximos. El escalado horizontal de lecturas consiste en colocar una caché en memoria frente a la capa relacional y absorber el tráfico de lecturas allí, lo cual suele ser mucho más económico por lectura atendida y protege a la base de datos de ser dimensionada en exceso únicamente para manejar picos de lectura. Para la mayoría de las cargas de trabajo de FinCorp con alta intensidad de lecturas, una base de datos bien dimensionada junto con una capa de caché tiene un costo menor que una base de datos permanentemente escalada verticalmente, y también es la única vía de escalado horizontal de lecturas que la plataforma ofrece. La lección en cuanto a costos es dimensionar la base de datos según sus necesidades de escritura y conjunto de trabajo, y permitir que la caché, no una instancia más grande, absorba el crecimiento de las lecturas.

4. Savings Plans: Comprometer el mínimo correctamente

Un Savings Plan es un compromiso basado en recursos que intercambia un plazo fijo por un descuento en servidores Compute Engine Dedicated Core, grupos de nodos Managed Kubernetes Dedicated Core y Nextcloud Workspace, cubriendo las dimensiones de núcleos y RAM (GB). La economía es precisa:

Varias reglas hacen que esto sea seguro solo si usted las respeta. Un plan reserva facturación, no capacidad física, por lo que nunca bloquea la aprovisionamiento. El exceso se maneja de forma adecuada: el uso por encima de la cantidad comprometida se factura a la tarifa estándar de pago por uso, por lo que el sobrecompromiso es el único riesgo real. Cuando varios planes cubren el mismo producto, se aplican en orden de antigüedad (cronológicamente por creación), y dentro de un producto, el descuento se aplica primero a la VM más antigua. La familia de CPU AMD Opteron está excluida. Un plan no se renueva automáticamente, y solo el propietario del contrato puede comprarlo.

El hecho operativo más importante es que un Savings Plan no puede editarse después de la activación; el único campo editable es el nombre del plan, y no puede cancelarse después de la compra. Esto convierte el compromiso en una decisión de un solo sentido, y dicta la disciplina: comprometer el mínimo. Comprometa solo la línea base de estado estable de la que usted está seguro de que se ejecutará durante todo el plazo, asuma el exceso de pago por uso para todo lo que esté por encima de ella, y alargue el plazo solo para la capacidad de la que usted tiene confianza de que persiste durante tres años. Comprometerse de manera optimista con el uso pico fija un gasto que no puede reducirse; comprometer el mínimo captura el descuento en el uso garantizado, mientras deja la carga variable en el pago por uso flexible.

5. Asignación, Showback y Chargeback

La asignación de costos se basa en la estructura de la Unidad 2.1. Dado que cada VDC ya genera su propia sección en la factura mensual, la jerarquía de contrato y VDC es el eje principal de asignación: un contrato agrupa un ámbito de gobernanza y facturación, y los VDC dentro de él separan entornos o proyectos en líneas de factura distintas. La vista de Costos y Uso en el DCD es la superficie de análisis para esto, y existe una API de Costos y Uso para alimentar los flujos de trabajo de facturación de forma programática.

La asignación admite dos modelos operativos. Showback informa a cada equipo o proyecto su parte de los costos para garantizar visibilidad y responsabilidad, sin mover dinero. Chargeback factura efectivamente el costo de vuelta a la unidad consumidora. Showback es el punto de partida más ligero y suele ser suficiente para cambiar el comportamiento; chargeback añade aplicación financiera a cambio de más mecanismos de facturación. Para FinCorp, mapear VDC a proyectos de modo que cada uno aparezca en su propia línea de factura proporciona un showback limpio de inmediato, con chargeback superpuesto después si finanzas lo requiere. (Considere el panel de control y la navegación de asignación como la capa de análisis; la construcción a continuación es la salvaguarda de alertas de costos, que es la ruta de creación bien documentada.)

Guía de implementación de DCD

Creará una alerta de costos que envía un correo electrónico a un destinatario cuando el gasto contractual supera un umbral presupuestario. Esta es la única construcción de costos bien documentada; es la barrera operativa que respalda las palancas arquitectónicas anteriores. El requisito previo es el acceso como propietario del contrato o administrador, ya que solo esos roles pueden crear alertas de costos. Tenga en cuenta que la alerta se configura a nivel de contrato (un monto y un correo electrónico), por lo que la asignación entre VDC es una cuestión de informes que se gestiona en la vista Cost & Usage, no en la propia alerta.

Objetivo de la construcción: Crear una alerta de costos frente a un umbral presupuestario.

Pasos (en Data Center Designer):

1. Vaya a Menú > Management > Cost alert. Se abre la ventana Cost alert; esta vista también enumera las alertas existentes.
2. Seleccione Create cost alert.
3. En el cuadro de diálogo, introduzca el monto (el umbral de gasto para el contrato) y la dirección de correo electrónico que debe ser notificada.
4. Seleccione Create cost alert para confirmar. La alerta ahora está activa y enviará un correo electrónico al destinatario una vez que el gasto contractual supere el umbral.

Errores comunes:

• Esperar que la alerta limite o detenga el gasto. Solo notifica; es un disparador, no una aplicación estricta del presupuesto. El gasto continúa más allá del umbral.
• Configurarla por VDC. La alerta de costos es a nivel de contrato (monto más correo electrónico); use la vista Cost & Usage para el análisis y la asignación por VDC.
• Confiar en las alertas en lugar de en la arquitectura. La alerta detecta la desviación; las decisiones sobre la clase de cómputo, la capa de almacenamiento y el Savings Plan son las que realmente determinan la factura.
• Dirigir la alerta a una bandeja de entrada personal. Envíela a una dirección de finanzas u operaciones supervisada para que la notificación sea vista y atendida.

Patrón de arquitectura

Una arquitectura de costos de FinCorp defendible organiza los mecanismos de control por impacto. En la base, la clase de cómputo se elige por nivel: núcleos dedicados para los niveles regulados dentro del alcance y los niveles con escalado automático (con un margen intencional como costo justificado de control), y núcleos compartidos para cargas de trabajo tolerantes y no productivas. El almacenamiento se estratifica según el patrón de acceso, manteniendo los volúmenes SSD en o por encima del umbral de 100 GB y los datos masivos o de archivo en Object Storage. El nivel de datos se dimensiona para escrituras y el conjunto de trabajo, con una caché en memoria que absorbe el crecimiento de lecturas en lugar de una base de datos sobredimensionada. Sobre esto, un Savings Plan compromete solo el nivel estable de núcleos dedicados y la base de RAM, con un plazo ajustado a la persistencia genuina, tomando el desbordamiento PAYG por encima de ese nivel. En la parte superior, la asignación vincula los VDC a proyectos para showback, y una alerta de costos a nivel de contrato proporciona el disparador de desviación. Como cifra de ejemplo, un nivel que opera con 32 núcleos dedicados estables costaría aproximadamente 1,28 EUR por hora con PAYG (32 x 0,04); comprometer ese nivel en un plan de 3 años reduce la tarifa de los núcleos a aproximadamente 0,77 EUR por hora (32 x 0,024), una reducción del 40% sobre la línea base garantizada, mientras que cualquier pico por encima de 32 núcleos sigue facturándose con PAYG.

Resumen

El costo de la nube en IONOS CLOUD se diseña, no se limita a monitorear. La clase de contención de cómputo es el palanca más importante, y el aprovisionamiento deliberado en exceso de los hosts dentro del alcance se justifica como un costo de control; el almacenamiento se estratifica según el patrón de acceso dentro del umbral de rendimiento de SSD; y la capa de datos escala las lecturas mediante una caché en lugar de una instancia sobredimensionada. Los Savings Plan capturan descuentos por plazo del 15% (1 año) y del 40% (3 años) en núcleos dedicados y RAM, pero no pueden editarse después de la activación, lo que exige comprometer solo el umbral seguro y asumir el exceso bajo el modelo PAYG. La asignación se apoya en la estructura de contrato y VDC para showback o chargeback, y una alerta de costo a nivel de contrato proporciona el disparador operativo incorporado en el DCD.

Puntos clave:

• La contención de cómputo es la primera palanca de costo: los núcleos compartidos son más baratos, mientras que los núcleos exclusivos (dedicados) compran predictibilidad y aislamiento; el autoescalado fija la forma de cómputo de cada réplica en el momento del diseño, integrando la elasticidad en la decisión de costo.
• Estratifique el almacenamiento según el patrón de acceso: HDD 0,04, SSD Standard 0,07, SSD Premium 0,15 EUR/GB/mes; mantenga los volúmenes SSD en o por encima del umbral de rendimiento completo de 100 GB; coloque los datos masivos y de archivo en Object Storage.
• Escale las lecturas de la capa de datos con una caché en memoria, no con una base de datos sobredimensionada, ya que no hay réplicas de lectura.
• Los Savings Plan ofrecen descuentos del 15% (1 año) y del 40% (3 años) en núcleos dedicados y RAM, el exceso se factura bajo PAYG, los planes se aplican en orden de antigüedad y no pueden editarse después de la activación, por lo que solo debe comprometerse el umbral seguro.
• Asigne por contrato y VDC (cada VDC ya se factura como su propia línea); elija entre showback o chargeback; una alerta de costo a nivel de contrato (monto más correo electrónico) es la barrera de contención en el momento de la construcción y solo notifica, no limita el gasto.

Terminología importante:

• Clase de uso de CPU: Si los núcleos de un servidor son exclusivos (Dedicated Core) o compartidos (vCPU); la palanca principal de costo y rendimiento de cómputo.
• Savings Plan: Un compromiso de facturación de 1 o 3 años basado en recursos para núcleos dedicados y RAM, con exceso bajo PAYG, no editable después de la activación y solo comprable por el propietario del contrato.
• Showback / Chargeback: Informar a un equipo su parte de costo por responsabilidad (showback) frente a facturarle efectivamente el costo (chargeback).
• Alerta de costo: Un umbral a nivel de contrato (monto más correo electrónico) que notifica sobre el exceso de gasto; advierte, pero no limita.