Unidad 7.3: Ingeniería de rendimiento

Introducción

El rendimiento en IONOS Cloud se ingenia en el momento del diseño, no se ajusta después de los hechos. La plataforma expone un pequeño número de decisiones que dominan la latencia y el rendimiento de extremo a extremo: en qué nivel de almacenamiento se encuentra un Volume y cuán grande es, si un nivel de base de datos está frente a un pooler y una caché, y dónde cada nivel se encuentra en la ruta de red en capas que estableció en la Unidad 1.2. Si se toman estas decisiones correctamente, la arquitectura se comporta de manera predecible bajo carga; si se toman incorrectamente, ninguna cantidad de ajuste posterior recupera el espacio de cabeza perdido.

Esta unidad sintetiza las decisiones tomadas en módulos anteriores en una sola vista de rendimiento. Supone las clases de cómputo de la Unidad 4.1, los niveles de Block Storage de las Unidades 4.2 y 5.1, el patrón de no réplica de lectura de la Unidad 5.3, el nivel de caché de la Unidad 5.5, y los equilibradores de carga de las Unidades 3.3 y 3.4. La plataforma de transacciones reguladas de FinCorp ancla las decisiones trabajadas.

1. Pisos de rendimiento de almacenamiento y selección de nivel

Block Storage en IONOS es un dispositivo de bloque iSCSI disponible como HDD, SSD Estándar y SSD Premium. El criterio de selección es raramente la capacidad, ya que los tres niveles alcanzan el mismo máximo de 4 TB por Volume. El criterio es el perfil de rendimiento, y los dos niveles SSD se comportan de manera muy diferente a HDD.

El rendimiento de HDD es estático y independiente del tamaño de Volume: cada HDD Volume ofrece el mismo rendimiento de 200 MB/s de lectura y escritura secuencial a un tamaño de bloque de 1 MB y 1,100 IOPS a 4 KB (con picos más altos). Un HDD Volume de 50 GB y un HDD Volume de 2 TB funcionan de manera idéntica. Esto hace que HDD sea predecible pero plano, adecuado para acceso de archivo y almacenamiento en bloque secuencial en lugar de bases de datos transaccionales.

El rendimiento de SSD es lo opuesto: escala con el tamaño de Volume hasta un límite. La siguiente tabla es el perfil de rendimiento de SSD documentado por la plataforma.

Dado que el rendimiento de SSD y los IOPS se acumulan por gigabyte, un SSD Volume pequeño limita un Workload exigente. La plataforma recomienda reservar volúmenes de SSD de al menos 100 GB para obtener el beneficio completo de alta velocidad de SSD; se permiten volúmenes más pequeños, pero funcionan de manera subóptima. Para cargas de trabajo de bases de datos, este piso de 100 GB es la regla que soporta la carga: un SSD Volume por debajo de aproximadamente 100 GB degradará un nivel de base de datos, incluso cuando su conjunto de datos es pequeño. El rendimiento que Data Center Designer predice para un Volume se deriva de su tamaño, y para SSD se limita una vez que el Volume supera los 600 GB, en los techos por VM de 45,000 lecturas IOPS y 600 MB/s de rendimiento secuencial para SSD Premium.

La consecuencia de diseño es directa. Usted dimensiona un SSD Volume de base de datos para el rendimiento en primer lugar y la capacidad en segundo. La base de datos transaccional de FinCorp contiene solo unos pocos decenas de gigabytes de datos en vivo, pero provisionarla en un SSD Volume de 40 GB estaría por debajo del piso de rendimiento y limitaría el nivel que lleva los Workload regulados de la empresa. El Volume se provisiona, por lo tanto, en o por encima de 100 GB, independientemente de la huella de datos, y en SSD Premium para que la asignación de IOPS por GB se duplique en comparación con SSD Estándar. El archivo de auditoría de bulk, por otro lado, es secuencial y sensible al costo, por lo que aterriza en HDD, donde el tamaño no afecta el rendimiento, o en Object Storage por completo.

2. Palancas de rendimiento: agrupación, almacenamiento en caché y límites de Node

Una vez que el almacenamiento está correctamente jerarquizado, la siguiente pregunta de rendimiento es la concurrencia, y aquí los límites honestos de la plataforma dan forma al diseño. Managed PostgreSQL y MariaDB no tienen réplicas de lectura (Unidad 5.3). No puede escalar las lecturas agregando puntos de conexión de réplica, por lo que las palancas de rendimiento son la agrupación de conexiones y el almacenamiento en caché.

