Concevoir une infrastructure fiable pour vos charges de travail dans Google Cloud

Déploiement à zone unique

Le schéma suivant montre une architecture d'application à zone unique avec redondance à chaque niveau, pour une disponibilité plus élevée des fonctions effectuées par chaque composant :

Comme le montre le schéma précédent, cet exemple d'architecture comprend les composants suivants :

• Un équilibreur de charge HTTP/S externe régional permettant de recevoir les requêtes des utilisateurs et d'y répondre.
• Un groupe d'instances géré (MIG) zonal en tant que backend pour l'équilibreur de charge HTTP/S. Le MIG comporte deux VM Compute Engine. Chaque VM héberge une instance d'un serveur Web.
• Un équilibreur de charge interne pour gérer la communication entre le serveur Web et les instances du serveur d'applications.
• Un deuxième MIG zonal servant de backend à l'équilibreur de charge interne. Ce MIG contient deux VM Compute Engine. Chaque VM héberge une instance d'un serveur d'applications.
• Une instance de base de données Cloud SQL Enterprise à partir de laquelle l'application écrit et lit des données. La base de données est répliquée manuellement sur une deuxième instance de base de données Cloud SQL dans la même zone.

Disponibilité globale : déploiement à zone unique

Le tableau suivant indique la disponibilité de chaque niveau dans le schéma d'architecture à zone unique précédent :

Les ressources d'infrastructure Google Cloud regroupées dans le tableau précédent fournissent la disponibilité globale suivante et le temps d'arrêt mensuel maximal estimé :

• Disponibilité globale : 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73 %
• Temps d'arrêt mensuel maximal estimé : environ 1 heure et 57 minutes

Ce calcul ne prend en compte que les ressources d'infrastructure affichées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :

• Conception interne de l'application
• Les processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud

Pour en savoir plus, consultez la section Facteurs affectant la fiabilité des applications.

Effets des pannes et conseils pour la récupération

Dans une architecture de déploiement à zone unique, en cas de défaillance d'un composant, l'application peut traiter les requêtes si chaque niveau contient au moins un composant fonctionnel disposant d'une capacité suffisante. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge transfère les requêtes des utilisateurs aux autres instances du serveur Web. Si une VM qui héberge un serveur Web ou une instance de serveur d'applications plante, le MIG garantit qu'une nouvelle VM est créée automatiquement. Si la base de données plante, vous devez activer manuellement la deuxième base de données et mettre à jour les instances du serveur d'applications pour qu'elles se connectent à la base de données.

Une panne zonale ou régionale affecte les VM Compute Engine et les instances de base de données Cloud SQL lors d'un déploiement à zone unique. Les pannes zonales n'affectent pas l'équilibreur de charge de cette architecture, car il s'agit d'une ressource régionale. Cependant, l'équilibreur de charge ne peut pas distribuer le trafic, car aucun backend n'est disponible. Si une panne zonale se produit, vous devez attendre que Google la résolve, puis vérifier que l'application fonctionne comme prévu.

La section suivante décrit une approche architecturale que vous pouvez utiliser pour répartir les ressources sur plusieurs zones, ce qui permet d'améliorer la résilience de l'application aux pannes zonales.

Déploiement multizone

Dans le cas d'un déploiement à zone unique, en cas de panne zonale, l'application risque de ne pas pouvoir diffuser les requêtes tant que le problème n'est pas résolu. Pour améliorer la résilience de votre application contre les pannes zonales, vous pouvez provisionner plusieurs instances de ressources zonales (telles que les VM Compute Engine) sur deux zones ou plus. Pour les services compatibles avec les ressources à l'échelle de la région (telles que les buckets Cloud Storage), vous pouvez déployer des ressources régionales.

Le schéma suivant illustre une architecture interzone à disponibilité élevée, avec les composants de chaque niveau de la pile d'applications répartis sur deux zones :

Comme le montre le schéma précédent, cet exemple d'architecture comprend les composants suivants :

• Un équilibreur de charge HTTP/S externe régional reçoit les requêtes des utilisateurs et y répond.
• Un MIG régional est le backend de l'équilibreur de charge HTTP/S. Le MIG contient deux VM Compute Engine dans différentes zones. Chaque VM héberge une instance de serveur Web.
• Un équilibreur de charge interne gère la communication entre le serveur Web et les instances du serveur d'applications.
• Un deuxième MIG régional est le backend de l'équilibreur de charge TCP. Ce MIG comporte deux VM Compute Engine dans différentes zones. Chaque VM héberge une instance d'un serveur d'applications.
• Une instance Cloud SQL Enterprise configurée pour la haute disponibilité est la base de données de l'application. L'instance de base de données principale est répliquée de manière synchrone sur une instance de base de données de secours.

