Unidad 7.3: Ingeniería de rendimiento

Introducción

El rendimiento en IONOS CLOUD se diseña en la fase de diseño, no se ajusta a posteriori. La plataforma expone un número reducido de decisiones que determinan la latencia de extremo a extremo y el rendimiento: en qué nivel de almacenamiento se encuentra un volumen y de qué tamaño es, si un nivel de base de datos está respaldado por un pooler y una caché, y en qué punto del camino de red por capas establecido en la Unidad 1.2 se ubica cada nivel. Si se toman estas decisiones correctamente, la arquitectura ofrece un rendimiento predecible bajo carga; si se cometen errores, ninguna cantidad de ajustes posteriores puede recuperar el margen perdido.

Esta unidad sintetiza las decisiones tomadas en módulos anteriores en una única visión de rendimiento. Parte de las clases de cómputo de la Unidad 4.1, los niveles de almacenamiento en bloque de las Unidades 4.2 y 5.1, el patrón sin 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 regulada de FinCorp sirve como base para las decisiones prácticas.

1. Límites de rendimiento de almacenamiento y selección de niveles

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

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

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

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

La consecuencia de diseño es directa. Usted dimensiona un volumen de SSD para base de datos priorizando el rendimiento y la capacidad en segundo lugar. La base de datos transaccional de FinCorp contiene solo unas pocas decenas de gigabytes de datos activos, pero aprovisionarla en un volumen de SSD de 40 GB la situaría por debajo del límite de rendimiento y limitaría el nivel que soporta la carga de trabajo regulada de la empresa. Por lo tanto, el volumen se aprovisiona en 100 GB o más, 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 Standard. El archivo de auditoría masiva, por el contrario, es secuencial y sensible al costo, por lo que se coloca en HDD, donde el tamaño no afecta el rendimiento, o directamente en Object Storage.

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

Una vez que el almacenamiento se ha estratificado correctamente, 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 es posible escalar las lecturas añadiendo puntos de acceso de réplica, por lo que las palancas de rendimiento son la agrupación de conexiones y el caché.

El límite de conexiones no es un ajuste configurable. El parámetro max_connections de PostgreSQL se calcula a partir de la RAM del clúster y no es configurable por el usuario, variando desde 384 conexiones con 4 GB de RAM hasta un límite máximo de 1,000 conexiones con más de 8 GB, reservando 11 conexiones para el uso interno de superusuario y replicación. Una capa de aplicación que abra una conexión nueva por solicitud agotará este límite mucho antes de agotar la CPU. La respuesta nativa es el agrupador de conexiones pgbouncer gestionado: DBaaS no realiza agrupación por defecto, pero puede activar pgbouncer gestionado y elegir el modo de transacción (el valor predeterminado, que libera la conexión después de cada transacción) o el modo de sesión. Cuando el agrupación está habilitado, las aplicaciones se conectan en el puerto 6432 en lugar del puerto nativo 5432 de la base de datos. El agrupación en modo transacción permite que un pequeño número de conexiones reales de backend atienda a un gran número de clientes de aplicación, lo cual es lo que mantiene a una capa sin estado activa dentro del límite derivado de la RAM.

El caché es la segunda palanca y la que sustituye a las réplicas de lectura. La capa In-Memory DB (Unidad 5.5) absorbe el tráfico intensivo de lecturas por delante de la base de datos relacional con una recuperación de menos de un milisegundo, de modo que las lecturas repetidas nunca llegan a PostgreSQL. Un único clúster In-Memory DB puede absorber muchas más conexiones concurrentes que la capa relacional (el motor subyacente Valkey tiene un límite predeterminado de 10,000 conexiones de cliente), que es precisamente la razón por la que el caché, y no la base de datos, es la capa que enfrenta la ruta de lecturas intermitente. La colocación cache-aside o write-through (Unidad 5.5) determina la consistencia; en cualquier caso, el caché es el multiplicador de rendimiento que permite que la plataforma sin réplicas de lectura escale.

La tercera palanca es el cómputo horizontal. Un solo Node tiene un límite finito independientemente del almacenamiento y del agrupación, por lo que las capas sin estado con un rendimiento genuinamente alto escalan horizontalmente detrás de un Load Balancer en lugar de escalar un solo servidor indefinidamente. Aquí es donde dos realidades de los equilibradores de carga se hacen sentir. Primero, un servicio LoadBalancer de Kubernetes es una IP estática de un solo Node, no un equilibrador distribuido gestionado (Unidad 6.1), por lo que es en sí mismo un límite de un solo Node a menos que se coloque un Managed Application Load Balancer aprovisionado por separado por delante del clúster. Segundo, los equilibradores gestionados distribuyen pero no aceleran: el Managed Network Load Balancer y el Managed Application Load Balancer ofrecen ambos los algoritmos Round Robin, Least Connections, Random y Source IP, y la elección del algoritmo gobierna cómo se distribuye uniformemente la carga entre los destinos sanos, no la velocidad con la que funciona un solo destino. Least Connections suaviza los costos de solicitud desiguales; Source IP preserva la afinidad de sesión a costa de la distribución uniforme. El equilibrador aumenta el rendimiento agregado solo añadiendo backends sanos, por lo que la planificación de capacidad es, en última instancia, planificación de backends.

3. Ajuste de tamaño adecuado frente a sobreprovisionamiento

El ajuste de tamaño adecuado consiste en alinear los recursos con la demanda observada y es la opción predeterminada para la eficiencia de costos. Dos mecanismos de la plataforma lo hacen menos doloroso de lo que suena. CPU, RAM, NICs y almacenamiento pueden escalarse hacia arriba en vivo en servidores Dedicated Core (Unidad 4.3), por lo que puede comenzar con una configuración pequeña y crecer sin reconstruir; solo el escalado hacia abajo de CPU y RAM, y un hotplug de RAM superior a 240 GB, requieren un reinicio. Además, el rendimiento del almacenamiento SSD crece con el volumen, por lo que aumentar un volumen para obtener capacidad también aumenta su ancho de banda, lo que mantiene el ajuste de tamaño del almacenamiento y el rendimiento alineados en lugar de en tensión.

El sobreprovisionamiento deliberado es la excepción justificada, y la Unidad 2.4 lo planteó como un costo de control en lugar de un desperdicio. El caso más claro es el umbral de SSD para bases de datos de la Sección 1: se sobreprovisiona capacidad para comprar rendimiento, porque ambos están acoplados en SSD. Un segundo caso es el margen en un nivel que no puede absorber un reinicio de manera adecuada durante las horas pico, donde el costo de mantener CPU y RAM de reserva es menor que una recuperación mediante escalado hacia abajo que induce un reinicio. La disciplina consiste en sobreprovisionar solo donde un umbral de rendimiento medido o una restricción operativa lo justifique, y ajustar el tamaño adecuado en todas las demás partes.

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

4. Dónde se gana o se pierde la latencia en la arquitectura por capas

La forma por capas de la Unidad 1.2 (equilibrador público de capa 7, cómputo sin estado, equilibrador privado de capa 4 y nivel de datos exclusivo para uso privado) también es un mapa de latencia. Cada salto añade viajes de ida y vuelta, y el objetivo del diseño es mantener la ruta crítica corta y alejar de ella los componentes lentos.

El Managed Application Load Balancer público termina TLS una sola vez en el borde y reenvía al nivel sin estado, por lo que los saltos hacia los servidores de back-end pueden ejecutarse en texto plano sobre la LAN privada y evitar handshakes repetidos. El nivel sin estado no debe retener estado de sesión, tanto porque el Auto Scaling y el failover del equilibrador de carga lo requieren (Unidades 4.3 y 7.1), como porque externalizar el estado de sesión al nivel In-Memory DB convierte una consulta lenta a la base de datos por solicitud en un acierto de caché de menos de un milisegundo. El equilibrador privado de capa 4 situado delante del nivel de datos añade un salto de passthrough TCP, pero no realiza trabajo de TLS. El componente más lento, la base de datos relacional, se encuentra en la parte inferior de la ruta y está protegido tanto por el pooler (que lo mantiene dentro de su límite de conexiones) como por la caché (que impide que la mayoría de las lecturas lleguen a él). Por lo tanto, la latencia se gana terminando TLS una sola vez, manteniendo el nivel de aplicación sin estado y con caché frontal, y agrupando todas las conexiones a la base de datos; se pierde mediante conexiones por solicitud, SSD de tamaño insuficiente bajo la base de datos y lecturas que llegan al nivel relacional en lugar de a la caché.