El límite de conexiones no es un control de ajuste. El max_connections de PostgreSQL se calcula a partir de Cluster RAM y no es configurable por el usuario, que va desde 384 conexiones a 4 GB RAM hasta un límite máximo de 1.000 conexiones por encima de 8 GB, con 11 conexiones reservadas para uso interno de superusuario y replicación. Un nivel de aplicación que abre una conexión fresca por solicitud agotará este límite mucho antes de agotar CPU. La respuesta nativa es el grupo de conexiones administrado pgbouncer: DBaaS no agrupa por defecto, pero puede activar el grupo de conexiones administrado pgbouncer y elegir el modo de transacción (el predeterminado, que libera la conexión después de cada transacción) o el modo de sesión. Cuando se habilita la agrupación, las aplicaciones se conectan en el puerto 6432 en lugar del puerto 5432 nativo de la base de datos. La agrupación en modo de transacción permite que un pequeño número de conexiones de backend reales sirva a un gran número de clientes de aplicación, lo que mantiene un nivel de estado sin estado ocupado dentro del límite derivado de RAM.

El almacenamiento en caché es la segunda palanca y la que sustituye a las réplicas de lectura. El nivel In-Memory DB (Unidad 5.5) absorbe el tráfico de lectura pesado frente a la base de datos relacional con recuperación en milisegundos, de modo que las lecturas repetidas nunca alcanzan PostgreSQL en absoluto. Un solo In-Memory DB Cluster puede absorber muchas más conexiones concurrentes que el nivel relacional (el motor Valkey subyacente predetermina un límite de 10.000 conexiones de cliente), lo que es precisamente por qué la caché, y no la base de datos, es el nivel que enfrenta la ruta de lectura de explosión. La colocación de caché adyacente o de escritura (Unidad 5.5) determina la coherencia; de cualquier manera, la caché es el multiplicador de rendimiento que hace que la plataforma sin réplicas de lectura se escalable.

La tercera palanca es el cálculo horizontal. Un solo Node tiene un límite finito independientemente del almacenamiento y la agrupación, por lo que los niveles de estado sin estado de alto rendimiento se escalan hacia afuera detrás de un Load Balancer en lugar de escalar un solo servidor de manera indefinida. Este es también el lugar donde dos realidades de equilibrio de carga muerden. Primero, un servicio de equilibrio de carga Kubernetes es un Node estático único, no un equilibrio de carga distribuido administrado (Unidad 6.1), por lo que es en sí mismo un límite de Node único a menos que frente al Cluster con un Managed Application Load Balancer provisto por separado. Segundo, los equilibradores administrados distribuyen pero no aceleran: Managed Network Load Balancer y Managed Application Load Balancer ofrecen algoritmos de Round Robin, Least Connections, Random y Source IP, y la elección del algoritmo gobierna cómo se distribuye uniformemente la carga en los objetivos saludables, no cómo se ejecuta rápidamente un solo objetivo. Least Connections suaviza los costos de solicitud desiguales; Source IP preserva la afinidad de sesión al precio de una distribución uniforme. El equilibrador aumenta el rendimiento agregado solo agregando backends saludables, por lo que la planificación de capacidad es en última instancia la planificación de backends.

3. Ajuste de tamaño correcto versus sobreaprovisionamiento

El ajuste de tamaño correcto coincide con los recursos y la demanda observada, y es el valor predeterminado para la eficiencia de costos. Dos mecánicas de plataforma hacen que sea menos doloroso de lo que suena. CPU, RAM, NICs y almacenamiento pueden escalarse en vivo en servidores Dedicated Core (Unidad 4.3), por lo que puede comenzar con un tamaño pequeño y crecer sin necesidad de reconstruir; solo CPU y RAM se reducen de escala y un RAM con conexión caliente por encima de 240 GB requiere un reinicio. Y el rendimiento de almacenamiento de SSD crece con el Volume, por lo que aumentar un Volume para capacidad también aumenta su rendimiento, lo que mantiene el ajuste de tamaño correcto del almacenamiento y el rendimiento alineados en lugar de en tensión.

El sobreaprovisionamiento deliberado es la excepción justificada, y la Unidad 2.4 lo enmarcó como un costo de control en lugar de desperdicio. El caso más claro es el piso de la base de datos SSD de la Sección 1: usted sobreaprovisiona la capacidad para comprar rendimiento porque los dos están acoplados en SSD. Un segundo caso es la capacidad de absorción en un nivel que no puede absorber un reinicio de manera elegante durante las horas pico, donde el costo de llevar CPU y RAM de repuesto es más barato que una recuperación de reducción de escala que induce un reinicio. La disciplina es sobreaprovisionar solo donde un piso de rendimiento medido o una restricción operativa lo justifica, y ajustar el tamaño correcto en todas partes.

La siguiente tabla resume dónde se aplica cada postura.

4. Donde se gana o pierde la latencia en toda la arquitectura en capas

La forma en capas de la Unidad 1.2 (equilibrador de carga de capa 7 público hasta el cálculo sin estado y equilibrador de carga de capa 4 privado hasta el nivel de datos privado) también es un mapa de latencia. Cada salto agrega viajes de ida y vuelta, y el objetivo de diseño es mantener el camino caliente corto y los componentes lentos fuera de él.

