Problèmes d’applications plus anciennes

De nombreuses applications cloud plus anciennes utilisent une architecture monolithique. Même si ces applications héritées peuvent servir plusieurs locataires, elles sont conçues comme un ensemble volumineux et encombrant de composants hautement interdépendants. Une défaillance dans un composant peut avoir un impact dévastateur sur un autre composant, entraînant des pannes de service pour plusieurs ou tous les locataires. La mise à jour de ces systèmes nécessite de les mettre hors ligne, ce qui limite l'accès des utilisateurs pendant le processus de mise à niveau. Les problèmes des services monolithiques sont exacerbés lorsqu'ils sont déployés dans des centres de données propriétaires avec un matériel limité car les contraintes matérielles limitent encore la disponibilité et l'évolutivité des ressources logicielles.

La solution microservices de Genesys Cloud

Genesys Cloud résout les problèmes de l’architecture monolithique grâce à notre utilisation de microservices. Avec les microservices, nous résolvons des problèmes complexes avec des objets simples et sans état. Notre architecture de microservices offre également un nombre pratiquement illimité évolutivité sur des milliers de serveurs dans plusieurs centres de données géographiquement diversifiés.

mono vs micro

Au lieu d'utiliser plusieurs composants étroitement couplés, Genesys Cloud divise ses fonctionnalités en services, chacun traitant un type de demande donné. Chaque service Genesys Cloud utilise des Elastic Load Balancers (ELB) pour distribuer le travail ; chaque groupe contient plusieurs serveurs, qui évoluent dynamiquement en fonction de la charge. Nous surveillons en permanence le trafic au niveau du service et optimisons les microservices en fonction des niveaux d'utilisation et des types de demandes.

Ce diagramme illustre les principaux services du Genesys Cloud.

Mise à l’échelle à la demande 

La plupart des services Genesys Cloud utilisent un ELB avec un groupe de mise à l’échelle automatique (ASG). Genesys Cloud distribue la charge et surveille les groupes en fonction de politiques spécifiques au service (processeur pour les services à forte intensité de calcul, temps de réponse moyen pour un service de requête, etc.). Lorsque nous dépassons une stratégie de seuil, le groupe ajoute ou supprime automatiquement des ressources supplémentaires en fonction des besoins. Par exemple, si une organisation doit soudainement envoyer un million de fax, les microservices associés s’adaptent automatiquement pour répondre à la demande sans impacter d’autres locataires.

Traitement à sécurité intégrée

Parce qu'ils fonctionnent indépendamment, un problème avec un microservice ne peut pas affecter l'autre, ce qui limite considérablement le potentiel de problèmes. Par exemple, trois microservices distincts gèrent la récupération de la messagerie vocale, la télécopie sortante et le routage des appels entrants des clients. Si le microservice de récupération de messagerie vocale échoue, les appels clients entrants microservice continuent de fonctionner sans interruption.

Fiabilité grâce à la récupération

Lorsqu’un serveur individuel tombe en panne, l’ELB / ASG approprié détecte les échecs de vérification de l’état de fonctionnement ou les délais d’attente et détache le composant non conforme de l’équilibrage de charge. Si cette erreur n’est pas passagère, une logique supplémentaire déclenche un comportement d’auto-réparation, dans laquelle le nœud errant est arrêté et un nouveau serveur créé pour prendre sa place. Le trafic se poursuit sans interruption, les autres serveurs du groupe prenant en charge le travail supplémentaire de manière transparente. PureCloud récupère avant qu’un utilisateur détecte une interruption de service. Ce processus de récupération nécessite une pointe de ressources, mais nous avons accès à une large bande passante à la demande via Amazon Web Services (AWS).

PureCloud repose sur AWS, le leader incontesté des déploiements internationaux dans le cloud. Nous travaillons en étroite collaboration avec Amazon pour tester et affiner leurs systèmes de surveillance et d'ELB.

Régions AWS