Disponibilité globale : déploiement multizone

Le tableau suivant indique la disponibilité de chaque niveau dans le schéma d'architecture à deux zones précédent :

Les ressources d'infrastructure Google Cloud regroupées dans le tableau précédent fournissent la disponibilité globale suivante et le temps d'arrêt mensuel maximal estimé :

• Disponibilité globale : 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91 %
• Temps d'arrêt mensuel maximal estimé : environ 39 minutes

Ce calcul ne prend en compte que les ressources d'infrastructure affichées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :

• Conception interne de l'application
• Les processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud

Pour en savoir plus, consultez la section Facteurs affectant la fiabilité des applications.

Effets des pannes et conseils pour la récupération

Dans un déploiement à deux zones, en cas de défaillance d'un composant, l'application peut traiter les requêtes si au moins un composant fonctionnel disposant d'une capacité suffisante existe à chaque niveau. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge transfère les requêtes des utilisateurs à l'instance de serveur Web dans l'autre zone. Si une VM qui héberge un serveur Web ou une instance de serveur d'applications plante, le MIG garantit qu'une nouvelle VM est créée automatiquement. Si la base de données Cloud SQL principale plante, Cloud SQL bascule automatiquement vers l'instance de base de données de secours.

Le schéma suivant illustre la même architecture que le schéma précédent et les effets d'une panne zonale sur la disponibilité de l'application :

Comme le montre le schéma précédent, en cas de panne dans l'une des zones, l'équilibreur de charge de cette architecture n'est pas affecté, car il s'agit d'une ressource régionale. Une panne zonale peut affecter des VM Compute Engine individuelles et l'une des instances de base de données Cloud SQL. Toutefois, l'application reste disponible et réactive, car les VM se trouvent dans les MIG régionaux et la base de données Cloud SQL est configurée pour la haute disponibilité. Les groupes d'instances gérés assurent la création automatique de VM pour conserver le nombre minimal de VM configuré. Si l'instance de base de données Cloud SQL principale est affectée par une panne zonale, Cloud SQL bascule automatiquement vers l'instance de secours dans l'autre zone. Une fois la panne résolue par Google, vous devez vérifier que l'application s'exécute comme prévu dans toutes les zones où elle est déployée.

Si les deux zones de cette architecture présentent une panne, l'application est indisponible. L'équilibreur de charge reste disponible, sauf en cas d'interruption à l'échelle de la région. Cependant, l'équilibreur de charge ne peut pas distribuer le trafic, car aucun backend n'est disponible. Si une panne multizone ou une panne régionale se produit, vous devez attendre que Google résolve la panne, puis vérifier que l'application fonctionne comme prévu.

Les sections suivantes présentent des options d'architecture pour protéger votre application contre les pannes multizones et les pannes régionales.

Déploiement multirégional avec équilibrage de charge régional

Dans un déploiement à zone unique ou multizone, en cas de panne régionale, l'application ne peut pas diffuser les requêtes tant que le problème n'est pas résolu. Pour protéger votre application contre les pannes régionales, vous pouvez répartir les ressources Google Cloud sur deux régions ou plus.

Le schéma suivant montre une architecture interrégionale à disponibilité élevée, avec les composants de chaque niveau de la pile d'applications répartis sur plusieurs régions :

Comme le montre le schéma précédent, cet exemple d'architecture comprend les composants suivants :

• Une zone Cloud DNS publique avec une règle de routage qui dirige le trafic vers deux régions Google Cloud.
• Un équilibreur de charge HTTP/S externe régional dans chaque région pour recevoir les requêtes des utilisateurs et y répondre.
• Le backend de chaque équilibreur de charge HTTP/S régional est un MIG régional. Chaque MIG contient deux VM Compute Engine dans différentes zones. Chacune de ces VM héberge une instance d'un serveur Web.
• Un équilibreur de charge interne dans chaque région gère la communication entre les instances du serveur Web et les instances du serveur d'applications.
• Une deuxième paire de MIG régionaux est le backend des équilibreurs de charge internes. Chacun de ces MIG contient deux VM Compute Engine dans différentes zones. Chaque VM héberge une instance d'un serveur d'applications.
• L'application écrit et lit dans une instance multirégionale Spanner. La configuration multirégionale utilisée dans cette architecture (eur5) comprend quatre instances dupliquées en lecture/écriture. Les instances dupliquées en lecture/écriture sont provisionnées de manière égale entre deux régions et dans des zones distinctes. La configuration multirégionale Spanner inclut également une instance dupliquée témoin dans une troisième région.

