DBaaS : AWS renforce (encore) son offre serverless
Au cours de son événement re:Invent 2023 à Las Vegas, AWS a présenté de nouveaux services et des mises à jour de ses offres de bases de données et d’entreposage serverless. Le géant du cloud entend automatiser la gestion du partitionnement de données et l’optimisation des charges de travail… à l’instar de ce que propose Oracle et Snowflake.
Lors de son Saturday Night Live, Peter DeSantis, désormais responsable du développement des services de calcul (et non plus de l’infrastructure), a remis le couvert sur l’approche serverless d’AWS.
L’occasion d’annoncer de nouveaux services et des mises à jour pour des solutions de bases de données et d’entrepôts de données. Comme promis lors d’un partenariat annoncé avec IBM en 2022, AWS accueille Db2 en mode BYOL (Bring Your Own Licence) depuis son SGBD RDS.
Mais l’annonce de la préversion privée d’Aurora Limitless Database a davantage été mise en avant lors de la première journée de l’événement re:Invent 2023. Cette version d’Aurora est dotée d’une capacité de scalabilité horizontale capable de traiter « des millions d’écritures par seconde et des pétaoctets de données ».
Aurora Limitless Database : une nouvelle architecture pour automatiser le « sharding » des données
Ici, il s’agit de faire sauter les limites inhérentes à Aurora et à la base de données PostgreSQL (pour le moment).
Pour Aurora, AWS avait déjà mis en place un système de sharding. Le sharding est une technique consistant à diviser les données en petite partition afin d’améliorer la scalabilité et leur traitement en parallèle. Or, ce mécanisme n’est utilisé qu’en dernier recours, selon Doug Henschen, analyste chez Constellation Research.
« Lorsque les clients atteignaient la limite de la mise à l’échelle verticale, c’est-à-dire qu’ils avaient déjà utilisé les instances de calcul les plus puissantes, ils devaient se résoudre à répartir les données sur plusieurs instances de base de données », résume-t-il, dans un billet de blog. « Il s’agit d’une pratique courante pour les déploiements de grandes bases de données, mais le partage manuel au niveau de la couche applicative introduit une complexité et des charges administratives ».
« D’abord, vous devez constituer votre propre couche de routage et d’orchestration, ensuite il faut gérer les shards (ou tessons). À l’échelle, il se peut que vous gériez des dizaines, voire des centaines de shards », confirme Peter DeSantis. « Toutes les charges applicatives ne sont pas uniformes à travers toutes ces partitions. Donc, il faut adapter l’élasticité des [instances de] shards à la hausse et à la baisse en fonction de la charge ».
Les choses seraient particulièrement complexes au moment d’effectuer des changements transactionnels à travers plusieurs shards.
Pour contourner ces limites, AWS a revu son architecture dans le but de séparer la gestion du sharding du routage des transactions.
Limitless Database est donc constitué de nœuds de sharding et de nœuds de routage de transaction. Ils sont réunis dans des grappes (DB Shard Group) adressables par un seul point de terminaison.
Les données sont automatiquement routées vers les partitions et « il est possible de configurer le service pour colocaliser les lignes de différentes tables dans un même shard afin de minimiser le nombre de requêtes à effectuer », déclare le SVP, Utility Computing Products chez AWS.
De manière générale, Aurora Limitless Database doit assurer la consistance des données (ACID) à travers tous les tessons.
Les routeurs agissent comme une couche d’orchestration légère qui n’utilise qu’une petite portion de données pour comprendre le schéma de la base de données et la répartition des shards.
« Les routeurs de transactions gèrent les métadonnées relatives à l’emplacement des données, analysent les requêtes SQL entrantes et les envoient aux grappes, agrègent les données des grappes pour renvoyer un résultat unique au client et gèrent les transactions distribuées afin de maintenir la cohérence de l’ensemble de la base de données distribuée », explique Channy Yun, principal developer advocate chez AWS, dans un billet de blog.
La gestion des shards est fonction de l’hyperviseur Caspian Heat Manager, une technologie interne à AWS. Celui-ci ne répartit pas les shards en fonction de la consommation de CPU, mais de la mémoire. Caspian s’appuie sur la technique du surabonnement de mémoire (memory oversubscription) pour l’allocation dynamique des ressources.
Le système de stockage distribué d’Aurora se nomme, en interne, Grover. « Grover nous permet de découpler notre SGBD de la couche de stockage physique », explique Peter DeSantis.
Cette couche logique gère le mécanisme WAL (Write Ahead Logs) afin de répliquer les logs dans différentes zones de disponibilités. « Grover ne fait pas que de stocker les logs, il les traite et crée une copie identique de la structure de la mémoire de la base de données sur le système distant. Ces structures de données peuvent renvoyer vers la mémoire de la base de données Aurora afin de réduire les I/O et assurer la durabilité des données ».
C’est cette capacité qui est utilisée dans Limitless Database pour « séparer un shard en deux. Une fois cela fait, nous pouvons utiliser notre flotte de routeurs, pour mettre à jour la couche de routage sans que le client de la base de données soit au courant de ces changements », avance Peter DeSantis.
Un réseau dédié à la synchronisation temporelle des serveurs
Pour l’isolation et la consistance de ce système distribué, il faut s’assurer de leur synchronisation temporelle entre les serveurs. Il suffit en principe d’horodater les opérations de la base de données. En principe seulement, selon Peter DeSantis. « Une horloge standard d’un serveur dérive d’environ une seconde par mois. Certains serveurs vont être en avance, d’autres en retard », avance-t-il. « Une seconde, cela ne paraît pas grand-chose, mais dans ce cas-là cette horloge n’a plus d’utilité pour garantir un horodatage ».
La synchronisation des horloges des serveurs EC2 passe par un service appelé Amazon Time Sync, qui, par le passé, assurait une latence d’une milliseconde entre les horloges. Or, vérifier que les serveurs sont synchronisés réclame deux fois plus de temps et impacte le volume de transaction par seconde.
Ce délai est dû au système d’exploitation, à la latence réseau, aux équipements qui ne sont pas forcément adaptés pour effectuer cette synchronisation à l’échelle d’une ou de plusieurs régions.
En conséquence, les équipes d’AWS ont modifié le système afin de synchroniser les horloges en quelques microsecondes. Ce résultat n’était pas possible sans changer l’infrastructure physique.
Cette synchronisation est délivrée par une impulsion poussée à travers un réseau dédié à la synchronisation temporelle, lui-même piloté par l’hyperviseur Nitro. AWS a dédié des racks 48U pour recevoir par satellite l’heure d’une horloge atomique. « Chacun de ces racks a également une horloge atomique locale, pour conserver cette synchronicité si le satellite n’est pas disponible », explique Peter DeSantis. « Chaque zone de disponibilité dispose de plusieurs de ces racks de distribution temporelle ».
Dans chaque rack, AWS a placé une appliance dédiée, développée en interne. Elle fait interagir une puce Nitro et un FPGA, pour distribuer l’impulsion temporelle, ainsi qu’un ASIC chargé uniquement de la synchronisation des horloges. « Cette synchronisation est effectuée exclusivement au niveau du matériel et le système permet de distribuer l’impulsion directement aux serveurs EC2 connectés », vante le SVP Utility Computing Products chez AWS.
ElastiCache a aussi le droit à son mode serverless
Ces technologies sont également utilisées pour propulser ElastiCache Serverless. Ce service en disponibilité générale est compatible avec les dernières versions majeures en date de Redis (7.1) et de Memcached (1.6).
Selon AWS, ce service permet d’obtenir une couche de cache hautement disponible depuis un seul point de terminaison, répliquée automatiquement sur plusieurs zones de disponibilité, permettant d’obtenir un SLA de 99,99 %.
« Ici, ce sont les shards du cache qui sont exécutés à l’aide de Caspian, afin d’équilibrer la charge », assure Peter DeSantis.
La seule grosse différence avec Limitless Database tient dans une optimisation de la couche de routage « qui ne peut souffrir d’aucune latence ». Aussi, la création des shards est gérée par le moteur de base de données choisie.
AWS revendique une latence de 500 microsecondes dans 50 % des cas (p50) et de 1,2 milliseconde dans 99 % des cas (p99). ElastiCache Serverless prend en charge jusqu’à cinq téraoctets de mémoire.
La promesse d’AWS, c’est de supprimer le besoin d’écrire des logiques personnalisées, de gérer plusieurs couches de cache ou l’utilisation d’un proxy tiers afin de répliquer les données. Ce serait notamment très utile pour MemCached qui ne bénéficierait pas par défaut de ces mécanismes de haute disponibilité, selon AWS.
La facturation du service dépend des ressources consommées, à savoir le volume de gigaoctets de données, stockées à l’heure, le nombre d’unités de calcul consommées et le volume de données stockées dans un snapshot par mois.
AWS tente de rattraper Oracle et Snowflake, selon Constellation Research
Doug Henschen de Constellation Research retient surtout les annonces d’Aurora Limitless Database et la mise à jour de RedShift Serverless. Le géant du cloud pose là les arguments techniques afin de maintenir la compétition avec son rival préféré, Oracle.
« Étant donné qu’Aurora est si compétitive en matière de coûts [...], Aurora Limitless Database est un pas en avant important pour potentiellement égaler des rivaux tels qu’Oracle sur l’évolutivité automatisée. »
Doug HenschenAnalyste, Constellation Research
« Aurora Limitless Database va intensifier la concurrence avec la base de données numéro un au monde et la plus grande cible concurrentielle d’Aurora, Oracle Database », affirme l’analyste.
AWS ne ferait là que rattraper son retard alors que son concurrent a introduit un mécanisme de sharding automatisé en 2017, poursuit-il. « Néanmoins, étant donné qu’Aurora est si compétitive en matière de coûts (vantée même comme un dixième du coût de ses rivaux), Aurora Limitless Database est un pas en avant important pour potentiellement égaler des rivaux tels qu’Oracle sur l’évolutivité automatisée », souligne Doug Henschen.
Pour RedShift Serverless, AWS utilise une autre technique. Les logs du datawarehouse managé ont été utilisés pour entraîner des modèles de machine learning afin d’identifier les charges de travail et de prédire leur évolution dans le temps. L’idée est de détecter les changements de volume de données, les usages concurrents, la complexité des requêtes. En fonction des patterns identifiés, le système peut automatiquement ajuster les capacités à la hausse ou à la baisse afin de répondre aux cas d’usage. Les administrateurs peuvent ajuster un paramètre suivant s’ils souhaitent minimiser les coûts ou maximiser les performances. « Des tests internes démontrent que ces optimisations peuvent vous permettre d’obtenir un rapport prix-performance jusqu’à 10 fois supérieur pour des charges de travail variables, sans intervention manuelle », assure AWS.
« Les prévisions et l’optimisation des charges de travail à l’aide du machine learning sont bien connues dans le monde du data warehousing. Ces techniques ont été mises en œuvre par des entreprises telles qu’Oracle et Snowflake », rappelle l’analyste de Constellation Research.
« Ici aussi, AWS rattrape son retard, mais l’attrait de Redshift réside dans le fait qu’il s’agit d’une option d’entreposage de données compétitive en termes de coûts au sein de l’écosystème AWS », remarque à nouveau Doug Henschen.
« Le fait d’égaler les rivaux en ajoutant des capacités sophistiquées de mise à l’échelle et d’optimisation basées sur le ML avec des garde-fous en matière de coûts rendra RedShift plus efficace et plus performant, mais aussi plus compétitif », conclut-il.
