Le service DynamoDB
Introduction
Notre mini-projet dont l’implémentation a commencé au chapitre Le développement d’API Serverless se rapproche maintenant de sa fin. Dans ce chapitre nous allons lui rajouter la touche finale : la partie persistance.
Mais d’abord, rappelons les lignes générales de notre projet et voyons où nous en sommes exactement. Pour mémoire, le schéma d’architecture du projet est reproduit ci-dessous :
Le schéma d’architecture du projet
Et voilà maintenant où nous en sommes au niveau de notre implémentation :
Le stade actuel de l’implémentation
Pour résumer, nous venons d’implémenter la plupart des briques d’architecture de notre projet, il ne nous reste plus qu’à réaliser la dernière partie, à savoir, une fonction Lambda. Cette fonction Lambda sera chargée d’« écouter » sur la file d’attente SQS où sont publiés les ordres de virements bancaires et, dès qu’un nouvel ordre arrive, de l’extraire de la file d’attente, puis de le convertir dans un objet Java particulier, avant de le rendre persistant dans une base de données.
La technologie choisie pour la base de données en question est celle connue sous le nom de NoSQL. Ceci peut paraître étrange, car notre...
Les bases de données NoSQL
Les RDBMS (Relational Data Base Management System) ont été le standard pour la gestion des données depuis la fin des années 80, lorsque IBM a sorti DB2, la première base de données relationnelle. Ultérieurement, dans les années 90, le modèle relationnel a purement et simplement explosé, avec l’apparition des produits commerciaux comme Oracle, Sybase et Microsoft SQL Server, produits qui existent encore aujourd’hui et qui continuent à être présents de manière incontournable dans toutes les organisations, même s’ils ne sont plus du tout ce qu’ils étaient à l’époque.
Mais avec l’apparition et l’escalade du Web sont apparues d’autres RDBMS de type open-source, comme par exemple MySQL, MariaDB ou PostgreSQL. Ils ont émergé et sont rapidement devenus des standards pour toute organisation soucieuse de trouver une alternative aux solutions extrêmement coûteuses proposées par des sociétés comme IBM, Oracle et Microsoft.
Peu de temps après les choses ont commencé à changer, car les besoins en volumes de données des acteurs clés d’Internet, comme Facebook, Amazon ou Google, ont commencé à dépasser les capacités des RDBMS. De nouveaux modèles de gestion...
DynamoDB : la solution NoSQL d’AWS
Comme déjà évoqué, DynamoDB est la solution NoSQL proposée par l’infrastructure AWS. Ce service est accessible depuis la console AWS, comme tous les autres services. Et toujours comme tous les autres services, il est accessible avec AWS CLI, qui est la méthode que nous privilégions ici, pour des raisons déjà largement évoquées.
DynamoDB est un système de stockage basé sur le modèle paires clé/valeur où les données sont organisées dans des tables. Chaque table contient des éléments, appelés items. Chaque table possède aussi une clé primaire qui sert aux mêmes objectifs que dans le cas du modèle relationnel, à savoir identifier et localiser des items. En plus des clés primaires, une table peut également maintenir des index secondaires.
Une table DynamoDB a un nom et, comme on vient de le préciser, elle contient une collection d’items. À son tour, un item est une collection d’attributs de type paire clé/valeur. La valeur dont on parle là peut être de type scalaire (nombre, chaîne de caractères, binaire ou booléen), un ensemble (de nombres, chaînes de caractères, binaires) ou document JSON (objet ou array). Les items d’une table ne doivent pas obligatoirement être du même type.
En plus de la console AWS, pour créer et manipuler des tables DynamoDB, on peut utiliser AWS CLI, comme on vient de le préciser, mais aussi CloudFormation ou son sous-ensemble SAM, ainsi que le SDK. Dans notre exercice, nous allons utiliser SAM pour la création des tables, et le SDK Java pour toutes les autres opérations de persistance de données. Mais si on veut créer très rapidement une table DynamoDB, on peut le faire avec la commande suivante :
nicolas@BEL20:~/AWSLambda/projects/aws-lambda/chapter5$ aws dynamodb create-table
--table-name test-table --attribute-definitions AttributeName=id,AttributeType=
S --key-schema AttributeName=id,KeyType=HASH --provisioned-throughput
ReadCapacityUnits=5,WriteCapacityUnits=5
{
"TableDescription": {
"AttributeDefinitions":...
Le projet Java
Pour accéder au projet Java qui accompagne ce chapitre, procédez de la même manière que précédemment :
Créez un nouveau répertoire destiné à contenir le projet et positionnez-vous dedans.
Clonez le repository GIT ainsi :
$ git clone https://github.com/nicolasduminil/aws-lambda.git
...
$ cd chapter7
Ouvrez votre IDE si ce n’est pas déjà fait. Allez à File - New - Project from existing sources et sélectionnez le sous-répertoire nommé chapter7 dans lequel vous aviez cloné le projet. Cliquez sur OK.
Dans le nouvel écran intitulé Import Project qui s’affiche, cochez l’option Import project from external model et, dans la liste déroulante en dessous, sélectionnez Maven. Cliquez sur Finish.
Vous venez d’importer dans votre IDE le projet Java associé à ce chapitre. Il s’agit bien évidemment d’un projet Maven, comme tous les autres.
1. Le fichier pom.xml
Le projet qu’on vient d’importer est un projet maven mono-module :
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>fr.simplex-software.aws.lambda</groupId>
<artifactId>chapter7</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Money Transfer :: The SQS consumer module</name>
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencyManagement>
<dependencies>
<dependency> ...
Déploiement et exécution
Le script deploy.sh effectue le déploiement du projet sur l’infrastructure AWS et le listing ci-dessous présente le résultat de son exécution :
nicolas@BEL20:~$ cd AWSLambda/projects/aws-lambda/chapter7
nicolas@BEL20:~/AWSLambda/projects/aws-lambda/chapter7$ ./deploy.sh
make_bucket: bucketname-19674
Deploying with following values
===============================
Stack name : chapter7-stack
Region : None
Confirm changeset : False
Deployment s3 bucket : bucketname-19674
Capabilities : ["CAPABILITY_IAM"]
Parameter overrides : {}
Initiating deployment
=====================
Uploading to 32ff4cdb90cb7141310ab7f4c509ca94 11613434 / 11613434.0 (100.00%)
Uploading to 48e9a426cd27c2773ed0251a5a36fbc9.template 1124 / 1124.0 (100.00%)
Waiting for changeset to be created..
CloudFormation stack changeset
-----------------------------------------------------------------------------
Operation LogicalResourceId ResourceType...