Disponibilité globale : déploiement multirégional avec équilibrage de charge régional

Dans le déploiement multirégional illustré dans le schéma précédent, les équilibreurs de charge et les VM sont provisionnés de manière redondante dans deux régions. La zone DNS est une ressource globale et l'instance Spanner est une ressource multirégionale.

Pour calculer la disponibilité globale de l'infrastructure Google Cloud présentée dans cette architecture, nous devons d'abord calculer la disponibilité globale des ressources dans chaque région, puis prendre en compte les ressources qui couvrent plusieurs régions. Procédez comme suit :

1. Calculer la disponibilité globale des ressources d'infrastructure par région, autrement dit, en excluant des ressources DNS et de la base de données :

   Ressources et contrat de niveau de service	Contrat de niveau de service
   Équilibreur de charge externe	99,99 %
   Niveau Web : VM Compute Engine dans des zones distinctes	99,99 %
   Équilibreur de charge interne	99,99 %
   Niveau d'application : VM Compute Engine dans des zones distinctes	99,99 %

   Disponibilité globale par région : 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96 %

2. Calculez la disponibilité globale des ressources d'infrastructure en tenant compte de la redondance à deux zones des équilibreurs de charge et des VM Compute Engine.

   La disponibilité théorique est de 1-(1-0,9996)(1-0,9996) = 99,999984 %. Toutefois, la disponibilité réelle que vous pouvez attendre est limitée à la disponibilité cible des déploiements multirégionaux, qui est de 99,999 %.

3. Calculez la disponibilité globale de toutes les ressources d'infrastructure, y compris les ressources Cloud DNS et Spanner :

   • Disponibilité globale : 0,99999 x 1 x 0,99999 = 99,998 %
   • Temps d'arrêt mensuel maximal estimé : environ 52 secondes

Ce calcul ne prend en compte que les ressources d'infrastructure affichées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :

• Conception interne de l'application
• Les processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud

Pour en savoir plus, consultez la section Facteurs affectant la fiabilité des applications.

Effets des pannes et conseils pour la récupération

Si l'un des composants de ce déploiement multirégional échoue, mais qu'il existe au moins un composant fonctionnel avec une capacité suffisante à chaque niveau, l'application continue de fonctionner. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge HTTP/S externe régional transfère les requêtes des utilisateurs aux autres instances du serveur Web de la région. De même, si l'une des instances du serveur d'applications plante, les équilibreurs de charge internes envoient des requêtes aux autres instances du serveur d'applications. Si l'une des VM plante, les MIG s'assurent de créer automatiquement des VM pour conserver le nombre minimal de VM configuré.

Les pannes dans une zone n'affectent pas les équilibreurs de charge, car il s'agit de ressources régionales et résilientes aux pannes zonales. Une panne zonale peut affecter les VM Compute Engine individuelles. Toutefois, les instances du serveur Web et du serveur d'applications restent disponibles, car les VM font partie des MIG régionaux. Les groupes d'instances gérés s'assurent de créer automatiquement des VM pour conserver le nombre minimal de VM configuré. L'instance Spanner de cette architecture utilise une configuration multirégionale, résiliente aux pannes zonales.

Pour en savoir plus sur le fonctionnement de la réplication multirégionale dans Spanner, consultez les pages Configurations régionales et multirégionales et Démystifier les configurations multirégionales Spanner.

Le schéma suivant illustre la même architecture multirégionale que le schéma précédent et les effets d'une panne régionale dans la disponibilité de l'application :

Comme le montre le schéma précédent, même en cas de panne dans les deux zones de n'importe quelle région, l'application reste disponible, car une pile d'applications indépendante est déployée dans chaque région. La zone DNS dirige les requêtes des utilisateurs vers la région non touchée par la panne. L'instance Spanner multirégionale est résiliente aux pannes régionales. Une fois la panne résolue par Google, vous devez vérifier que l'application s'exécute comme prévu dans la région où la panne a eu lieu.

