Unité 7.3 : Ingénierie des performances

Introduction

Les performances sur IONOS CLOUD sont conçues dès la phase de conception, et non optimisées a posteriori. La plateforme expose un petit nombre de décisions qui dominent la latence et le débit de bout en bout : le niveau de stockage sur lequel se trouve un volume et sa taille, la présence ou non d'un pooler et d'un cache devant un niveau de base de données, et l'emplacement de chaque niveau sur le chemin réseau hiérarchisé que vous avez établi dans l'Unité 1.2. Si ces choix sont bien faits, l'architecture offre des performances prévisibles sous charge ; s'ils sont erronés, aucune optimisation ultérieure ne permettra de récupérer la marge perdue.

Cette unité synthétise les décisions prises dans les modules précédents en une vue unique des performances. Elle suppose les classes de calcul de l'Unité 4.1, les niveaux de stockage en bloc des Unités 4.2 et 5.1, le motif sans réplique de lecture de l'Unité 5.3, le niveau de cache de l'Unité 5.5, et les équilibreurs de charge des Unités 3.3 et 3.4. La plateforme de transactions réglementée de FinCorp sert de base aux décisions concrètes.

1. Planchers de performance du stockage et sélection de la gamme

Block Storage sur IONOS CLOUD est un périphérique de bloc iSCSI disponible en HDD, SSD Standard et SSD Premium. Le critère de sélection est rarement la capacité, car les trois gammes atteignent la même limite maximale de 4 To par volume. Le critère est le profil de performance, et les deux gammes SSD se comportent très différemment de HDD.

La performance de HDD est statique et indépendante de la taille du volume : chaque volume HDD offre la même vitesse de lecture/écriture séquentielle de 200 Mo/s à une taille de bloc de 1 Mo et 1 100 IOPS à 4 Ko (avec des pics plus élevés). Un volume HDD de 50 Go et un volume HDD de 2 To offrent des performances identiques. Cela rend HDD prévisible mais constant, adapté à l'accès séquentiel en masse et aux archives plutôt qu'aux bases de données transactionnelles.

La performance de SSD est à l'opposé : elle augmente avec la taille du volume jusqu'à une limite. Le tableau suivant présente le profil de performance SSD documenté par la plateforme.

Étant donné que le débit et les IOPS de SSD s'accumulent par gigaoctet, un petit volume SSD sature une charge de travail exigeante. La plateforme recommande de réserver des volumes SSD d'au moins 100 Go pour tirer pleinement parti de la haute vitesse de SSD ; les volumes plus petits sont autorisés mais offrent des performances sous-optimales. Pour les charges de travail de base de données, ce plancher de 100 Go est la règle fondamentale : un volume SSD inférieur à environ 100 Go dégradera un niveau de base de données, même si son jeu de données est minuscule. La performance que Data Center Designer prédit pour un volume est dérivée de sa taille, et pour SSD, elle est plafonnée dès que le volume dépasse 600 Go, aux limites par VM de 45 000 IOPS de lecture et 600 Mo/s de débit séquentiel pour SSD Premium.

La conséquence en matière de conception est directe. Vous dimensionnez un volume SSD de base de données d'abord pour la performance et ensuite pour la capacité. La base de données transactionnelle de FinCorp ne contient que quelques dizaines de gigaoctets de données actives, mais sa provision sur un volume SSD de 40 Go situerait le niveau sous le plancher de performance et limiterait le niveau même qui porte la charge de travail réglementée de l'entreprise. Le volume est donc provisionné à 100 Go ou plus, indépendamment de l'empreinte des données, et sur SSD Premium afin que l'allocation d'IOPS par Go soit doublée par rapport à SSD Standard. L'archive d'audit en masse, en revanche, est séquentielle et sensible au coût, elle est donc placée sur HDD où la taille n'affecte pas les performances, ou sur Object Storage.

2. Leviers de débit : regroupement, mise en cache et plafonds de Node

