Gestion de capacité avec l'équilibrage de charge

Last reviewed 2018-01-18 UTC

Afin de répartir le trafic, la plupart des équilibreurs de charge utilisent une méthode de hachage par interrogation à répétition alternée ou basée sur le flux. Cette approche peut entraîner certaines difficultés d'adaptation lorsque la demande de trafic augmente au-delà de la capacité de service disponible. Dans ce tutoriel, vous allez découvrir comment Cloud Load Balancing optimise la capacité globale de votre application, ce qui se traduit par une expérience utilisateur améliorée et des coûts réduits par rapport à la plupart des mécanismes d'équilibrage de charge.

Ce tutoriel fait partie d'une série d'articles consacrés aux bonnes pratiques d'utilisation des produits Cloud Load Balancing. Il est accompagné d'une présentation conceptuelle intitulée Optimisations de la capacité des applications avec l'équilibrage de charge global, qui explique en détail les mécanismes sous-jacents de débordement de l'équilibrage de charge global. Pour en savoir plus sur la latence, consultez la page Optimiser la latence des applications avec Cloud Load Balancing.

Dans ce tutoriel, nous partons du principe que vous avez une certaine expérience de Compute Engine. Vous devez également connaître les principes fondamentaux de l'équilibreur de charge d'application externe.

Objectifs

Dans ce tutoriel, vous allez configurer un simple serveur Web exécutant une application de calcul sur des ensembles Mandelbrot, qui nécessite une utilisation intensive des processeurs. Vous commencerez par mesurer la capacité du réseau à l'aide d'outils de test de charge (siege et httperf). Vous ajusterez ensuite cette capacité pour plusieurs instances de VM dans une seule région, puis mesurerez le temps de réponse sous charge. Enfin, vous ajusterez la capacité du réseau sur plusieurs régions à l'aide de l'équilibrage de charge global, puis mesurerez le temps de réponse du serveur sous charge et le comparerez à l'équilibrage de charge appliqué à une seule région. Cette séquence de tests vous permettra d'observer les effets positifs de la gestion de charge sur plusieurs régions avec Cloud Load Balancing.

La vitesse de communication réseau d'une architecture serveur classique à trois niveaux est généralement limitée par la vitesse du serveur d'applications ou la capacité de la base de données, et non par la charge du processeur sur le serveur Web. Après avoir exécuté le tutoriel, vous pourrez utiliser les mêmes outils de test de charge et les mêmes paramètres de capacité afin d'optimiser le comportement de l'équilibrage de charge dans une application réelle.

Vous découvrirez comment :

utiliser les outils de tests de charge (siege et httperf) ;
déterminer la capacité de service d'une seule instance de VM ;
mesurer les effets d'une surcharge avec un équilibrage de charge sur une seule région ;
mesurer les effets d'un débordement sur une autre région avec un équilibrage de charge global.

Coûts

Ce tutoriel utilise des composants facturables de Google Cloud, dont :

Compute Engine
Équilibrage de charge et règles de transfert

Utilisez le Simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Avant de commencer

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine API.
Enable the API

Configurer votre environnement

Dans cette section, vous allez configurer les paramètres du projet, le réseau VPC et les règles de base du pare-feu dont vous avez besoin pour exécuter le tutoriel.

Démarrer une instance Cloud Shell

Ouvrez Cloud Shell depuis Google Cloud Console. Pour la suite du tutoriel, sauf indication contraire, vous allez utiliser Cloud Shell.

Configurer les paramètres du projet

Afin de faciliter l'exécution des commandes gcloud, vous pouvez définir des propriétés pour éviter d'avoir à spécifier les options correspondantes dans chaque commande.

Définissez votre projet par défaut en remplaçant [PROJECT_ID] par l'ID de votre projet dans la commande suivante :
```
gcloud config set project [PROJECT_ID]
```
Définissez votre zone Compute Engine par défaut en remplaçant [ZONE] par la zone de votre choix, puis définissez-la comme variable d'environnement pour une utilisation ultérieure :
```
gcloud config set compute/zone [ZONE]
export ZONE=[ZONE]
```

Créer et configurer le réseau VPC

