Unité 5.5 : Base de données en mémoire (niveau de cache)

Introduction

L'unité 5.3 a établi une limite de plateforme stricte : Managed PostgreSQL et MariaDB sur IONOS n'ont pas de réplicas de lecture, pas de réplication gérée vers un second Cluster, et pas de réplication inter-région. Les réplicas synchrones et asynchrones à l'intérieur d'un Cluster existent pour le basculement, et non pour servir le trafic de lecture. Cela laisse une question évidente pour toute charge de travail lourde en lecture : d'où vient la mise à l'échelle de la lecture ? La réponse se trouve dans cette unité. Le niveau de cache In-Memory DB absorbe la charge de lecture que serait portée par un réplica de lecture relationnel, et en faisant cela, il comble le fossé sans réplica de lecture avec un modèle natif plutôt qu'une fonctionnalité manquante.

Le même niveau effectue un deuxième travail qui compte tout autant. L'unité 4.3 a montré que VM Auto Scaling ne peut ajouter ou supprimer des réplicas sans état en toute sécurité. Toute session, verrou ou état transitoire qui vit dans la mémoire d'un Node de calcul est perdu le moment où ce Node est mis à l'échelle. Externaliser cet état dans un niveau partagé en mémoire est ce qui rend la couche d'application réellement sans état, et donc ce qui rend la mise à l'échelle automatique sûre. Cette unité se termine par la construction du Cluster dans le Data Center Designer et la connexion sur le réseau privé devant la couche relationnelle.

1. Le niveau de mise à l'échelle de lecture et d'externalisation d'état

In-Memory DB est proposé via IONOS DBaaS en tant que magasin de clés-valeurs géré, compatible OSS, épinglé à la version stable 7.2 du Redis OSS legacy. Il s'agit d'un serveur de structure de données, et non seulement d'un cache plat : il stocke des chaînes, des hachages, des listes, des ensembles, des ensembles triés, des bitmaps, des hyperloglogs, des index géospatiaux et des flux. Cette largeur permet à un niveau de servir deux rôles architecturaux à la fois.

Pourquoi il remplace les réplicas de lecture. Un réplica de lecture relationnel met à l'échelle les lectures en dupliquant le jeu de données sur un autre Node qui répond aux requêtes SELECT ; IONOS DBaaS ne propose pas cela. Au lieu de cela, l'application lit à travers un cache : la première requête pour une valeur manque et touche PostgreSQL ou MariaDB, le résultat est écrit dans In-Memory DB, et chaque requête suivante est servie à partir de la mémoire à une latence inférieure à la milliseconde sans toucher la base de données. L'utilisation du cache minimise les requêtes de base de données, réduisant considérablement le trafic et les ressources nécessaires, permettant ainsi une couche de mise à l'échelle rapide et rentable. Le principal relationnel reste petit car il ne voit que les manques et les écritures, tandis que le débit de lecture est mis à l'échelle avec la mémoire du cache plutôt que les cœurs de la base de données. C'est le choix de conception indiqué dans l'unité 2.4 en tant que mise à l'échelle basée sur le cache : vous achetez RAM dans le niveau de cache au lieu de mettre à l'échelle verticalement la base de données.

Pourquoi c'est la condition préalable de la mise à l'échelle automatique. Lorsque le niveau d'application conserve l'état de session dans la mémoire du processus local, chaque événement de mise à l'échelle vers le bas détruit les sessions fixées au Node supprimé, et chaque événement de mise à l'échelle vers le haut démarre un Node froid que les autres requêtes ne peuvent pas voir. Déplacer l'état de session et l'état transitoire dans le niveau partagé In-Memory DB signifie que n'importe quel réplica de calcul peut servir n'importe quelle requête, ce qui est exactement la condition préalable sans état requise par l'unité 4.3 avant qu'un groupe de mise à l'échelle automatique basé sur les métriques puisse ajouter ou supprimer des nœuds Dedicated Core sans rompre les utilisateurs. Le niveau de cache est donc la moitié de lecture du modèle sans réplica de lecture (5.3) et la moitié d'externalisation d'état de la mise à l'échelle automatique sécurisée (4.3).

