Découvrez la base de données qui prend en charge Amazon.com •

  • Français


  • Fonctionnalité sponsorisée Cette année, l’une des créations les plus innovantes d’Amazon a eu dix ans. En janvier 2012, la société a lancé DynamoDB, une base de données NoSQL sans serveur conçue pour être rapide, hautement fiable et rentable. Ce magasin de valeur clé alimente désormais plusieurs des plus grands services de l’entreprise, y compris l’assistant virtuel d’Amazon, Alexa.

    Un article d’Amazon Science détaillant ce qu’Amazon a appris de DynamoDB au cours de la dernière décennie a été récemment publié, accompagné d’un journal de l’innovation continue qui a été apportée au service depuis son lancement. Nous avons parlé à deux des auteurs de l’article, les ingénieurs principaux d’AWS, Akshat Vig et Somu Perianayagam, pour obtenir leur avis sur les principaux enseignements des dix dernières années.

    DynamoDB lui-même était le produit d’une expérience d’apprentissage, se souvient Akshat.

    « Amazon.com avait des équipes internes qui utilisaient des bases de données relationnelles. Nous n’étions pas en mesure de nous adapter aux besoins d’Amazon à l’époque », dit-il. Les systèmes relationnels que l’entreprise utilisait étaient mis à rude épreuve sous le poids de son activité en pleine croissance, culminant avec une série de pannes en 2004 pendant la saison des achats des Fêtes – “Nous savions qu’il devait y avoir une meilleure solution.”

    Amazon a inventé un service interne, Dynamo, pour résoudre ce problème. Il s’agissait d’une base de données clé-valeur axée sur la mise à l’échelle pour répondre aux principaux cas d’utilisation tels que la gestion du panier d’achat et les services de session. L’architecture de Dynamo offrait des performances constantes à grande échelle, permettant aux utilisateurs de prédire ses performances même lorsqu’il fonctionnait à un volume extrême.

    Le besoin de cohérence gérée

    L’adoption de Dynamo parmi les développeurs d’Amazon était initialement limitée et ses architectes ont rapidement compris que la complexité était un facteur. Toute équipe souhaitant utiliser Dynamo devait installer ses propres serveurs et gérer cette infrastructure. C’était un point de friction pour les codeurs occupés qui voulaient juste faire le travail.

    “Ce que les développeurs voulaient, c’était un moyen d’avoir cela en tant que service”, explique Akshat. “Ils voulaient une expérience entièrement gérée.”

    Pour obtenir la flexibilité de NoSQL avec la commodité d’un service géré tel que SimpleDB, Amazon a lancé DynamoDB en 2012. DynamoDB combine les meilleurs éléments de la conception originale de Dynamo – évolutivité incrémentielle et hautes performances prévisibles – avec les meilleurs éléments de SimpleDB, à savoir la facilité d’administration d’un service cloud, de cohérence et d’un modèle de données basé sur des tables qui est plus riche qu’un pur magasin clé-valeur, explique l’entreprise. Le résultat est le résultat de tout ce qui a été appris lors de la création de bases de données non relationnelles à grande échelle pour Amazon.com, combiné plus tard aux expériences de création de services de cloud computing hautement évolutifs et fiables chez AWS.

    DynamoDB gère des tâches telles que le provisionnement des ressources, la récupération automatique en cas de panne, le chiffrement des données et les mises à niveau logicielles, par exemple. Les sauvegardes continues sont toutes traitées en arrière-plan afin que les DBA n’aient pas à s’en soucier.

    DynamoDB diffère de Dynamo à plusieurs autres égards, mis à part sa focalisation sur les services gérés. Il s’agit d’un système multi-tenant, par opposition à l’option à locataire unique de Dynamo. Les clients Dynamo devaient gérer les clusters, mais les clients DynamoDB n’avaient plus besoin de provisionner les clusters. Ils pourraient simplement créer un tableau et le mettre à l’échelle de manière transparente. Il a également découplé le calcul et le stockage dans un changement important par rapport à l’architecture de Dynamo.

    DynamoDB offre un contrôle plus simple et plus précis que Dynamo, mais c’était par conception. Il fournit également une expérience entièrement gérée qui évolue automatiquement vers le haut et vers le bas. Cela représente un modèle mental plus simple pour les clients, leur permettant de créer des applications sans se soucier de l’infrastructure. Il offre également une API et un niveau de cohérence plus simples, éliminant ainsi le besoin de modifier les résolutions de conflits personnalisées.

    “L’idée est que les équipes n’ont pas à devenir des experts dans l’utilisation de la base de données”, explique Somu. “Cela réduit la complexité opérationnelle, en réduisant le réglage et les configurations qui, autrement, deviennent un obstacle à l’adoption.”

    L’avantage d’un magasin clé-valeur est la simplicité et la cohérence, expliquent les experts d’Amazon. Lors de l’accès aux requêtes dans une base de données relationnelle, une organisation exécute généralement des instructions JOIN sur plusieurs tables, ce qui introduit un niveau d’incertitude autour du temps d’opération. De nombreuses applications ont des modèles d’accès très simples qui ne nécessitent pas la complexité offerte par les bases de données relationnelles.

    Un magasin clé-valeur stocke un élément de données sous la forme d’une clé (par exemple, un produit) et d’une valeur, telle que “Tondeuse à gazon robot Glitzy”. Un client peut également stocker des documents JSON en tant que valeurs, en leur donnant plus de détails, mais sans les liens basés sur des tables que vous trouvez dans les systèmes relationnels. L’un des premiers projets de production impliquait un client faisant une publicité pour le Super Bowl où DynamoDB évoluait de manière transparente jusqu’à 100 000 écritures par seconde, explique Akshat. Il a ensuite été réduit après l’événement afin que le client n’encoure plus de frais. C’était un gros problème car ce n’était même pas considéré comme possible à l’époque. Cela semble évident maintenant, mais dans le passé, les bases de données n’étaient pas aussi élastiques ou évolutives.

    DynamoDB fournit un accès rapide aux éléments d’une table en spécifiant des valeurs de clé primaire. Cependant, de nombreuses applications peuvent bénéficier de la disponibilité d’une ou plusieurs clés secondaires (ou alternatives) pour permettre un accès efficace aux données avec des attributs autres que la clé primaire. Pour résoudre ce problème, les développeurs peuvent créer un ou plusieurs index secondaires sur une table et émettre des requêtes Query ou Scan sur ces index.

    Dix ans d’évolution

    Amazon a appliqué les leçons apprises lors de la création et de l’exploitation de Dynamo et SimpleDB lors du déploiement de DynamoDB. “Nous avons travaillé à rebours des clients, en leur demandant ce qu’ils aimaient dans ces produits et ce qui manquait”, explique Somu. L’entreprise a passé les dix dernières années à faire la même chose pour améliorer son service géré, ajoute-t-il.

    En 2013, Amazon a répondu aux demandes des clients pour plus de capacités d’indexation en ajoutant la prise en charge des index secondaires qui prenaient en charge des requêtes plus complexes. Les index secondaires locaux peuvent utiliser des éléments de document à partir du magasin de valeurs d’un enregistrement, créant des clés de tri supplémentaires. Les index secondaires globaux produisent des tables alternatives utilisant différentes clés de partition et de tri pour offrir encore plus d’options d’indexation.

    Le changement peut-être le plus fondamental de DynamoDB, qu’il utilisera par la suite pour piloter de nombreuses autres nouvelles fonctionnalités, a été introduit en 2014. “De nombreux clients demandaient des fonctionnalités telles que les restaurations de sauvegarde, la programmation événementielle, les exportations et les importations vers et depuis S3. “, se souvient Akshat. “Nous sommes retournés à la planche à dessin pour identifier les éléments de base dont nous avions besoin pour prendre en charge tous ces cas d’utilisation.”

    L’équipe a identifié la capture des données modifiées (CDC) comme le Saint Graal. Cette fonctionnalité architecturale identifie et enregistre les modifications de la base de données à la volée, les rendant disponibles pour d’autres processus tels que la restauration ponctuelle – qui permet aux clients de restaurer les données à partir de ces modifications à tout moment jusqu’à 35 jours avant.

    Amazon utilise DynamoDB Streams et Amazon Kinesis Data Streams for DynamoDB pour diffuser ces modifications, les rendant immédiatement disponibles pour d’autres processus et services. Ces processus peuvent inclure des applications d’analyse ou même d’autres bases de données ou entrepôts de données.

    « Pour un système de base de données distribué comme DynamoDB avec des millions de partitions, effectuer une sauvegarde et une restauration n’est pas facile », déclare Akshat.

    CDC aide à alimenter les services de sauvegarde et de restauration, avec d’autres améliorations alimentées par CDC, notamment le moteur de réplication des tables globales qui permet une prise en charge multirégionale et multiactive.

    D’autres demandes de fonctionnalités appelaient des types de fonctionnalités similaires à celles que vous trouveriez dans un système relationnel. “De nombreux clients demandaient un moyen de mettre à jour de manière transactionnelle plusieurs éléments sur plusieurs tables tout en garantissant l’atomicité, la cohérence, l’isolement et la durabilité (ACID)”, se souvient Akshat. “Généralement, dans une base de données distribuée, les transactions sont considérées comme incompatibles avec l’évolutivité.” L’équipe a répondu à cette exigence en utilisant un protocole de commande basé sur l’horodatage pour prendre en charge les transactions ACID à grande échelle.

    DynamoDB a également introduit des fonctionnalités d’importation et d’exportation en bloc. L’importation en bloc permet aux entreprises d’intégrer plus facilement leurs données dans le système en masse, et l’exportation en bloc permet aux entreprises d’exporter leurs données de table vers Amazon S3 où elles peuvent utiliser le service de requête interactif Amazon Athena.

    Certaines de ses améliorations ont nécessité des modifications rétroactives des données. Par exemple, lorsqu’il a introduit le chiffrement au repos, il a dû chiffrer toutes les données existantes dans les coulisses. Il a pu le faire sans aucun impact sur les performances et la disponibilité.

    Améliorations des coûts et de la capacité

    Aider à réduire les coûts a été un autre domaine d’intérêt. De nombreux clients ont des données auxquelles ils accèdent rarement et les déplaçaient vers la couche de stockage S3 d’Amazon pour réduire leurs dépenses mensuelles et annuelles. Amazon a répondu avec la classe de table Amazon DynamoDB Standard-Infrequent Access, qui stockait les données peu consultées à des taux plus équitables tout en répondant à la demande de cohérence, de disponibilité et de vitesse de la base de données.

    À l’origine, les partitions internes dont DynamoDB avait besoin pour évoluer nécessitaient des spécifications avancées de la part des clients. La base de données est facturée en fonction du débit, à l’aide d’unités de capacité de lecture et d’écriture (RCU et WCU). Au début, il répartirait ces unités de manière égale sur toutes les partitions de la base de données d’un client.

    “Cette première version associait étroitement l’affectation de la capacité et des performances aux partitions individuelles, ce qui a créé des défis pour nos clients”, explique Somu. DynamoDB a été lancé avec l’hypothèse que les applications accèdent uniformément aux données dans les tables. Cependant, de nombreuses charges de travail ont des modèles d’accès non uniformes – dans le temps et dans l’espace. Lorsque le taux de demande au sein d’une table n’est pas uniforme, le fractionnement d’une partition et la division égale du débit peuvent parfois avoir pour résultat que les éléments chauds de la partition ont moins de capacité disponible qu’avant le fractionnement. Les clients devraient provisionner la capacité de la table en fonction de leurs prévisions de trafic de pointe plutôt que de mettre automatiquement à l’échelle les partitions en conséquence.

    En 2018, Amazon a introduit des fonctionnalités à la demande, permettant à la base de données d’allouer des unités de capacité au niveau de la table. Cela a éliminé le besoin pour les utilisateurs de se soucier de l’allocation des partitions. DynamoDB divise désormais automatiquement les partitions en fonction du débit consommé. Le point de partage est choisi en fonction de la répartition du trafic au sein de la partition. La fonctionnalité est un simple commutateur dans l’interface DynamoDB, et les clients peuvent basculer une base de données entre provisionnée et à la demande sans modifier la conception sous-jacente ou la structure de données.

    S’en tenir à l’objectif premier

    Les fonctionnalités ajoutées ne sont pas le résultat d’une précipitation aveugle à livrer, explique Somu. « Ces évolutions se sont toutes concentrées sur l’échelle, les performances constantes et la disponibilité », ajoute-t-il. Avant que l’équipe de développement n’introduise une fonctionnalité, elle a exploré les effets potentiels sur ces latences de transaction très importantes.

    Réfléchir attentivement avant d’apporter des améliorations aux fonctionnalités permet à Amazon de maintenir une haute disponibilité en gardant son code performant et fiable. Par exemple, le Amazon Prime Day (12-13 juillet 2022), la société a atteint 105,2 millions de requêtes par seconde alors qu’elle servait des systèmes tels qu’Alexa et ses centres de distribution. La base de données n’a pas vacillé, rappelle Somu. Il a fourni des performances à un chiffre en millisecondes sur des billions d’appels d’API.

    L’âge de DynamoDB en années dépasse désormais son temps de réponse moyen en millisecondes. Alors qu’il envisage son prochain chapitre, qui sait quelles améliorations nous pourrions écrire dans dix ans ?

    Le document qui plonge profondément dans la création et l’évolution de DynamoDB – Amazon DynamoDB : un service de base de données NoSQL évolutif, prévisible et entièrement géré – Amazon Science – peut être téléchargé ici.

    Sponsorisé par AWS.

    L'équipe de Comparaland

    L'équipe rédactionnnelle du site

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *