Le Blog Amazon Web Services

Amazon DynamoDB est-il fait pour vous ?


Werner Vogels, le CTO d’Amazon plaisante souvent sur le fait qu’AWS est là pour s’occuper des malheurs des entreprises. En effet, lorsque nous demandons à nos clients de quelle manière nous pourrions les aider au mieux, le plus souvent la réponse tourne autour des bases de données, des coûts de licence associés, de la performance, de la scalabilité et du coût des spécialistes en bases de données. Une base de données NoSQL entièrement gérée telle qu’Amazon DynamoDB peut résoudre ces problématiques tout en apportant de nombreux avantages.

Dans cet article, nous expliquons comment déterminer si DynamoDB est un bon candidat pour votre application, puis nous détaillons les différentes étapes et bonnes pratiques à suivre pour une migration vers DynamoDB réussie.

Liberté !

Chez AWS, nous croyons à la liberté. La liberté d’évaluer, de tester et de choisir la bonne base de données en fonction du type de données, du schéma d’accès et de vos besoins en scalabilité. Nous sommes également convaincus que vous avez tout intérêt à libérer du temps pour que vos développeurs et administrateurs système s’occupent de vos applications plutôt que de gérer des moteurs de bases de données. Laissez donc ce travail à AWS ! Et c’est d’autant plus vrai pour les bases de données soumises à de très forte charge.

Bien souvent, les applications cloud-native sont construites différemment des applications traditionnelles, sans couplages forts, en micro-services et avec de l’autoscaling. Il est crucial de bien prendre le temps de considérer toutes les options et de les tester en profondeur. Ayez toujours à cœur de choisir le bon moteur de base de données tant pour vos applications traditionnelles que pour vos applications modernes. Ne tombez pas dans le travers consistant à utiliser la même base de données pour toutes vos applications.

AWS fait tout pour que le choix d’une base de données et sa configuration soit plus simple et moins cher qu’avec une base de données commerciale. AWS permet en effet de tester, expérimenter et se tromper sans risque, et les tarifs sont transparents et publics. En terme de bases de données, le portefeuille d’options ne cesse de croître, tant par le nombre que par les fonctionnalités. C’est la conséquence de l’adoption des architecture en micro-services, de l’Internet des objets (IoT) et des besoins spécifiques dans le domaine de l’analytics. La plupart des moteurs Open Source ou commerciaux sont disponible notamment sur la Marketplace AWS. Libre à vous de les déployer sur des instances Amazon EC2. Vous pouvez sinon utiliser le service entièrement géré Amazon Relational Database Service (Amazon RDS), pour vos besoins en base de données relationnelles.

Pour vous éviter de passer du temps (et donc de l’argent) à administrer et maintenir vos systèmes de bases de données vous pouvez faire le choix de laisser AWS s’en charger à votre place, en utilisant un service NoSQL entièrement géré comme DynamoDB. D’après Werner Vogels, 70% des besoins en base de données d’Amazon.com ne relèvent pas du modèle relationnel et seraient mieux couverts par un modèle clé-valeur. C’est ce constat qui a mené à la création de DynamoDB (article en anglais). DynamoDB est souvent utilisé à petite échelle du fait de sa très grande simplicité, mais il révèle également toute sa puissance à très grande échelle comme celle d’Amazon.com par exemple.

Amazon DynamoDB est-il fait pour vous ?

Vous pourriez envisager d’utiliser DynamoDB si :

  1. Vous rencontrez des problèmes de scalabilité avec les bases de données traditionnelles ;
  2. Vous êtes en plein développement de votre application. Il n’est en effet pas toujours judicieux de migrer des applications historiques qui ne sont plus activement développées, à moins que vous soyez prêts à investir du temps et des moyens pour ré-implémenter la couche d’accès aux données, les requêtes SQL dans le code ou encore les procédures stockées ;
  3. Votre application est transactionnelle (OLTP). Obtenir de très bonnes performances tant en lecture qu’en écriture est assez simple avec DynamoDB et vous pouvez vous attendre à ce que les performances soient constantes quelle que soit la charge ;
  4. Vous déployez une application critique qui se doit d’être disponible tout le temps ;
  5. Vous n’avez pas assez de temps pour vous occuper de la gestion au quotidien de votre système de base de données ;
  6. Vous souhaitez un très haut niveau de durabilité de vos données quelle que soit votre stratégie de sauvegarde ;
  7. Vous n’êtes pas en mesure de prévoir les pics (ou les creux) de charge sur votre système ;