Une fois le stockage correctement hiérarchisé, la prochaine question de performance est la concurrence, et ici, les limites honnêtes de la plateforme façonnent la conception. Managed PostgreSQL et MariaDB ne disposent pas de répliques de lecture (Unité 5.3). Vous ne pouvez pas mettre à l'échelle les lectures en ajoutant des points d'accès de réplique, de sorte que les leviers de débit sont le regroupement de connexions et la mise en cache.

Le plafond de connexions n'est pas un réglage ajustable. Le paramètre max_connections de PostgreSQL est calculé à partir de la RAM du cluster et n'est pas configurable par l'utilisateur, variant de 384 connexions pour 4 Go de RAM jusqu'à un plafond rigide de 1 000 connexions au-delà de 8 Go, avec 11 connexions réservées pour l'utilisation interne du superutilisateur et de la réplication. Une couche applicative qui ouvre une nouvelle connexion par requête épuiserait ce plafond bien avant d'épuiser le CPU. La réponse native est le regroupement de connexions pgbouncer géré : DBaaS ne fait pas de regroupement par défaut, mais vous pouvez activer pgbouncer géré et choisir le mode transaction (le mode par défaut, qui libère la connexion après chaque transaction) ou le mode session. Lorsque le regroupement est activé, les applications se connectent sur le port 6432 au lieu du port natif 5432 de la base de données. Le regroupement en mode transaction permet à un petit nombre de connexions backend réelles de servir un grand nombre de clients applicatifs, ce qui permet à une couche sans état chargée de rester dans les limites du plafond dérivé de la RAM.

La mise en cache est le deuxième levier et celui qui remplace les répliques de lecture. La couche In-Memory DB (Unité 5.5) absorbe le trafic intensif en lecture devant la base de données relationnelle avec une récupération inférieure à la milliseconde, de sorte que les lectures répétées n'atteignent jamais PostgreSQL. Un seul cluster In-Memory DB peut absorber beaucoup plus de connexions simultanées que la couche relationnelle (le moteur Valkey sous-jacent est réglé par défaut sur un plafond de 10 000 connexions clients), ce qui est précisément la raison pour laquelle le cache, et non la base de données, est la couche qui fait face au chemin de lecture variable. Le placement cache-aside ou write-through (Unité 5.5) détermine la cohérence ; dans tous les cas, le cache est le multiplicateur de débit qui permet à la plateforme sans réplique de lecture de mettre à l'échelle.

Le troisième levier est le calcul horizontal. Un seul Node a un plafond fini quel que soit le stockage et le regroupement, de sorte que les couches sans état à très haut débit se développent horizontalement derrière un Load Balancer plutôt que de mettre à l'échelle un seul serveur indéfiniment. C'est aussi là que deux réalités des équilibreurs de charge se font sentir. D'abord, un Service Kubernetes de type LoadBalancer est une IP statique sur un seul nœud, et non un équilibreur distribué géré (Unité 6.1), il constitue donc lui-même un plafond sur un seul nœud, à moins de placer le cluster derrière un Managed Application Load Balancer provisionné séparément. Deuxièmement, les équilibreurs gérés distribuent mais n'accélèrent pas : le Managed Network Load Balancer et le Managed Application Load Balancer proposent tous deux les algorithmes Round Robin, Least Connections, Random et Source IP, et le choix de l'algorithme régit la répartition uniforme de la charge entre les cibles saines, et non la vitesse d'exécution d'une cible individuelle. Least Connections lisse les coûts de requêtes inégaux ; Source IP préserve l'affinité de session au prix d'une distribution uniforme. L'équilibreur augmente le débit agrégé uniquement en ajoutant des backends sains, de sorte que la planification de la capacité est ultimement une planification des backends.

3. Dimensionnement optimal par rapport au surdimensionnement

