Les applications Internet peuvent connaître des fluctuations d'utilisation extrêmes. Bien que la plupart des applications d'entreprise ne soient pas confrontées à ce problème, de nombreuses entreprises doivent faire face à un type de charges de travail intensives différent : les tâches par lots ou CI/CD.
Ce modèle d'architecture repose sur un déploiement redondant d'applications dans plusieurs environnements informatiques. L'objectif est d'accroître la capacité, la résilience ou les deux.
Bien que vous puissiez gérer des charges de travail intensives dans un environnement informatique basé sur un centre de données en approvisionnant des ressources en quantité excessive, cette approche n'est pas forcément rentable. Avec les tâches par lots, vous pouvez optimiser leur utilisation en différant leur exécution sur des périodes plus longues, bien qu'il ne soit pas pratique de retarder les tâches si elles sont urgentes.
Le concept de modèle d'utilisation temporaire du cloud consiste à utiliser un environnement informatique privé pour la charge de base et à se connecter temporairement au cloud en cas de besoins de capacité accrus.
Dans le schéma ci-dessus, lorsque la capacité de données est à sa limite dans un environnement privé sur site, le système peut obtenir une capacité supplémentaire à partir d'un environnementGoogle Cloud si nécessaire.
Les principaux moteurs de ce modèle sont les économies d'argent et la réduction du temps et des efforts nécessaires pour répondre aux changements d'exigences de mise à l'échelle. Avec cette approche, vous ne payez que les ressources utilisées pour gérer les charges supplémentaires. Vous n'avez donc pas besoin de surprovisionner votre infrastructure. Vous pouvez plutôt profiter des ressources cloud à la demande et les adapter à la demande et à toutes les métriques prédéfinies. Votre entreprise peut ainsi éviter les interruptions de service pendant les périodes de forte demande.
La portabilité des charges de travail est une condition essentielle pour les scénarios d'utilisation temporaire du cloud. Lorsque vous autorisez le déploiement de charges de travail dans plusieurs environnements, vous devez supprimer les différences qui existent entre ces environnements. Par exemple, Kubernetes vous permet d'assurer la cohérence au niveau de la charge de travail dans différents environnements qui utilisent des infrastructures différentes. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE Enterprise.
Considérations de conception
Le modèle d'utilisation temporaire du cloud s'applique aussi bien aux charges de travail interactives et par lots. Toutefois, lorsque vous traitez des charges de travail interactives, vous devez déterminer comment répartir les requêtes entre les différents environnements :
Vous pouvez acheminer les requêtes entrantes des utilisateurs vers un équilibreur de charge exécuté dans le centre de données existant, puis faire en sorte que l'équilibreur de charge répartisse les requêtes entre les ressources locales et cloud.
Cette approche nécessite que l'équilibreur de charge ou un autre système en cours d'exécution dans le centre de données existant procède également au suivi des ressources allouées dans le cloud. L'équilibreur de charge ou un autre système doivent également initier l'augmentation ou la diminution automatique des ressources. Cette approche vous permet de mettre toutes les ressources cloud hors service en période de faible activité. Toutefois, la mise en place de mécanismes capables de procéder au suivi des ressources pourrait aller au-delà des capacités de vos solutions d'équilibrage de charge et augmenter ainsi la complexité globale.
Au lieu d'implémenter des mécanismes pour suivre les ressources, vous pouvez utiliser l'Cloud Load Balancing avec un backend de groupe de points de terminaison du réseau (NEG) de connectivité hybride. Vous utilisez cet équilibreur de charge pour acheminer les requêtes des clients internes ou les requêtes des clients externes vers des backends situés à la fois sur site et dansGoogle Cloud , et qui sont basés sur différentes métriques, comme la répartition du trafic en fonction d'une pondération. Vous pouvez également effectuer un scaling des backends en fonction de la capacité de diffusion de l'équilibrage de charge pour les charges de travail dans Google Cloud. Pour en savoir plus, consultez la présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.
Cette approche présente plusieurs avantages supplémentaires, tels que l'utilisation des fonctionnalités de protection DDoS de Google Cloud Armor, du WAF et de la mise en cache du contenu en périphérie du cloud à l'aide de Cloud CDN. Toutefois, vous devez dimensionner la connectivité réseau hybride pour gérer le trafic supplémentaire.
Comme indiqué dans Portabilité des charges de travail, une application peut être portable dans un autre environnement avec des modifications minimes pour assurer la cohérence des charges de travail, mais cela ne signifie pas que les performances de l'application seront identiques dans les deux environnements. Les différences d'infrastructures de calcul ou de mise en réseau sous-jacentes, ainsi que la proximité de services dépendants, déterminent généralement les performances. Les tests vous permettent d'obtenir une visibilité plus précise et de comprendre les attentes en termes de performances.
Vous pouvez utiliser des services d'infrastructure cloud pour créer un environnement permettant d'héberger vos applications sans portabilité. Utilisez les approches suivantes pour gérer les requêtes client lorsque le trafic est redirigé pendant les périodes de forte demande :
- Utilisez des outils cohérents pour surveiller et gérer ces deux environnements.
- Assurez-vous que le versionnage des charges de travail est cohérent et que vos sources de données sont à jour.
- Vous devrez peut-être ajouter de l'automatisation pour provisionner l'environnement cloud et rediriger le trafic lorsque la demande augmente et que la charge de travail cloud est censée accepter les requêtes client pour votre application.
Si vous avez l'intention de fermer toutes les ressources Google Cloud pendant les périodes de faible demande, l'utilisation de règles de routage DNS principalement pour l'équilibrage de charge du trafic n'est pas toujours optimale. Cela est principalement dû aux raisons suivantes :
- L'initialisation des ressources peut prendre un certain temps avant qu'elles puissent être diffusées aux utilisateurs.
- Les mises à jour DNS ont tendance à se propager lentement sur Internet.
En conséquence :
- Les utilisateurs peuvent être routés vers l'environnement Cloud même lorsqu'aucune ressource n'est disponible pour traiter leurs requêtes.
- Les utilisateurs peuvent continuer à être redirigés temporairement vers l'environnement sur site pendant que les mises à jour DNS se propagent sur Internet.
Avec Cloud DNS, vous pouvez choisir la stratégie DNS et la stratégie de routage qui correspondent à l'architecture et au comportement de votre solution, comme les stratégies de routage DNS par géolocalisation. Cloud DNS accepte également les vérifications de l'état pour les équilibreurs de charge réseau passthrough internes et les équilibreurs de charge d'application internes. Dans ce cas, vous pouvez l'intégrer à votre configuration DNS hybride globale basée sur ce modèle.
Dans certains cas, vous pouvez utiliser Cloud DNS pour distribuer les requêtes client avec des vérifications de l'état sur Google Cloud, par exemple lorsque vous utilisez des équilibreurs de charge d'application internes ou des équilibreurs de charge d'application internes interrégionaux. Dans ce scénario, Cloud DNS vérifie l'état général de l'équilibreur de charge d'application interne, qui vérifie lui-même l'état des instances backend. Pour en savoir plus, consultez Gérer les règles de routage DNS et les vérifications d'état.
Vous pouvez également utiliser le DNS fractionné Cloud DNS. L'horizon partagé Cloud DNS est une approche permettant de configurer des réponses ou des enregistrements DNS en fonction de l'emplacement ou du réseau spécifiques de l'auteur de la requête DNS pour le même nom de domaine. Cette approche est couramment utilisée pour répondre aux exigences selon lesquelles une application est conçue pour offrir une expérience privée et une expérience publique, chacune avec des fonctionnalités uniques. Cette approche permet également de répartir la charge de trafic entre les environnements.
Compte tenu de ces considérations, l'utilisation temporaire du cloud se prête généralement mieux aux charges de travail par lots qu'aux charges de travail interactives.
Avantages
Voici les principaux avantages du modèle d'architecture Cloud Bursting :
- L'utilisation temporaire du cloud vous permet de réutiliser des centres de données et environnements informatiques privés existants. Cette réutilisation peut être permanente ou temporaire jusqu'à ce que le remplacement des équipements existants soit nécessaire. Vous pourrez alors envisager une migration complète.
- Comme vous n'aurez plus besoin de conserver une capacité excédentaire pour répondre aux pics de requêtes, vous pourrez peut-être augmenter l'utilisation et la rentabilité de vos environnements informatiques privés.
- L'utilisation temporaire du cloud vous permet d'exécuter des tâches par lots en temps voulu sans qu'il soit nécessaire de surprovisionner des ressources de calcul.
Bonnes pratiques
Lorsque vous mettez en œuvre le modèle d'utilisation temporaire du cloud, tenez compte des bonnes pratiques suivantes :
- Pour vous assurer que les charges de travail exécutées dans le cloud peuvent accéder aux ressources de la même manière que les charges de travail exécutées dans un environnement sur site, utilisez le modèle maillé avec le principe d'accès sécurisé du moindre privilège. Si la conception de la charge de travail le permet, vous pouvez autoriser l'accès uniquement du cloud vers l'environnement informatique sur site, et non l'inverse.
- Pour minimiser la latence des communications entre les environnements, choisissez une régionGoogle Cloud géographiquement proche de votre environnement informatique privé. Pour en savoir plus, consultez Bonnes pratiques pour la sélection des régions Compute Engine.
- Lorsque vous utilisez le modèle d'utilisation temporaire du cloud pour des charges de travail par lots seulement, réduisez la surface d'attaque de sécurité en gardant toutes les ressources Google Cloud privées. Interdisez tout accès direct à ces ressources depuis Internet, même si vous utilisez l'équilibrage de charge externe Google Cloud pour fournir le point d'entrée de la charge de travail.
Sélectionnez la règle DNS et la règle de routage qui correspondent à votre modèle d'architecture et au comportement de la solution ciblée.
- Dans ce modèle, vous pouvez appliquer la conception de vos règles DNS de manière permanente ou lorsque vous avez besoin de capacité supplémentaire en utilisant un autre environnement pendant les périodes de forte demande.
- Vous pouvez utiliser des règles de routage DNS de géolocalisation pour définir un point de terminaison DNS global pour vos équilibreurs de charge régionaux. Cette tactique présente de nombreux cas d'utilisation pour les règles de routage DNS de géolocalisation, y compris les applications hybrides qui utilisent Google Cloud avec un déploiement sur site où la région Google Cloud existe.
Si vous devez fournir des enregistrements différents pour les mêmes requêtes DNS, vous pouvez utiliser le DNS fractionné (par exemple, les requêtes provenant de clients internes et externes).
Pour en savoir plus, consultez les architectures de référence pour le DNS hybride.
Pour vous assurer que les modifications DNS sont propagées rapidement, configurez votre DNS avec une valeur TTL relativement courte. Vous pourrez ainsi rediriger les utilisateurs vers des systèmes de secours lorsque vous aurez besoin de capacité supplémentaire à l'aide d'environnements cloud.
Pour les tâches qui ne sont pas urgentes et qui ne stockent pas de données en local, envisagez d'utiliser des instances de VM spot, qui sont nettement moins chères que les instances de VM classiques. Toutefois, une condition préalable est que, si la VM est préemptée, le système doit pouvoir redémarrer automatiquement le job.
Assurez la portabilité des charges de travail à l'aide de conteneurs, le cas échéant. De plus, GKE Enterprise peut être une technologie clé pour cette conception. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE Enterprise.
Surveillez tout trafic envoyé depuis Google Cloud vers un environnement informatique différent. Ce trafic est soumis à des frais de transfert de données sortantes.
Si vous prévoyez d'utiliser cette architecture à long terme avec un volume élevé de transfert de données sortantes, envisagez d'utiliser Cloud Interconnect. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et à réduire les frais de transfert de données sortantes pour le trafic qui remplit certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.
Lorsque vous utilisez Cloud Load Balancing, vous devez exploiter ses fonctionnalités d'optimisation de la capacité des applications , le cas échéant. Cela peut vous aider à résoudre certains problèmes de capacité qui peuvent survenir dans les applications distribuées à l'échelle mondiale.
Authentifiez les personnes qui utilisent vos systèmes en établissant une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.
Pour protéger les informations sensibles, il est vivement recommandé de chiffrer toutes les communications en transit. Si le chiffrement est requis au niveau de la connectivité, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, HA VPN via Cloud Interconnect et MACsec pour Cloud Interconnect.