Un matiz de hardware es relevante a este nivel. El ancho de banda de red del host muy alto en IONOS CLOUD es una propiedad de hardware dedicado específico, no de la infraestructura general de Block Storage. La red de host premium aparece en hardware dedicado, como los hosts de VMware Private Cloud y la plataforma GPU/HPC-AI, mientras que el interconexión de clase NVLink es específico de la plataforma Cloud GPU (VMs de GPU en Compute Engine), cuyos servidores GPU exponen dos clústeres NVLink de cuatro GPUs cada uno, dirigidos por separado. No se debe asumir un rendimiento de clase InfiniBand o RDMA para Block Storage general o LANs de cómputo estándar; estas ejecutan la infraestructura de bloques iSCSI y la red virtual estándar. Para FinCorp, la interpretación práctica es que el nivel de transacciones regulado en cómputo estándar se diseña mediante una jerarquización correcta de SSD, agrupación de conexiones y caché, mientras que cualquier futura carga de trabajo de HPC o entrenamiento de IA de baja latencia es una conversación de hardware separada en la plataforma GPU dedicada, no un atributo que la infraestructura general proporcione.

Resumen de decisiones

Resumen

La ingeniería de rendimiento en IONOS CLOUD consiste en una serie de decisiones de diseño en tiempo de diseño, no en ajustes posteriores: dimensionar y dimensionar el almacenamiento según su límite de rendimiento, agrupar y poner en caché la base de datos para operar dentro de los límites fijos de conexiones y la restricción de ausencia de réplicas de lectura, escalar las capas sin estado hacia fuera detrás de equilibradores de carga que distribuyen el tráfico en lugar de acelerarlo, y mantener la ruta crítica corta a lo largo de la arquitectura por capas. La sobreprovisión solo está justificada cuando un límite medido o una restricción operativa lo exige; en todos los demás casos, el dimensionamiento adecuado con crecimiento en vivo es más económico y suficiente.

Puntos clave:

• El rendimiento de SSD escala por gigabyte y se degrada por debajo de ~100 GB, por lo que los volúmenes de base de datos se dimensionan primero por rendimiento; el rendimiento de HDD es plano e independiente del tamaño del volumen.
• No hay réplicas de lectura; el agrupamiento (pgbouncer administrado, modo de transacción, puerto 6432) y la caché de In-Memory DB son las palancas para el rendimiento de lectura, y el límite de conexiones de PostgreSQL se deriva de la RAM, hasta 1.000.
• Los equilibradores de carga administrados distribuyen el tráfico entre backends sanos, pero no aceleran ningún backend individual; un servicio LoadBalancer de Kubernetes es una IP estática de un solo nodo.
• Por defecto, se debe dimensionar adecuadamente y crecer en vivo; solo se debe sobreprovisionar deliberadamente en el límite de SSD de la base de datos o en las capas de pico que no pueden absorber un reinicio.
• La red de host premium es una propiedad del hardware dedicado (VMware Private Cloud y GPU/HPC-AI), y el interconexión de clase NVLink es específica de la plataforma Cloud GPU (VMs de GPU en Compute Engine), no de la trama general de Block Storage.

Terminología importante:

• Agrupador de conexiones (pgbouncer): Un intermediario administrado que multiplexa muchos clientes de aplicación sobre un pequeño número de conexiones reales a la base de datos; se activa explícitamente, se alcanza en el puerto 6432 y usa el modo de transacción por defecto.
• Límite de rendimiento: El tamaño mínimo de volumen por debajo del cual el almacenamiento SSD entrega un rendimiento y IOPS degradados (~100 GB para cargas de trabajo de base de datos).
• Límite de un solo nodo: El rendimiento finito de un solo servidor o de un solo punto de acceso de un solo nodo, más allá del cual la única solución es escalar hacia fuera a través de backends adicionales sanos.

Lectura adicional

• Unidad 4.2: Imágenes, discos y Cloud-Init (niveles de almacenamiento en bloques y el nivel mínimo de SSD en contexto)
• Unidad 5.3: Bases de datos relacionales (el patrón sin réplica de lectura y los 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 por capas canónica (el mapa de latencia que esta unidad traza)