Série spéciale AWS re:Invent 2017 – Stockage de données

Troisième article de notre série revenant sur les annonces nous ayant marqué lors de la récente AWS re:Invent, nous vous présentons aujourd’hui un panel de nouveautés côté stockage de données sur AWS : Aurora, DynamoDB, S3, Glacier, mais aussi un nouveau né : Neptune !

Pour rappel, les autres articles de cette série de décembre sont :

1. Vendredi 8 décembre : Orchestration de conteneurs
2. Lundi 11 décembre : Une flopée d’annonces pour Lambda
3. Jeudi 14 décembre : Stockage de données (vous êtes ici)
4. Lundi 18 décembre : Service mobile, EC2 et Active MQ
5. Jeudi 21 décembre : Réalité virtuelle & augmentée et Machine Learning

Amazon Aurora Serverless & multi-master

Nous connaissons déjà Amazon Aurora, la base de données relationnelle d’Amazon, compatible MySQL ou PostgreSQL dont l’instance maximale fait 64 TB. Aujourd’hui quand nous créons une instance de base de données Aurora, nous devons présupposer de son utilisation, ce qui nous oblige à définir une taille d’instance et donc de figer la capacité d’utilisation. Dans un environnement où la charge est prédictible ce modèle est très intéressant.
Mais dans la majorité des cas nous ne maîtrisons pas notre charge de travail. Nous sommes souvent amenés à provisionner plus que nécessaire pour prévenir les mauvaises surprises ou encore changer les types d’instances pour s’adapter au trafic et dans certain cas utiliser les Read Replica (maximum 5) qu’offre Amazon Aurora ce qui permet d’augmenter la capacité de  lecture. Dans tous ces cas de figure, il y a toujours une marge entre les ressources allouées et celles effectivement utilisées donc un impact sur nos coûts.
L’un des objectifs majeur du cloud est Pay for What you Use. Et pour se rapprocher encore plus de ce modèle Amazon enrichit l’offre Aurora avec Amazon Aurora Serverless.

Amazon Aurora Serverless est une option simple et économique pour les charges de travail peu fréquentes, intermittentes ou imprévisibles, car :

• Elle démarre automatiquement.
• Elle adapte la capacité à l’utilisation de votre application.
• Elle s’arrête lorsqu’elle n’est pas utilisée.
• On ne paye que pour les ressources (ACU, stockage et IO) que l’on a consommé par seconde.

Dans ce modèle vous ne définissez plus un taille d’instance de base de données mais vous créez un endpoint. Cet endpoint servira de proxy entre vos applications, les requêtes que vous émettez et un ensemble de ressources (Amazon Aurora). Ce mode permet de garder des connexions actives (Warm pool) entre une flotte de base de données et votre endpoint.

 

Amazon annonce l’ouverture du service Aurora Serverless au public courant 2018.

DynamoDB

Backup à la demande

Faire un backup des tables DynamoDB n’a jamais été une sinécure. Dans tout projet, ce besoin existe pourtant bel et bien. Jusqu’alors AWS nous proposait officiellement d’utiliser le service Data Pipeline qui instancie pour l’utilisateur un cluster EMR temporaire. Si la volumétrie de la table était faible, il était possible de trouver des alternatives plus simples et légères que Data Pipeline : des scripts en Python ou JS pour sauvegarder les données dans un bucket S3.

L’inconvénient, c’est que ces deux solutions consomment des capacités DynamoDB.

Dorénavant AWS propose des sauvegardes à la manière des snapshots RDS. En un clic ou à travers un appel API, il est possible de créer un backup d’une table DynamoDB sans impacter les performances de votre application.

La sauvegarde est chiffrée, contient toutes les données de la table, les configurations des capacités de lecture/écriture et les index globaux/locaux. Ne sont en revanche pas présents les règles d’auto-scaling, les TTL, tag, les policies IAM et les métriques / alarmes CloudWatch.

