Unidad 2.4: Arquitectura de costes y FinOps

Introducción

El costo en la nube en IONOS no es un problema de facturación resuelto después de los hechos, sino una propiedad arquitectónica decidida en el momento del diseño, cuando usted elige una clase de cómputo, un nivel de almacenamiento, una estrategia de escalabilidad y un plazo de compromiso. Cada uno de ellos es un elemento de control, y difieren enormemente en magnitud: la elección de contenido de cómputo puede mover la factura más que todos los ajustes del panel de control combinados. FinOps aquí es por lo tanto en su mayoría arquitectura, con una delgada capa operativa de asignación y alertas en la parte superior. Esta unidad analiza los elementos de control en orden de impacto, explica cómo los Cloud Savings Plans comprometen el gasto de manera correcta, y termina construyendo el único guardrail bien documentado, una alerta de costo, en el Data Center Designer.

1. Contención de cálculo: el primer elemento de control de costes

La decisión de costes más importante es cómo un Workload comparte recursos físicos CPU. Compute Engine ofrece dos clases de uso de CPU: servidores de núcleo dedicado, donde el núcleo es Exclusivo para el VM, y servidores vCPU, donde el núcleo es Compartido con otros inquilinos. Los núcleos compartidos son más baratos y son adecuados para cargas de trabajo con picos, tolerantes a la latencia o no de producción. Los núcleos exclusivos cuestan más y son adecuados donde el rendimiento debe ser predecible o donde el aislamiento es un requisito en sí mismo, lo que en el caso de un patrimonio regulado es frecuentemente el caso.

Aquí es donde la sobreasignación deliberada se convierte en un control de costes justificado en lugar de un desperdicio. Para los hosts regulados de FinCorp, la exclusividad y el rendimiento predecible son entradas de cumplimiento y riesgo, por lo que pagar por núcleos dedicados (y provisionar espacio de cabeza por encima de la línea de base medida) compra aislamiento y estabilidad que un ahorro de núcleo compartido socavaría. La disciplina es ser deliberada: sobreasignar los hosts que llevan obligaciones de cumplimiento o rendimiento, y utilizar núcleos compartidos en todas partes donde el Workload tolere la contención. Tenga en cuenta también que VM Auto Scaling crea nuevos réplicas a partir de una plantilla de réplica de tiempo de diseño, por lo que un nivel que debe escalarse automáticamente tiene su forma de cálculo por réplica, y por lo tanto su costo por réplica, fijado en el tiempo de diseño, lo que incorpora la decisión de elasticidad en la decisión de costes.

2. Jerarquía de almacenamiento para acceso a patrones

El costo de almacenamiento se establece emparejando el nivel con el patrón de acceso, y los tres niveles de bloques tienen puntos de precio materialmente diferentes. Los precios publicados por GB al mes son:

Dos limitaciones dan forma a la elección más allá del precio. Primero, el piso de rendimiento de SSD: tanto los volúmenes SSD Estándar como SSD Premium requieren un tamaño mínimo de 100 GB para alcanzar el rendimiento completo, por lo que un SSD Volume subdimensionado paga precios SSD sin ofrecer el rendimiento SSD, lo que es un desperdicio común y evitable en discos de bases de datos. Segundo, Block Storage no es el hogar para datos bulk o de archivo; Object Storage es el nivel adecuado para copias de seguridad, archivos de auditoría, conjuntos de datos y datos fríos, y es donde vive el archivo Object-Lock de la Unidad 2.3. El patrón es poner datos calientes y sensibles a la latencia en SSD de tamaño adecuado, datos de capacidad en HDD y todo lo bulk o de archivo en Object Storage.

3. Escalada hacia arriba versus escalada basada en caché para la capa de datos

La capa de datos tiene una forma de coste distintiva porque la plataforma no tiene réplicas de lectura (Unidad 1.3 y Módulo 5). Las dos formas de manejar la creciente carga de lectura tienen economías muy diferentes. Escalar hacia arriba significa comprar una instancia de base de datos más grande, lo que aumenta un coste predecible y siempre activo y eventualmente alcanza límites. Escalar las lecturas significa colocar una caché en memoria en frente de la capa relacional y absorber el tráfico de lectura allí, lo que es típicamente mucho más barato por lectura servida y protege la base de datos de ser sobredimensionada puramente para manejar picos de lectura. Para la mayoría de las cargas de trabajo de FinCorp con lecturas intensivas, una base de datos de tamaño adecuado más una capa de caché cuesta menos que una base de datos escalada hacia arriba de forma perpetua, y también es el único camino de escalada de lectura horizontal que ofrece la plataforma. La lección de coste es dimensionar la base de datos para sus necesidades de escritura y conjunto de trabajo y dejar que la caché, no una instancia más grande, absorba el crecimiento de lectura.

