Le choix entre Amazon Aurora, Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, Amazon ElastiCache et Amazon Redshift repose sur une décision initiale. Il est nécessaire de définir la manière dont la charge de travail lit et écrit les données, ainsi que les garanties requises en matière de cohérence, de latence, de disponibilité et de récupération. Dans ce cours, nous élaborerons un cadre reproductible permettant de traduire ces exigences en un choix de base de données justifiable et vérifiable.
Ce cours se concentre sur cinq services de données gérés par AWS et sur les charges de travail auxquelles ils sont adaptés. Amazon Aurora et Amazon RDS sont destinés au traitement des transactions en ligne (OLTP) via des moteurs relationnels. Amazon DynamoDB est conçu pour les modèles d’accès clé-valeur, offrant des performances prévisibles de l’ordre de quelques millisecondes, même à grande échelle. Amazon ElastiCache est un cache en mémoire qui stocke des copies de données plutôt que de servir de système d’enregistrement principal. Amazon Redshift est dédié aux charges de travail analytiques impliquant l’analyse et l’agrégation de vastes ensembles de données.
Nous gardons également à l’esprit le périmètre AWS. Une Région est une zone géographique où AWS exploite plusieurs centres de données isolés. Une Zone de disponibilité (Availability Zone) correspond à un emplacement isolé au sein d’une Région. De nombreuses fonctionnalités de durabilité et de disponibilité dépendent de la manière dont un service utilise plusieurs Zones de disponibilité au sein d’une même Région.
Examinons le positionnement de ces cinq services sur le spectre allant des transactions au cache, en passant par l’analyse de données.
Nous utiliserons la même boucle de décision dans chaque leçon. Tout d’abord, nous définissons les schémas d’accès et le modèle de données. Ensuite, nous associons ces besoins à un mécanisme de service capable d’y répondre. Puis, nous identifions les compromis en termes de coûts, de responsabilité opérationnelle et de comportement en cas de défaillance. Enfin, nous validons notre choix en nous appuyant sur des preuves observables, et non sur des suppositions.
Les preuves doivent correspondre au périmètre que nous testons. Les métriques et les journaux révèlent ce qui s’est réellement passé lors de l’exécution. L’analyse statique et l’examen de la configuration indiquent seulement ce qui pourrait se produire compte tenu d’une configuration donnée. Une décision pertinente intègre au moins un signal issu de l’exécution capable d’infirmer nos hypothèses.
Visualisons le cheminement — des besoins aux preuves en passant par le mécanisme — que nous mettrons en pratique à maintes reprises.