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'augmenter la capacité ou 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 diagramme précédent, lorsque la capacité de données est à sa limite dans un environnement privé sur site, le système peut gagner de la capacité supplémentaire à partir d'un environnement Google Cloud si nécessaire.
Les principaux moteurs de ce modèle sont l'économie d'argent et la réduction du temps et des efforts nécessaires pour répondre aux changements de besoins d'évolutivité. Avec cette approche, vous ne payez que les ressources utilisées lors du traitement des 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 faire évoluer en fonction de la demande et de toute métrique prédéfinie. Votre entreprise peut ainsi éviter les interruptions de service pendant les heures de pointe.
La portabilité des charges de travail est une exigence potentielle 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 divers environnements qui utilisent différentes infrastructures. 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 doit également lancer 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 permettant de suivre les ressources peut 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 de suivi des 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 client internes ou les requêtes client externes vers des backends situés à la fois sur site et dans Google 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 faire évoluer les 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 section 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'exploitation des fonctionnalités de protection DDoS de Google Cloud Armor, du WAF et du cache de contenu au niveau du cloud edge à l'aide de Cloud CDN. Toutefois, vous devez dimensionner la connectivité réseau hybride pour gérer le trafic supplémentaire.
Comme indiqué dans la section Portabilité des charges de travail, une application peut être portable dans un autre environnement avec des modifications minimales pour assurer la cohérence des charges de travail, mais cela ne signifie pas que ses performances seront les mêmes dans les deux environnements. Les différences de calcul sous-jacent, des fonctionnalités de sécurité de l'infrastructure ou de l'infrastructure réseau, ainsi que la proximité des services dépendants, déterminent généralement les performances. Grâce aux tests, vous pouvez obtenir une visibilité plus précise et 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 pics de demande:
- Utilisez des outils cohérents pour surveiller et gérer ces deux environnements.
- Assurez-vous que la gestion des versions de la charge de travail est cohérente et que vos sources de données sont à jour.
- Vous devrez peut-être ajouter une automatisation pour provisionner l'environnement cloud et rediriger le trafic lorsque la demande augmente et que la charge de travail cloud doit 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 la charge de 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 servir les utilisateurs.
- Les mises à jour DNS ont tendance à se propager lentement sur Internet.
En conséquence :
- Les utilisateurs peuvent être acheminé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 vers l'environnement sur site temporairement pendant que les mises à jour DNS se propagent sur Internet.
Avec Cloud DNS, vous pouvez choisir les règles DNS et de routage qui correspondent à l'architecture et au comportement de votre solution, comme les règles de routage DNS de 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 global de l'équilibreur de charge d'application interne, qui vérifie à son tour l'état des instances backend. Pour en savoir plus, consultez la page Gérer les règles de routage DNS et les vérifications d'état.
Vous pouvez également utiliser le DNS fractionné Cloud DNS. Le DNS fractionné 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écifique de l'expéditeur de la requête DNS pour le même nom de domaine. Cette approche est couramment utilisée pour répondre aux exigences d'une application conçue pour offrir à la fois 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 d'utilisation intensive dans le cloud:
- 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 les équipements existants soient remplacés. Vous pouvez alors envisager une migration complète.
- Comme vous n'avez 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 provisionner des ressources de calcul supplémentaires.
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 de sécurité le moins privilégié. Si la conception de la charge de travail le permet, vous ne pouvez autoriser l'accès que du cloud à l'environnement IT sur site, et non l'inverse.
- Pour minimiser la latence des communications entre les environnements, choisissez une région Google Cloud géographiquement proche de votre environnement informatique privé. Pour en savoir plus, consultez la section 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 à la charge de travail.
Sélectionnez les règles DNS et de routage qui correspondent à votre modèle d'architecture et au comportement de la solution ciblée.
- Dans le cadre de ce modèle, vous pouvez appliquer la conception de vos règles DNS de manière permanente ou lorsque vous avez besoin d'une capacité supplémentaire à l'aide d'un autre environnement pendant les pics de 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 stratégie 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 dans une région Google Cloud.
Si vous devez fournir des enregistrements différents pour les mêmes requêtes DNS, vous pouvez utiliser le DNS fractionné (par exemple, pour 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 afin de pouvoir rediriger les utilisateurs vers des systèmes de secours lorsque vous avez besoin de capacité supplémentaire à l'aide d'environnements cloud.
Pour les tâches qui ne sont pas très urgentes et qui ne stockent pas de données localement, envisagez d'utiliser des instances de VM Spot, qui reviennent nettement moins cher que les instances de VM classiques. Toutefois, une condition préalable est que, si la tâche de VM est préemptée, le système doit pouvoir la redémarrer automatiquement.
Utilisez des conteneurs pour assurer la portabilité des charges de travail, 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 de transfert de données sortant élevé, envisagez d'utiliser Cloud Interconnect. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et peut réduire les frais de transfert de données sortants pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.
Lorsque vous utilisez Cloud Load Balancing, vous devez utiliser ses fonctionnalités d'optimisation de la capacité des applications , le cas échéant. Cela peut vous aider à résoudre certains des problèmes de capacité pouvant survenir dans les applications distribuées dans le monde entier.
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 couche de 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.