Si deux des régions de cette architecture présentent des pannes, l'application est indisponible. Attendez que Google ait résolu les pannes. Ensuite, vérifiez que l'application s'exécute comme prévu dans toutes les régions où elle est déployée.

Pour les déploiements multirégionaux, au lieu d'utiliser des équilibreurs de charge régionaux, vous pouvez envisager d'utiliser un équilibreur de charge global. La section suivante présente une architecture de déploiement multirégionale qui utilise un équilibreur de charge global et décrit les avantages et les risques de cette approche.

Déploiement multirégional avec équilibrage de charge global

Le schéma suivant illustre un autre déploiement multirégional utilisant un équilibreur de charge global plutôt que des équilibreurs de charge régionaux :

Comme le montre le schéma précédent, cette architecture utilise un équilibreur de charge HTTP/S externe global (avec Cloud CDN activé) pour recevoir les requêtes des utilisateurs et y répondre. Chaque règle de transfert de l'équilibreur de charge utilise une seule adresse IP externe. Vous n'avez pas besoin de configurer un enregistrement DNS distinct pour chaque région. Les backends de l'équilibreur de charge HTTP/S externe global sont deux MIG régionaux. L'équilibreur de charge achemine les requêtes vers la région la plus proche des utilisateurs.

Tous les autres composants de cette architecture sont identiques à l'architecture présentée dans le document Déploiement multirégional avec équilibrage de charge régional.

Avantages et risques de l'équilibrage de charge global pour les déploiements multirégionaux

Pour équilibrer le trafic externe vers une application répartie sur plusieurs régions, vous pouvez utiliser un équilibreur de charge global ou plusieurs équilibreurs de charge régionaux.

Voici les avantages d'une architecture utilisant un équilibreur de charge global :

• Vous ne devez gérer qu'un seul équilibreur de charge.
• Les équilibreurs de charge mondiaux utilisent une seule adresse IP Anycast pour fournir un équilibrage de charge entre les régions Google Cloud.
• Les équilibreurs de charge mondiaux sont résilients aux pannes régionales et fournissent un basculement automatique entre les régions.
• Les équilibreurs de charge mondiaux sont compatibles avec les fonctionnalités suivantes, qui peuvent améliorer la fiabilité de vos déploiements :
  • Mise en cache périphérique à l'aide de Cloud CDN
  • Possibilité d'utiliser des buckets Cloud Storage très durables en tant que backends
  • Règles de sécurité Google Cloud Armor

Voici les risques d'une architecture utilisant un équilibreur de charge global :

• Une modification de configuration incorrecte dans l'équilibreur de charge global peut rendre l'application indisponible pour les utilisateurs. Par exemple, lors de la mise à jour de l'interface de l'équilibreur de charge global, si vous supprimez accidentellement une règle de transfert, celui-ci cesse de recevoir des requêtes utilisateur. L'effet de ce risque est plus faible dans le cas d'une architecture multirégionale utilisant des équilibreurs de charge régionaux, car même si l'équilibreur de charge régional dans l'une des régions est affecté par une erreur de configuration, les équilibreurs de charge des autres régions continuent de fonctionner.
• Une panne d'infrastructure qui affecte les ressources globales peut rendre l'équilibreur de charge global indisponible.

Pour limiter ces risques, vous devez gérer avec soin les modifications apportées à l'équilibreur de charge global et envisager d'utiliser des solutions de remplacement en profondeur si possible. Pour en savoir plus, consultez la page Recommandations pour gérer le risque d'interruption des ressources globales.

Disponibilité globale : déploiement multirégional avec équilibrage de charge global

Dans le déploiement multirégional illustré dans le schéma précédent, les VM et les équilibreurs de charge internes sont répartis de manière redondante entre deux régions. L'équilibreur de charge externe est une ressource globale et l'instance Spanner est une ressource multirégionale.

Pour calculer la disponibilité globale de ce déploiement, nous calculons d'abord la disponibilité globale des ressources dans chaque région, puis nous examinons les ressources couvrant plusieurs régions.