Mais du coup, DynamoDB est-il fait pour vous ?

Avant de répondre à cette épineuse question, vous devriez pouvoir répondre par l’affirmative à celles-ci :

  1. Pouvez-vous organiser vos données de façon hiérarchique ou les agréger en une ou deux tables ?
  2. La protection de vos données est-elle importante ?
  3. Les solutions traditionnelles de sauvegarde ne sont plus efficaces, tant techniquement que financièrement à cause d’une volumétrie trop importante ou d’une trop grande volatilité des données ?
  4. La charge sur votre base suit elle une forte saisonnalité (jour/nuit par exemple) ou alors est elle soumise à d’importants pics de trafic ?
  5. Votre application requiert-elle un temps de réponse constant de l’ordre de la milliseconde, quelle que soit la charge et sans configuration particulière ?
  6. Souhaitez-vous offrir un service scalable, redondé et global ?
  7. Votre application a-t-elle de gros besoins en volumétrie, de l’ordre du téraoctet ou plus ?
  8. Êtes-vous prêt à investir un peu de temps dans la formation de vos développeurs au NoSQL ?

Voici quelques exemples où DynamoDB n’est à priori pas éligible :

  • Applications ou services réalisant des requêtes ad-hoc. Bien qu’il soit possible d’utiliser des frameworks pour implémenter un modèle relationnel sur plusieurs tables DynamoDB, c’est en général une mauvaise idée.
  • Traitement analytique en ligne (OLAP) et entrepôts de données. Ces types d’applications nécessitent des jointures entre les tables de facts et dimensions, ce qui produit naturellement une vue normalisée (relationnelle) de vos données.
  • Stockage d’objets binaires (BLOB). Bien que DynamoDB puisse stocker de la donnée binaire à hauteur de 400 Ko, DynamoDB n’est pas adapté pour le stockage de documents ou des images. Dans ce cas, il est conseillé de stocker dans DynamoDB un pointeur vers un objet stocké dans Amazon S3.

Si après avoir étudié tous ces points vous pensez que DynamoDB répond à vos besoins, vous pouvez suivre les étapes suivantes.

Planifiez votre migration

Lors d’une migration d’une base de données traditionnelle vers DynamoDB, il est bon de commencer par un PoC (Proof of Concept), afin de valider la faisabilité technique d’une telle migration. Il est aussi possible de faire tourner les deux systèmes en parallèle lors de la phase de test pour tester la non-régression. L’approche itérative et agile est toujours la meilleure dans ce cas. Pour plus de détails sur les différentes étapes de migration, vous pouvez lire le livre blanc sur les Bonnes pratiques de migration d’un SGBDR vers Amazon DynamoDB.

Dans la suite de cet article, nous considérons que vous migrez depuis une SGBDR hébergé on-premises vers DynamoDB. Les étapes qui vont suivre peuvent malgré tout s’appliquer à d’autres cas de figure.

1. Formation des développeurs

Lorsque l’on migre une application vers le cloud, la première étape est de former les développeurs pour qu’ils puissent s’adapter et s’habituer à ne plus inclure des requêtes SQL directement dans leur code mais à faire des appels API à la base NoSQL, ici, DynamoDB.

Bloquez du temps pour la formation de vos développeurs. Vous pouvez utiliser les contenus disponibles sur la page Ressources Amazon DynamoDB. Ces ressources contiennent différents labs, des exemples clients et des contenus de formation de qualité. En général, un développeur a besoin de quelques jours pour se familiariser avec DynamoDB puis quelques jours de plus pour tester et expérimenter et configurer son environnement de développement pour pouvoir travailler efficacement.

Notez qu’une version locale de DynamoDB peut être librement téléchargée. DynamoDB local permet à vos développeurs de tester leur code sans avoir accès au service DynamoDB. Une fois le code validé en local, il est alors possible très facilement de le tester sur le service DynamoDB. Cette approche permet également de ne pas avoir à payer pour les tests sur DynamoDB.

