Lors du Re:Invent si on exclue les annonces gravitant autour de l'IA, on constate qu'un grand nombre de nouveautés majeures et structurantes concernent les bases de données et en particulier leur capacité à être utilisées dans des architectures multi-regions. Dans cette article nous reviendrons tout d'abord sur les cas d'usages se prêtant à cette approche ainsi que les caractéristiques à considérer lors de la conception.
Pourquoi utiliser une base de données en déploiement multi region ?
On peut noter trois raisons principales pouvant pousser à la mise en place d'une architecture multi-region:
- Augmenter la disponibilité et assurer une continuité de l'activité en cas de perte partielle ou totale d'une region
- Se conformer à des règles de conformité ou de souveraineté locales, obligeant à conserver les données avec une localisation spécifique
- Améliorer les performances dans le cas d'applications accessibles globalement, en particulier reduction de la latence mais aussi en permettant une approche distribuée pour des données sur plusieurs points du globe (référentiel produit global, leaderboard mondial,...)
Pour réaliser un déploiement de la couche de données en mode multi region, on peut, soit réaliser soi-même la solution en réalisant par exemple des synchronisations applicatives entre des bases de données régionales ce qui est en générale complexe surtout si on considère la robustesse nécessaire dans ce contexte, soit s'appuyer sur une base de données dotées nativement d'un mode de déploiement multi-region. C'est uniquement ce dernier cas qui va nous intéresser dans la suite de cet article.
Deux caractéristiques fondamentales vont ensuite orienter le choix du service de base de données, le type de réplication et la nécessité ou non de faire de la haute disponibilité en disposant de plusieurs instances maitres (ie. capables d'écrire/modifier la donnée et pas uniquement de la lire).
Pour la réplication deux principes sont possibles:
| Asynchrone | Synchrone | |
|---|---|---|
| Fonctionnement | Quand une modification est demandée, l'acquittement est renvoyé au client lors de l'écriture de la transaction dans une région | Quand une modification est demandée, l'acquittement est renvoyé au client lorsque la transaction est propagée dans toutes les régions sur lesquelles la base est déployée |
| Impact sur le RPO | Le RPO sera superieur à zéro, en général quelques secondes | un RPO de zéro est posssible |
| Impact sur les performances | Très faible latence d'écriture, quelques millisecondes | Forte latence d'écriture, jusqu'à une centaines de millisecondes, dépend fortement du type de base de données |
| Impact sur la Cohérence | Eventual consistency, cohérence obtenue lorsque que la transaction est propagées sur l'ensemble des régions | Strong consistency, cohérence forte à l'écriture de la transaction |
Pour la disponibilité, deux alternatives également:
| Actif/Passif (single-writer) | Actif/Actif (multi-writer) | |
|---|---|---|
| Fonctionnement | Une seule instance de la base peut effectuer des modifications, les autres sont en lecture seule. Solution plus simple, en particulier pas de risque de conflit d'écriture | Plusieurs instances de la base peuvent effectuer des modifications. Solution plus complexe devant en particulier gérer les conflits d'écriture |
| Impact sur la gestion des defaillances (failover) | Dans la plupart des cas la detection de la perte de l'instance principale doit être faite coté application. Bascule complexe, au moins de l'ordre de la minute. | Failover (par exemple perte de region) transparent pour l'application, bascule immediate possible |
Le nombre de regions devant être utilisées peut également avoir un impact sur le choix de la base et le design de la solution. Si l'approche multi-region concerne un plan de secours, un couple de region suffit, si elle correspond à un besoin de déploiement global, un plus grand nombre de région sera nécessaire.
Passons maintenant aux nouveautés présentées par AWS lors du Re:Invent 2024 et qui élargissent le champs des possibles en matière de déploiement multi-région pour les bases de données.
Base in-memory: MemoryDB
AWS annonce la disponibilité générale sur 12 régions de Amazon MemoryDB en mode Multi-Region actif/actif, permettant d'atteindre une disponibilité de 99,999 %, des temps de lecture de l'ordre de la microseconde et des écritures en moins de 10 millisecondes. Compatible avec Valkey.
La réplication des données entre régions est asynchrone et se propage avec une latence de moins d’une seconde. MemoryDB gère automatiquement les conflits de mise à jour et les divergences de données selon le principe du "Last Writer Wins".
Jusqu’à cinq régions peuvent être ajoutées à un cluster multi-regional.
Cas d'usages: applications demandant résilience, très faible latence et haute disponibilité.
Base NoSQL: DynamoDB Global Tables
DynamoDB existe déjà depuis longtemps avec un mode multi-région avec Global Tables. Certes, mais uniquement en "Eventual Consistency" (On parle de tables MREC pour Multi Region Eventual Consistency). On peut désormais créer des tables DynamoDB en MRSC, prononcé "Merci", pour Multi Region Strong Consistency et ainsi disposer d'une cohérence forte globale. Autrement dit, lors d'une lecture dans n'importe quelle région on a la certitude de lire la toute dernière version des données pour l'ensemble des régions utilisées.
C'est par contre encore en preview avec un certain nombre de limitation:
- Disponible uniquement dans les régions US
- Pas de LSI ni de TTL
- Pas de chiffrement avec des CMK
- ...
Cas d'usages: stockage de profils utilisateurs, suivi d'inventaire global ou transactions financières par exemple.
Base Distribuée: Aurora DSQL
L'une des grandes annonces de ce Re:Invent: Amazon Aurora DSQL, une nouvelle base de données SQL distribuée, serverless, multi région, d'où sa présence ici, et dotée de fonctionnalités très très innovantes pour une base SQL :
- Scalabilité horizontale quasi illimitée, avec un redimensionnement indépendant selon les besoins en lectures, écritures, calculs et stockage.
- Haute disponibilité : 99,99 % pour une seule région et 99,999 % pour des déploiements multi-régions. Déploiement actif/Actif.
- Auto Scalling : ajuste sa capacité en fonction des besoins de la charge de travail, sans nécessiter de sharding de base de données ou de mises à niveau des instances.
- Compatibilité PostgreSQL (Attention la compatibilité n'est pas totale!) en strong consistency multi-regionale.
- Actuellement disponible en preview dans les régions US.
En un mot la DynamoDB pour le SQL....
Un article détaillé sur les possibilités, le fonctionnement détaillé et les impacts applicatifs est en cours de rédaction.