Le dimensionnement optimal consiste à aligner les ressources sur la demande observée et constitue l'approche par défaut pour l'efficacité des coûts. Deux mécanismes de la plateforme rendent cette démarche moins contraignante qu'il n'y paraît. Le CPU, la RAM, les cartes réseau (NIC) et le stockage peuvent être augmentés en direct sur les serveurs Dedicated Core (Unité 4.3), ce qui permet de commencer avec une configuration modeste et de l'élargir sans reconstruction ; seules la réduction du CPU et de la RAM, ainsi qu'un ajout à chaud de RAM supérieur à 240 Go, nécessitent un redémarrage. De plus, les performances du stockage SSD augmentent avec la taille du volume, de sorte qu'augmenter un volume pour la capacité augmente également son débit, ce qui maintient le dimensionnement optimal du stockage et les performances alignés plutôt qu'en tension.

Le surdimensionnement délibéré est l'exception justifiée, et l'Unité 2.4 l'a présenté comme un coût de contrôle plutôt que comme un gaspillage. Le cas le plus clair est le seuil minimal de SSD pour les bases de données issu de la Section 1 : on surdimensionne la capacité pour acheter des performances, car les deux sont couplées sur SSD. Un deuxième cas concerne la marge sur une couche qui ne peut pas absorber un redémarrage de manière fluide pendant les heures de pointe, où le coût de maintien d'un CPU et d'une RAM supplémentaires est inférieur à celui d'une récupération par réduction provoquant un redémarrage. La rigueur consiste à surdimensionner uniquement là où un seuil de performance mesuré ou une contrainte opérationnelle le justifie, et à dimensionner de manière optimale partout ailleurs.

Le tableau suivant résume où chaque approche s'applique.

4. Où la latence est gagnée ou perdue dans l'architecture en couches

La forme en couches décrite dans l'unité 1.2 (équilibreur de charge public de couche 7 vers calcul sans état, puis équilibreur de charge privé de couche 4, puis niveau de données réservé à l'accès privé) est également une carte de latence. Chaque saut ajoute des allers-retours, et l'objectif de conception est de garder le chemin critique court et d'éloigner les composants lents de celui-ci.

Le Managed Application Load Balancer public met fin à la session TLS une seule fois sur le bord et transfère vers le niveau sans état, de sorte que les sauts vers les serveurs en aval peuvent se dérouler en texte brut sur le LAN privé et éviter les poignées de main répétées. Le niveau sans état ne doit conserver aucun état de session, à la fois parce que l'Auto Scaling et la bascule de l'équilibreur de charge l'exigent (unités 4.3 et 7.1) et parce que l'externalisation de l'état de session vers le niveau In-Memory DB transforme une consultation de base de données lente par requête en un accès au cache en moins d'une milliseconde. L'équilibreur de charge privé de couche 4 placé devant le niveau de données ajoute un saut de passage TCP, mais aucun travail TLS. Le composant le plus lent, la base de données relationnelle, se situe au bas du chemin et est protégé à la fois par le pooler (qui la maintient sous sa limite de connexions) et par le cache (qui empêche la plupart des lectures de l'atteindre). La latence est donc gagnée en mettant fin à TLS une seule fois, en gardant le niveau d'application sans état et protégé par un cache, et en mutualisant toutes les connexions à la base de données ; elle est perdue à cause des connexions par requête, d'un SSD sous-dimensionné sous la base de données, et des lectures qui atteignent le niveau relationnel au lieu du cache.

Une nuance matérielle est importante à ce niveau. La très haute bande passante du réseau hôte sur IONOS CLOUD est une propriété de matériel dédié spécifique, et non de la trame Block Storage générale. Le réseau hôte premium apparaît sur du matériel dédié tel que les hôtes VMware Private Cloud et la plateforme GPU/HPC-AI, tandis que l'interconnexion de classe NVLink est spécifique à la plateforme Cloud GPU (VM GPU de Compute Engine), dont les serveurs GPU exposent deux clusters NVLink de quatre GPU chacun, adressés séparément. Ne supposez pas une performance de classe InfiniBand ou RDMA pour le Block Storage général ou les LAN de calcul standard ; ceux-ci utilisent la trame de bloc iSCSI et le réseau virtuel standard. Pour FinCorp, l'interprétation pratique est que le niveau de transactions réglementé sur le calcul standard est conçu par une stratification SSD correcte, une mutualisation et une mise en cache, tandis que toute charge de travail future de HPC ou d'entraînement IA à faible latence constitue une discussion matérielle distincte sur la plateforme GPU dédiée, et non un attribut fourni par la trame générale.

