Série de conférences techniques : Concevoir pour l'évolutivité dans votre cloud multilocataire

Chez Jitterbit, notre mission est de simplifier les défis de connectivité les plus complexes et de permettre à chacun de se connecter au monde numérique d’aujourd’hui. Même si nous insistons sur le fait qu’il n’est pas nécessaire d’être développeur pour utiliser les produits Jitterbit, chaque solution logicielle de qualité repose sur une équipe de développeurs exceptionnels.   Dans la série Jitterbit Tech Talk blog, les membres de l’équipe de développement de Jitterbit nous donnent un aperçu de la création d’une plateforme cloud d’entreprise et des défis qu’ils ont dû relever en matière de multi-locataires, d’évolutivité et de sécurité.

Cette semaine, Pankaj Arora, notre directeur principal de la technologie, examine comment concevoir et architecturer une plateforme cloud d'entreprise hautement évolutive.

Le Cloud offre aux entreprises un moyen puissant de proposer leurs produits et services, faciles d'accès de n'importe où et sur n'importe quel appareil. Il offre également d'immenses avantages au fournisseur, notamment une visibilité sur l'utilisation de son offre, un développement et un déploiement rapides, ainsi qu'une réduction globale des coûts informatiques et de maintenance. Par conséquent, presque toutes les entreprises cherchent aujourd'hui à rendre leurs solutions disponibles dans le Cloud.

Mais devenir une véritable entreprise cloud implique bien plus que d'installer des logiciels sur un serveur hébergé et d'accoler le mot “ Cloud ” à vos supports marketing.

Je discutais récemment avec un stratège en technologie qui m'a fait remarquer qu'environ 75% d'entreprises souhaiteraient migrer leurs solutions d'entreprise existantes vers le cloud. Étonnamment, 90% d'entre elles élaborent un plan initial qui reposerait sur une architecture dans laquelle leurs applications existantes seraient simplement déployées sur un serveur cloud accessible au public. Cette approche annule tous les avantages que le cloud a à offrir.

La construction d'une véritable plateforme cloud multi-locataire nécessite de résoudre un certain nombre de défis de différentes natures tels que la sécurité, la fiabilité, l'évolutivité, la haute disponibilité, la tolérance aux pannes, la journalisation, la surveillance, le système de notification, la capacité de déploiement continu et bien plus encore.

Dans l'article d'aujourd'hui, nous examinerons de plus près la manière dont nous avons relevé le défi de la ‘ scalabilité ’ lors du développement de notre plateforme d'intégration cloud multi-tenant.

Le degré d'évolutivité d'une application est lié à sa capacité à évoluer verticalement et horizontalement. Dans un environnement Cloud, cela signifie concevoir des services répondant à des requêtes externes qui s'adaptent de manière à pouvoir exploiter des systèmes dorsaux internes tels que des bases de données, des caches, des couches de médiation, des processus par lots (moteur analytique, moteur de recommandation), etc., afin de traiter un nombre pratiquement infini de requêtes dans un laps de temps raisonnablement court. Il n'est pas toujours possible de prédire le nombre d'utilisateurs qui accèderont à votre plateforme. Concevoir une architecture qui prend cela en compte dans le modèle multi-tenant permet de transformer cette incertitude en un problème générique d'évolutivité.

Mise à l'échelle verticale

La scalabilité verticale consiste à ajouter des ressources telles que des processeurs supplémentaires ou de la mémoire à un seul nœud d'un système, et cela devrait être la première chose à laquelle vous pensez lors de la mise à l'échelle de vos services. Il est très important de concevoir vos applications de manière à ce qu'elles utilisent de manière optimale ces ressources. Prenons le cas d'usage courant de notre plateforme de cloud d'intégration hybride, où les opérations d'intégration sont assurées par un nœud de serveur sur site ou dans le cloud. Ici, les services doivent accepter une requête pour exécuter des intégrations, transmettre la requête aux nœuds de serveur et continuer à traiter d'autres requêtes. La couche de services ne doit pas dépendre des processus se déroulant à différentes couches du système, ni être bloquée par eux. Par conséquent, il est très important de disposer d'une architecture asynchrone et pilotée par les événements.

Une façon simple de comprendre l'architecture asynchrone est de penser à votre architecture comme à un restaurant. Un serveur prend les commandes d'une table et les transmet au chef. Pendant que le chef, le commis et le débarrasseur s'occupent d'activités telles que la cuisine, le service et le nettoyage, le serveur continue de servir de nouveaux clients et apporte l'addition à la fin du service.

