Améliorer la reprise après sinistre et les performances à l’échelle mondiale •

Fonctionnalité sponsorisée Nous comptons tous sur les données pour donner un sens au présent et faire des prévisions informatives. Mais les données elles-mêmes peuvent être extrêmement imprévisibles. La mise à l’échelle de l’architecture de votre base de données est suffisamment complexe lorsque vous avez une stratégie qui s’étend sur des années, mais les événements du monde réel peuvent faire dérailler les plans les mieux conçus.

Nous ne parlons pas seulement d’éviter les pannes de centres de données, les pannes de courant, les coupures de câbles, etc. Le volume et la vitesse de croissance des données sont stupéfiants au niveau macro et imprévisibles au niveau organisationnel.

Comme l’explique Aman Dhingra, architecte des solutions Amazon Web Services (AWS), les entreprises peuvent avoir une infrastructure de données qui fonctionne au niveau local, régional, mais si un produit ou un service décolle à l’échelle mondiale, elles peuvent soudainement découvrir qu’elles ont des utilisateurs dans le monde entier. Et les accords de fusions et acquisitions (M&A) peuvent rapidement étendre une opération régionale – et ses applications et données – en une entité mondiale couvrant plusieurs zones géographiques tout en respectant les exigences de souveraineté des données

Au fur et à mesure que l’organisation devient plus complexe, les enjeux augmentent en termes de tolérance aux pannes et de reprise après sinistre. Le défi pour les spécialistes des bases de données est qu’ils doivent maintenir une expérience d’application cohérente d’une région à l’autre, que les utilisateurs soient des employés internes ou des clients.

S’adapter à une base d’utilisateurs géographiquement distribuée ou même mondiale “tout en maintenant une expérience utilisateur prévisible et agréable”, explique Dhingra, incitera souvent les entreprises à envisager de fournir des lectures ou des écritures locales à partir d’une zone proche de l’utilisateur final.

Cela signifie construire une infrastructure de données dans d’autres régions pour reproduire la configuration à la base. Mais si vous ne le faites pas dans le cloud, cela signifie également trouver l’immobilier pour l’héberger et le personnel pour le mettre en place et le maintenir dès le premier jour. Des bottes permanentes sur le terrain sont nécessaires et tout mettre en place peut prendre au mieux des mois et plus probablement des années.

Les organisations qui adoptent cette approche misent également sur la capacité de leur architecture de base de données traditionnelle ou héritée à évoluer en conséquence. Et peut-être plus important encore, les personnes hautement qualifiées finissent par se concentrer sur la maintenance de cette infrastructure complexe, plutôt que sur l’innovation pour le compte de leurs clients.

S’assurer que les données sont répliquées entre les différents sites peut également être un défi permanent en fonction de l’architecture déployée. La simple migration des données à l’échelle mondiale présente ses propres problèmes en termes de rotation d’Internet. Les délais d’attente, les pannes de base de données et les conflits de données peuvent tous s’ajouter à une expérience moins que magique, tant pour les utilisateurs que pour les administrateurs.

Obtenez ces bottes sur le sol?

Ainsi, il est à noter que si Amazon propose pas moins de 11 bases de données différentes. Les principaux hommes d’État du portefeuille sont le service de base de données NoSQL sans serveur natif du cloud, DynamoDB, qui est utilisé par certains de ses clients les plus en vue. Il constitue la base de multiples plates-formes de commerce électronique, de médias ou de jeux à fort trafic – le type d’applications où la latence est essentielle à l’engagement.

Être un service de base de données cloud entièrement géré est un attrait pour ces entreprises, car il supprime cette maintenance continue et les frais généraux opérationnels pour les clients eux-mêmes. Mais DynamoDB a également été conçu pour être une base de données sans serveur, conçue pour évoluer horizontalement, ce qui signifie qu’elle est particulièrement adaptée aux applications massives où une faible latence est essentielle.

Il offre également une option supplémentaire conçue pour améliorer encore la faible latence et la résilience – les tables globales – qui simplifie le déploiement des jeux de données répliqués dans d’autres régions et permet la réplication en direct entre eux à l’aide des tables globales DynamoDB.

Disney a construit son service de streaming vidéo à la demande par abonnement Disney + à l’aide de tableaux mondiaux. Le spécialiste des conférences Web, Zoom, l’a également largement utilisé pour gérer la croissance sans précédent et imprévisible du contenu et des utilisateurs pendant la pandémie. Et bien sûr, DynamoDB sous-tend les propres opérations d’Amazon, y compris son dernier événement Prime Day, où les demandes ont atteint un pic de 105 millions par seconde.

“La simplicité des tables globales est que même lorsque vous avez une table existante dans une région et que vous décidez de la mettre en ligne dans une autre région, le processus d’ajout d’une autre table répliquée est transparent.” explique Dhingra.

