Unité 7.3 : Ingénierie de performance

Introduction

Les performances sur IONOS Cloud sont conçues à la conception, et non réglées après coup. La plateforme expose un petit nombre de décisions qui dominent la latence et le débit de bout en bout : sur quel niveau de stockage un Volume est situé et quelle est sa taille, si un niveau de base de données est précédé d'un pooler et d'un cache, et où chaque niveau se situe sur le chemin réseau en couches que vous avez établi dans l'Unité 1.2. Si vous faites ces choix correctement, l'architecture fonctionne de manière prévisible sous charge ; si vous les faites incorrectement, aucun réglage ultérieur ne peut récupérer la marge perdue.

Cette unité synthétise les décisions prises dans les modules précédents en une seule vue des performances. Elle suppose les classes de calcul de l'Unité 4.1, les niveaux Block Storage des Unités 4.2 et 5.1, le modèle sans réplica 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ées de FinCorp ancre les décisions travaillées.

1. Niveaux de performances de stockage et sélection de niveau

Block Storage sur IONOS est un dispositif de bloc iSCSI disponible en tant que HDD, SSD Standard et SSD Premium. Le critère de sélection est rarement la capacité, puisque les trois niveaux atteignent le même maximum de 4 To par Volume. Le critère est le profil de performance, et les deux niveaux SSD se comportent de manière très différente par rapport à HDD.

Les performances de HDD sont statiques et indépendantes de la taille de Volume : chaque HDD Volume offre les mêmes 200 Mo/s de lecture/écriture séquentielle à une taille de bloc de 1 Mo et 1 100 IOPS à 4 Ko (avec des pics plus élevés). Un HDD Volume de 50 Go et un HDD Volume de 2 To fonctionnent de manière identique. Cela rend HDD prévisible mais plat, adapté à l'accès en bloc et aux archives séquentielles plutôt qu'aux bases de données transactionnelles.

Les performances de SSD sont à l'opposé : elles évoluent avec la taille de Volume jusqu'à une limite. Le tableau suivant présente le profil de performance documenté de la plateforme pour SSD.

Puisque le débit et les IOPS de SSD s'accumulent par gigaoctet, un petit SSD Volume peut limiter une charge de travail exigeante. La plateforme recommande de réserver des volumes SSD d'au moins 100 Go pour bénéficier pleinement des hautes performances de SSD ; les volumes plus petits sont autorisés mais fonctionnent de manière sous-optimale. Pour les charges de travail de base de données, cette limite de 100 Go est la règle porteuse : un SSD Volume en dessous d'environ 100 Go dégraderait un niveau de base de données, même si son jeu de données est minuscule. Les performances que Data Center Designer prédit pour un Volume sont dérivées de sa taille, et pour SSD, elles sont plafonnées une fois que Volume dépasse 600 Go, aux plafonds par VM de 45 000 lectures IOPS et 600 Mo/s de débit séquentiel pour SSD Premium.

La conséquence de conception est directe. Vous dimensionnez un SSD Volume de base de données en fonction des performances en premier, puis de la capacité en second. La base de données transactionnelle de FinCorp ne contient que quelques dizaines de gigaoctets de données actives, mais la provisionner sur un SSD Volume de 40 Go se situerait en dessous du plancher de performance et limiterait le niveau même qui supporte la charge de travail réglementée de l'entreprise. Le Volume est donc provisionné à ou au-dessus de 100 Go, indépendamment de l'empreinte des données, et sur SSD Premium afin que l'allocation de IOPS par gigaoctet soit doublée par rapport à SSD Standard. Les archives d'audit de masse, en revanche, sont séquentielles et sensibles au coût, elles atterrissent donc sur HDD où la taille n'affecte pas les performances, ou sur Object Storage entièrement.

2. Moyens d'augmentation du débit : regroupement, mise en cache et plafonds Node

Une fois que le stockage est correctement hiérarchisé, la prochaine question de performance est la concurrence, et c'est ici que les limites honnêtes de la plateforme façonnent la conception. Managed PostgreSQL et MariaDB n'ont pas de réplicas de lecture (Unité 5.3). Vous ne pouvez pas mettre à l'échelle les lectures en ajoutant des points de terminaison de réplica, donc les moyens d'augmentation du débit sont le regroupement de connexions et la mise en cache.

Le plafond de connexion n'est pas un réglage. Le max_connections de PostgreSQL est calculé à partir de Cluster RAM et n'est pas configurable par l'utilisateur, allant de 384 connexions à 4 Go RAM à un plafond dur de 1 000 connexions au-dessus de 8 Go, avec 11 connexions réservées pour une utilisation interne de superutilisateur et de réplication. Un niveau d'application qui ouvre une nouvelle connexion par requête épuisera ce plafond longtemps avant d'épuiser CPU. La réponse native est le pooler de connexions géré pgbouncer : DBaaS ne regroupe pas par défaut, mais vous pouvez activer le pooler de connexions géré pgbouncer 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 5432 natif de la base de données. Le regroupement en mode transaction permet à un petit nombre de connexions réelles de serveur de desservir un grand nombre de clients d'application, ce qui maintient un niveau d'application occupé et sans état à l'intérieur du plafond dérivé de RAM.

