Aller au contenu

Proxy-only subnet sur GCP : Le guide pour bien démarrer

Bannière d'article

Vous êtes sur le point de déployer votre nouvelle application sur Google Cloud, et pour exposer celle-ci au monde, vous avez choisi un répartiteur de charge moderne basé sur Envoy. Il peut s'agir d'un Global External HTTPS Load Balancer ou de ses cousins régionaux. Au moment de la configuration, une question vous est posée : la création d'un "proxy-only subnet". C'est une étape obligatoire, mais qui soulève souvent des interrogations. Ce sous-réseau n'est pas destiné à vos machines virtuelles, mais il s'agit d'un espace réseau réservé que Google Cloud utilisera pour allouer des adresses IP à ses proxys Envoy managés. Ces proxys sont le cœur de votre répartiteur de charge. Comprendre comment dimensionner et gérer ce sous-réseau est donc essentiel pour garantir la performance et la scalabilité de vos services.

Quelle taille pour mon subnet ?

La première décision à prendre concerne la taille de ce sous-réseau. La documentation de Google Cloud impose une taille minimale qui doit pouvoir fournir au moins 64 adresses IP, ce qui correspond à un masque de sous-réseau en /26. Cependant, se contenter du strict minimum est rarement une bonne idée en production. L'approche recommandée est bien plus confortable. Il est conseillé de démarrer avec un préfixe en /23, ce qui vous alloue 512 adresses IP. C'est un excellent point de départ qui offre une marge de manœuvre suffisante pour la plupart des applications, tout en restant raisonnable. Si votre réseau VPC commence à être à l'étroit en adresses privées RFC 1918, sachez qu'il est tout à fait possible d'utiliser une plage d'adresses non-RFC 1918 pour ce subnet spécifique, une astuce précieuse pour éviter les conflits.

Comment Google choisit le nombre de proxys ?

Le véritable intérêt de ce système est son élasticité. Le nombre de proxys n'est pas fixe. Google Cloud l'ajuste dynamiquement en fonction du trafic que votre application reçoit. Toutes les dix minutes, le service évalue la capacité nécessaire pour gérer la charge et ajuste le nombre de proxys en conséquence. Pour ce faire, il se base sur le plus grand des besoins calculés entre la bande passante et le volume de connexions ou de requêtes.

Imaginons que votre service diffuse des tutoriels vidéo. Chaque instance de proxy peut gérer jusqu'à 18 Mo par seconde de trafic. Si, pendant la période d'observation, votre application doit servir un total de 180 Mo par seconde, Google Cloud calculera qu'il a besoin de dix proxys pour satisfaire la demande en bande passante.

Maintenant, pensons à un site de commerce en ligne durant une vente flash. Le calcul se portera sur les connexions et les requêtes. Un proxy peut gérer environ 600 nouvelles connexions par seconde en HTTP, ou 150 en HTTPS à cause de la charge supplémentaire du chiffrement. Il peut aussi maintenir 3000 connexions actives simultanément. Si votre site reçoit une vague de 2000 nouvelles connexions HTTPS par seconde, le système saura qu'il doit provisionner plus de treize proxys juste pour absorber ce pic de nouvelles connexions. De la même manière, un proxy peut traiter jusqu'à 1400 requêtes par seconde, un chiffre important pour les API très sollicitées.

L'impact caché de la journalisation

Un détail crucial à ne pas négliger est l'impact de la journalisation, ou logging, sur les performances. Le chiffre de 1400 requêtes par seconde est valable lorsque la journalisation via Cloud Logging est désactivée. Si vous décidez d'activer la journalisation pour 100% de vos requêtes afin d'avoir une observabilité complète, la capacité de traitement d'un proxy chute de moitié, pour atteindre environ 700 requêtes par seconde. Cela signifie que pour un même trafic, vous aurez besoin de deux fois plus de proxys, ce qui a une incidence directe sur la facture. Heureusement, il est possible de configurer l'échantillonnage des journaux pour ne tracer qu'un pourcentage du trafic, trouvant ainsi le juste équilibre entre observabilité et maîtrise des coûts.

Quelques détails importants

Il est primordial de se rappeler que ces proxys sont alloués au niveau du VPC et de la région, et non par répartiteur de charge individuel. Vous devez donc créer un unique proxy-only subnet dans chaque région où vous déployez des répartiteurs de charge basés sur Envoy. Si vous avez trois load balancers différents dans la même région du même VPC, ils partageront tous le même pool de proxys hébergés dans ce subnet. Enfin, n'oubliez pas que chaque proxy provisionné pour répondre à vos besoins en trafic engendre un coût horaire supplémentaire. La compréhension de ces mécanismes de mise à l'échelle vous permet non seulement d'anticiper les performances, mais aussi d'estimer plus finement vos dépenses sur le cloud.

Conclusion

Le proxy-only subnet peut sembler n'être qu'un détail technique dans la configuration d'un load balancer sur GCP. Pourtant, le choix de sa taille initiale et la compréhension de son fonctionnement dynamique sont des éléments clés pour construire une architecture robuste et évolutive. En démarrant avec une taille confortable comme un /23 et en gardant à l'esprit les facteurs qui influencent le scaling automatique, vous vous assurez que votre infrastructure pourra encaisser les montées en charge sans sourciller. Vous avez maintenant toutes les cartes en main pour dimensionner ce composant essentiel avec confiance.

Sources