Mais le différenciateur clé, ajoute-t-il, est que les options de réplication pour les tables globales DynamoDB incluent la réplication multi-active. “La plupart des bases de données mondiales peuvent effectuer des lectures partout mais n’écrivent que dans une seule région.” Ceci est clairement limitant, d’autant plus si cette seule région est celle qui se déconnecte. Toute organisation aura bien sûr des stratégies de basculement automatisées, mais leur mise en œuvre prendrait de quelques dizaines de secondes à quelques minutes. En ce qui concerne DynamoDB avec des tables globales, dit Dhingra, le basculement est instantané et automatisé.

Le processus de réplication lui-même est effectué sur le propre réseau mondial d’AWS, ce qui réduit encore la latence. « Un contributeur majeur à la réplication elle-même en termes de latence est le délai d’exécution d’Internet. Mais vous savez, il faut quelques millisecondes supplémentaires pour que la réplication réelle ait lieu. Et les utilisateurs ont la possibilité de surveiller cette latence de réplication à l’aide d’AWS CloudWatch. métrique que nous fournissons », explique Dhingra.

Ne te retourne pas

La latence pour les utilisateurs finaux sera cohérente avec celle d’une table DynamoDB non globale, c’est-à-dire dans la moyenne à un chiffre de la milliseconde pour n’importe quelle échelle.

“Généralement, ce que nous voyons est une latence de réplication comprise entre 300 millisecondes et une seconde et demie. Encore une fois, le principal contributeur est le temps d’exécution d’Internet. Imaginez si vous avez une table à Sydney et une autre table en Virginie. Ce sera probablement 170 -180 millisecondes de temps d’exécution d’Internet uniquement”, déclare Dhingra.

Ceci est renforcé par la résolution automatique des conflits qui se produit lorsque deux emplacements tentent d’écrire dans la même information. Avec “la dernière écriture gagne”, l’écriture la plus récente sera celle qui apparaîtra sur toutes les tables.

Qu’une organisation ait l’intention d’opérer à l’international et de mettre en œuvre des tables globales dès le départ, ou qu’elle ait besoin d’étendre sa couverture à court terme, DynamoDB lui permet d’accélérer la réplication via la console AWS, l’AWS CLI ou via l’infrastructure populaire en tant qu’outils de code. comme AWS CloudFormation et Terraform. Les administrateurs doivent simplement s’assurer que leur pile d’applications – active ou passive – est configurée dans la région supplémentaire, prête à recevoir du trafic.

“Toutes les données existantes que la table pourrait avoir seront également renseignées dans l’autre région, et la réplication en direct démarrera également automatiquement”, explique Dhingra.

Les fonctionnalités de sécurité offertes par DynamoDB sont également répliquées dans toutes les régions avec les données avec les mêmes politiques de contrôle d’accès et un accès basé sur les rôles disponibles pour la configuration jusqu’au niveau de l’attribut.

“Ainsi, vous pouvez vraiment affiner l’accès que les applications peuvent avoir aux données d’une table DynamoDB. Qu’il soit global ou local. C’est également essentiel.”

La question est de savoir si toute cette échelle a un coût. Un modèle courant d’utilisation de DynamoDB par les clients consiste à l’intégrer à AWS Lambda, une plate-forme informatique sans serveur pilotée par les événements. Mais, explique Dhingra, “Vous ne payez que par demande ou payez au fur et à mesure que vous l’utilisez. Ainsi, vous pouvez toujours avoir la pile d’applications dans plusieurs régions et si cela implique des fonctions Lambda, et vous ne paierez pas pour cela à moins qu’il ne soit réellement utilisé. “

Bien sûr, il y aura des clients qui utiliseront une variété de couches de calcul différentes, dont certaines peuvent ne pas être sans serveur, explique Dhingra. “Certaines régions où vous avez configuré des tables globales peuvent ne pas voir beaucoup de trafic client ou cela peut varier par rapport à d’autres régions géographiques. Ainsi, le mode de facturation à la demande aide vraiment à suivre le paiement par demande et même à projeter votre croissance et en termes de coût.”

Chaque organisation individuelle doit planifier et budgétiser la manière dont elle va mettre en œuvre son infrastructure globale à l’aide de DynamoDB avec des tables globales. Cela implique de décider d’opter pour une configuration passive ou active et de réfléchir exactement à la manière dont ils géreront la reprise après sinistre.

Mais la seule chose qu’ils n’auront pas à planifier est l’immobilier et les bottes sur le terrain pour mettre en œuvre la réplication des données et assurer la résilience. Parce que, comme le dit Dhingra, “En termes de tables globales, c’est quelques clics sur la console.” Amazon DynamoDB est proposé dans un niveau gratuit pour tous ceux qui souhaitent tester ce service de base de données NoSQL sans serveur.

Sponsorisé par AWS.