La mise en cache est le deuxième moyen et celui qui remplace les réplicas de lecture. Le niveau In-Memory DB (Unité 5.5) absorbe le trafic lourd de lecture devant la base de données relationnelle avec une récupération en sous-milliseconde, de sorte que les lectures répétées n'atteignent jamais PostgreSQL du tout. Un seul In-Memory DB Cluster peut absorber beaucoup plus de connexions concurrentes que le niveau relationnel (le moteur Valkey sous-jacent par défaut a un plafond de 10 000 connexions client), ce qui est précisément pourquoi la mise en cache, et non la base de données, est le niveau qui fait face au chemin de lecture à burst. Le positionnement de la mise en cache (Unité 5.5) détermine la cohérence ; de toute façon, la mise en cache est le multiplicateur de débit qui fait que la plateforme sans réplica de lecture est évolutivité.

Le troisième moyen est le calcul horizontal. Un seul Node a un plafond fini, quelle que soit la capacité de stockage et le regroupement, donc les niveaux d'application réellement à haut débit s'étendent derrière un Load Balancer plutôt que de mettre à l'échelle un seul serveur indéfiniment. C'est également là que deux réalités d'équilibrage de charge se manifestent. Premièrement, un service LoadBalancer Kubernetes est un Node statique unique IP, et non un équilibreur de charge distribué géré (Unité 6.1), il est donc lui-même un plafond unique Node, à moins que vous ne placiez le Cluster devant un Managed Application Load Balancer provisionné séparément. Deuxièmement, les équilibreurs gérés distribuent mais n'accélèrent pas : les Managed Network Load Balancer et Managed Application Load Balancer offrent tous deux des algorithmes Round Robin, Least Connections, Random et Source IP, et le choix de l'algorithme détermine comment la charge se répartit uniformément sur les cibles saines, et non comment une cible individuelle s'exécute rapidement. Least Connections lisse les coûts de requête inégaux ; Source IP préserve l'affinité de session au prix d'une répartition uniforme. L'équilibreur d'une charge augmente le débit global uniquement en ajoutant des backends sains, donc la planification de la capacité est en fin de compte une planification de backend.

3. Adaptation de la taille versus sur-approvisionnement

L'adaptation de la taille correspond les ressources à la demande observée et est la valeur par défaut pour l'efficacité coûts. Deux mécanismes de plateforme la rendent moins douloureuse qu'il n'y paraît. CPU, RAM, les cartes réseau et le stockage peuvent être mis à l'échelle en temps réel sur des serveurs Dedicated Core (Unité 4.3), vous pouvez donc commencer petit et grandir sans reconstruire ; seuls CPU et RAM réduisent la taille et un RAM hotplug au-dessus de 240 Go nécessite un redémarrage. Et les performances de stockage SSD augmentent avec le Volume, donc la croissance d'un Volume pour la capacité augmente également son débit, ce qui maintient l'adaptation de la taille et les performances du stockage alignées plutôt que en tension.

Le sur-approvisionnement 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 plancher de la base de données SSD de la Section 1 : vous sur-approvisionnez la capacité pour acheter des performances, car les deux sont couplées sur SSD. Un second cas est la marge de manœuvre sur un niveau qui ne peut pas absorber un redémarrage de manière élégante pendant les heures de pointe, où le coût de transport de pièces de rechange CPU et RAM est moins cher qu'un redémarrage induit par une récupération de réduction de taille. La discipline consiste à sur-approvisionner uniquement lorsque un plancher de performance mesuré ou une contrainte opérationnelle le justifie, et à adapter la taille partout ailleurs.

Le tableau suivant résume où chaque posture s'applique :

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

La forme en couches de l'Unité 1.2 (équilibrage de charge public de la couche 7 à la calcul stateless à l'équilibrage de charge privé de la couche 4 à la couche de données privée) est également une carte de latence. Chaque saut ajoute des aller-retour, et l'objectif de conception est de garder le chemin chaud court et les composants lents en dehors de celui-ci.