Ce que la mise à l'échelle du cache fait et ne fait pas. Un In-Memory DB Cluster est mis à l'échelle de deux manières, et la distinction est facile à mal comprendre. La mise à l'échelle verticale modifie les cœurs et RAM par Node et constitue la façon dont vous augmentez le débit ; les nœuds sont modifiés après avoir été arrêtés, donc les grappes multi-Node conservent la perturbation minimale en changeant d'abord les secondaires, puis le principal. La mise à l'échelle horizontale modifie le nombre de nœuds, mais la documentation est explicite : cela fournit uniquement une haute disponibilité et n'augmentera pas les performances : le principal accepte toutes les lectures et les écritures et les secondaires sont une capacité de secours pour le basculement automatique, et non des points de terminaison de lecture supplémentaires. Ainsi, le cache met à l'échelle les lectures à travers la taille de la mémoire, et non en répartissant les lectures sur les réplicas, mirroring la réalité sans réplica de lecture du niveau relationnel un niveau plus haut.

1.1 FinCorp : fermer le fossé de mise à l'échelle de lecture

Le chemin de lecture du portail client de FinCorp était le problème ouvert laissé par l'unité 5.3. Les vues de résumé de compte et d'historique des transactions sont lues beaucoup plus souvent qu'elles ne sont écrites, et le PostgreSQL Cluster réglementé sur le niveau de données privé ne peut pas être mis à l'échelle en ajoutant des réplicas de lecture. FinCorp place un In-Memory DB Cluster sur le même LAN privé, devant le PostgreSQL Cluster, et achemine les lectures du portail à travers celui-ci. Les résumés de compte chauds sont servis à partir de la mémoire ; la base de données n'est touchée que lors d'une erreur de cache ou d'une écriture. Le même Cluster contient l'état de session du portail, donc le niveau web public sans état peut être placé sous le groupe de mise à l'échelle automatique Dedicated Core conçu dans l'unité 4.3 sans perdre les sessions lorsque les nœuds sont mis à l'échelle vers le bas. Un niveau géré résout les deux contraintes, et il ne quitte jamais le réseau privé.

2. Cache-Aside vs Write-Through

Le cache n'aide que si l'application l'intègre avec une stratégie de lecture et d'écriture délibérée. Deux modèles dominent, et le choix est une décision d'architecture d'application que la plateforme ne prend pas pour vous.

Le tableau suivant oppose les deux modèles d'intégration :

Cache-aside est la valeur par défaut pour un niveau de mise à l'échelle de lecture car il ne met en cache que les données réellement demandées, en gardant la mémoire du cache concentrée sur l'ensemble de travail. Son coût est le « cold-miss » lors du premier accès et la discipline d'invalidation ou de rafraîchissement d'une clé à chaque écriture pour que le cache ne serve pas une valeur obsolète après les modifications de la base de données. Pour le portail de FinCorp, où un petit ensemble de comptes est lu constamment et la plupart sont lus rarement, cache-aside garde l'ensemble de travail « chaud » résident et laisse la longue traîne à la base de données.

Write-through maintient le cache autoritaire immédiatement après une écriture en écrivant les deux magasins ensemble, ce qui convient aux données lues très peu de temps après leur écriture. Il paie cette fraîcheur avec une latence d'écriture, car chaque écriture attend maintenant les deux magasins, et il peut remplir le cache avec des entrées qui ne seront jamais lues par la suite.

Une règle pratique : choisissez un délai de vie pour les clés mises en cache qui correspond à la façon dont une valeur peut être obsolète, et traitez l'expulsion comme une sauvegarde, et non comme le mécanisme d'expiration principal. Puisque le cache se substitue à la mise à l'échelle de lecture et n'est pas un système d'enregistrement, l'application doit toujours être en mesure de reconstruire n'importe quelle valeur à partir du niveau relationnel en cas de défaillance. Les options de persistance ci-dessous durcissent le cache contre les redémarrages, mais le niveau relationnel Cluster reste la source de vérité.

3. Placement, dimensionnement et expulsion

3.1 Placement sur réseau privé

