Partager via

Modèle de mise à l’échelle multicloud

  • Article

Ajoutez automatiquement des ressources à une application existante pour faire face à une hausse de la charge.

Contexte et problème

Votre application ne peut pas augmenter sa capacité pour répondre à une hausse inattendue de la demande. En raison de ce manque de scalabilité, les utilisateurs ne peuvent donc pas accéder à l’application pendant les pics d’utilisation. L’application peut répondre aux demandes d’un nombre fixe d’utilisateurs.

Les entreprises internationales ont besoin d’applications cloud sécurisées, fiables et disponibles. La réponse à la hausse de la demande et l’utilisation de l’infrastructure appropriée pour prendre en charge cette demande sont des aspects critiques. Les entreprises ont des difficultés à équilibrer les coûts et la maintenance en ce qui concerne la sécurité, le stockage et la disponibilité en temps réel des données métier.

Vous ne pourrez peut-être pas exécuter votre application dans le cloud public. Toutefois, ceci peut ne pas être économiquement faisable pour que l’entreprise puisse maintenir la capacité nécessaire dans son environnement local afin de gérer les pics de demande de l’application. Avec ce modèle, vous pouvez tirer parti de l’élasticité du cloud public pour votre solution locale.

Solution

Le modèle de mise à l’échelle multicloud étend une application située dans un cloud local avec les ressources du cloud public. Le modèle se déclenche en réponse à une hausse ou une baisse de la demande, puis ajoute ou supprime respectivement des ressources dans le cloud. Ces ressources assurent une redondance, une disponibilité rapide et un routage géoconforme.

Cross-cloud scaling pattern

Notes

Ce modèle s’applique uniquement aux applications sans état de votre application.

Components

Le modèle de mise à l’échelle multicloud inclut les composants suivants.

En dehors du cloud

Traffic Manager

Dans le diagramme, il se situe en dehors du groupe de clouds publics, mais il doit pouvoir coordonner le trafic dans le centre de données local et dans le cloud public. L’équilibreur offre une haute disponibilité pour l’application en supervisant les points de terminaison et en assurant la redistribution du basculement en cas de besoin.

DNS (Domain Name System)

Le DNS (Domain Name System) se charge de traduire (ou résoudre) un nom de site web ou de service en une adresse IP.

Cloud

Serveur de builds hébergé

Environnement d’hébergement de votre pipeline de build.

Ressources de l’application

Les ressources d’application doivent pouvoir effectuer un scale-in et un scale-out, à l’image des groupes de machines virtuelles identiques et des conteneurs.

Nom de domaine personnalisé

Utilisez un nom de domaine personnalisé pour le Glob de routage des requêtes.

Adresses IP publiques

Les adresses IP publiques sont utilisées pour router le trafic entrant via Traffic Manager vers le point de terminaison des ressources d’application du cloud public.  

Cloud local

Serveur de builds hébergé

Environnement d’hébergement de votre pipeline de build.

Ressources de l’application

Les ressources d’application doivent pouvoir effectuer un scale-in et un scale-out, à l’image des groupes de machines virtuelles identiques et des conteneurs.

Nom de domaine personnalisé

Utilisez un nom de domaine personnalisé pour le Glob de routage des requêtes.

Adresses IP publiques

Les adresses IP publiques sont utilisées pour router le trafic entrant via Traffic Manager vers le point de terminaison des ressources d’application du cloud public.

Problèmes et considérations

Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :

Extensibilité

Le composant clé de la mise à l’échelle multicloud est la possibilité de fournir une mise à l’échelle à la demande. La mise à l’échelle doit se produire entre l’infrastructure cloud publique et locale et fournir un service cohérent et fiable à la demande.

Disponibilité

Vérifiez que les applications déployées en local sont configurées pour la haute disponibilité via la configuration matérielle locale et le déploiement de logiciels.

Simplicité de gestion

Le modèle multicloud garantit une gestion fluide et l’accès à une interface familière entre les environnements.

Quand utiliser ce modèle

Utilisez ce modèle :

  • Quand vous avez besoin d’augmenter la capacité de votre application pour faire face à des demandes inattendues ou régulières.
  • Quand vous ne souhaitez pas investir dans des ressources qui vont être utilisées uniquement durant les pics d’activité. Payez pour ce que vous utilisez.

Ce modèle n’est pas recommandé quand :

  • Votre solution impose aux utilisateurs de se connecter via Internet
  • Votre entreprise doit se conformer à des réglementations locales qui imposent à la connexion d’origine de provenir d’un appel local
  • Votre réseau est confronté à des goulots d’étranglement réguliers qui limitent les performances de la mise à l’échelle.
  • Votre environnement est déconnecté d’Internet et ne peut pas atteindre le cloud public.

Étapes suivantes

Pour en savoir plus sur les sujets abordés dans cet article :

Lorsque vous êtes prêt à tester l’exemple de solution, poursuivez avec le Guide de déploiement de la solution de mise à l’échelle multicloud. Ce guide de déploiement fournit des instructions pas à pas sur le déploiement et sur le test de ses composants. Découvrez comment créer une solution multicloud pour fournir un processus déclenché manuellement permettant de passer d’une application web hébergée sur Azure Stack Hub à une application web hébergée sur Azure. Découvrez également comment utiliser la mise à l’échelle automatique via Traffic Manager, en garantissant un utilitaire cloud flexible et scalable en cas de charge.