PureCloud est déployé dans plusieurs régions AWS indépendantes du monde entier. Chaque région comprend plusieurs « zones de disponibilité» Amazon, chacune comprenant un ou plusieurs centres de données physiques. La redondance est intégrée à la structure même du système, même à ce niveau, chaque zone de disponibilité possédant une alimentation, une connectivité réseau principale, une mémoire de données répliquée et (dans certains cas) une séparation physique couvrant les plaques d’erreur tectoniques. Les données client sont répliquées dans les zones et les centres de données d’une région. La perte d’un centre de données entier ne réduirait que temporairement la capacité. la situation guérira automatiquement, et ce, sans aucune perte de données. En plus d’assurer la durabilité des données, la souveraineté des données est également un aspect important du déploiement dans le cloud. L’architecture PureCloud permet à une organisation de définir sa « région d’enregistrement» afin de garantir que les données ne dépassent pas les limites régionales de notre infrastructure.

Régions AWS pour Genesys Cloud

Régions AWS pour le déploiement de Genesys Cloud

Navigateurs et clients mobiles

À bien des égards, les clients PureCloud reflètent l’approche sans état utilisée par les microservices. Lorsque navigateur rend PureCloud, un ensemble d’objets est intégré à la mémoire de navigateur, y compris les notifications d’événement pour les mises à jour des données. Au fur et à mesure que navigateur reçoit de nouvelles informations, il met à jour les objets en mémoire, puis met à jour la vue pour utilisateur.

A chaque fois qu’un utilisateur change de vue ou démarre un nouveau tâche, les données locales existantes sont immédiatement affichées lors d’une demande de vérification des mises à jour. Ces demandes de données sont conçues pour correspondre aux services disponibles et optimisées pour réduire la bande passante des données et améliorer la vitesse des vues client.

Mises à jour continuelles

Nous introduisons sans cesse de nouveaux codes dans notre système de production PureCloud. Si un petit défaut est détecté, nous le corrigeons immédiatement et sortons les nouvelles versions des services affectés.

Notre architecture distribuée nous permet de publier des mises à jour évolutives sans mettre tout le système à la maintenance. Nous utilisons l’équilibrage de la charge et des techniques telles que les « déploiements rouge-noir» pour nous assurer que nos clients ne sont pas affectés négativement par notre processus de mise à jour. Lorsqu’une nouvelle version d’un microservice (contenant de nouvelles fonctionnalités ou de nouveaux correctifs) est disponible, nous créons une toute nouvelle image de serveur pour ce service. Cette image est utilisée pour créer des serveurs entièrement nouveaux plutôt que pour appliquer des correctifs aux systèmes Au fur et à mesure que ces nouveaux serveurs arrivent code de conclusion et sont jugés sains, ils sont ensuite connectés à l’équilibreur de charge et un petit pourcentage du trafic commence maintenant à être manipulés par eux. En supposant que les nouveaux serveurs fonctionnent comme souhaité, davantage de capacité est ajoutée et les anciens serveurs (avec la version précédente du service) sont supprimés de l’équilibreur de charge et les demandes en attente sont drainées. En quelques minutes, des flottes de serveurs fournissant les fonctions d’un microservice peuvent être remplacées. En plus de garantir la continuité de la prestation de services, cette solution offre une fiabilité inégalée. Éviter la mise à niveau sur place réduit la fragilité en garantissant que les systèmes que nous testons dans nos environnements de pré-production sont fonctionnellement identiques aux systèmes déployés en production. De plus, cela permet de revenir rapidement à la variante connue d’un microservice dans le cas peu probable où une nouvelle version ne fonctionnerait pas comme souhaité.

L’indépendance des microservices et notre processus automatisé de tests et de promotion de la construction permettent à Genesys de proposer des solutions de bogues sans craindre de détruire par inadvertance autre chose. De plus, Genesys peut créer des microservices pour les nouvelles fonctionnalités sans impacter les services existants. Les mises à jour ont lieu alors que des millions de clients utilisent activement PureCloud.