Bonnes pratiques pour connecter les ECS services Amazon dans un VPC

En utilisant ECS les tâches Amazon dans unVPC, vous pouvez diviser les applications monolithiques en parties distinctes qui peuvent être déployées et mises à l'échelle indépendamment dans un environnement sécurisé. Cette architecture est appelée architecture orientée services (SOA) ou microservices. Cependant, il peut être difficile de s'assurer que toutes ces parties, à la fois à l'intérieur et à l'extérieur d'unVPC, peuvent communiquer entre elles. Il existe plusieurs approches pour faciliter la communication, qui présentent toutes des avantages et des inconvénients différents.

Utilisation de Service Connect

Nous recommandons Service Connect, qui fournit une ECS configuration Amazon pour la découverte de services, la connectivité et la surveillance du trafic. Avec Service Connect, vos applications peuvent utiliser des noms abrégés et des ports standard pour se connecter aux services du même cluster ou d'autres clusters, y compris VPCs au sein de la même région. Pour plus d'informations, consultez Amazon ECS Service Connect.

Lorsque vous utilisez Service Connect, Amazon ECS gère toutes les étapes de la découverte de services : création des noms pouvant être découverts, gestion dynamique des entrées pour chaque tâche au démarrage et à l'arrêt des tâches, exécution d'un agent pour chaque tâche configuré pour découvrir les noms. Votre application peut rechercher les noms en utilisant les fonctionnalités standard relatives aux DNS noms et en établissant des connexions. Si votre application le fait déjà, vous n'avez pas besoin de la modifier pour utiliser Service Connect.

Les modifications ne se produisent que lors des déploiements

Vous fournissez la configuration complète dans chaque définition de service et de tâche. Amazon ECS gère les modifications apportées à cette configuration lors de chaque déploiement de service, afin de garantir que toutes les tâches d'un déploiement se comportent de la même manière. Par exemple, l'un des problèmes courants liés à DNS la découverte de services est le contrôle d'une migration. Si vous modifiez un DNS nom pour qu'il pointe vers les nouvelles adresses IP de remplacement, cela peut prendre un maximum de TTL temps avant que tous les clients commencent à utiliser le nouveau service. Avec Service Connect, le déploiement du client met à jour la configuration en remplaçant les tâches du client. Vous pouvez configurer le disjoncteur de déploiement et toute autre configuration de déploiement pour affecter les modifications de Service Connect de la même manière que pour tout autre déploiement.

Utilisation de la découverte de services

Une autre approche de service-to-service communication est la communication directe à l'aide de la découverte de services. Dans cette approche, vous pouvez utiliser l'intégration de la découverte de AWS Cloud Map services avec AmazonECS. À l'aide de la découverte de services, Amazon ECS synchronise la liste des tâches lancées avec AWS Cloud Map, ce qui permet de conserver un DNS nom d'hôte qui correspond aux adresses IP internes d'une ou de plusieurs tâches provenant de ce service en particulier. D'autres services d'Amazon VPC peuvent utiliser ce DNS nom d'hôte pour envoyer du trafic directement vers un autre conteneur en utilisant son adresse IP interne. Pour de plus amples informations, consultez Découverte de service.

Dans le schéma précédent, il existe trois services. service-a-localpossède un conteneur et communique avecservice-b-local, qui possède deux conteneurs. service-b-localdoit également communiquer avecservice-c-loacl, qui possède un conteneur. Chaque conteneur de ces trois services peut utiliser les DNS noms internes de AWS Cloud Map pour rechercher les adresses IP internes d'un conteneur auprès du service en aval avec lequel il doit communiquer.

Cette approche de service-to-service communication permet une faible latence. À première vue, c'est également simple car il n'y a aucun composant supplémentaire entre les conteneurs. Le trafic se déplace directement d'un conteneur à l'autre.