In-Memory DB est connecté à une seule connexion réseau : une connexion LAN privée unique par Cluster, définie par un centre de données, un identifiant LAN et un IP dans le sous-réseau de ce LAN. Il n'y a pas de point de terminaison public et pas de gestion d'adresse IP pour le Cluster, vous choisissez donc un IP à l'intérieur de votre sous-réseau (ou utilisez l'adresse IP du sous-réseau que la plateforme attribue sous DHCP) et le Cluster devient accessible à cette adresse après la mise en service. C'est le même placement de niveau de données privées utilisé pour les bases de données relationnelles et de documents dans ce module : le cache est situé sur le réseau LAN privé devant la base de données Cluster relationnelle, accessible uniquement depuis le niveau application et le niveau base de données, et jamais depuis Internet. Les clients se connectent via TLS uniquement si le Cluster a été explicitement configuré pour l'utiliser (TLS n'est pas activé par défaut), avec le certificat serveur émis par Let's Encrypt lorsqu'il est activé, donc l'architecte doit décider d'activer TLS, puis avoir le client se connecter avec l'option TLS et le certificat CA correspondant.

Les plages d'adresses IP suivantes sont réservées par la plateforme et ne peuvent pas être utilisées pour les connexions In-Memory DB :

3.2 Dimensionnement à partir de RAM et de la persistance

Vous n'approvisionnez pas directement le disque du cache. Vous choisissez le nombre de cœurs CPU et les RAM par Node, et la plateforme déduit le stockage approvisionné Block Storage à partir du RAM configuré et du mode de persistance choisi, avec un minimum de 10 Go par Node appliqué pour chaque mode. La relation est fixe :

Le mode de persistance est le levier de dimensionnement qui compte le plus. La valeur par défaut est Aucune, ce qui signifie que le jeu de données n'existe que en mémoire et est perdu en cas de redémarrage ; pour un cache de lecture pure qui peut toujours se reconstruire à partir du niveau relationnel, Aucune est souvent le choix correct et le moins coûteux. RDB écrit des instantanés ponctuels périodiques ; AOF enregistre chaque opération d'écriture et peut reconstruire le jeu de données en cas de redémarrage ; RDB_AOF combine les deux pour la configuration la plus durable et la plus gourmande en stockage. Le compromis est direct : une durabilité accrue multiplie le stockage approvisionné par rapport à RAM, donc un Node de 32 Go dimensionné au maximum coûte 32 Go de disque sous Aucune mais 256 Go sous RDB et AOF. Dimensionnez les RAM en fonction de votre jeu de travail plus la marge pour l'expulsion, puis choisissez le mode de persistance le plus bas que les exigences de récupération de la charge de travail autorisent.

Les plafonds durs, par rapport à votre quota de contrat, sont d'un maximum de 16 cœurs CPU, 32 Go RAM et 2 To de stockage par Cluster, jusqu'à 5 nœuds par Cluster. Le moteur Valkey sous-jacent a une valeur par défaut d'un maximum de 10 000 connexions clientes (maxclients), ce qui est une valeur par défaut technologique plutôt qu'une limite IONOS publiée.

3.3 Expulsion

Lorsqu'un cache Node atteint sa limite de mémoire pour les données entrantes, la politique d'expulsion décide de ce qui est supprimé. La politique par défaut est allkeys-lru, qui expulse la clé la moins récemment utilisée parmi toutes les clés, ce qui est le comportement correct pour un cache de lecture générale où toute clé est un candidat pour la suppression. L'ensemble des politiques prises en charge est noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random, et volatile-ttl. Les politiques volatile-* n'expulsent que les clés qui portent une date d'expiration, ce qui convient lorsque certaines clés ne doivent jamais être expulsées ; noeviction rejette les nouvelles écritures une fois la mémoire pleine, ce qui transforme un cache en un point de défaillance dur et est rarement correct pour un niveau de mise à l'échelle. Pour un niveau de lecture à côté du cache, conservez la politique par défaut allkeys-lru (ou allkeys-lfu si la fréquence d'accès est un meilleur signal que la récence) afin que le cache fasse toujours de la place pour le jeu de travail actuel.

DCD Marche à suivre pour la mise en œuvre

Ce guide de mise en œuvre provisionne un seul In-Memory DB Cluster et le place sur le centre de données privé de FinCorp afin que l'application puisse l'utiliser comme cache de lecture à travers le PostgreSQL Cluster de l'Unité 5.3. Le prérequis est un VDC existant avec au moins un serveur sur un LAN privé : le Cluster doit rejoindre un LAN privé existant, et vous devez avoir un IP dans le sous-réseau de ce LAN pour l'attribuer. Réutilisez le VDC et le LAN de données privées de FinCorp créés dans le Module 3.

Objectif de construction : Mettre en place le cache et le configurer comme couche de lecture.

Étapes (dans le Data Center Designer) :

1. Dans le DCD, allez à Menu > Bases de données > In-Memory DB. La vue d'ensemble du In-Memory DB Cluster s'ouvre et affiche les ressources allouées à votre contrat.
2. Cliquez sur Créer Cluster.
3. Définir les propriétés du Cluster. Entrez un nom de Cluster ; laissez la Version à la valeur par défaut 7.2. Définissez Instances sur le nombre de nœuds : choisissez 1 pour un cache à un seul Node ou jusqu'à 5 pour une haute disponibilité. N'oubliez pas que les nœuds supplémentaires fournissent une redondance, et non une augmentation du débit de lecture. Si vous définissez plus d'un Node, une option de Type de réplication apparaît ; elle est asynchrone par défaut pour In-Memory DB.
4. Sélectionner le nombre de ressources requis. Utilisez les curseurs pour définir le Nombre de CPU et la Taille de RAM par instance. RAM est la décision de taille réelle : taillez-le à l'ensemble de travail, car le multiplicateur de persistance et le disque par Node dérivent de celui-ci. Restez dans les limites de 16 cœurs et 32 Go par Cluster.
5. Connecter le Cluster à un VDC. Sélectionnez le centre de données, le LAN privé et une Adresse IP (avec CIDR) à l'intérieur du sous-réseau de ce LAN. Une seule connexion est autorisée par Cluster, et elle doit être privée. Choisissez une adresse qui ne entre pas en conflit avec les hôtes existants et qui n'est pas dans une plage réservée.
6. Planifier la maintenance du Cluster. Définissez le jour de la semaine et l'heure de début de la fenêtre de maintenance hebdomadaire. Choisissez une véritable période de faible trafic plutôt que de la laisser non planifiée, car les mises à jour de version et les redémarrages se produisent ici et peuvent brièvement interrompre les connexions.
7. Définir les utilisateurs. Entrez un Nom d'utilisateur et un Mot de passe pour le Cluster. Ces informations d'identification ne peuvent être définies qu'à la création et ne peuvent pas être modifiées par la suite, donc enregistrez-les immédiatement dans votre magasin de secrets.
8. Examinez le coût estimé affiché pour la configuration, puis cliquez sur Enregistrer. L'état du Cluster affiche Occupé pendant la création et Disponible lorsqu'il est prêt ; la plateforme ne vous avertit pas, donc interrogez jusqu'à ce que l'état soit Disponible.

Une fois le Cluster disponible, pointez le client de cache de l'application vers l'adresse IP privée attribuée sur le port par défaut 6379 (sur TLS si vous l'avez activé lors de la configuration de l'instance), et mettez en œuvre le chemin de lecture du cache-aside de la Section 2 : vérifiez le cache, revenez à PostgreSQL en cas de défaillance, et peuplez le cache sur le chemin du retour.

Erreurs courantes :

• Traiter les nœuds supplémentaires comme une mise à l'échelle de la lecture. L'ajout de nœuds fournit uniquement une haute disponibilité et n'augmente pas les performances ; mettez à l'échelle les lectures avec plus de RAM et une redimensionnement vertical, et non avec plus de répliques.
• Oublier que les informations d'identification sont définies uniquement à la création. Le nom d'utilisateur et le mot de passe ne peuvent pas être mis à jour plus tard, donc enregistrez-les au moment de la création ; la récupération d'un mot de passe perdu signifie reconstruire le Cluster.
• Laisser la persistance au mauvais niveau pour le coût. Aucun ne perd toutes les données au redémarrage, mais provisionne le moins de disque ; RDB et AOF ensemble provisionnent 8 fois la RAM en disque. Pour un cache de lecture pure qui se reconstruit à partir de la base de données, Aucun est généralement correct.
• Choisir noeviction pour un cache à mise à l'échelle. Lorsque la mémoire est pleine, noeviction rejette les nouvelles écritures et transforme le cache en point de défaillance ; conservez la valeur par défaut allkeys-lru, à moins qu'une clé spécifique ne doive jamais être évincée.
• Attribuer un IP dans une plage réservée, ou attendre une seconde connexion. Un Cluster prend exactement une connexion LAN privée, et les plages réservées par la plateforme (par exemple 10.233.0.0/18) ne peuvent pas être utilisées.
• Ne pas planifier une véritable fenêtre de maintenance. Les mises à jour et les redémarrages s'exécutent dans la fenêtre hebdomadaire et peuvent brièvement interrompre les connexions, donc placez-la délibérément dans une période calme et faites en sorte que les clients se reconnectent.

Une courte connexion client illustre la contrainte TLS-et-point de terminaison privé que l'écriture établit :

redis-cli -h 192.168.1.100 -p 6379 --tls --cacert ca.crt -a "$PASSWORD" ping

L'hôte est le LAN IP privé attribué à l'étape 5, le port est le port par défaut 6379, et la paire --tls --cacert n'est nécessaire que si TLS a été activé lors de la configuration de l'instance (le point de terminaison géré met fin à TLS avec un certificat Let's Encrypt lorsqu'il est activé, mais TLS n'est pas activé par défaut). Il n'y a pas d'adresse publique pour se connecter, ce qui est le but : le cache n'est accessible qu'à partir de l'intérieur du centre de données virtuel.

Résumé

Le niveau de cache In-Memory DB est le seul composant qui résout deux limites de plateforme à la fois. Il est le substitut natif des répliques de lecture que Managed PostgreSQL et MariaDB ne proposent pas, en absorbant la charge de lecture via la mémoire de sorte que la base de données principale ne voit que les écritures et les erreurs de cache, et il est le magasin d'état partagé qui rend le niveau d'application réellement sans état et donc sûr à mettre sous VM Auto Scaling. Conçu sur le niveau de données privé avec un chemin de lecture avec cache, dimensionné à partir de RAM et du mode de persistance, et laissé sur son paramètre d'éviction par défaut, il permet à FinCorp de mettre à l'échelle les lectures et de mettre à l'échelle le calcul sans jamais introduire une réplique de lecture de base de données ou un point de terminaison public.

Points clés :

• Il n'y a pas de répliques de lecture relationnelles sur IONOS ; le cache In-Memory DB est la façon dont vous mettez à l'échelle les lectures, en servant l'ensemble de travail actif à partir de la mémoire et en touchant la base de données uniquement en cas d'erreurs et d'écritures.
• Le cache est également le niveau d'externalisation de l'état qui rend la condition préalable d'un état sans état pour l'auto-mise à l'échelle (Unité 4.3) réel.
• L'ajout de nœuds au Cluster fournit une haute disponibilité, et non une bande passante de lecture ; augmentez la capacité en ajoutant RAM et en redimensionnant verticalement.
• Le disque provisionné est dérivé de RAM multiplié par le multiplicateur de persistance (Aucun 1x, RDB 2x, AOF 4x, RDB+AOF 8x), avec un plancher de 10 Go par Node ; choisissez le niveau de persistance le plus bas que les exigences de récupération permettent.
• Le Cluster prend exactement une connexion privée LAN, avec TLS disponible si vous l'activez lors de la configuration de l'instance, n'a pas de point de terminaison public, et ses informations d'identification sont fixes lors de la création ; le paramètre d'éviction par défaut allkeys-lru est correct pour un cache de lecture.
• Le mode de persistance In-Memory DB (Aucun, RDB, AOF ou RDB_AOF) contrôle si les données survivent à un redémarrage et, à travers un multiplicateur fixe sur RAM, la quantité de Block Storage que le Cluster provisionne.

Terminologie importante :

• Cache-aside : Un modèle de lecture où l'application lit le cache, revient à la base de données en cas d'erreur, et remplit le cache avec le résultat ; les écritures vont à la base de données et invalident ou mettent à jour la clé mise en cache.
• Write-through : Un modèle où l'application écrit dans le cache et la base de données ensemble, en gardant le cache autoritaire immédiatement après une écriture au coût d'une latence d'écriture.
• Mode de persistance : Le paramètre In-Memory DB (Aucun, RDB, AOF ou RDB_AOF) qui contrôle si les données survivent à un redémarrage et, à travers un multiplicateur fixe sur RAM, la quantité de Block Storage que le Cluster provisionne.
• Politique d'éviction : La règle (par défaut allkeys-lru) qui décide quelles clés sont supprimées lorsque un Node atteint sa limite de mémoire.

Lecture supplémentaire

• Unité 5.3 : Bases de données relationnelles, pour la limite de non-réplica de lecture cette couche ferme
• Unité 4.3 : Élasticité et VM Auto Scaling, pour la précondition sans état cette couche satisfait
• Unité 2.4 : Architecture de coût et FinOps, pour l'économie de mise à l'échelle basée sur le cache par rapport à la mise à l'échelle verticale de la base de données