Chez Jitterbit, notre mission est de simplifier même les défis de connectivité les plus complexes et de permettre à quiconque de se connecter dans le monde numérique d'aujourd'hui. Bien que nous insistions sur le fait que vous n'avez pas besoin d'être un développeur pour utiliser les produits de Jitterbit, derrière chaque excellente solution logicielle se trouve une équipe de développeurs fantastiques. Dans le Jitterbit Tech Talk blog series, les membres de l'équipe de développement de Jitterbit nous donnent un aperçu de la création d'une plate-forme cloud de classe entreprise et des défis qu'ils ont dû résoudre en matière de multi-tenant, d'évolutivité et de sécurité.
Cette semaine, Pankaj Arora, notre directeur principal de la technologie, examine comment vous concevez et concevez une plate-forme cloud de classe entreprise hautement évolutive.
Le Cloud offre aux entreprises un moyen puissant de proposer leurs produits et services facilement accessibles depuis n'importe où et sur n'importe quel appareil. Cela offre également d'énormes avantages au fournisseur, notamment une visibilité sur la manière dont son offre est utilisée, un développement et un déploiement rapides et des réductions globales des coûts informatiques et de maintenance. En conséquence, presque tous company cherche aujourd'hui à rendre ses solutions disponibles dans le Cloud.
Mais il y a bien plus à faire pour devenir un véritable cloud company que d'installer un logiciel sur un serveur hébergé et d'appliquer le « Cloud » sur vos supports marketing.
Je discutais récemment avec un stratège technologique et ils ont noté qu'environ 75% des entreprises aimeraient migrer leurs offres d'entreprise héritées vers le cloud. Étonnamment, 90 % d'entre eux élaborent un plan initial qui serait construit sur une architecture dans laquelle leurs applications héritées seraient simplement déployées sur un serveur cloud accessible au public. Cette approche annule tous les avantages que le Cloud a à offrir.
La création d'une véritable plate-forme cloud multi-locataire nécessite de résoudre un certain nombre de défis différents 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, etc.
Dans l'article d'aujourd'hui, nous examinerons plus en détail comment nous avons géré le défi de l'« évolutivité » lors du développement de notre plate-forme d'intégration cloud multi-tenant.
L'étendue de l'évolutivité d'une application est liée à sa capacité à évoluer verticalement et horizontalement. Dans un environnement Cloud, cela signifie concevoir des services qui servent des requêtes externes qui évoluent de manière à pouvoir tirer parti des systèmes backend internes tels que les bases de données, les caches, les couches de médiation, les processus par lots (moteur analytique, moteur de recommandation), etc. pour gérer des requêtes pratiquement infinies dans un délai raisonnable. peu de temps. Il n'est pas toujours possible de prédire le nombre d'utilisateurs qui accèdent à votre plateforme. La conception d'une architecture qui en tient compte dans le modèle multi-locataire contribue à faire de cette incertitude un problème d'évolutivité générique.
Mise à l'échelle verticale
L'évolutivité verticale implique l'ajout de ressources telles que des processeurs ou de la mémoire supplémentaires à 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 ces ressources de manière optimale. Prenons le cas d'utilisation courant de notre plate-forme cloud d'intégration hybride, où les opérations d'intégration sont servies par un nœud de serveur sur site ou cloud. Ici, les services doivent accepter une demande pour exécuter des intégrations, transmettre la demande aux nœuds de serveur et continuer à traiter davantage de demandes. La couche de services ne doit pas être dépendante ou bloquée par les processus se déroulant à différentes couches du système. En tant que tel, il est très important d'avoir une architecture asynchrone, 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 passe au chef. Pendant que le chef, le food-runner et le bus boy s'occupent d'activités telles que la cuisine, le service et le nettoyage, le serveur continue de servir de nouveaux clients et effectue des contrôles à la fin du service.
Maintenir l'asynchronicité pendant que le système fonctionne avec tous les composants comme la base de données, le cache et la couche médiatrice est très important. Le transfert de charge vers des nœuds de serveur hautement disponibles en cluster qui exécutent des intégrations libère les ressources pour que la couche de service puisse prendre plus de demandes et répondre lorsque les processus sont terminés.
Mise à l'échelle horizontale
La prochaine considération clé doit être que les services sont écrits de manière à ce que le nombre d'instances de ces services en cours d'exécution et le système partagé qui exécute les transactions à un moment donné n'aient pas d'importance. Cela donne à notre plate-forme cloud la flexibilité nécessaire pour mettre à l'échelle automatiquement la couche de services. Chaque partie du backend est hautement disponible et auto-évolutive pour répondre à la demande croissante des conteneurs de services.
Cependant, nous ne pouvons pas avoir des conteneurs infinis 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 point, le nombre de ressources (cuisiniers, coureurs, garçons de bus) 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 plate-forme en plusieurs zones, chaque zone se comportant 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. Mise à l'échelle horizontale infinie possible, car nous pouvons intégrer n'importe quel nombre de zones
2. Tolérance aux pannes, en cas de défaillance de toute la zone en raison d'une catastrophe naturelle
3. Séparation des données, dans le cas d'une plate-forme SaaS qui nécessite même une ségrégation des métadonnées basée sur la localisation, comme pour les zones US, 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 touche. Aucune intervention manuelle ne devrait être requise de la part d'un utilisateur pour effectuer le travail.
Dans notre cloud d'intégration hybride blog, nous avons expliqué comment nous avons rencontré le défi d'utiliser une couche de médiateur d'une manière qui prend en charge une échelle verticale limitée. En écrivant notre propre couche de connexion non bloquante personnalisée basée sur le transport HTTPS sécurisé, nous avons pu étendre l'architecture pour avoir une échelle verticale 50x. Bien sûr, il est également évolutif horizontalement. Cette combinaison de mise à l'échelle verticale et horizontale nous a donné 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 plate-forme Cloud. Mais les composants partagés sont partagés et, par conséquent, ne sont pas aussi évolutifs que la couche de services. Il est très important de prendre soin de certains composants qui peuvent être sensibles à une charge élevée, par exemple les bases de données. Un modèle peut consister à hiérarchiser et à mettre en file d'attente l'utilisation des composants partagés lorsque plusieurs chargements simultanés à volume élevé peuvent causer des problèmes. La hiérarchisation peut réduire la charge et atténuer les erreurs sur toutes les demandes critiques. De retour dans notre restaurant, la cuisine est un élément partagé et bien que le serveur puisse prendre la commande d'un apéritif, d'un plat principal et d'un dessert, la cuisine priorisera la cuisson de ces éléments et équilibrera leur charge.
Une autre façon de traiter la charge peut consister à mettre en cache des données qui changent rarement pour éviter une utilisation intensive de ces composants. Si les frites sont un élément populaire du menu, le restaurant peut décider de « mettre en cache » un lot continu plutôt que de les faire frire sur 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 plate-forme Cloud. La surveillance peut être externe ou initiée par l'application, mais dans les deux cas, l'objectif final est de laisser le système évoluer automatiquement en fonction de la charge.
Ensuite blog post, nous parlerons de la surveillance, de la journalisation et d'autres éléments de l'architecture.
