Cette page décrit les bonnes pratiques à suivre pour configurer les options de mise en réseau pour les ressources App Engine. Nous vous recommandons de consulter toutes les sections de cette page pour comprendre les options de mise en réseau compatibles avec App Engine et leurs implications.
Bonnes pratiques
Gestion des adresses IP.Surveillez l'utilisation des adresses IP.
Utilisez des adresses IP non-RFC 1918.
Utilisez des sous-réseaux IPv4 et IPv6 (double pile).
Utilisez le regroupement de connexions et réutilisez les connexions.Utilisez des environnements d'exécution compatibles.
Débit externe plus rapide vers Internet.
Débit interne plus rapide vers une API Google.
Gestion des adresses IP
Vous devez gérer vos adresses IP, car chaque instance de votre service App Engine consomme des adresses IP de votre sous-réseau. Utilisez les stratégies suivantes pour gérer vos adresses IP :
Allocation d'adresses IP alternatives : allouez des plages d'adresses IP privées standards ou des plages d'adresses IP alternatives pour limiter l'épuisement des adresses IP. Consultez Stratégies d'épuisement des adresses IP.
Dimensionnement du sous-réseau : assurez-vous que la plage d'adresses IPv4 de votre sous-réseau est de
/26ou plus pour fournir suffisamment d'adresses IP pour le scaling.Surprovisionner les adresses IP : nous vous recommandons de surprovisionner le nombre d'adresses IP disponibles dans votre sous-réseau pour éviter l'épuisement. Comme pour les autres services App Engine, vous devez généralement utiliser quatre fois plus d'adresses IP (deux fois pour l'état stable et deux fois de plus pendant le déploiement) que le nombre d'instances en cours d'exécution pour faciliter le scaling et les mises à jour.
Surveiller l'utilisation des adresses IP
Si vous utilisez la sortie VPC directe, assurez-vous de disposer de suffisamment d'adresses IP allouées à votre sous-réseau. Le nombre d'adresses IP que vous utilisez dépend du nombre d'instances exécutées par vos charges de travail. Nous vous recommandons donc de surveiller l'utilisation de vos adresses IP. Assurez-vous que votre utilisation des adresses IP au fil du temps reste dans les limites acceptées par le sous-réseau.
Pour estimer votre utilisation des adresses IP :
Dans la console Google Cloud , accédez à la page "Explorateur de métriques" :
Recherchez le nombre d'instances dans votre projet à l'aide du type de métrique
appengine.googleapis.com/system/instance_count. Cette métrique comptabilise toutes les instances App Engine du projet. Pour les versions configurées avec la sortie VPC directe, filtrez par l'étiquettemodule_id, qui identifie le service, ou par l'étiquetteversion_id. Cloud Monitoring vous permet d'afficher la valeur de cette métrique au fil du temps.Multipliez par deux la valeur de la métrique du nombre d'instances pour obtenir une estimation du nombre d'adresses IP utilisées.
Stratégies d'épuisement des adresses IP
Un grand nombre de charges de travail App Engine peut entraîner des problèmes d'épuisement des adresses IP lorsque vous utilisez l'espace d'adresses IP privées RFC 1918 avec la sortie VPC directe. Les stratégies suivantes peuvent vous aider à gérer l'épuisement des adresses IP en utilisant d'autres plages d'adresses IP.
Utiliser des adresses IPv4 non-RFC 1918
Outre les plages d'adresses IPv4 RFC 1918, App Engine est également compatible avec les plages RFC 6598 et Classe E/RFC 5735. Tous les services et fonctionnalitésGoogle Cloud fonctionnent avec ces plages non-RFC 1918, y compris les réseaux VPC, Cloud Load Balancing et Private Service Connect.
Pour une compatibilité optimale, nous vous recommandons de commencer par la plage RFC 6598 (100.64.0.0/10). Si vous utilisez déjà cette plage ailleurs, envisagez d'utiliser la classe E/RFC 5735 (240.0.0.0/4). La classe E est un espace immense qui compte plus de 268 millions d'adresses IP disponibles. Elle pourra donc soutenir votre croissance pendant longtemps. Toutefois, la classe E présente certaines limites. Par exemple, elle n'est pas compatible avec Windows ni avec certains matériels sur site. Découvrez comment exploiter l'espace d'adressage IPv4 de classe E pour atténuer les problèmes d'épuisement des adresses IPv4 dans GKE.
Utiliser Cloud NAT ou Private Service Connect
Si votre charge de travail App Engine se trouve dans une plage non-RFC 1918 et doit atteindre une destination sur site qui n'accepte que la RFC 1918, choisissez l'une des solutions suivantes :
- Utilisez Hybrid NAT pour effectuer la traduction d'adresses et la sortie via une petite plage RFC 1918.
- Exposez le service sur site en tant que service hybride Private Service Connect.
Utiliser des sous-réseaux IPv4 et IPv6 (double pile)
Bien que cela ne réduise pas l'épuisement des adresses IPv4, envisagez de migrer vos applications vers IPv6. Pour éviter les problèmes d'épuisement des adresses IPv4 à l'avenir, configurez des ressources à double pile.
Stratégies de réduction de l'épuisement des ports
La section suivante décrit les stratégies permettant de réduire l'épuisement des ports avec App Engine.
Utiliser le regroupement de connexions et réutiliser les connexions
Lorsque vous envoyez un grand nombre de requêtes depuis votre application App Engine vers une seule adresse IP de destination, utilisez le regroupement de connexions pour maintenir et réutiliser les connexions vers la destination. Des taux de connexion élevés à une seule adresse IP peuvent épuiser les ports sortants et entraîner des erreurs de connexion refusée.
Stratégies de performances et de débit
Cette section présente les options évolutives permettant d'améliorer les performances et le débit du réseau vers Internet et les services Google.
Utiliser des environnements d'exécution compatibles
La sortie VPC directe n'est compatible qu'avec les environnements d'exécution standards de deuxième génération. Les environnements d'exécution compatibles exécutent des implémentations de langage standards, prennent en charge les intégrations de bibliothèques modernes et offrent des performances réseau plus rapides et plus robustes.
Utiliser la sortie VPC directe pour un débit de sortie réseau plus rapide
Pour accélérer le débit des connexions de sortie réseau, utilisez la sortie VPC directe pour acheminer le trafic via votre réseau VPC.
Exemple 1 : Trafic externe vers Internet
Si vous envoyez du trafic externe vers l'Internet public, acheminez tout le trafic via le réseau VPC en définissant le champ vpc_egress sur all-traffic dans votre fichier app.yaml.
Avec cette approche, vous devez configurer Cloud NAT pour accéder à l'Internet public.
Pour configurer Cloud NAT pour votre service App Engine, consultez Configurer une adresse IP sortante statique. Pour connaître les paramètres de passerelle Cloud NAT à utiliser avec la sortie VPC directe pour Public NAT ou Private NAT, consultez Interactions de la sortie VPC directe Cloud NAT.
Exemple 2 : Trafic interne vers une API Google
Si vous utilisez la sortie VPC directe pour envoyer du trafic vers une API Google, telle que Cloud Storage, choisissez l'une des options suivantes :
- Spécifiez
private-ranges-only(par défaut) avec l'accès privé à Google :- Définissez
vpc_egress: private-ranges-onlydans votre fichierapp.yaml. - Activez l'accès privé à Google.
- Configurez le DNS pour l'accès privé à Google.
Assurez-vous que votre domaine cible (tel que
storage.googleapis.com) est mappé sur l'une des plages d'adresses IP internes suivantes :199.36.153.8/30199.36.153.4/30
- Définissez
- Spécifiez
all-trafficavec l'accès privé à Google :- Définissez
vpc_egress: all-trafficdans votre fichierapp.yaml. - Activez l'accès privé à Google.
- Définissez
Utiliser le paramètre de MTU par défaut pour App Engine
Ne modifiez pas le paramètre d'unité de transmission maximale (MTU) d'un réseau VPC lorsque vous l'utilisez avec App Engine. Utilisez plutôt la MTU par défaut de 1 460 octets.
Considérations liées au coût
Lorsque vous configurez les options de mise en réseau de vos ressources, tenez compte des points suivants :
- Colocalisez vos ressources : essayez de déployer vos ressources App Engine dans la même région que vos bases de données de backend, telles que Cloud SQL, Firestore et les buckets Cloud Storage. Le transfert de données entre les ressources Google Cloud au sein d'une même région est sans frais.
- Passer à la sortie VPC directe : si vous acheminez le trafic de manière sécurisée vers des ressources de réseau VPC internes, envisagez de passer à la sortie VPC directe à partir des connecteurs d'accès au VPC sans serveur. La sortie VPC directe n'entraîne pas de frais de calcul de base, ce qui élimine les frais généraux de calcul de base et les coûts d'inactivité associés aux instances de connecteur.
- Utilisez Cloud CDN : déchargez les éléments statiques et le contenu pouvant être mis en cache en plaçant Cloud CDN devant vos ressources App Engine. La diffusion de données à partir de la périphérie est nettement moins coûteuse que le paiement d'une sortie Internet standard directement depuis App Engine. Vous ne pouvez pas activer Cloud CDN directement sur l'URL
appspot.compar défaut. À la place, acheminez les requêtes via un équilibreur de charge d'application externe doté d'un backend de groupe de points de terminaison du réseau (NEG) sans serveur. Pour en savoir plus, consultez Configurer un équilibreur de charge d'application externe global avec App Engine. - Surveiller la sortie Internet : le trafic sortant qui traverse les limites d'une région ou qui est acheminé vers l'Internet public entraîne des frais standards. Concentrez vos efforts de surveillance sur le trafic sortant qui traverse les limites de la région.
Pour en savoir plus, consultez les tarifs d'App Engine ou estimez les coûts à l'aide du simulateur de coût.
Étapes suivantes
- Comparer la sortie VPC directe et les connecteurs d'accès au VPC sans serveur
- Configurer la sortie VPC directe