1. Calculez la disponibilité globale des ressources d'infrastructure par région, en excluant l'équilibreur de charge externe et la base de données :

   Ressource	Contrat de niveau de service
   Niveau Web : VM Compute Engine dans des zones distinctes	99,99 %
   Équilibreur de charge interne	99,99 %
   Niveau d'application : VM Compute Engine dans des zones distinctes	99,99 %

   Disponibilité globale par région : 0,9999 x 0,9999 x 0,9999 = 99,97 %

2. Calculez la disponibilité globale des ressources d'infrastructure en tenant compte de la redondance à deux zones de l'équilibreur de charge interne et des VM Compute Engine.

   La disponibilité théorique est de 1-(1-0.9997)(1-0.9997) = 99,999991 %. Toutefois, la disponibilité réelle que vous pouvez attendre est limitée à la disponibilité cible des déploiements multirégionaux, qui est de 99,999 %.

3. Calculez la disponibilité globale de toutes les ressources d'infrastructure, y compris l'équilibreur de charge global et les ressources Spanner :

   • Disponibilité globale : 0,99999 x 0,9999 x 0,99999 = 99,988 %
   • Temps d'arrêt mensuel maximal estimé : environ 5 minutes et 11 secondes

Ce calcul ne prend en compte que les ressources d'infrastructure affichées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :

• Conception interne de l'application
• Les processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud

Pour en savoir plus, consultez la section Facteurs affectant la fiabilité des applications.

Effets des pannes et conseils pour la récupération

Si un composant de cette architecture échoue, l'application continue de fonctionner si au moins un composant fonctionnel avec une capacité suffisante existe à chaque niveau. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge HTTP/S externe global transfère les requêtes des utilisateurs aux autres instances du serveur Web. Si une instance de serveur d'applications plante, les équilibreurs de charge internes envoient les requêtes aux autres instances de serveur d'applications. Si l'une des VM plante, les MIG s'assurent de créer automatiquement des VM pour conserver le nombre minimal de VM configuré.

Si une panne se produit dans l'une des zones de n'importe quelle région, l'équilibreur de charge n'est pas affecté. L'équilibreur de charge HTTP/S externe global est résilient aux pannes zonales et régionales. Les équilibreurs de charge internes sont des ressources régionales. Elles sont résilientes aux pannes zonales. Les pannes zonales peuvent affecter les VM Compute Engine individuelles. Toutefois, les instances du serveur Web et du serveur d'applications restent disponibles, car les VM font partie des MIG régionaux. Les MIG garantissent que de nouvelles VM sont créées automatiquement pour conserver le nombre minimal de VM configuré. L'instance Spanner de cette architecture utilise une configuration multirégionale, résiliente aux pannes zonales.

Le schéma suivant illustre la même architecture multirégionale que le schéma précédent et les effets d'une panne régionale dans la disponibilité de l'application :

Comme le montre le schéma précédent, même en cas de panne dans les deux zones de n'importe quelle région, l'application reste disponible, car une pile d'applications indépendante est déployée dans chaque région. L'équilibreur de charge HTTP/S externe global achemine les requêtes des utilisateurs vers l'application dans la région qui n'est pas affectée par la panne. L'instance Spanner multirégionale est résiliente aux pannes régionales. Une fois que Google a résolu la panne, vous devez vérifier que l'application s'exécute comme prévu dans la région où la panne a eu lieu.

Pour en savoir plus sur le fonctionnement de la réplication multirégionale dans Spanner, consultez les pages Configurations régionales et multirégionales et Démystifier les configurations multirégionales Spanner.

Si deux des régions de cette architecture présentent des pannes, l'application est indisponible. L'équilibreur de charge HTTP/S externe global est disponible, mais il ne peut pas distribuer de trafic, car aucun backend n'est disponible. Attendez que Google ait résolu les pannes. Ensuite, vérifiez que l'application s'exécute comme prévu dans toutes les régions où elle est déployée.

Les déploiements multirégionaux permettent de garantir une haute disponibilité pour vos applications métier les plus critiques. Pour assurer la continuité des opérations lors des événements de défaillance, outre le déploiement de l'application dans plusieurs régions, vous devez prendre certaines mesures supplémentaires. Par exemple, vous devez effectuer une planification des capacités pour vous assurer qu'une capacité suffisante est réservée dans toutes les régions ou que les risques associés à l'autoscaling d'urgence sont acceptables. Vous devez également mettre en œuvre des pratiques opérationnelles pour les tests de reprise après sinistre, la gestion des incidents, la vérification de l'état des applications après les incidents et la réalisation de rétrospectives.