Un point important que vos développeurs doivent également aborder concerne les index. La bonne utilisation des index qu’ils soient locaux ou globaux est primordiale pour optimiser vos requêtes. Les index globaux (GSI) se comportent comme une table DynamoDB externe, gérée par AWS. Ces index étant facturés, il faut les utiliser uniquement quand ils sont nécessaires.

2. Conversion des données

Selon la taille de votre base, vous pouvez convertir vos différentes tables en une unique table dans votre base source, avant la migration. Ceci vous fera gagner du temps plus tard lors du processus de migration. Il est également possible de créer une tâche périodique d’export vers AWS. Pensez à bien lire les recommendations sur la façon de dénormaliser la donnée sur la page de documentation Premiers pas pour la modélisation des données relationnelle dans DynamoDB ainsi que les bonnes pratiques de modélisations.

3. Migration des données

Une fois vos données dénormalisées, il faut décider de la façon dont seront importées les données, en une ou deux étapes : import complet ou import complet puis synchronisation juste avant la bascule. AWS Database Migration Service (AWS DMS) fonctionne avec DynamoDB comme cible, et comme source une base relationnelle, Amazon S3 ou MongoDB par exemple. Avec AWS DMS, seule l’instance de replication utilisée lors de la migration vous sera facturée. En général, les projets de migrations vers DynamoDB utilisent AWS DMS, puis basculent le trafic vers DynamoDB une fois la période de réplication et de tests terminée.

Si le transfert de données vers DynamoDB prend plus d’une semaine à cause par exemple d’une bande passante limitée, l’option AWS Snowball est alors à considérer. D’autant plus que AWS DMS sait parfaitement s’appuyer sur Snowball comme étape intermédiaire à la migration. Snowball est une solution de transfert de données qui utilise des périphériques physiques pour transférer de gros volumes de données vers et depuis le cloud AWS.

4. Modèle de cohérence

Un point d’attention particulier concerne le modèle de cohérence en lecture. En effet, chaque écriture ou mise à jour d’une table DynamoDB donne lieu à une copie des données dans trois zones de disponibilités différentes et ce afin d’augmenter la durabilité de vos données. Cette duplication sur les trois zones prend en général moins d’une seconde.

DynamoDB propose trois modèles de cohérence en lecture : cohérence à terme (eventually consistent), forte et transactionnelle. Par défaut c’est le modèle de cohérence à terme qui est utilisé. Si votre application ou vos utilisateurs peuvent parfois tolérer des données périmées, dans le cas d’une lecture suivant immédiatement une écriture par exemple, alors ce mode par défaut sera adapté et vous permettra de provisionner moins de capacité, et donc de réduire vos coûts.

En revanche, si vous ne pouvez pas vous permettre la moindre incohérence temporelle, alors il vous faudra opter pour le mode de cohérence forte. DynamoDB retournera alors la réponse la plus à jour reflétant ainsi les mises à jour de toutes les opérations d’écriture précédentes ayant réussi. La capacité provisionnée sera alors plus importante et les coûts supérieurs.

Enfin, pour les applications transactionnelles où la dernière écriture doit toujours être disponible pour toutes les requêtes, les APIs transactionnelles de DynamoDB sont le meilleur choix. Afin de supporter les transactions et de simplifier la vie des développeurs lors des changements “tout ou rien”, DynamoDB réalise deux opérations de lecture ou d’écriture pour chaque item de la transaction : une première pour préparer la transaction et l’autre pour la valider. Bien que le coût de chaque lecture et écriture soit identique, cela fait grimper le nombre d’opérations et c’est donc le mode de cohérence le plus onéreux.

5. Sécurité – chiffrement

Si vous optez pour la méthode de migration proposée dans cet article, vos données seront chiffrées en transit lors de la migration. Lorsque vous créez une nouvelle table dans DynamoDB, le chiffrement au repos est activé par défaut. Ce chiffrement utilise l’algorithme Advanced Encryption Standard 256 bits (AES-256) ce qui protège vos données de tout accès non autorisé. Le chiffrement au repos se base sur le service AWS Key Management Service (AWS KMS) pour la gestion des clefs de chiffrement. Le chiffrement est sans impact, tant en terme de performance qu’en terme de coût. Alors, pourquoi s’en priver ?