4. Planes de ahorro: Compromiso de piso correcto

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

Varias reglas hacen que esto sea seguro solo si usted respeta ellas. Un plan reserva facturación, no capacidad física, por lo que nunca bloquea la provisión. El desbordamiento se maneja de manera elegante: el uso por encima de la cantidad comprometida se factura a la tarifa estándar de pago por uso, por lo que el único riesgo real es el compromiso excesivo. Cuando varios planes cubren el mismo producto, se aplican en orden cronológico de creación (de más antiguo a más reciente), y dentro de un producto, el descuento se aplica en orden de más antiguo a más reciente. La familia AMD Opteron CPU está excluida. Un plan no se renueva automáticamente, y solo el propietario del contrato puede comprar uno.

El hecho operativo más importante es que un Plan de ahorro no se puede editar después de la activación; el único campo editable es el nombre del plan, y no se puede cancelar después de la compra. Eso hace que el compromiso sea una decisión de un solo sentido, y dicta la disciplina: compromiso de piso. Comprometa solo la línea base de estado estable que está seguro de ejecutar durante todo el plazo, tome el desbordamiento de pago por uso para todo lo que supere eso, y prolongue el plazo solo para la capacidad que esté seguro de que persiste durante tres años. Comprometerse de manera optimista al uso máximo bloquea el gasto que no se puede editar hacia abajo; comprometer el piso captura el descuento en el uso garantizado mientras deja la carga variable en la flexible tarifa de pago por uso.

5. Asignación, Showback y Chargeback

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

La asignación admite dos modelos de operación. Los informes Showback muestran a cada equipo o proyecto su participación en el costo para tener visibilidad y responsabilidad sin mover dinero. Chargeback factura el costo de regreso a la unidad que lo consume. Showback es el punto de partida más ligero y suele ser suficiente para cambiar el comportamiento; chargeback agrega un refuerzo financiero a costa de más maquinaria de facturación. Para FinCorp, asignar VDC a proyectos para que cada uno aterrice en su propia línea de facturación da un showback limpio de inmediato, con chargeback agregado más tarde si las finanzas lo requieren. (Trate el panel de control y la navegación de asignación como la capa de análisis; la construcción debajo es la barrera de guardia de alerta de costo, que es el camino de creación bien documentado).

DCD Implementación paso a paso

Usted creará una alerta de costes que envía un correo electrónico a un destinatario cuando el gasto del contrato supera un umbral de presupuesto. Esta es la única construcción de costes bien documentada; es la barrera de seguridad operativa que respalda las palancas arquitectónicas anteriores. El requisito previo es el acceso de propietario de contrato o administrador, ya que solo esos roles pueden crear alertas de costes. Tenga en cuenta que la alerta se establece a nivel de contrato (una cantidad y un correo electrónico), por lo que la asignación en VDC es una preocupación de informes que se maneja en la vista de Costes y uso, no en la alerta en sí.

Objetivo de la construcción: Crear una alerta de costes contra un umbral de presupuesto.

Pasos (en el Data Center Designer):

1. Vaya a Menú > Administración > Alerta de costes. Se abre la ventana de Alerta de costes; esta vista también enumera las alertas existentes.
2. Elija Crear alerta de costes.
3. En el diálogo, ingrese la cantidad (el umbral de gasto para el contrato) y la dirección de correo electrónico que debe ser notificada.
4. Elija Crear alerta de costes para confirmar. La alerta ahora está activa y enviará un correo electrónico al destinatario una vez que el gasto del contrato supere el umbral.

Errores comunes:

• Esperar que la alerta limite o detenga el gasto. Solo notifica; es un disparador, no una aplicación de presupuesto estricta. El gasto continúa más allá del umbral.
• Establecerlo por VDC. La alerta de costes es a nivel de contrato (cantidad más correo electrónico); utilice la vista de Costes y uso para el análisis y la asignación por VDC.
• Confíar en las alertas en lugar de la arquitectura. La alerta detecta desviaciones; las decisiones de clase de proceso, nivel de almacenamiento y planes de ahorro son lo que realmente establecen la factura.
• Dirigir la alerta a una bandeja de correo personal. Envíela a una dirección de finanzas o operaciones supervisada para que la notificación sea vista y tratada.