Créez un réseau VPC pour les opérations de test :

gcloud compute networks create lb-testing --subnet-mode auto

Définissez une règle de pare-feu pour autoriser le trafic interne :

gcloud compute firewall-rules create lb-testing-internal \
    --network lb-testing --allow all --source-ranges 10.128.0.0/11

Définissez une règle de pare-feu pour autoriser le trafic SSH vers le réseau VPC :

gcloud compute firewall-rules create lb-testing-ssh \
    --network lb-testing --allow tcp:22 --source-ranges 0.0.0.0/0

Déterminer la capacité de diffusion d'une seule instance de VM

Pour examiner les caractéristiques de performance d'un type d'instance de VM, procédez comme suit :

Configurez une instance de VM qui diffuse l'exemple de charge de travail (l'instance de serveur Web).
Créez une deuxième instance de VM dans la même zone (l'instance de tests de charge).

Avec la deuxième instance de VM, vous allez mesurer les performances à l'aide de simples tests de charge et d'outils de mesure des performances. Ces mesures vous permettront par la suite de définir le paramètre de capacité d'équilibrage de charge approprié pour le groupe d'instances.

La première instance de VM se sert d'un script Python pour créer une tâche nécessitant une utilisation intensive du processeur, afin de calculer et d'afficher l'image d'un ensemble Mandelbrot sur chaque requête envoyée au chemin d'accès racine (/). Le résultat n'est pas mis en cache. Au cours de ce tutoriel, le script Python sera obtenu à partir du dépôt GitHub utilisé pour cette solution.

Configuration à deux serveurs pour tester la réponse du serveur Web

Configurer les instances de VM

Configurez l'instance de VM webserver en tant qu'instance de VM à quatre cœurs. Pour ce faire, installez et démarrez le serveur Mandelbrot :

gcloud compute instances create webserver --machine-type n1-highcpu-4 \
    --network=lb-testing --image-family=debian-12 \
    --image-project=debian-cloud --tags=http-server \
    --metadata startup-script='#! /bin/bash
apt-get -y update
apt-get install -y git python-numpy python-matplotlib
    git clone \
https://github.com/GoogleCloudPlatform/lb-app-capacity-tutorial-python.git
    cd lb-app-capacity-tutorial-python
python webserver.py'

Créez une règle de pare-feu pour autoriser l'accès externe à l'instance webserver à partir de votre propre machine :
```
gcloud compute firewall-rules create lb-testing-http \
    --network lb-testing --allow tcp:80 --source-ranges 0.0.0.0/0 \
    --target-tags http-server 
```
Remarque : Cette étape ouvre également le pare-feu aux plages d'adresses IP 130.211.0.0/22 et 35.191.0.0/16 utilisées pour les vérifications de l'état.

Récupérez l'adresse IP de l'instance webserver :

gcloud compute instances describe webserver \
    --format "value(networkInterfaces[0].accessConfigs[0].natIP)"

Dans un navigateur Web, accédez à l'adresse IP renvoyée par la commande précédente. Un ensemble de calcul Mandelbrot s'affiche :

Créez l'instance de tests de charge :

gcloud compute instances create loadtest --machine-type n1-standard-1 \
    --network=lb-testing --image-family=debian-12 \
    --image-project=debian-cloud

Tester les instances de VM

L'étape suivante consiste à exécuter des requêtes pour évaluer les caractéristiques de performance de l'instance de VM de tests de charge.

Utilisez la commande ssh pour vous connecter à l'instance de VM de tests de charge.
```
gcloud compute ssh loadtest
```
Remarque : Vous allez effectuer les étapes suivantes de cette procédure de test à partir de la ligne de commande de l'instance à laquelle vous êtes connecté.
Sur l'instance de tests de charge, installez siege et httperf en tant qu'outils de test de charge :
```
sudo apt-get install -y siege httperf
```
L'outil siege permet de simuler les requêtes d'un nombre déterminé d'utilisateurs, les requêtes de suivi n'étant exécutées qu'après réception de la réponse par les utilisateurs. Vous obtenez ainsi des informations sur la capacité et les temps de réponse estimés des applications dans un environnement réel.

L'outil httperf permet d'envoyer un nombre spécifique de requêtes par seconde, indépendamment de la réception de réponses ou d'erreurs. Vous obtenez ainsi des informations sur la manière dont les applications répondent à une charge spécifique.
Envoyez une simple requête au serveur Web :
```
curl -w "%{time_total}\n" -o /dev/#objectives_2 -s webserver
```
Vous obtenez une réponse telle que 0.395260. Cela signifie que le serveur a mis 395 millisecondes (ms) pour répondre à votre requête.

Exécutez la commande suivante pour exécuter 20 requêtes de 4 utilisateurs en parallèle :

siege -c 4 -r 20 webserver

Vous obtenez un résultat semblable à celui-ci :

** SIEGE 4.0.2
** Preparing 4 concurrent users for battle.
The server is now under siege...
Transactions:                    80 hits
Availability:                 100.00 %
Elapsed time:                  14.45 secs
Data transferred:               1.81 MB
Response time:                  0.52 secs
Transaction rate:               5.05 trans/sec
Throughput:                     0.12 MB/sec
Concurrency:                    3.92
Successful transactions:         80
Failed transactions:               0
**Longest transaction:            0.70
Shortest transaction:           0.37
**

Le résultat est expliqué en détail dans le manuel de siege. Comme vous pouvez le voir dans cet exemple, les temps de réponse varient entre 0,37 et 0,7 secondes. En moyenne, 5,05 requêtes par seconde ont été traitées. Ces données permettent d'estimer la capacité de diffusion du système.

Exécutez les commandes suivantes pour valider les résultats à l'aide de l'outil de test de charge httperf :

httperf --server webserver --num-conns 500 --rate 4

Cette commande exécute 500 requêtes à raison de 4 requêtes par seconde, soit un nombre inférieur aux 5,05 transactions par seconde effectuées par siege.

Vous obtenez un résultat semblable à celui-ci :

httperf --client=0/1 --server=webserver --port=80 --uri=/ --rate=4
--send-buffer=4096 --recv-buffer=16384 --num-conns=500 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to
FD_SETSIZE
Maximum connect burst length: 1

Total: connections 500 requests 500 replies 500 test-duration 125.333 s

Connection rate: 4.0 conn/s (251.4 ms/conn, <=2 concurrent connections)
**Connection time [ms]: min 369.6 avg 384.5 max 487.8 median 377.5 stddev 18.0
Connection time [ms]: connect 0.3**
Connection length [replies/conn]: 1.000

Request rate: 4.0 req/s (251.4 ms/req)
Request size [B]: 62.0

Reply rate [replies/s]: min 3.8 avg 4.0 max 4.0 stddev 0.1 (5 samples)
Reply time [ms]: response 383.8 transfer 0.4
Reply size [B]: header 117.0 content 24051.0 footer 0.0 (total 24168.0)
Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0

CPU time [s]: user 4.94 system 20.19 (user 19.6% system 80.3% total 99.9%)
Net I/O: 94.1 KB/s (0.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Le résultat est expliqué dans le fichier README httperf. Notez la ligne commençant par Connection time [ms], qui indique que les connexions ont duré au total entre 369,6 et 487,8 ms et n'ont généré aucune erreur.

Répétez le test trois fois en définissant l'option rate sur 5, 7 et 10 requêtes par seconde.

Les blocs suivants montrent les commandes httperf et leur résultat (qui n'affichent que les lignes correspondantes avec les informations de durée de connexion).

Commande pour 5 requêtes par seconde :

httperf --server webserver --num-conns 500 --rate 5 2>&1| grep 'Errors\|ion time'

Résultat pour 5 requêtes par seconde :

Connection time [ms]: min 371.2 avg 381.1 max 447.7 median 378.5 stddev 7.2
Connection time [ms]: connect 0.2
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Commande pour 7 requêtes par seconde :

httperf --server webserver --num-conns 500 --rate 7 2>&1| grep 'Errors\|ion time'

Résultat pour 7 requêtes par seconde :

Connection time [ms]: min 373.4 avg 11075.5 max 60100.6 median 8481.5 stddev
10284.2
Connection time [ms]: connect 654.9
Errors: total 4 client-timo 0 socket-timo 0 connrefused 0 connreset 4
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Commande pour 10 requêtes par seconde :

httperf --server webserver --num-conns 500 --rate 10 2>&1| grep 'Errors\|ion time'

Résultat pour 10 requêtes par seconde :

Connection time [ms]: min 374.3 avg 18335.6 max 65533.9 median 10052.5 stddev
16654.5
Connection time [ms]: connect 181.3
Errors: total 32 client-timo 0 socket-timo 0 connrefused 0 connreset 32
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Déconnectez-vous de l'instance webserver :
```
exit
```

Au vu de ces mesures, nous constatons que le système a une capacité de traitement d'environ 5 requêtes par seconde (RPS). Pour 5 requêtes par seconde, l'instance de VM réagit avec une latence comparable à 4 connexions. Pour 7 et 10 connexions par seconde, le temps de réponse moyen affiche une hausse significative de plus de 10 secondes avec plusieurs erreurs de connexion. En d'autres termes, tout dépassement de 5 requêtes par seconde entraîne un ralentissement important.

Dans un système plus complexe, la capacité du serveur est déterminée de la même manière, mais dépend beaucoup de la capacité de tous ses composants. Pour identifier les goulots d'étranglement, vous pouvez utiliser les outils siege et httperf, ainsi que la surveillance de la charge du processeur et des E/S de tous les composants (par exemple, le serveur frontend, le serveur d'applications et le serveur de base de données). Il vous sera ainsi plus facile d'optimiser le scaling pour chaque composant.

Mesurer les effets d'une surcharge avec un équilibreur de charge sur une seule région

Dans cette section, vous allez examiner les effets d'une surcharge sur des équilibreurs de charge appliqués à une seule région, tels que ceux généralement utilisés sur site, ou sur l'équilibreur de charge réseau passthrough externe de Google Cloud. Vous pourrez également observer cet effet avec un équilibreur de charge HTTP(S) lorsque celui-ci est utilisé pour un déploiement régional (et non mondial).

Configuration d'un équilibreur de charge dans un déploiement régional sur une seule zone

Créer l'équilibreur de charge HTTP(S) sur une seule région

Vous trouverez ci-dessous la procédure à suivre pour créer un équilibreur de charge HTTP(S) sur une seule région avec une dimension fixe de trois instances de VM.

Créez un modèle d'instance pour les instances de VM du serveur Web à l'aide du script de génération Python Mandelbrot que vous avez utilisé précédemment. Exécutez les commandes suivantes dans Cloud Shell :

gcloud compute instance-templates create webservers \
    --machine-type n1-highcpu-4 \
    --image-family=debian-12 --image-project=debian-cloud \
    --tags=http-server \
    --network=lb-testing \
    --metadata startup-script='#! /bin/bash
apt-get -y update
apt-get install -y git python-numpy python-matplotlib
git clone \
    https://github.com/GoogleCloudPlatform/lb-app-capacity-tutorial-python.git
cd lb-app-capacity-tutorial-python
python webserver.py'

Créez un groupe d'instances géré composé de trois instances selon le modèle de l'étape précédente :
```
gcloud compute instance-groups managed create webserver-region1 \
    --size=3 --template=webservers
```

Créez la vérification de l'état, le service backend, le mappage d'URL, le proxy cible et la règle de transfert global nécessaires pour générer l'équilibrage de charge HTTP :

gcloud compute health-checks create http basic-check \
    --request-path="/health-check" --check-interval=60s

gcloud compute backend-services create web-service \
    --health-checks basic-check --global
gcloud compute backend-services add-backend web-service \
    --global --instance-group=webserver-region1 \
    --instance-group-zone $ZONE

gcloud compute url-maps create web-map --default-service web-service

gcloud compute target-http-proxies create web-proxy --url-map web-map

gcloud compute forwarding-rules create web-rule --global \
    --target-http-proxy web-proxy --ports 80

Obtenez l'adresse IP de la règle de transfert :
```
gcloud compute forwarding-rules describe --global web-rule --format "value(IPAddress)"
```
Le résultat représente l'adresse IP publique de l'équilibreur de charge que vous avez créé.
Dans un navigateur, accédez à l'adresse IP renvoyée par la commande précédente. Après quelques instants, la même image Mandelbrot que celle vue précédemment s'affiche. Cependant, l'image est cette fois diffusée depuis l'une des instances de VM du groupe que vous venez de créer.
Connectez-vous à la machine loadtest :
```
gcloud compute ssh loadtest
```
Dans la ligne de commande de la machine loadtest, testez la réponse du serveur avec différents nombres de requêtes par seconde (RPS). Veillez à utiliser des valeurs RPS comprises entre 5 et 20.

Par exemple, la commande suivante génère 10 RPS. Remplacez [IP_address] par l'adresse IP de l'équilibreur de charge de l'étape précédente de cette procédure.
```
httperf --server [IP_address] --num-conns 500 --rate 10 2>&1| grep 'Errors\|ion time'
```
La latence de réponse augmente considérablement lorsque le nombre de RPS s'accroît après 12 ou 13 RPS. Voici une représentation typique des résultats :
Déconnectez-vous de l'instance de VM loadtest :
```
exit
```

Ces performances sont caractéristiques d'un système régionalement équilibré. Lorsque la charge augmente par rapport à la capacité de diffusion, la latence moyenne et maximale des requêtes s'accroît considérablement. Avec 10 RPS, la latence moyenne des requêtes est proche de 500 ms, mais avec 20 RPS, elle passe à 5 000 ms. La latence a été multipliée par 10 et l'expérience utilisateur s'est rapidement détériorée, avec pour conséquence l'abandon de l'application par l'utilisateur ou des délais avant expiration de celle-ci, voire les deux.

Dans la section suivante, vous allez ajouter une deuxième région à la topologie de l'équilibrage de charge, puis comparer les effets du basculement entre régions sur la latence de l'utilisateur final.

Mesurer les effets d'un débordement sur une autre région

Si vous utilisez une application globale avec un équilibreur de charge d'application externe et que vos backends sont déployés dans plusieurs régions, le trafic est automatiquement acheminé vers une autre région en cas de surcharge de capacité dans une région particulière. Pour ce faire, vous devez ajouter un deuxième groupe d'instances de VM dans une autre région à la configuration que vous avez créée à la section précédente.

Configuration d'un équilibreur de charge dans un déploiement sur plusieurs régions

Créer des serveurs dans plusieurs régions

Dans les étapes suivantes, vous allez ajouter un groupe de backends dans une autre région et attribuer une capacité de 10 RPS par région. Vous pourrez alors observer comment l'équilibrage de charge réagit lorsque cette limite est dépassée.

Dans Cloud Shell, choisissez une zone dans une autre région que votre zone par défaut, puis définissez-la en tant que variable d'environnement :
```
export ZONE2=[zone]
```

Créez un groupe d'instances dans la deuxième région composé de trois instances de VM :

gcloud compute instance-groups managed create webserver-region2 \
    --size=3 --template=webservers --zone $ZONE2

Ajoutez le groupe d'instances au service backend existant avec une capacité maximale de 10 RPS :

gcloud compute backend-services add-backend web-service \
    --global --instance-group=webserver-region2 \
    --instance-group-zone $ZONE2 --max-rate 10

Définissez le paramètre max-rate sur 10 RPS pour le service de backend existant :

gcloud compute backend-services update-backend web-service \
    --global --instance-group=webserver-region1 \
    --instance-group-zone $ZONE --max-rate 10

Une fois toutes les instances démarrées, connectez-vous à l'instance de VM loadtest :
```
gcloud compute ssh loadtest
```
Exécutez 500 requêtes à 10 RPS. Remplacez [IP_address] par l'adresse IP de l'équilibreur de charge :
```
httperf --server [IP_address] --num-conns 500 --rate 10 2>&1| grep 'ion time'
```
Vous obtenez ce type de résultat :
```
Connection time [ms]: min 405.9 avg 584.7 max 1390.4 median 531.5 stddev
181.3
Connection time [ms]: connect 1.1
```
Le résultat est semblable à celui obtenu avec l'équilibreur de charge régional.

Étant donné que l'outil de test exécute immédiatement une charge complète sans augmentation progressive de la charge, comme c'est le cas dans une application réelle, vous devez répéter le test plusieurs fois pour que le mécanisme de débordement se déclenche. Exécutez 500 requêtes 5 fois à 20 RPS. Remplacez [IP_address] par l'adresse IP de l'équilibreur de charge.

for a in \`seq 1 5\`; do httperf --server [IP_address] \
    --num-conns 500 --rate 20 2>&1| grep 'ion time' ; done

Vous obtenez ce type de résultat :

Connection time [ms]: min 426.7 avg 6396.8 max 13615.1 median 7351.5 stddev
3226.8
Connection time [ms]: connect 0.9
Connection time [ms]: min 417.2 avg 3782.9 max 7979.5 median 3623.5 stddev
2479.8
Connection time [ms]: connect 0.9
Connection time [ms]: min 411.6 avg 860.0 max 3971.2 median 705.5 stddev 492.9
Connection time [ms]: connect 0.7
Connection time [ms]: min 407.3 avg 700.8 max 1927.8 median 667.5 stddev 232.1
Connection time [ms]: connect 0.7
Connection time [ms]: min 410.8 avg 701.8 max 1612.3 median 669.5 stddev 209.0
Connection time [ms]: connect 0.8

Une fois le système stabilisé, le temps de réponse moyen est de 400 ms à 10 RPS et ne dépasse pas 700 ms à 20 RPS. Cela représente une amélioration considérable par rapport au délai de 5 000 ms obtenu par un équilibreur de charge régional, et cela se traduit par une expérience utilisateur bien meilleure.

Le graphique suivant représente le temps de réponse mesuré par RPS en utilisant l'équilibrage de charge mondial :

Graphique montrant la stabilité du temps de réponse à mesure que le nombre de requêtes par minute augmente

Comparer les résultats de l'équilibrage de charge régional et mondial

Une fois que vous avez défini la capacité d'un seul nœud, vous pouvez comparer la latence observée par les utilisateurs finaux dans un déploiement basé sur une seule région avec la latence dans une architecture d'équilibrage de charge global. Bien que le nombre de requêtes dans une seule région soit inférieur à la capacité totale de diffusion dans cette région, la latence observée dans les deux systèmes est relativement la même pour les utilisateurs finaux, car ces derniers sont toujours redirigés vers la région la plus proche.

Lorsque la charge dans une région dépasse la capacité de diffusion de cette région, la latence pour l'utilisateur final varie considérablement selon la solution employée :

Les solutions d'équilibrage de charge régional atteignent leur limite lorsque le trafic dépasse la capacité disponible, car celui-ci ne peut pas être acheminé ailleurs que vers les instances de VM backend en surcharge. C'est le cas des équilibreurs de charge sur site classiques, des Équilibreurs de charge réseau passthrough externes sur Google Cloud, et des Équilibreurs de charge d'application externes dans une configuration basée sur une seule région (par exemple, une mise en réseau de Niveau Standard). La latence moyenne et maximale des requêtes est plus de 10 fois supérieure. Résultat, l'expérience utilisateur se détériore et risque d'entraîner une baisse importante du nombre d'utilisateurs.
Les équilibreurs de charge d'application externes globaux avec des backends dans plusieurs régions permettent de faire déborder le trafic vers la région la plus proche ayant une capacité de diffusion disponible. La latence mesurable pour l'utilisateur final est comparativement plus faible et offre une expérience utilisateur bien meilleure. Si votre application ne peut pas s'adapter rapidement aux conditions de trafic dans une région, la solution recommandée est d'utiliser l'équilibreur de charge d'application externe global. Même en cas de défaillance des serveurs d'applications utilisateur à l'échelle d'une région, le trafic est vite redirigé vers d'autres régions, ce qui évite toute interruption de service.

Nettoyer

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Pour supprimer le projet :

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Étapes suivantes

Consultez ces pages pour obtenir des informations complémentaires en contexte à propos des solutions d'équilibrage de charge de Google :