Lors de la création d’une nouvelle table, trois options s’offrent à vous :

  • La première est d’utiliser une clef (Customer Master Key, CMK) gérée et détenue par le service DynamoDB. C’est le choix par défaut. Dans ce cas, une unique clef CMK est utilisée pour chiffrer toutes vos tables DynamoDB.
  • La deuxième option consiste à utiliser une clef CMK gérée par AWS mais déployée dans votre compte AWS au sein du service KMS. Ceci vous permet de voir la CMK et ses permissions associées dans votre compte. Ici aussi, la même clef servira à chiffrer toutes vos tables. En revanche, utiliser une CMK déployée dans votre compte vous donnera davantage de possibilité d’audit et de contrôle car vous pourrez voir toutes les demandes de chiffrement / déchiffrement de vos tables DynamoDB à travers les logs AWS CloudTrail.
  • La troisième option enfin vous permet d’utiliser une clef CMK qui vous appartient, gérée par vous et stockée dans votre compte. Ce choix vous donne un contrôle maximum sur les permissions associées à cette clef et vous permet également d’utiliser des clefs différentes pour chacune de vos tables DynamoDB. En revanche, la gestion (permissions, rotation, etc.) de ces clefs est à votre charge.

Enfin, par défaut, toutes les communications vers et depuis DynamoDB se font sur le protocole HTTPS qui protège le trafic en utilisant le chiffrement SSL/TLS.

6. Réseau et sécurité

La plupart des clients AWS accèdent à DynamoDB depuis leur VPC en utilisant un point de terminaison VPC pour DynamoDB ce qui permet de rendre accessible DynamoDB à vos ressources déployées dans des subnets privés sans avoir à faire du NAT et sans nécessité d’avoir une Internet Gateway. La création d’un point de terminaison VPC pour DynamoDB n’entraînant aucun frais supplémentaire, vous avez tout intérêt à l’utiliser.

7. Performance – débit et Auto Scaling

Gérer la performance de DynamoDB demande très peu de travail. Le service offre les performances demandées par votre configuration de capacité avec une constance dans les temps de réponse remarquable. La gestion de cette configuration peut se faire de différentes manières.

Tout d’abord, lisez la page de documentation relatif au mode de capacité en lecture/écriture pour bien comprendre les impacts de cette configuration. En effet, une capacité trop élevée induira des coûts inutiles alors qu’une capacité sous-estimée entraînera des problèmes de performances sur votre application.

Vous pouvez automatiser les changements de capacité en fonction de la charge en activant l’Auto Scaling. Ainsi la capacité tant en lecture qu’en écriture sera adaptée automatiquement par le service en fonction de la charge réellement reçue, tout en respectant les bornes que vous aurez configurées. Vous pourrez ensuite utiliser Amazon CloudWatch et la console DynamoDB pour observer les actions de l’Auto Scaling et ainsi vérifier que vos limites ont été correctement définies.

Enfin, pour encore plus de simplicité, vous pouvez utiliser le mode de capacité à la demande et laisser AWS gérer entièrement à votre place toutes les opérations de mise à l’échelle.

8. Performance requise – ms ou μs ?

Dans le cas où vos applications nécessiteraient des performances très élevées où l’ordre de grandeur serait à la micro seconde (μs) plutôt qu’à la milliseconde (ms), vous pouvez utiliser Amazon DynamoDB Accelarator (DAX). DAX est un espace tampon en mémoire qui permet d’accélérer considérablement les accès à DynamoDB tout en réduisant les besoins de capacité en lecture de DynamoDB. DAX peut être envisagé pour toute application effectuant beaucoup de lectures : les performances augmenteront et votre facture DynamoDB baissera dans la plupart des cas.

9. Durabilité et stabilité

Les données. Ce sont en général vos bijoux de famille. Une fois vos données dans DynamoDB, il serait sage de penser à les sauvegarder pour vous protéger de toute erreur ou défaut pouvant amener à la perte de donnée. De plus, DynamoDB étant un service régional, vous pouvez également envisager une façon de récupérer vos données en cas de défaillance du service.

