Salut tout le monde! Je m'appelle Kirill, je suis CTO chez Adapty. La plupart de notre architecture est sur AWS, et aujourd'hui, je parlerai de la façon dont nous avons réduit les coûts des serveurs de 3 fois en utilisant des instances ponctuelles dans un environnement de production, ainsi que de la façon de configurer leur mise à l'échelle automatique. Il y aura d'abord un aperçu de son fonctionnement, puis des instructions détaillées pour commencer.
Que sont les instances ponctuelles ?
les instances sont des serveurs d'autres utilisateurs AWS qui sont actuellement inactifs, et ils les vendent à un prix très réduit (Amazon écrit jusqu'à 90 %, d'après notre expérience ~ 3x, varie en fonction de la région, de l'AZ et du type d'instance). Leur principale différence avec les modèles ordinaires est qu'ils peuvent s'éteindre à tout moment. C'est pourquoi nous avons longtemps cru qu'il était normal de les utiliser pour des environnements vierges, ou pour des tâches de calcul, avec des résultats intermédiaires enregistrés sur S3 ou dans la base de données, mais pas pour la vente. Il existe des solutions tierces qui vous permettent d'utiliser des spots en production, mais il existe de nombreuses béquilles pour notre cas, nous ne les avons donc pas mises en œuvre. L'approche décrite dans l'article fonctionne entièrement dans le cadre de la fonctionnalité AWS standard, sans scripts, couronnes, etc. supplémentaires.
Vous trouverez ci-dessous quelques captures d'écran illustrant l'historique des prix des instances ponctuelles.
m5.large dans la région eu-west-1 (Irlande). Le prix est resté globalement stable depuis 3 mois, économisant actuellement 2.9x.
m5.large dans la région us-east-1 (Virginie du Nord). Le prix évolue constamment sur 3 mois, économisant actuellement de 2.3x à 2.8x selon la zone de disponibilité.
t3.small dans la région us-east-1 (Virginie du Nord). Le prix est stable depuis 3 mois, économisant actuellement 3.4x.
Architecture des services
L'architecture de base du service dont nous parlerons dans cet article est présentée dans le schéma ci-dessous.
Équilibreur de charge d'application → Groupe cible EC2 → Elastic Container Service
L'Application Load Balancer (ALB) est utilisé comme équilibreur, qui envoie des requêtes au groupe cible EC2 (TG). TG est responsable de l'ouverture des ports sur les instances pour les ALB et de leur connexion aux ports des conteneurs Elastic Container Service (ECS). ECS est un analogue de Kubernetes dans AWS, qui gère les conteneurs Docker.
Une instance peut avoir plusieurs conteneurs en cours d'exécution avec les mêmes ports, nous ne pouvons donc pas les définir de manière fixe. ECS indique à TG qu'il lance une nouvelle tâche (dans la terminologie Kubernetes, cela s'appelle un pod), il vérifie les ports libres sur l'instance et en affecte un à la tâche lancée. TG vérifie également régulièrement si l'instance et l'API fonctionnent dessus à l'aide du contrôle de santé, et s'il détecte des problèmes, il arrête d'y envoyer des requêtes.
Groupes EC2 Auto Scaling + fournisseurs de capacité ECS
Le diagramme ci-dessus ne montre pas le service EC2 Auto Scaling Groups (ASG). D'après le nom, vous pouvez comprendre qu'il est responsable de la mise à l'échelle des instances. Cependant, jusqu'à récemment, AWS ne disposait pas de capacité intégrée pour gérer le nombre de machines en cours d'exécution à partir d'ECS. ECS a permis d'adapter le nombre de tâches, par exemple en fonction de l'utilisation du processeur, de la RAM ou du nombre de requêtes. Mais si les tâches occupaient toutes les instances libres, alors les nouvelles machines n’étaient pas automatiquement créées.
Cela a changé avec l’avènement des fournisseurs de capacité ECS (ECS CP). Désormais, chaque service dans ECS peut être associé à un ASG, et si les tâches ne correspondent pas aux instances en cours d'exécution, de nouvelles seront créées (mais dans les limites ASG établies). Cela fonctionne également dans le sens inverse : si ECS CP détecte des instances inactives sans tâches, il donnera alors la commande ASG pour les arrêter. ECS CP a la capacité de spécifier un pourcentage cible de charge d'instance, afin qu'un certain nombre de machines soient toujours libres pour des tâches évolutives rapidement ; j'en parlerai un peu plus tard.
Modèles de lancement EC2
Le dernier service dont je parlerai avant d'entrer dans les détails de la création de cette infrastructure est les modèles de lancement EC2. Il vous permet de créer un modèle selon lequel toutes les machines démarreront, afin de ne pas répéter cela à chaque fois. Ici, vous pouvez sélectionner le type de machine à démarrer, le groupe de sécurité, l'image disque et bien d'autres paramètres. Vous pouvez également spécifier les données utilisateur qui seront téléchargées sur toutes les instances lancées. Vous pouvez exécuter des scripts dans les données utilisateur, par exemple, vous pouvez modifier le contenu d'un fichier .
L'un des paramètres de configuration les plus importants pour cet article est = vrai. Si ce paramètre est activé, dès qu'ECS reçoit un signal indiquant qu'une instance ponctuelle est supprimée, il transfère toutes les tâches qui y travaillent à l'état Drainage. Aucune nouvelle tâche ne sera assignée à cette instance ; si des tâches souhaitent y être déployées maintenant, elles seront annulées. Les demandes de l'équilibreur cessent également d'arriver. La notification de suppression d'instance arrive 2 minutes avant l'événement réel. Par conséquent, si votre service n'effectue pas de tâches de plus de 2 minutes et n'enregistre rien sur le disque, vous pouvez utiliser des instances ponctuelles sans perdre de données.
Concernant le disque - AWS récemment Il est possible d'utiliser Elastic File System (EFS) avec ECS ; avec ce schéma, même le disque n'est pas un obstacle, mais nous n'avons pas essayé cela, car en principe nous n'avons pas besoin du disque pour stocker l'état. Par défaut, après réception du SIGINT (envoyé lors du passage d'une tâche à l'état Drainage), toutes les tâches en cours seront arrêtées au bout de 30 secondes, même si elles ne sont pas encore terminées ; vous pouvez modifier ce temps à l'aide du paramètre . L'essentiel est de ne pas le régler plus de 2 minutes pour les machines spot.
Création d'un service
Passons à la création du service décrit. Dans le processus, je décrirai en outre plusieurs points utiles qui n'ont pas été mentionnés ci-dessus. En général, il s'agit d'une instruction étape par étape, mais je ne considérerai pas certains cas très basiques ou au contraire très spécifiques. Toutes les actions sont effectuées dans la console visuelle AWS, mais peuvent être reproduites par programme à l'aide de CloudFormation ou Terraform. Chez Adapty, nous utilisons Terraform.
Modèle de lancement EC2
Ce service crée une configuration des machines qui seront utilisées. Les modèles sont gérés dans la section EC2 -> Instances -> Modèles de lancement.
Image machine Amazon (AMI) — spécifiez l'image disque avec laquelle toutes les instances seront lancées. Pour ECS, dans la plupart des cas, il vaut la peine d'utiliser l'image optimisée d'Amazon. Il est régulièrement mis à jour et contient tout ce qui est nécessaire au fonctionnement d'ECS. Pour connaître l'identifiant actuel de l'image, rendez-vous sur la page , sélectionnez la région que vous utilisez et copiez l'ID AMI correspondant. Par exemple, pour la région us-east-1, l'ID actuel au moment de la rédaction est ami-00c7c1cf5bdc913ed. Cet ID doit être inséré dans l'élément Spécifier une valeur personnalisée.
Type d'instance — indiquez le type d'instance. Choisissez celui qui convient le mieux à votre tâche.
Paire de clés (connexion) — spécifiez un certificat avec lequel vous pouvez vous connecter à l'instance via SSH, si nécessaire.
Paramètres réseau — spécifiez les paramètres du réseau. Plateforme de réseautage dans la plupart des cas, il devrait y avoir un cloud privé virtuel (VPC). Groupes de sécurité — des groupes de sécurité pour vos instances. Puisque nous utiliserons un équilibreur devant les instances, je recommande de spécifier ici un groupe qui autorise les connexions entrantes uniquement à partir de l'équilibreur. Autrement dit, vous disposerez de 2 groupes de sécurité, un pour l'équilibreur, qui autorise les connexions entrantes depuis n'importe où sur les ports 80 (http) et 443 (https), et le second pour les machines, qui autorise les connexions entrantes sur n'importe quel port du groupe d'équilibrage. . Les connexions sortantes dans les deux groupes doivent être ouvertes à l'aide du protocole TCP vers tous les ports vers toutes les adresses. Vous pouvez limiter les ports et les adresses pour les connexions sortantes, mais vous devez ensuite surveiller en permanence que vous n'essayez pas d'accéder à quelque chose sur un port fermé.
Stockage (volumes) — spécifiez les paramètres de disque pour les machines. La taille du disque ne peut pas être inférieure à celle spécifiée dans l'AMI ; pour ECS optimisé, elle est de 30 Gio.
Détails avancés — spécifiez des paramètres supplémentaires.
Possibilité d'achat — si nous voulons acheter des instances ponctuelles. Nous le souhaitons, mais nous ne cocherons pas cette case ici, nous la configurerons dans le groupe Auto Scaling, il y a plus d'options là-bas.
Profil d'instance IAM — indiquez le rôle avec lequel les instances seront lancées. Pour que les instances s'exécutent dans ECS, elles ont besoin d'autorisations, qui se trouvent généralement dans le rôle ecsInstanceRole. Dans certains cas, il peut être créé, sinon, alors ici sur la façon de procéder. Après création, nous l'indiquons dans le modèle.
Ensuite, il existe de nombreux paramètres, en gros, vous pouvez laisser des valeurs par défaut partout, mais chacun d'eux a une description claire. J'active toujours l'instance optimisée pour EBS et les options T2/T3 Unlimited si elles sont utilisées instances.
temps de l'utilisateur — indiquer les données utilisateur. Nous allons éditer le fichier /etc/ecs/ecs.config, qui contient la configuration de l'agent ECS.
Un exemple de ce à quoi pourraient ressembler les données utilisateur :
#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.configECS_CLUSTER=DemoApiClusterProd — le paramètre indique que l'instance appartient à un cluster portant le nom donné, c'est-à-dire que ce cluster pourra placer ses tâches sur ce serveur. Nous n'avons pas encore créé de cluster, mais nous utiliserons ce nom lors de sa création.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — le paramètre spécifie que lorsqu'un signal est reçu pour désactiver une instance ponctuelle, toutes les tâches qui s'y trouvent doivent être transférées à l'état Drainage.
ECS_CONTAINER_STOP_TIMEOUT=1m - le paramètre précise qu'après avoir reçu un signal SIGINT, toutes les tâches ont 1 minute avant d'être tuées.
ECS_ENGINE_AUTH_TYPE=docker — le paramètre indique que le schéma Docker est utilisé comme mécanisme d'autorisation
ECS_ENGINE_AUTH_DATA=... — paramètres de connexion au registre de conteneurs privé, où sont stockées vos images Docker. S'il est public, vous n'avez rien à préciser.
Pour les besoins de cet article, j'utiliserai une image publique de Docker Hub, précisez donc les paramètres ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA il ne faut pas.
Bon à savoir: Il est recommandé de mettre à jour l'AMI régulièrement, car les nouvelles versions mettent à jour les versions de Docker, Linux, agent ECS, etc. Pour ne pas oublier cela, vous pouvez sur la sortie de nouvelles versions. Vous pouvez recevoir des notifications par e-mail et mettre à jour manuellement, ou vous pouvez écrire une fonction Lambda qui créera automatiquement une nouvelle version du modèle de lancement avec une AMI mise à jour.
Groupe de mise à l'échelle automatique EC2
Auto Scaling Group est responsable du lancement et de la mise à l’échelle des instances. Les groupes sont gérés dans la section EC2 -> Auto Scaling -> Groupes Auto Scaling.
Modèle de lancement — sélectionnez le modèle créé à l'étape précédente. Nous laissons la version par défaut.
Options d'achat et types d'instances — spécifiez les types d'instances pour le cluster. Adhere to launch template utilise le type d’instance du modèle de lancement. Combiner les options d'achat et les types d'instances vous permet de configurer de manière flexible les types d'instances. Nous l'utiliserons.
Base à la demande en option — le nombre d'instances régulières et non ponctuelles qui fonctionneront toujours.
Pourcentage de demande au-dessus de la base — pourcentage d'instances régulières et ponctuelles, 50-50 seront distribués également, 20-80 pour chaque instance régulière, 4 instances ponctuelles seront collectées. Pour les besoins de cet exemple, j'indiquerai 50-50, mais en réalité on fait le plus souvent 20-80, dans certains cas 0-100.
Types d'instances — ici, vous pouvez spécifier des types supplémentaires d'instances qui seront utilisées dans le cluster. Nous ne l'avons jamais utilisé parce que je ne comprends pas vraiment le sens de l'histoire. Cela est peut-être dû aux limites de types spécifiques d'instances, mais elles peuvent être facilement augmentées grâce au support. Si vous connaissez l'application, je serai ravi de la lire dans les commentaires)
Réseau — paramètres réseau, sélectionnez le VPC et les sous-réseaux pour les machines, dans la plupart des cas, vous devez sélectionner tous les sous-réseaux disponibles.
L'équilibrage de charge - les paramètres de l'équilibreur, mais nous le ferons séparément, nous ne toucherons à rien ici. Bilans de santé sera également configuré plus tard.
Taille de groupe — nous indiquons les limites du nombre de machines dans le cluster et le nombre de machines souhaité au démarrage. Le nombre de machines dans le cluster ne sera jamais inférieur au minimum spécifié ni supérieur au maximum, même si la mise à l'échelle doit s'effectuer conformément aux métriques.
Politiques de mise à l'échelle — paramètres de mise à l'échelle, mais nous évoluerons en fonction des tâches ECS en cours d'exécution, nous configurerons donc la mise à l'échelle plus tard.
Protection contre la mise à l'échelle de l'instance — protection des instances contre la suppression lors de la réduction. Nous l'activons pour qu'ASG ne supprime pas la machine sur laquelle des tâches sont en cours d'exécution. ECS Capacity Provider désactivera la protection pour les instances qui n'ont pas de tâches.
Ajouter des balises — vous pouvez spécifier des tags pour les instances (pour cela, la case Tag new instances doit être cochée). Je recommande de spécifier la balise Name, puis toutes les instances lancées au sein du groupe auront le même nom et il est pratique de les afficher dans la console.
Après avoir créé le groupe, ouvrez-le et allez dans la section Configurations avancées. Pourquoi toutes les options ne sont pas visibles dans la console au stade de la création.
Politiques de résiliation — les règles prises en compte lors de la suppression d'instances. Ils sont appliqués dans l'ordre. Nous utilisons généralement ceux de l’image ci-dessous. Tout d'abord, les instances avec le modèle de lancement le plus ancien sont supprimées (par exemple, si nous avons mis à jour l'AMI, nous avons créé une nouvelle version, mais toutes les instances ont réussi à y basculer). Ensuite, les instances les plus proches de la prochaine heure de facturation sont sélectionnées. Et puis les plus anciens sont sélectionnés en fonction de la date de lancement.
Bon à savoir: pour mettre à jour toutes les machines d'un cluster, pratique à utiliser . Si vous combinez cela avec la fonction Lambda de l'étape précédente, vous disposerez d'un système de mise à jour d'instance entièrement automatisé. Avant de mettre à jour toutes les machines, vous devez désactiver la protection contre la réduction d'instance pour toutes les instances du groupe. Pas de configuration dans le groupe, mais une protection depuis les machines elles-mêmes, cela se fait sur l'onglet Gestion des instances.
Équilibreur de charge d'application et groupe cible EC2
L'équilibreur est créé dans la section EC2 → Load Balancing → Load Balancers. Nous utiliserons Application Load Balancer ; une comparaison des différents types d’équilibreurs peut être lue sur .
Les auditeurs - il est logique de créer les ports 80 et 443 et de rediriger plus tard de 80 vers 443 en utilisant les règles d'équilibrage.
Zones de disponibilité — dans la plupart des cas, nous sélectionnons des zones d'accessibilité pour tout le monde.
Configurer les paramètres de sécurité — le certificat SSL de l'équilibreur est indiqué ici, l'option la plus pratique est en ACM. À propos des différences Politique de sécurité peut être lu , vous pouvez le laisser sélectionné par défaut ELBSecurityPolicy-2016-08. Après avoir créé l'équilibreur, vous le verrez Nom DNS, dont vous avez besoin pour configurer le CNAME de votre domaine. Par exemple, voici à quoi cela ressemble dans Cloudflare.
Groupe de sécurité - créer ou sélectionner un groupe de sécurité pour l'équilibreur, j'en ai écrit plus juste ci-dessus dans la section Modèle de lancement EC2 → Paramètres réseau.
Groupe ciblé — nous créons un groupe chargé d'acheminer les demandes de l'équilibreur vers les machines et de vérifier leur disponibilité afin de les remplacer en cas de problème. Type de cible doit être une instance, Passerelle и Port Quoi qu'il en soit, si vous utilisez HTTPS pour la communication entre l'équilibreur et les instances, vous devez alors leur télécharger un certificat. Pour les besoins de cet exemple, nous ne ferons pas cela, nous quitterons simplement le port 80.
Bilans de santé — paramètres permettant de vérifier la fonctionnalité du service. Dans un service réel, il devrait s'agir d'une requête distincte qui implémente des parties importantes de la logique métier ; pour les besoins de cet exemple, je laisserai les paramètres par défaut. Ensuite, vous pouvez sélectionner l'intervalle de requête, le délai d'attente, les codes de réussite, etc. Dans notre exemple, nous indiquerons les codes de réussite 200-399, car l'image Docker qui sera utilisée renvoie un code 304.
Enregistrer les cibles — ici, les voitures du groupe sont sélectionnées, mais dans notre cas, cela sera fait par ECS, nous sautons donc simplement cette étape.
Bon à savoir: au niveau de l'équilibreur, vous pouvez activer les journaux qui seront enregistrés dans S3 dans un certain . À partir de là, ils peuvent être exportés vers des services tiers à des fins d'analyse, ou vous pouvez effectuer des requêtes SQL directement sur les données dans S3 avec . C'est pratique et fonctionne sans aucun code supplémentaire. Je recommande également de configurer la suppression des journaux du compartiment S3 après une période de temps spécifiée.
Définition des tâches ECS
Dans les étapes précédentes, nous avons créé tout ce qui concerne l'infrastructure de service ; nous passons maintenant à la description des conteneurs que nous allons lancer. Cela se fait dans la section ECS → Définitions de tâches.
Compatibilité des types de lancement - sélectionnez EC2.
Rôle IAM d'exécution de tâches - choisir ecsTaskExecutionRole. Grâce à lui, des journaux sont écrits, l'accès aux variables secrètes est donné, etc.
Dans la section Définitions de conteneur, cliquez sur Ajouter un conteneur.
Image(s) — lien vers l'image avec le code du projet ; pour cet exemple j'utiliserai une image publique de Docker Hub .
Limites de mémoire — limites de mémoire pour le conteneur. Limite stricte — limite stricte, si le conteneur dépasse la valeur spécifiée, la commande docker kill sera exécutée, le conteneur mourra immédiatement. Limite douce — limite souple, le conteneur peut dépasser la valeur spécifiée, mais ce paramètre sera pris en compte lors du placement des tâches sur les machines. Par exemple, si une machine dispose de 4 Gio de RAM et que la limite logicielle d'un conteneur est de 2048 2 Mio, cette machine peut avoir un maximum de 4 tâches en cours d'exécution avec ce conteneur. En réalité, 4096 Gio de RAM représentent un peu moins de XNUMX XNUMX Mio, cela peut être consulté dans l'onglet Instances ECS du cluster. La limite souple ne peut pas être supérieure à la limite stricte. Il est important de comprendre que s'il y a plusieurs conteneurs dans une même tâche, alors leurs limites sont résumées.
Mappages de ports - dans Port hôte Nous indiquons 0, cela signifie que le port sera attribué dynamiquement et sera surveillé par le groupe cible. Port à conteneurs — le port sur lequel votre application s'exécute est souvent spécifié dans la commande d'exécution, ou attribué dans le code de votre application, Dockerfile, etc. Pour notre exemple, nous utiliserons 3000 car il est répertorié dans l’image utilisée.
Bilan de santé — paramètres de vérification de l'état du conteneur, à ne pas confondre avec ceux configurés dans le groupe cible.
Environment - paramètres d'environnement. Unités CPU - similaire aux limites de mémoire, uniquement concernant le processeur. Chaque cœur de processeur contient 1024 512 unités, donc si le serveur dispose d'un processeur dual-core et que le conteneur est défini sur 4, alors XNUMX tâches avec ce conteneur peuvent être lancées sur un serveur. Les unités CPU correspondent toujours au nombre de cœurs, il ne peut pas y en avoir un peu moins, comme c'est le cas pour la mémoire.
Command — une commande pour démarrer un service dans un conteneur, tous les paramètres sont spécifiés séparés par des virgules. Cela pourrait être gunicorn, npm, etc. Si elle n'est pas spécifiée, la valeur de la directive CMD du Dockerfile sera utilisée. Nous indiquons npm,start.
Variables d'environnement — variables d'environnement du conteneur. Il peut s'agir de simples données textuelles ou de variables secrètes provenant de ou .
Stockage et journalisation — ici, nous allons configurer la journalisation dans CloudWatch Logs (un service pour les journaux d'AWS). Pour ce faire, cochez simplement la case Configurer automatiquement CloudWatch Logs. Après avoir créé la définition de tâche, un groupe de journaux sera automatiquement créé dans CloudWatch. Par défaut, les journaux y sont stockés indéfiniment ; je recommande de modifier la période de conservation de Ne jamais expirer à la période requise. Cela se fait dans les groupes CloudWatch Log, vous devez cliquer sur la période en cours et en sélectionner une nouvelle.
Cluster ECS et fournisseur de capacité ECS
Accédez à la section ECS → Clusters pour créer un cluster. Nous sélectionnons EC2 Linux + Networking comme modèle.
Nom du cluster - très important, nous faisons ici le même nom que celui spécifié dans le paramètre Launch Template ECS_CLUSTER, dans notre cas - DemoApiClusterProd. Cochez la case Créer un cluster vide. Vous pouvez éventuellement activer Container Insights pour afficher les métriques des services dans CloudWatch. Si vous avez tout fait correctement, dans la section Instances ECS, vous verrez les machines créées dans le groupe Auto Scaling.
Aller à l'onglet Fournisseurs de capacité et créez-en un nouveau. Je vous rappelle qu'il est nécessaire de contrôler la création et l'arrêt des machines en fonction du nombre de tâches ECS en cours d'exécution. Il est important de noter qu’un prestataire ne peut être affecté qu’à un seul groupe.
Groupe Mise à l'échelle automatique — sélectionnez le groupe créé précédemment.
Mise à l'échelle gérée - activez-le pour que le fournisseur puisse faire évoluer le service.
Capacité cible % — de quel pourcentage de machines chargées de tâches avons-nous besoin. Si vous spécifiez 100 %, toutes les machines seront toujours occupées à exécuter des tâches. Si vous précisez 50 %, alors la moitié des voitures sera toujours gratuite. Dans ce cas, en cas de forte augmentation de la charge, les nouveaux taxis pourront immédiatement libérer les voitures, sans avoir à attendre le déploiement des instances.
Protection de résiliation gérée — activer, ce paramètre permet au fournisseur de supprimer la protection des instances contre la suppression. Cela se produit lorsqu'il n'y a aucune tâche active sur la machine et autorise le % de capacité cible.
Service ECS et configuration de la mise à l’échelle
Dernière étape :) Pour créer un service, vous devez vous rendre sur le cluster précédemment créé dans l'onglet Services.
Type de lancement — vous devez cliquer sur la stratégie Passer à la stratégie de fournisseur de capacité et sélectionner les fournisseurs précédemment créés.
Définition de tâche — sélectionnez la définition de tâche créée précédemment et sa révision.
Nom du service — pour éviter toute confusion, nous indiquons toujours la même chose que la définition de la tâche.
Type de service - toujours Réplique.
Nombre de tâches — le nombre souhaité de tâches actives dans le service. Ce paramètre est contrôlé par la mise à l'échelle, mais doit néanmoins être spécifié.
Pourcentage minimum en bonne santé и Pourcentage maximum — déterminer le comportement des tâches pendant le déploiement. Les valeurs par défaut sont 100 et 200, indiquant qu'au moment du déploiement, le nombre de tâches augmentera plusieurs fois, puis reviendra à la valeur souhaitée. Si vous avez 1 tâche en cours d'exécution, min=0 et max=100, alors pendant le déploiement, elle sera supprimée, et après cela, une nouvelle sera déclenchée, c'est-à-dire qu'elle sera indisponible. Si 1 tâche est en cours d'exécution, min=50, max=150, alors le déploiement n'aura pas lieu du tout, car 1 tâche ne peut pas être divisée en deux ou augmentée d'une fois et demie.
Type de déploiement - quittez la mise à jour continue.
Modèles de placement — règles de placement des tâches sur les machines. La valeur par défaut est AZ Balanced Spread : cela signifie que chaque nouvelle tâche sera placée sur une nouvelle instance jusqu'à ce que les machines de toutes les zones de disponibilité augmentent. Nous faisons habituellement BinPack - CPU et Spread - AZ ; avec cette politique, les tâches sont placées aussi densément que possible sur une machine par CPU. S'il est nécessaire de créer une nouvelle machine, celle-ci est créée dans une nouvelle zone de disponibilité.
Type d'équilibreur de charge - sélectionnez Équilibreur de charge d'application.
Rôle IAM du service - choisir ecsServiceRole.
Nom de l'équilibreur de charge — sélectionnez l'équilibreur créé précédemment.
Délai de grâce pour le contrôle de santé — faites une pause avant d'effectuer des contrôles de santé après le déploiement d'une nouvelle tâche, nous la définissons généralement sur 60 secondes.
Conteneur à équilibrer la charge — dans l'élément Nom du groupe cible, sélectionnez le groupe précédemment créé et tout sera renseigné automatiquement.
Mise à l'échelle automatique du service — paramètres de mise à l'échelle du service. Sélectionnez Configurer Service Auto Scaling pour ajuster le nombre souhaité de votre service. Nous définissons le nombre minimum et maximum de tâches lors de la mise à l'échelle.
Rôle IAM pour Service Auto Scaling - choisir AWSServiceRoleForApplicationAutoScaling_ECSService.
Politiques de mise à l'échelle automatique des tâches — règles de mise à l'échelle. Il en existe 2 types :
- Suivi des cibles — suivi des métriques cibles (utilisation du CPU/RAM ou nombre de requêtes pour chaque tâche). Par exemple, nous voulons que la charge moyenne du processeur soit de 85 %, lorsqu'elle augmente, de nouvelles tâches seront ajoutées jusqu'à ce qu'elle atteigne la valeur cible. Si la charge est inférieure, alors les tâches seront supprimées, au contraire, sauf si la protection contre la réduction est activée (Désactiver la mise à l'échelle).
- Mise à l'échelle des étapes - réaction à un événement arbitraire. Ici, vous pouvez configurer une réaction à n'importe quel événement (CloudWatch Alarm), lorsqu'il se produit, vous pouvez ajouter ou supprimer le nombre spécifié de tâches, ou spécifier le nombre exact de tâches.
Un service peut avoir plusieurs règles de mise à l'échelle, cela peut être utile, l'essentiel est de s'assurer qu'elles n'entrent pas en conflit les unes avec les autres.
Conclusion
Si vous avez suivi les instructions et utilisé la même image Docker, votre service devrait renvoyer une page comme celle-ci.
- Nous avons créé un modèle selon lequel toutes les machines du service sont lancées. Nous avons également appris à mettre à jour les machines lorsque le modèle change.
- Nous avons configuré le traitement du signal d'arrêt de l'instance ponctuelle, donc moins d'une minute après sa réception, toutes les tâches en cours sont supprimées de la machine, donc rien n'est perdu ou interrompu.
- Nous avons surélevé l'équilibreur pour répartir la charge uniformément sur les machines.
- Nous avons créé un service qui s'exécute sur des instances ponctuelles, ce qui réduit les coûts des machines d'environ 3 fois.
- Nous avons configuré la mise à l'échelle automatique dans les deux sens pour gérer l'augmentation des charges de travail sans encourir de coûts de temps d'arrêt.
- Nous utilisons Capacity Provider pour que l'application gère l'infrastructure (les machines) et non l'inverse.
- Etaient bon.
Si vous avez des pics de charge prévisibles, par exemple si vous faites de la publicité dans une grande campagne par e-mail, vous pouvez configurer la mise à l'échelle par .
Vous pouvez également évoluer en fonction des données provenant de différentes parties de votre système. Par exemple, nous avons la fonctionnalité utilisateurs de l'application mobile. Parfois, une campagne est envoyée à plus d’un million de personnes. Après une telle distribution, il y a toujours une forte augmentation des requêtes vers l'API, puisque de nombreux utilisateurs se connectent à l'application en même temps. Ainsi, si nous constatons qu'il y a beaucoup plus d'indicateurs standards dans la file d'attente pour l'envoi de notifications push promotionnelles, nous pouvons immédiatement lancer plusieurs machines et tâches supplémentaires pour être prêts pour le chargement.
Je serai heureux si vous me racontez dans les commentaires des cas intéressants d'utilisation d'instances ponctuelles et d'ECS ou quelque chose sur la mise à l'échelle.
Bientôt, il y aura des articles sur la façon dont nous traitons des milliers d'événements analytiques par seconde sur une pile principalement sans serveur (avec de l'argent) et sur le fonctionnement du déploiement de services à l'aide de GitLab CI et Terraform Cloud.
Abonnez-vous à nous, ce sera intéressant !
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Utilisez-vous des instances ponctuelles en production ?
-
22,2%Oui6
-
66,7%Non18
-
11,1%J'en ai entendu parler grâce à un article et je prévois de les utiliser3
27 utilisateurs ont voté. 5 utilisateurs se sont abstenus.
Source: habr.com