Le backup est disponible immédiatement : en coulisses, DynamoDB effectue un snapshot complet et sauvegarde tout le changelog. En quelque sorte, déclencher un backup revient à enregistrer le timestamp avec toutes les métadonnées de la table.

Tables Globales

Comme chacun le sait, les tables DynamoDB sont déjà répliquées sur les différentes AZ d’une même région. AWS annonce les Tables Globales qui permettent de répliquer une table sur deux ou plusieurs régions. Très pratique pour servir les données au plus prêt des clients à travers le monde.

Cela est complètement transparent pour le code applicatif. Il suffit d’envoyer les requêtes d’écriture et de lecture eventually consistant à n’importe quel endpoint DynamoDB. Pour les lectures strongly consistant la demande doit se faire sur le même endpoint que l’écriture.

 Les mises à jour sont propagées aux autres régions en utilisant les DynamoDB Streams. CloudWatch permet de monitorer le temps de propagation avec la métrique “ReplicationLatency” ainsi que le nombre en attente “PendingReplicationCount”.

 Chaque enregistrement aura deux colonnes en lecture seule :

• aws:rep:updateregion

• aws:rep:updatetime

Retrouvez les détails concernant le backup et les tables globales sur le blog AWS.

Amazon Neptune

Le nouveau service (encore en preview) Amazon Neptune lance AWS sur le domaine des bases de données orientées graphe.

Le moteur de cette base, spécifiquement développé par Amazon, met en avant des performances assez impressionnantes. L’annonce parle en effet d’un moteur capable de stocker des milliards de relations et de les requêter avec des latences en millisecondes.

À la manière d’une base de données RDS, le service se présente sous la forme d’un service entièrement géré : patchs, backups, détection des pannes et reprise sur erreur. Le service se déploie par conséquent sur des instances EC2 rattachées à un VPC.

Amazon Neptune offre également une haute disponibilité sur la base d’un cluster pouvant aller jusqu’à 15 réplicas en lecture, répartis sur 3 zones de disponibilité différentes avec un stockage redondé et également sauvegardé en continu sur S3.

Au-delà des aspects techniques du service, la base de données peut être peuplée à partir de fichiers CSV représentant les relations, directement stockés sur S3. Enfin, la base de données supporte 2 langages standards de requêtes Apache TinkerPop3 et Resource Description Framework (RDF).

Amazon S3 Select et Glacier Select

Traditionnellement cantonné au téléchargement intégral de fichiers, le modèle object storage de S3 évolue. Il propose à présent un langage de requête SQL pour ne récupérer que les bytes qui nous intéressent dans les fichiers. De ce fait, le code applicatif n’a plus besoin de consommer des ressources pour lire et filtrer les données d’un objet. Le transfert réseau est d’autant réduit que la requête est restrictive. Les chiffres annoncés sont impressionnants : gain potentiel de performance de 400% et coût de requête diminué de 80%. Pour en profiter, il suffit de changer le code pour utiliser l’API select object content.

Durant la phase de preview du service les contraintes sont les suivantes :

• Les objets chiffrés au repos ne sont pas supportés
• Seul le mode de compression GZIP est supporté
• Les formats CSV et JSON encodés en UTF-8 sont pris en charge

En guise d’exemple imaginez que vous deviez analyser des fichiers CSV zippés d’une chaîne de grande distribution. Chaque jour la totalité des ventes des 200 points de vente sont déposées sur S3 dans un fichier CSV zippé. Le besoin est d’analyser les ventes d’une seule boutique. Sans la fonctionnalité S3 Select il faudrait télécharger, décompresser et parcourir l’ensemble des fichiers CSV. Avec S3 Select une simple requête SQL suffit pour chaque fichier :

SELECT s.* FROM S3Object s WHERE s.id=42

Cette fonctionnalité est également disponible sur Glacier. Consulter l’annonce.