Cette approche convient lorsque vous utilisez le mode awsvpc réseau, où chaque tâche possède sa propre adresse IP unique. La plupart des logiciels ne prennent en charge que l'utilisation d'DNSAenregistrements, qui se résolvent directement en adresses IP. Lorsque vous utilisez le mode awsvpc réseau, l'adresse IP de chaque tâche est un A enregistrement. Toutefois, si vous utilisez le mode bridge réseau, plusieurs conteneurs peuvent partager la même adresse IP. En outre, les mappages de ports dynamiques entraînent l'attribution aléatoire de numéros de port aux conteneurs sur cette adresse IP unique. À ce stade, un A enregistrement ne suffit plus pour la découverte de services. Vous devez également utiliser un SRV enregistrement. Ce type d'enregistrement permet de suivre à la fois les adresses IP et les numéros de port, mais nécessite que vous configuriez les applications de manière appropriée. Certaines applications prédéfinies que vous utilisez peuvent ne pas prendre en charge SRV les enregistrements.

Un autre avantage du mode awsvpc réseau est que vous disposez d'un groupe de sécurité unique pour chaque service. Vous pouvez configurer ce groupe de sécurité pour autoriser les connexions entrantes provenant uniquement des services en amont spécifiques qui doivent communiquer avec ce service.

Le principal inconvénient de la service-to-service communication directe utilisant la découverte de services est que vous devez implémenter une logique supplémentaire pour effectuer de nouvelles tentatives et faire face aux échecs de connexion. DNSles enregistrements ont une période time-to-live (TTL) qui contrôle la durée pendant laquelle ils sont mis en cache. Il faut un certain temps pour que l'DNSenregistrement soit mis à jour et que le cache expire afin que vos applications puissent récupérer la dernière version de l'DNSenregistrement. Il se peut donc que votre application finisse par résoudre l'DNSenregistrement pour pointer vers un autre conteneur qui n'existe plus. Votre application doit gérer les nouvelles tentatives et disposer d'une logique lui permettant d'ignorer les mauvais backends.

Utilisation d'un équilibreur de charge interne

Une autre approche de service-to-service communication consiste à utiliser un équilibreur de charge interne. Un équilibreur de charge interne existe entièrement à l'intérieur de votre VPC ordinateur et n'est accessible qu'aux services qui s'y trouvent. VPC

L'équilibreur de charge maintient une haute disponibilité en déployant des ressources redondantes dans chaque sous-réseau. Lorsqu'un conteneur serviceA doit communiquer avec un conteneur depuisserviceB, il ouvre une connexion avec l'équilibreur de charge. L'équilibreur de charge ouvre ensuite une connexion vers un conteneur à partir deservice B. L'équilibreur de charge sert de lieu centralisé pour gérer toutes les connexions entre chaque service.

Si un conteneur s'serviceBarrête, l'équilibreur de charge peut le retirer du pool. L'équilibreur de charge effectue également des contrôles de santé par rapport à chaque cible en aval de son pool et peut automatiquement supprimer les mauvaises cibles du pool jusqu'à ce qu'elles redeviennent saines. Les applications n'ont plus besoin de connaître le nombre de conteneurs en aval. Ils ouvrent simplement leurs connexions à l'équilibreur de charge.

Cette approche est avantageuse pour tous les modes réseau. L'équilibreur de charge peut suivre les adresses IP des tâches en mode awsvpc réseau, ainsi que les combinaisons plus avancées d'adresses IP et de ports en mode bridge réseau. Il répartit le trafic de manière uniforme entre toutes les combinaisons d'adresses IP et de ports, même si plusieurs conteneurs sont hébergés sur la même EC2 instance Amazon, mais uniquement sur des ports différents.

Le seul inconvénient de cette approche est son coût. Pour être hautement disponible, l'équilibreur de charge doit disposer de ressources dans chaque zone de disponibilité. Cela entraîne des coûts supplémentaires en raison des frais supplémentaires liés au paiement de l'équilibreur de charge et à la quantité de trafic qui passe par l'équilibreur de charge.

Cependant, vous pouvez réduire les frais généraux en faisant en sorte que plusieurs services partagent un équilibreur de charge. Cela convient particulièrement aux REST services qui utilisent un Application Load Balancer. Vous pouvez créer des règles de routage basées sur les chemins qui acheminent le trafic vers différents services. Par exemple, /api/user/* peut être acheminé vers un conteneur faisant partie du user service, alors qu'il /api/order/* peut être acheminé vers le order service associé. Avec cette approche, vous ne payez que pour un seul Application Load Balancer et vous en avez un qui soit cohérentURL. API Cependant, vous pouvez répartir le trafic entre différents microservices sur le backend.