Aujourd’hui, les détaillants en ligne vendent des millions de produits et services à des clients du monde entier. Cela était plus répandu en 2020, car les restrictions liées au COVID-19 ont pratiquement éliminé les visites dans les magasins physiques et les transactions en personne. Bien sûr, les consommateurs devaient encore acheter de la nourriture, des vêtements et d’autres produits essentiels, et, par conséquent, les canaux de vente numériques mondiaux ont augmenté de 4,2 billions de dollars, en hausse de 900 milliards de dollars par rapport à l’année précédente.
Était-il suffisant pour ces détaillants d’avoir des sites Web et des applications mobiles robustes pour empêcher leurs clients de faire leurs achats chez des concurrents ? Malheureusement non. En regardant à travers le paysage du commerce électronique de 2020, il y avait clairement des gagnants et des perdants. Mais quel a été le facteur décisif ?
Considérez ceci : 40 % des consommateurs partiront après seulement trois secondes si une page Web ou une application mobile ne parvient pas à se charger complètement. Ce n’est pas beaucoup de temps pour s’assurer que tout s’affiche correctement. Bien qu’il y ait beaucoup à dire pour optimiser correctement les images et le code, tout ce travail peut être vain si la latence des données consomme une partie importante du temps de chargement.
La colocation aide, mais peut poser de nouveaux défis
Un bon moyen de réduire la latence des données consiste à déployer des bases de données dans les mêmes régions géographiques que les applications qu’elles desservent. Par exemple, une entreprise dont le siège est à San Diego peut avoir des applications déployées dans des centres de données situés dans l’ouest des États-Unis (États-Unis), l’est des États-Unis et l’Europe de l’ouest. Les clients qui vivent dans ces régions sont dirigés vers les applications et les services les plus proches d’eux.
Mais quel genre d’expérience un client à Londres aura-t-il si l’application fonctionne rapidement, mais ralentit ensuite ? Ou pire, que se passe-t-il s’il cale lorsqu’il doit effectuer un appel de données vers San Diego ? C’est pourquoi la colocalisation d’une application avec ses données est si importante.
Le concept est d’une simplicité trompeuse. Les données doivent être distribuées dans les régions où elles sont nécessaires. En fait, accomplir cela, cependant, peut être difficile. Une option consisterait à déployer nos données dans un système de gestion de base de données relationnelle (RDBMS) traditionnel avec un serveur de base de données dans chacune des trois régions.
Mais ensuite, nous devons traiter des questions qui se posent d’un point de vue opérationnel. Comment synchroniserions-nous les serveurs de base de données dans toutes les régions ? Comment les dimensionnerions-nous pour répondre aux fluctuations de la demande de trafic ? Des questions comme celles-ci conduisent à ce que j’appelle le problème des données distribuées. Et, comme tout problème complexe, résoudre le problème nécessite souvent des outils spécifiques.
La promesse de NoSQL avec mise à l’échelle horizontale et sensibilisation au centre de données
C’est là qu’entrent en jeu les bases de données non relationnelles NoSQL (« pas seulement SQL »). Les bases de données NoSQL ont principalement évolué au cours de la dernière décennie en tant qu’alternative aux systèmes de gestion de bases de données relationnelles à instance unique, ou RDBMS, qui avaient du mal à suivre les demandes de débit du trafic Internet à l’échelle du Web. Ils résolvent les problèmes d’évolutivité grâce à un processus appelé « mise à l’échelle horizontale » où plusieurs instances de serveur de la base de données sont liées les unes aux autres pour former un « cluster ».
Certains des produits de base de données NoSQL ont également été conçus avec une prise en compte du centre de données, ce qui signifie que la base de données est configurée pour regrouper logiquement certaines instances afin d’optimiser la distribution des données utilisateur et des charges de travail.
Par exemple, Apache Cassandra, la base de données NoSQL open source introduite par Facebook en 2007, est à la fois évolutive horizontalement et compatible avec les centres de données. Si nous devions déployer Cassandra pour résoudre ce problème, cela ressemblerait à l’image ci-dessous.
Un déploiement hypothétique d’Apache Cassandra, avec un cluster couvrant trois centres de données régionaux déployés dans l’ouest des États-Unis, l’est des États-Unis et l’Europe de l’ouest. Carte non à l’échelle.
Notre hypothétique détaillant de commerce électronique dont le siège est à San Diego pourrait effectuer des écritures sur son centre de données (DC) « local », qui serait le DC de l’ouest des États-Unis. Ces données seraient ensuite répliquées dans les deux autres centres de données, dans l’est des États-Unis et en Europe occidentale. Les applications déployées au niveau régional pourraient alors être configurées pour obtenir des données de leur centre de données local.
De cette manière, toutes les interactions de données initiées par le client seraient limitées à sa propre zone géographique. Cela empêche les opérations inter-DC à latence élevée d’être perceptibles par les utilisateurs finaux.
L’autre avantage de ce type de déploiement est que les centres de données régionaux peuvent être mis à l’échelle indépendamment les uns des autres. Peut-être que le trafic augmente en Europe de l’Ouest, nécessitant l’ajout de ressources supplémentaires. Dans ce cas, de nouvelles instances de base de données peuvent être ajoutées à ce seul contrôleur de domaine ; les niveaux de ressources de ceux qui ne sont pas nécessaires n’augmenteront pas et n’ajouteront pas de coûts inutiles. Une fois que le trafic diminue, les instances d’un DC peuvent également être réduites pour réduire les coûts.
Bien sûr, la mise à l’échelle d’un cluster ou d’un DC peut nécessiter des opérations d’infrastructure complexes. Le déploiement de bases de données tout en utilisant des plates-formes d’orchestration telles que Kubernetes peut grandement alléger ce fardeau, permettant aux entreprises de se soucier moins de l’infrastructure et davantage des nouvelles fonctionnalités (pour en savoir plus sur ce sujet, consultez « A Case for Databases on Kubernetes from a Former Skeptic »). Les bases de données cloud natives et sans serveur telles que DataStax Astra DB peuvent aller plus loin, en rendant essentiellement l’infrastructure sous-jacente invisible pour les développeurs d’applications.
Deux prédictions
Je m’attends à ce que dans 10 ans, les bases de données à instance unique deviendront une relique du passé. Au fur et à mesure que cela se produira, de plus en plus de produits de base de données adopteront la sensibilisation aux centres de données.
Les tendances de la mise à l’échelle horizontale et de la prise de conscience des centres de données stimulent plus que jamais l’innovation dans les technologies de base de données.
Il est difficile de voir quand la prochaine grande hausse du commerce électronique se produira ou quelle sera l’ampleur de l’effet par rapport à ce que nous avons vu en 2020. Une chose est certaine. Les entreprises capables de résoudre le problème des données distribuées en réduisant la latence pour fournir des données plus rapidement aux applications que leurs clients utilisent se retrouveront bien en avance sur leurs concurrents.