Résumé de la décision

Résumé

L'ingénierie des performances sur IONOS CLOUD consiste en un ensemble de décisions de conception prises à l'avance, plutôt qu'en un réglage a posteriori : dimensionner et hiérarchiser le stockage en fonction de son seuil de performance minimal, mutualiser et mettre en cache la base de données pour fonctionner dans les limites des plafonds de connexions fixes et de la contrainte d'absence de répliques de lecture, mettre à l'échelle les couches sans état en les déployant derrière des équilibreurs de charge qui répartissent le trafic sans l'accélérer, et maintenir le chemin critique court au sein de l'architecture en couches. Le surdimensionnement n'est justifié que là où un seuil mesuré ou une contrainte opérationnelle l'exige ; partout ailleurs, le dimensionnement optimal avec croissance en direct est à la fois moins coûteux et suffisant.

Points clés :

• Les performances des SSD évoluent en fonction de la taille en gigaoctets et se dégradent en dessous d'environ 100 Go, c'est pourquoi les volumes de base de données sont dimensionnés en priorité pour les performances ; les performances des HDD sont constantes et indépendantes de la taille du volume.
• Il n'y a pas de répliques de lecture ; la mutualisation (pgbouncer managé, mode transaction, port 6432) et le cache In-Memory DB sont les leviers pour augmenter le débit de lecture, et le plafond de connexions PostgreSQL est dérivé de la mémoire vive, jusqu'à 1 000 connexions.
• Les équilibreurs de charge managés répartissent le trafic entre les backends sains, mais n'accélèrent aucun backend individuel ; un Service LoadBalancer Kubernetes est une IP statique sur un seul nœud.
• Par défaut, il faut dimensionner de manière optimale et faire croître en direct ; le surdimensionnement doit être effectué délibérément uniquement au niveau du seuil minimal des SSD de base de données ou sur les couches de pointe qui ne peuvent pas absorber un redémarrage.
• Le réseau hôte premium est une caractéristique du matériel dédié (VMware Private Cloud et GPU/HPC-AI), et l'interconnexion de classe NVLink est spécifique à la plateforme Cloud GPU (VM GPU Compute Engine), et non au tissu général de Block Storage.

Terminologie importante :

• Mutualisateur de connexions (pgbouncer) : Un intermédiaire managé qui multiplexe de nombreux clients applicatifs sur un petit nombre de connexions réelles à la base de données ; activé explicitement, accessible sur le port 6432, et fonctionnant par défaut en mode transaction.
• Seuil de performance minimal : La taille minimale du volume en dessous de laquelle le stockage SSD offre un débit et des IOPS dégradés (environ 100 Go pour les charges de travail de base de données).
• Plafond mononœud : Le débit fini d'un seul serveur ou d'un seul point d'entrée mononœud, au-delà duquel le seul remède consiste à mettre à l'échelle en déployant sur des backends sains supplémentaires.

Lectures complémentaires

• Unité 4.2 : Images, disques et Cloud-Init (niveaux de stockage par blocs et plancher SSD dans le contexte)
• Unité 5.3 : Bases de données relationnelles (le motif sans réplique de lecture et les modes de réplication)
• Unité 5.5 : Base de données en mémoire (le niveau de cache qui absorbe la charge de lecture)
• Unité 1.2 : L'architecture en couches canonique (la carte de latence que cette unité suit)