Il est très important de maintenir l'asynchronisme pendant que le système interagit avec l'ensemble des composants tels que la base de données, le cache et la couche de médiation. Transférer la charge vers des nœuds de serveur en cluster et hautement disponibles qui exécutent des intégrations libère des ressources pour permettre à la couche de service d'accepter un plus grand nombre de requêtes et de répondre une fois les processus terminés.

Mise à l'échelle horizontale

La considération clé suivante devrait être que les services soient écrits de telle sorte qu'il importe peu de savoir combien d'instances de ces services sont en cours d'exécution et quel système partagé effectue des transactions à un momento donné. Cela confère à notre plateforme cloud la flexibilité nécessaire pour adapter automatiquement la couche de services. Chaque partie du backend est hautement disponible et auto-évolutive pour répondre à la demande croissante de conteneurs de services.

Cependant, nous ne pouvons pas avoir un nombre infini de conteneurs exécutant des couches de service qui utilisent des composants partagés. Ce n'est pas la conception optimale. Revenons à notre exemple de restaurant. Avec la mise à l'échelle verticale, un seul restaurant pourrait devenir hautement évolutif en ajoutant plus de personnel, mais à un certain moment, le nombre de ressources (cuisiniers, commis, débarrasseurs) atteindra un point de saturation. Pour évoluer davantage, cette entreprise devrait ouvrir des emplacements supplémentaires qui aideraient à répartir les clients et à équilibrer la charge.

Il est préférable de diviser l'ensemble de la plateforme en plusieurs zones, chaque zone agissant comme une réplique de la zone initiale. Cela nous permet d'utiliser plusieurs zones pour équilibrer la charge des besoins futurs.

Ce modèle présente de multiples avantages :

1. Possibilité de mise à l'échelle horizontale infinie, car nous pouvons intégrer un nombre illimité de zones

2. Tolérance aux pannes, au cas où toute la zone viendrait à défaillir en raison d'une catastrophe naturelle

3. Séparation des données, dans le cas d'une plateforme SaaS qui nécessite également une ségrégation des métadonnées basée sur la localisation, telle que pour les zones États-Unis, EMEA, etc.

Le résultat souhaité ici est que l'expérience d'un utilisateur soit la même, peu importe où il se trouve et quelle zone il atteint. Aucune intervention manuelle ne devrait être requise de la part d'un utilisateur pour accomplir son travail.

Dans notre cloud d'intégration hybride blog, nous avons discuté de la difficulté rencontrée en utilisant une couche de médiation d'une manière qui ne prenait en charge qu'une mise à l'échelle verticale limitée. En écrivant notre propre couche de connexion non bloquante personnalisée basée sur un transport HTTPS sécurisé, nous avons pu étendre l'architecture pour obtenir une mise à l'échelle verticale 50 fois supérieure. Bien entendu, elle est également extensible horizontalement. Cette combinaison de mise à l'échelle verticale et horizontale nous a fourni une couche moins coûteuse et facilement extensible pour répondre à nos besoins croissants.

Optimisation de l'utilisation des composants partagés :

Les composants partagés doivent eux-mêmes être évolutifs et hautement disponibles pour prendre en charge la plateforme cloud. Cependant, comme ils sont partagés, ils ne sont pas aussi évolutifs que la couche des services. Il est très important de prêter une attention particulière à certains composants pouvant être sensibles à une charge élevée, comme les bases de données. Une approche possible consiste à hiérarchiser et à mettre en file d’attente les usage des composants partagés lorsque des charges simultanées et volumineuses peuvent poser problème. La hiérarchisation permet de réduire la charge et d’atténuer les erreurs sur les requêtes critiques.   Pour revenir à notre restaurant, la cuisine est un composant partagé et, bien que le serveur puisse prendre la commande d’un client pour une entrée, un plat principal et un dessert, la cuisine établira un ordre de priorité pour la préparation de ces plats et équilibrera la charge de travail.

Une autre façon de gérer la charge consiste à mettre en cache les données qui changent rarement afin d'éviter une valeur élevée de usage pour ces composants. Si les frites sont un plat très demandé au menu, le restaurant peut décider de “ mettre en cache ” un lot continu plutôt que de les faire frire à la commande.

Surveillance des composants :

Enfin, il est très important de surveiller chaque composant et de connaître ses limites. Le système doit être capable d'augmenter la bande passante automatiquement et au bon moment pour maintenir les systèmes opérationnels selon les besoins de la plateforme Cloud. La surveillance peut être externe ou initiée par l'application, mais dans les deux cas, l'objectif final est de permettre au système de s'adapter automatiquement en fonction de la charge.

Dans le prochain article consacré au blog, nous aborderons la surveillance, la journalisation et d'autres aspects de l'architecture.