Concernant la sauvegarde, DynamoDB supporte le Point In Time Recovery (PITR). A moins que vous soyez en mesure de reconstruire vos données à partir d’une autre source telle qu’Amazon S3, vous devriez systématiquement utiliser le PITR pour vous prémunir de tout problème ou erreur pouvant venir de vos applications ou de vous même. Si vous êtes amené à restaurer des données via le PITR, une nouvelle table DynamoDB sera créée avec les données telles qu’elles étaient à la date choisie. Vous aurez alors à configurer les paramètres relatifs à la performances, le débit et l’Auto Scaling.

DynamoDB supporte également les sauvegardes (… et les restaurations) à la demande. La sauvegarde d’une table DynamoDB se fait sans aucun impact sur les performances et ne prend que quelques secondes. Les sauvegardes ainsi réalisées soit automatiquement, soit manuellement peuvent-être restaurées à tout moment et ce quelque soit le statut de la table d’origine, ce qui pourra vous sauver en cas de suppression malencontreuse d’une table DynamoDB par exemple.

10. Redondance régionale

Dans le cas où votre application serait globale (distribuée tout autour de la planète), prenez le temps de regardez Global Tables. Global Tables permet en quelques clics de déployer vos tables DynamoDB sur plusieurs régions via une réplication multi-master. Prenez soin de bien suivre les bonnes pratiques relatives à l’utilisation de Global Tables et d’activer l’Auto Scaling. Notez enfin que les lectures à cohérence forte ne peuvent-être réalisées que dans une unique région. Dans les autres régions, les lectures seront à cohérence à terme.

11. Optimisations financières

Voilà. Vous êtes maintenant un utilisateur de DynamoDB, toutes vos données y sont désormais stockées. Il est maintenant important d’utiliser au mieux le service et d’optimiser vos coûts. Voici quelques astuces pour vous aider à optimiser vos dépenses sur DynamoDB.

DynamoDB propose un mode de capacité à la demande. Avec ce mode, AWS s’occupe d’ajuster la capacité en lecture et en écriture pour vous de façon à suivre au plus près la demande. Ce mode vous simplifie la vie car il n’est plus nécessaire de configurer une capacité initiale ou l’Auto Scaling. Cependant, si votre application génère des demandes relativement constantes et stables alors le mode à la demande ne sera pas le plus avantageux financièrement.

Il est important de bien comprendre comment est facturé DynamoDB :

  • Vous payez un prix fixe pour la capacité que vous avez provisionné ou alors un prix variant en fonction de la charge si vous avez choisi le mode de capacité à la demande ;
  • Le prix des unités de capacité en lecture et en écriture est fixé régionalement ;
  • Vous pouvez utiliser l’Auto Scaling pour n’utiliser toujours que le minimum de capacité nécessaire ;
  • Vous pouvez utiliser les lectures à cohérence à terme car une unité de lecture supportera plus de lecture à cohérence à terme que de lecture à cohérence forte ;
  • N’oubliez pas les coûts de transfert inter-régions si vous utilisez des tables dans plusieurs régions ;
  • Utilisez Amazon CloudWatch, AWS Cost Explorer et AWS Budgets afin de suivre votre capacité et vos dépenses ;
  • Enfin, vous pouvez acheter de la capacité réservée à l’avance. Si vous êtes en mesure de prévoir vos besoins en terme de capacité en lecture et écriture, la capacité réservée apporte une réduction significative par rapport au tarif normal. (Notez que la capacité réservée ne s’applique pas au mode de capacité à la demande).

Comme souvent, l’optimisation des usages se fait en suivant de près les coûts et en modifiant le cas échéant la configuration de vos tables DynamoDB de façon à ne payer que pour les ressources que vous utilisez réellement.

Conclusion

Dans cet article, nous avons parcouru les différents points que vous devez considérer avant de décider si DynamoDB est le bon candidat pour votre application, ainsi que la façon dont vous pourrez migrer vos données. Si vous avez des questions ou des commentaires, n’hésitez pas à les soumettre dans la section commentaire plus bas.

Article original contribué par Lex Crosett, Enterprise Solutions Architect et adapté en français par Alexis Günst Horn, Solutions Architect dans les équipes AWS France.