Patrón de arquitectura

Una arquitectura de costos de FinCorp defensible capa los controles por impacto. En la base, se elige la clase de proceso por nivel: núcleos dedicados para los niveles regulados y con escalado automático (con un margen de maniobra deliberado como un costo de control justificado), núcleos compartidos para cargas de trabajo tolerantes y no de producción. El almacenamiento se organiza por patrón de acceso, con volúmenes de SSD mantenidos en o por encima del piso de 100 GB y datos de archivo y almacenamiento en masa en Object Storage. El nivel de datos se dimensiona para escrituras y conjunto de trabajo, con una caché en memoria que absorbe el crecimiento de lecturas en lugar de una base de datos sobredimensionada. Sobre eso, un Plan de ahorro compromete solo el piso de núcleos dedicados y RAM en un plazo que coincide con la persistencia real, tomando el exceso de pago por uso por encima de él. En la parte superior, los mapas de asignación asignan VDC a proyectos para mostrar los costos, y una alerta de costo a nivel de contrato proporciona el disparador de deriva. Como una cifra trabajada, un nivel que ejecuta de forma constante 32 núcleos dedicados costaría alrededor de 1,28 euros por hora con pago por uso (32 x 0,04); comprometer ese piso en un plan de 3 años reduce el cargo por núcleo a alrededor de 0,77 euros por hora (32 x 0,024), una reducción del 40% en la línea de base garantizada, mientras que cualquier aumento por encima de 32 núcleos aún se factura con pago por uso.

Resumen

El costo en la nube en IONOS está arquitectado, no solo monitoreado. La clase de contención de cómputo es el mayor control, con una sobreasignación deliberada de hosts en el ámbito justificada como un costo de control; el almacenamiento está organizado por patrón de acceso dentro del piso de rendimiento de SSD; y el nivel de datos se escala en lecturas a través de una caché en lugar de una instancia sobredimensionada. Los Planes de Ahorro capturan descuentos de plazo de 15% (1 año) y 40% (3 años) en núcleos dedicados y RAM, pero no se pueden editar después de la activación, lo que obliga a comprometer solo el piso seguro y a tomar el desbordamiento de pago por uso. La asignación sigue la estructura de contrato y VDC para el showback o chargeback, y una alerta de costo a nivel de contrato proporciona el disparador operativo integrado en el DCD.

Puntos clave:

• La contención de cómputo es el primer control de costo: los núcleos compartidos son más baratos, los núcleos exclusivos (dedicados) compran previsibilidad y aislamiento; el auto-escalado 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.
• Organice el almacenamiento según el patrón de acceso: HDD 0,04, SSD Estándar 0,07, SSD Premium 0,15 EUR/GB/mes; mantenga los volúmenes de SSD en o por encima del piso de rendimiento completo de 100 GB; coloque el bulk y el archivo en Object Storage.
• Escale las lecturas del nivel de datos con una caché en memoria, no con una base de datos sobredimensionada, ya que no hay réplicas de lectura.
• Los Planes de Ahorro ofrecen descuentos de 15% (1 año) y 40% (3 años) en núcleos dedicados y RAM, el desbordamiento se factura con pago por uso, los planes se aplican de manera oldest-first, y no se pueden editar después de la activación, así que comprometa solo el piso seguro.
• Asigne por contrato y VDC (cada VDC ya factura como su propia línea); elija showback o chargeback; una alerta de costo a nivel de contrato (cantidad más correo electrónico) es la barrera de guardia en el momento de la compilació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 (Núcleo Dedicado) o Compartidos (vCPU); el principal control de costo y rendimiento de cómputo.
• Plan de Ahorro: Un compromiso de facturación basado en recursos de 1 año o 3 años en núcleos dedicados y RAM, con desbordamiento de pago por uso, no editable después de la activación, comprable solo por el propietario del contrato.
• Showback / Chargeback: Informar a un equipo su participación en el costo para la responsabilidad (showback) versus facturar realmente el costo de regreso a él (chargeback).
• Alerta de costo: Un umbral a nivel de contrato (cantidad más correo electrónico) que notifica sobre el exceso de gasto; advierte pero no limita.