Le Managed Application Load Balancer public termine TLS une fois à la limite et transmet au niveau stateless, de sorte que les sauts de back-end peuvent s'exécuter en texte brut sur le LAN privé et éviter les poignées de main répétées. Le niveau stateless ne devrait contenir aucun état de session, à la fois parce que le scaling automatique et la bascule de l'équilibrage de charge l'exigent (Unités 4.3 et 7.1) et parce que l'externalisation de l'état de session vers la couche In-Memory DB transforme une recherche de base de données lente par requête en un cache de sous-milliseconde. L'équilibrage de charge privé de la couche 4 devant la couche 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 trouve au bas du chemin et est protégé à la fois par le pooler (qui le maintient à l'intérieur de son plafond de connexion) et le cache (qui empêche la plupart des lectures d'atteindre celui-ci). La latence est donc gagnée en terminant TLS une fois, en gardant le niveau d'application stateless et avec un cache, et en regroupant chaque connexion de base de données ; elle est perdue par des connexions par requête, des SSD sous-dimensionnés sous la base de données, et des lectures qui tombent dans la couche relationnelle au lieu du cache.

Une nuance matérielle compte à cette altitude. Une bande passante réseau hôte très élevée sur IONOS est une propriété de matériel dédié spécifique, et non de la toile générale Block Storage. Le réseau hôte premium apparaît sur du matériel dédié tel que les hôtes VMware Private Cloud et la plate-forme GPU/HPC-AI, tandis que l'interconnecteur de classe NVLink est spécifique à la plate-forme Cloud GPU (Compute Engine GPU VM), dont les serveurs GPU exposent deux clusters NVLink de quatre GPU chacun, adressés séparément. Ne supposez pas des performances InfiniBand ou RDMA pour les Block Storage généraux ou les LAN de calcul standard ; ceux-ci utilisent la toile de blocs iSCSI et le réseau virtuel standard. Pour FinCorp, la lecture pratique est que le niveau de transaction réglementé sur le calcul standard est conçu grâce à un SSD correct, au regroupement et au cache, tandis que toute charge de travail de formation HPC ou d'IA à faible latence future est une conversation matérielle distincte sur la plate-forme GPU dédiée, et non un attribut que la toile générale fournit.

Résumé de la décision

Résumé

L'ingénierie des performances sur IONOS est un ensemble de placements de conception plutôt qu'un réglage après coup : répartir et dimensionner le stockage en fonction de ses performances, regrouper et mettre en cache la base de données pour fonctionner dans des plafonds de connexion fixes et la limite de réplica de lecture, mettre à l'échelle les couches sans état derrière les équilibreurs de charge qui répartissent plutôt qu'accélèrent, et garder le chemin chaud court à travers l'architecture en couches. La sur-provision est justifiée uniquement lorsque un plancher mesuré ou une contrainte opérationnelle l'exige ; partout ailleurs, la mise à la bonne taille avec une croissance en direct est à la fois moins chère et suffisante.

Points clés :

• Les performances de SSD sont proportionnelles au gigaoctet et se dégradent en dessous d'environ 100 Go, donc les volumes de base de données sont dimensionnés en fonction des performances en premier ; les performances de HDD sont plates et indépendantes de la taille de Volume.
• Il n'y a pas de réplicas de lecture ; le regroupement (pgbouncer géré, mode transaction, port 6432) et le cache de In-Memory DB sont les leviers de débit de lecture, et le plafond de connexion de PostgreSQL est dérivé de RAM jusqu'à 1 000.
• Les équilibreurs de charge gérés répartissent le trafic sur les backends sains mais n'accélèrent aucun backend unique ; un service de Kubernetes LoadBalancer est un Node statique unique IP.
• Mettre à la bonne taille et faire grandir en direct par défaut ; sur-provisionner délibérément uniquement au plancher de la base de données SSD ou sur les couches de pointe qui ne peuvent pas absorber un redémarrage.
• Le réseau hôte premium est une propriété du matériel dédié (VMware Private Cloud et GPU/HPC-AI), et l'interconnect de classe NVLink est spécifique à la plateforme GPU Cloud (Compute Engine GPU VMs), et non au tissu général Block Storage.

Terminologie importante :

• Pooler de connexions (pgbouncer) : Un intermédiaire géré qui multiplexe de nombreux clients d'application sur un petit nombre de connexions de base de données réelles ; activé explicitement, accessible sur le port 6432, par défaut en mode transaction.
• Plancher de performances : La taille minimale de Volume en dessous de laquelle le stockage SSD livre un débit dégradé et IOPS (~100 Go pour les charges de travail de base de données).
• Plafond unique-Node : Le débit fini d'un serveur ou d'un point de terminaison unique-Node, au-delà duquel le seul remède est la mise à l'échelle sur plusieurs backends sains.

Lecture supplémentaire

• Unité 4.2 : Images, disques et Cloud-Init (les niveaux Block Storage et le plancher SSD dans leur contexte)
• Unité 5.3 : Bases de données relationnelles (le modèle sans réplica 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 canonique en couches (la carte de latence que cette unité trace)