El Managed Application Load Balancer público termina TLS una vez en el borde y lo reenvía a la capa sin estado, para que los saltos de back-end puedan ejecutarse en texto sin formato en la LAN privada y evitar apretones de manos repetidos. La capa sin estado no debe contener ningún estado de sesión, tanto porque el escalado automático y el failover del equilibrador de carga lo requieren (Unidades 4.3 y 7.1) como porque externalizar el estado de sesión a la capa In-Memory DB convierte una búsqueda de base de datos lenta por solicitud en un impacto de caché de submilisegundo. El equilibrador de carga de capa 4 privado frente al nivel de datos agrega un salto de paso de TCP pero no realiza trabajo de TLS. El componente más lento, la base de datos relacional, se encuentra al final del camino y está protegida tanto por el pooler (que mantiene su techo de conexión) como por la caché (que mantiene la mayoría de las lecturas lejos de ella). Por lo tanto, la latencia se gana al terminar TLS una vez, mantener la capa de aplicación sin estado y con caché, y agrupar cada conexión de base de datos; se pierde con conexiones por solicitud, SSD de tamaño insuficiente debajo de la base de datos y lecturas que caen en el nivel relacional en lugar de la caché.

Una sutileza del hardware es importante a esta altitud. La banda de ancho de red de host muy alta en IONOS es una propiedad de hardware dedicado específico, no de la tela general Block Storage. La conectividad de host de alta gama aparece en hardware dedicado como los hosts VMware Private Cloud y la plataforma GPU/HPC-AI, mientras que el interconectado de clase NVLink es específico de la plataforma Cloud GPU (máquinas virtuales Compute Engine GPU), cuyos servidores GPU exponen dos clusters NVLink de cuatro GPU cada uno, dirigidos por separado. No asuma rendimiento de clase InfiniBand o RDMA para Block Storage general o LAN de cálculo estándar; esos ejecutan la tela de bloque iSCSI y la red virtual estándar. Para FinCorp, la lectura práctica es que el nivel de transacciones reguladas en el cálculo estándar se ingeniera a través de una correcta jerarquía SSD, agrupación y caché, mientras que cualquier futuro entrenamiento de Workload de baja latencia HPC o IA es una conversación de hardware separada en la plataforma GPU dedicada, no un atributo que proporcione la tela general.

Resumen de la decisión

Resumen

La ingeniería de rendimiento en IONOS es un conjunto de colocaciones de diseño en tiempo de ejecución en lugar de ajustes posteriores: nivel y tamaño de almacenamiento en su piso de rendimiento, agrupar y almacenar en caché la base de datos para trabajar dentro de límites de conexión fijos y el límite de réplica de no lectura, escalar capas sin estado hacia atrás detrás de equilibradores de carga que distribuyen en lugar de acelerar, y mantener el camino caliente corto a través de la arquitectura en capas. La sobre-provisión solo está justificada donde un piso medido o una restricción operativa lo exige; en todas partes, el ajuste de tamaño correcto con crecimiento en vivo es tanto más barato como suficiente.

Puntos clave:

• El rendimiento de SSD se escala por gigabyte y se degrada por debajo de ~100 GB, por lo que los volúmenes de la base de datos se dimensionan para el rendimiento en primer lugar; el rendimiento de HDD es plano y es independiente del tamaño de Volume.
• No hay réplicas de lectura; la agrupación (managed pgbouncer, modo de transacción, puerto 6432) y la caché de In-Memory DB son las palancas de rendimiento de lectura, y el límite de conexión de PostgreSQL es RAM-derivado hasta 1,000.
• Los equilibradores de carga administrados distribuyen el tráfico a través de backends saludables pero no aceleran ningún backend individual; un servicio de LoadBalancer de Kubernetes es un Node estático individual.
• Ajuste de tamaño correcto y crecimiento en vivo por defecto; sobre-provisión deliberadamente solo en el piso de la base de datos SSD o en las capas pico que no pueden absorber un reinicio.
• La red de host de alta gama es una propiedad de hardware dedicado (VMware Private Cloud y GPU/HPC-AI), y el interconectado de clase NVLink es específico de la plataforma de GPU en la nube (Compute Engine GPU VMs), no el tejido general de Block Storage.

Terminología importante:

• Pooler de conexiones (pgbouncer): Un intermediario administrado que multiplexa muchos clientes de aplicaciones en un pequeño número de conexiones de base de datos reales; activado explícitamente, alcanzado en el puerto 6432, predeterminado en modo de transacción.
• Piso de rendimiento: El tamaño mínimo de Volume por debajo del cual el almacenamiento de SSD entrega un rendimiento degradado y IOPS (~100 GB para cargas de trabajo de base de datos).
• Límite de techo de un Node: El rendimiento finito de un servidor o un punto final de un Node individual, más allá del cual el único remedio es escalar hacia afuera a través de backends adicionales saludables.

Lectura adicional

• Unidad 4.2: Imágenes, discos y Cloud-Init (niveles de Block Storage y el piso de SSD en contexto)
• Unidad 5.3: Bases de datos relacionales (el patrón de no-replica de lectura y modos de replicación)
• Unidad 5.5: Base de datos en memoria (el nivel de caché que absorbe la carga de lectura)
• Unidad 1.2: La arquitectura en capas canónica (el mapa de latencia que esta unidad traza)