Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cas d'utilisation : Auditer les performances du réseau
Supposons que vous êtes un administrateur réseau chargé de gérer un réseau comprenant plusieurs applications à équilibrage de charge. Vous devez auditer les configurations réseau qui prennent en charge ces applications pour vous assurer que les configurations sont cohérentes avec l'état attendu de votre réseau. En effectuant cet audit, vous pouvez faire en sorte que les clients obtiennent la latence la plus faible possible pour vos applications.
Le cas d'utilisation suivant montre comment Network Topology peut vous aider à vérifier vos configurations existantes. Par exemple, vous pouvez vérifier que toutes les requêtes client sont traitées par des instances d'application de la région Google Cloudla plus proche du client. Vous pouvez également vous assurer que le trafic interrégional est faible, car il provient de bases de données qui répliquent les données à l'échelle mondiale.
Présentation de la topologie
Le déploiement s'étend sur trois régions Google Cloud (us-central1, europe-west1 et asia-east1). Toutes les requêtes client externes sont traitées par un seul équilibreur de charge d'application externe disposant de plusieurs backends dans chacune des trois régions. Les requêtes des clients provenant de l'une des trois régions commerciales (Amériques, EMEA et APAC) sont traitées par des instances d'application dans la régionGoogle Cloud la plus proche.
Le graphique suivant montre la hiérarchie de premier niveau du déploiement.
Exemple de topologie Network Topology (cliquez pour agrandir)
Ressources et chemins du trafic
Dans cet exemple, le projet contient les ressources Google Cloudsuivantes:
1 équilibreur de charge HTTP(S)
4 services de backend : browse, shopping_cart, checkout et feeds.
12 groupes d'instances (qui sont les backends de l'équilibreur de charge).
Il existe un groupe d'instances pour chaque service de backend dans chacune des trois régions.
3 instances de base de données, une dans chaque région.
Vous prévoyez que le trafic de certains pays va se diriger vers les emplacements suivants :
Le trafic provenant des pays de la région commerciale Americas est acheminé vers les backends de la région us-central1. Par exemple, le trafic provenant d'un client externe au Canada est acheminé via l'équilibreur de charge vers le backend checkout dans la région us-central1.
Le trafic provenant des pays de la région commerciale EMEA est acheminé vers les backends de la région europe-west1. Par exemple, le trafic provenant d'un client externe en Pologne est acheminé via l'équilibreur de charge vers le backend checkout dans la région europe-west1.
Le trafic provenant des pays de la région commerciale APAC est acheminé vers les backends de la région asia-east1. Par exemple, le trafic provenant d'un client externe situé au Japon transite par l'équilibreur de charge vers le backend checkout de la région asia-east1.
Le trafic vers une instance de base de données provient d'un backend de la même région. Par exemple, les backends de asia-east1 n'envoient des données qu'à l'instance de base de données dans asia-east1.
Le trafic interrégional est limité à l'instance dupliquée de base de données. Par exemple, le trafic entre us-central1 et europe-west1 ne transite qu'entre les instances de base de données de ces régions.
Flux de trafic inattendu
Dans ce scénario, vous découvrez que le trafic provenant de la région commerciale EMEA est désormais acheminé vers deux régions Google Cloud différentes, us-central1 et europe-west1. En utilisant Network Topology, vous découvrez que l'un des backends est surexploité.
Vous souhaitez vérifier que le trafic externe qui passe par l'équilibreur de charge est acheminé vers la bonne région. Google Cloud Vous filtrez le graphique pour n'afficher que le trafic de votre équilibreur de charge externe shopping-site-lb.
Après avoir appliqué le filtre, Network Topology n'affiche que les connexions liées à l'équilibreur de charge, comme illustré dans l'exemple suivant.
Filtre pour un équilibreur de charge (cliquez pour agrandir)
Vous placez le pointeur sur chaque région commerciale afin de mettre en évidence la communication avec celle-ci.
Lorsque vous placez le pointeur sur Amériques et APAC, vous voyez le trafic acheminé vers la région Google Cloud la plus proche: us-central1 et asia-
east1 respectivement. Cependant, lorsque vous maintenez le pointeur sur EMEA, vous voyez le trafic acheminé vers us-central1 et europe-west1. Idéalement, pour réduire la latence, tout le trafic provenant de la région EMEA doit être acheminé vers europe-west1.
Ensuite, vous cliquez sur EMEA pour étudier le débit entre cette région et les régionsGoogle Cloud . Network Topology superpose les valeurs de bande passante sur chaque connexion. Vous voyez qu'environ 0,58 octet par seconde est acheminé vers us-central1 et 29,9 ko/s vers europe-west1. Vous savez que la majeure partie du trafic est dirigée comme vous vous y attendez, mais une partie du trafic est acheminée vers us-central1.
Valeurs de bande passante superposées1 (cliquez pour agrandir)
1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.
Pour examiner la situation plus en détail, développez us-central1 pour voir où le trafic est acheminé. Comme il n'y a qu'un seul réseau avec un seul sous-réseau dans cette région, Network Topology n'affiche pas ces niveaux de la hiérarchie et passe aux groupes d'instances.
Vous constatez que le trafic est dirigé vers un groupe d'instances associé au service de backend de l'équilibreur de charge. Comme il s'agit d'un trafic relativement faible acheminé vers europe-west1, il est possible que les ressources de europe-west1 soient surexploitées, provoquant un débordement du trafic vers us-central1.
Chemin du trafic1 (cliquez pour agrandir)
1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.
Pour confirmer votre conclusion, vous développez la région europe-west1 jusqu'à atteindre l'instance associée au même service de backend de l'équilibreur de charge. Network Topology affiche des graphiques de séries temporelles dans le volet Détails de l'instance.
Dans le graphique, vous remarquez que le taux d'utilisation du processeur est à 81% pour l'instance. Le seuil pour cet exemple est de 80 %, ce qui indique que l'instance est surexploitée. Pour résoudre ce problème, augmentez le groupe d'instances afin que le trafic retourne au flux idéal.
Graphique de séries temporelles pour une instance1 (cliquez pour agrandir)
1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.
Trafic interrégional
Dans la section suivante, vous vérifiez que le trafic interne entre les régions est limité au trafic d'instances de base de données.
Pour vous concentrer sur le trafic interne, dans la liste Configuration de la topologie, ne cochez que les cases Instances et Barrières Cloud NAT. Étant donné que vous ne consultez que le trafic dans votre application, vous n'avez pas besoin de voir les clients ni le trafic de l'équilibreur de charge externes.
Afficher le trafic interne uniquement (cliquez pour agrandir)
Vous développez la région asia-east1 et vous voyez cinq groupes d'instances. Ils ne sont pas agrégés par réseau, sous-réseau ou zone, car ils se trouvent tous dans le même réseau, sous-réseau, etc.
Vous remarquez qu'un seul groupe d'instances (db-group-asia) contient un chemin d'accès pour le trafic interrégions. Tous les autres groupes d'instances communiquent dans la région.
Vous développez le groupe db-group-asia jusqu'à atteindre l'entité de base. Dans ce scénario, l'entité de base est une instance de machine virtuelle (VM) (db-instance-asia) faisant office de serveur de base de données. Elle communique avec d'autres régions pour répliquer les données, ce qui est normal, donc aucune autre enquête n'est requise.
̦
Trafic interrégional1 (cliquez pour agrandir)
1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/08 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/08 (UTC)."],[],[],null,["# Use case: Audit network performance\n===================================\n\nAssume that you're a network administrator who supports a network that includes\nseveral load-balanced applications. You've been asked to audit the network\nconfigurations that support those applications to ensure that the configurations\nare consistent with the expected state of your network. By doing this audit, you\ncan ensure that customers are getting the lowest possible latency to your\napplications.\n\nThe following use case demonstrates how Network Topology can help you\ncheck your existing configurations. For example, you can check that all client\nrequests are being served by application instances from the Google Cloud\nregion that's closest to the client. You can also ensure that cross-region\ntraffic is low because that traffic comes from databases that replicate data\nglobally.\n\nTopology overview\n-----------------\n\nThe deployment spans three Google Cloud regions (`us-central1`,\n`europe-west1`, and `asia-east1`). All external client requests are served by a\nsingle external Application Load Balancer that has multiple backends in each of the three\nregions. Client requests that come from one of three business regions (Americas,\nEMEA, and APAC) are served by application instances in the closest\nGoogle Cloud region.\n\nThe following graph shows the top-level hierarchy for the deployment.\n[](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-topology.png) Network Topology example topology (click to enlarge)\n\n### Resources and traffic paths\n\nIn this example, the project contains the following Google Cloud\nresources:\n\n- 1 HTTPS load balancer\n\n- 4 backend services: `browse`, `shopping_cart`, `checkout`, and `feeds`\n\n- 12 instance groups (which are the load balancer's backends)\n\n There is one instance group for each backend service in each of the three\n regions.\n- 3 database instances, one in each region\n\nYou expect that traffic from certain countries goes to the following\nlocations:\n\n- Traffic from countries in the `Americas` business region goes to backends in the `us-central1` region. For example, traffic from an external client in Canada travels through the load balancer to the `checkout` backend in the `us-central1` region.\n- Traffic from countries in the `EMEA` business region goes to backends in the `europe-west1` region. For example, traffic from an external client in Poland travels through the load balancer to the `checkout` backend in the `europe-west1` region.\n- Traffic from countries in the `APAC` business region goes to backends in the `asia-east1` region. For example, traffic from an external client in Japan travels through the load balancer to the `checkout` backend in the `asia-east1` region.\n- Traffic to a database instance comes from a backend in the same region. For example, the backends in `asia-east1` send data only to the database instance in `asia-east1`.\n- Cross-region traffic is limited to database replication. For example, traffic between `us-central1` and `europe-west1` travels only between database instances in those regions.\n\nUnexpected traffic flow\n-----------------------\n\nIn this scenario, you discover that traffic from the `EMEA` business region\nis now going to two different Google Cloud regions, `us-central1` and\n`europe-west1`. By using Network Topology, you discover that one of\nthe backends is overutilized.\n\n1. You want to check that external traffic that is going through the load\n balancer eventually goes to the correct Google Cloud region. You filter\n the graph to show only the traffic for your external load balancer\n `shopping-site-lb`.\n\n After you apply the filter, Network Topology shows only the\n connections related to the load balancer, as shown in the following example.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-filter.png) Filter for a load balancer (click to enlarge)\n2. You hold the pointer over each business region to highlight the communication\n to that region.\n\n When you hold the pointer over **Americas** and **APAC** , you see traffic\n going to the nearest Google Cloud region: `us-central1` and `asia-\n east1` respectively. However, when you hold the pointer over **EMEA** , you\n see traffic going to `us-central1` and `europe-west1`. Ideally, to reduce\n latency, all traffic from EMEA should go to `europe-west1`.\n3. Next, you click **EMEA** to study the throughput between it and the\n Google Cloud regions. Network Topology overlays bandwidth\n values on each connection. You see that about 0.58 bytes per second is\n going to `us-central1` and 29.9 kilobytes per second is going\n to `europe-west1`. You know that most of the traffic is being directed as\n you would expect, but some traffic is flowing to `us-central1`.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-bandwidth.png) Overlaid bandwidth values^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n4. To investigate further, you expand `us-central1` to view where traffic is\n going. Because there's only one network with a single subnet in that region,\n Network Topology doesn't show those levels of the hierarchy and\n skips to the instance groups.\n\n You see that traffic is going to an instance group that's associated with the load\n balancer's backend service. Because it's a relatively small amount of traffic\n going to `europe-west1`, it's possible that resources in `europe-west1` are\n overutilized and causing traffic to overflow to `us-central1`.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-traffic.png) Traffic path^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n5. To confirm your conclusion, you expand the `europe-west1` region until you\n reach the instance that is associated with the same load balancer's backend\n service. Network Topology shows time-series charts in the details\n pane for the instance.\n\n In the chart, you notice that the CPU utilization rate is at 81% for the\n instance. The threshold for this example is 80%, indicating that the instance\n is oversubscribed. You resolve this issue by scaling up the instance group so\n that traffic returns to the ideal flow.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-chart.png) Time-series chart for an instance^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\nInter-region traffic\n--------------------\n\nIn the following section, you check that internal traffic between regions\nis limited to only database instance traffic.\n\n1. To focus on internal traffic, in the **Topology configuration** list, you select\n only the **Instances** and **Cloud NAT gateways** checkboxes. Because you are only\n viewing traffic within your application, you don't need to see external clients\n and external load balancer traffic.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-internalonly.png) Showing internal-only traffic (click to enlarge)\n2. You expand the `asia-east1` region, and you see five instance groups. They are\n not aggregated by network, subnet, or zone because\n they are all in the same network, subnet, and so on.\n\n You notice that only one instance group (`db-group-asia`) contains a path\n for inter-region traffic. All other instance groups are communicating within\n the region.\n\n You continue to expand the `db-group-asia` group until you reach the base\n entity. In this scenario, the base entity is a virtual machine (VM) instance\n (`db-instance-asia`) that acts as a database server. It's communicating with\n other regions to replicate data, which is what you expected, so no further\n investigations are required.\n ̦\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-dbtraffic.png) Inter-region traffic^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\n \u003cbr /\u003e\n\nWhat's next\n-----------\n\n- [Monitor your networking configuration with Network Topology](/network-intelligence-center/docs/network-topology/how-to/audit-troubleshoot-networking-issues)\n- [Use case: Troubleshoot network connectivity](/network-intelligence-center/docs/network-topology/concepts/troubleshooting-network-connectivity)\n- [Troubleshoot Network Topology](/network-intelligence-center/docs/network-topology/support/troubleshooting)"]]
