{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Cr\u00e9ation d'une API \u00e9volutive sur des instances spot AWS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour \u00e0 tous ! Je m'appelle Kirill, je suis CTO chez Adapty. La majeure partie de notre architecture se trouve sur AWS, et aujourd'hui, je vais vous expliquer comment nous avons r\u00e9duit nos co\u00fbts de serveur par trois gr\u00e2ce \u00e0 l'utilisation d'instances Spot dans notre environnement de production, ainsi que comment configurer leur auto-scaling. D'abord, je donnerai un aper\u00e7u de son fonctionnement, puis une instruction d\u00e9taill\u00e9e pour le lancer.<\/p>\n

<\/p>\n

Qu'est-ce que les instances Spot ?<\/h2>\n

<\/p>\n

Les<\/a><\/noindex> instances Spot sont des serveurs d'autres utilisateurs d'AWS qui sont actuellement inoccup\u00e9s, et ils les vendent avec une grande remise (Amazon affirme jusqu'\u00e0 90%, selon notre exp\u00e9rience environ 3x, cela varie en fonction de la r\u00e9gion, de l'AZ et du type d'instance). Leur principale diff\u00e9rence avec les instances classiques est qu'elles peuvent s'arr\u00eater \u00e0 tout moment. Nous avons longtemps pens\u00e9 qu'elles \u00e9taient adapt\u00e9es pour les environnements de d\u00e9veloppement ou pour des t\u00e2ches de calcul avec des r\u00e9sultats interm\u00e9diaires sauvegard\u00e9s sur S3 ou dans une base de donn\u00e9es, mais pas pour la production. Il existe des solutions tierces qui permettent d'utiliser les Spot en production, mais elles n\u00e9cessitent beaucoup de bricolage pour notre cas d'utilisation, c'est pourquoi nous ne les avons pas mises en \u0153uvre. L'approche d\u00e9crite dans cet article fonctionne enti\u00e8rement dans le cadre des fonctionnalit\u00e9s standard d'AWS, sans scripts suppl\u00e9mentaires, cron jobs, etc.<\/p>\n

<\/a><\/noindex><\/p>\n

Voici quelques captures d'\u00e9cran qui montrent l'historique des prix des instances Spot.<\/p>\n

<\/p>\n

m5.large dans la r\u00e9gion eu-west-1 (Irlande). Le prix est principalement stable depuis 3 mois, actuellement l'\u00e9conomie est de 2.9x.<\/p>\n

<\/p>\n

\"Cr\u00e9ation<\/p>\n

<\/p>\n

m5.large dans la r\u00e9gion us-east-1 (Virginie du Nord). Le prix change constamment pendant 3 mois, actuellement l'\u00e9conomie varie de 2.3x \u00e0 2.8x selon la zone de disponibilit\u00e9.<\/p>\n

<\/p>\n

\"Cr\u00e9ation<\/p>\n

<\/p>\n

t3.small dans la r\u00e9gion us-east-1 (Virginie du Nord). Le prix est stable depuis 3 mois, actuellement l'\u00e9conomie est de 3.4x.<\/p>\n

<\/p>\n

\"Cr\u00e9ation<\/p>\n

<\/p>\n

Architecture du service<\/h2>\n

<\/p>\n

L'architecture de base du service dont nous allons parler dans cet article est illustr\u00e9e dans le diagramme ci-dessous.<\/p>\n

<\/p>\n

\"Cr\u00e9ation<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

Un Application Load Balancer (ALB) est utilis\u00e9 comme \u00e9quilibrage de charge, qui envoie des requ\u00eates au EC2 Target Group (TG). Le TG est responsable de l'ouverture des ports sur les instances pour l'ALB et de leur liaison avec les ports des conteneurs Elastic Container Service (ECS). L'ECS est l'\u00e9quivalent de Kubernetes sur AWS, qui g\u00e8re les conteneurs Docker.<\/p>\n

<\/p>\n

Un m\u00eame instance peut ex\u00e9cuter plusieurs conteneurs fonctionnant sur les m\u00eames ports, c'est pourquoi nous ne pouvons pas les d\u00e9finir de mani\u00e8re fixe. ECS informe le TG qu'il lance une nouvelle t\u00e2che (appel\u00e9e pod dans le jargon Kubernetes), il v\u00e9rifie les ports disponibles sur l'instance et en attribue un \u00e0 la t\u00e2che en cours. De plus, le TG v\u00e9rifie r\u00e9guli\u00e8rement si l'instance fonctionne et si l'API y est op\u00e9rationnelle gr\u00e2ce \u00e0 un contr\u00f4le de sant\u00e9, et s'il d\u00e9tecte des probl\u00e8mes, il cesse d'y envoyer des requ\u00eates.<\/p>\n

<\/p>\n

Groupes de mise \u00e0 l'\u00e9chelle EC2 + Fournisseurs de capacit\u00e9 ECS<\/h3>\n

<\/p>\n

Le service EC2 Auto Scaling Groups (ASG) n'est pas repr\u00e9sent\u00e9 dans le diagramme ci-dessus. Comme son nom l'indique, il est responsable de la mise \u00e0 l'\u00e9chelle des instances. Cependant, jusqu'\u00e0 r\u00e9cemment, AWS n'avait pas de fonctionnalit\u00e9 int\u00e9gr\u00e9e permettant de g\u00e9rer le nombre de machines lanc\u00e9es depuis ECS. ECS permettait de faire \u00e9voluer le nombre de t\u00e2ches, par exemple, en fonction de l'utilisation de CPU, de RAM ou du nombre de requ\u00eates. Mais si les t\u00e2ches prenaient toutes les instances disponibles, de nouvelles machines n'\u00e9taient pas automatiquement lanc\u00e9es.<\/p>\n

<\/p>\n

Cela a chang\u00e9 avec l'introduction des Fournisseurs de capacit\u00e9 ECS (ECS CP). Maintenant, chaque service dans ECS peut \u00eatre li\u00e9 \u00e0 un ASG, et si les t\u00e2ches ne tiennent pas sur les instances en cours, de nouvelles instances seront cr\u00e9\u00e9es (dans les limites d\u00e9finies par l'ASG). Cela fonctionne aussi dans l'autre sens, si ECS CP d\u00e9tecte des instances inactives sans t\u00e2ches, il commandera \u00e0 l'ASG de les \u00e9teindre. ECS CP a la possibilit\u00e9 de sp\u00e9cifier un pourcentage cible d'utilisation des instances, de sorte qu'un certain nombre de machines restent toujours disponibles pour un d\u00e9ploiement rapide des t\u00e2ches, j'en parlerai un peu plus tard.<\/p>\n

<\/p>\n

Mod\u00e8les de lancement EC2<\/h3>\n

<\/p>\n

Le dernier service dont je vais parler avant de passer \u00e0 une description d\u00e9taill\u00e9e de la cr\u00e9ation de cette infrastructure est les Mod\u00e8les de lancement EC2. Il permet de cr\u00e9er un mod\u00e8le selon lequel toutes les machines seront lanc\u00e9es, afin de ne pas r\u00e9p\u00e9ter ce processus \u00e0 chaque fois depuis le d\u00e9but. Ici, vous pouvez choisir le type de machine \u00e0 lancer, le groupe de s\u00e9curit\u00e9, l'image disque et beaucoup d'autres param\u00e8tres. Vous pouvez \u00e9galement sp\u00e9cifier des donn\u00e9es utilisateur qui seront appliqu\u00e9es \u00e0 toutes les instances lanc\u00e9es. Dans ces donn\u00e9es utilisateur, vous pouvez ex\u00e9cuter des scripts, par exemple, il est possible de modifier le contenu du fichier de configuration de l'agent ECS<\/a><\/noindex>.<\/p>\n

<\/p>\n

Un des param\u00e8tres de configuration les plus importants dans le cadre de cet article est ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Si ce param\u00e8tre est activ\u00e9, d\u00e8s qu'ECS re\u00e7oit le signal qu'une instance spot est retir\u00e9e, il change le statut de toutes les t\u00e2ches qui fonctionnent dessus \u00e0 Draining. Aucune nouvelle t\u00e2che ne sera affect\u00e9e \u00e0 cette instance ; si des t\u00e2ches souhaitent imm\u00e9diatement \u00eatre d\u00e9ploy\u00e9es sur celle-ci, elles seront annul\u00e9es. Les requ\u00eates du r\u00e9partiteur de charge cessent \u00e9galement d'arriver. La notification de suppression de l'instance arrive 2 minutes avant l'\u00e9v\u00e9nement r\u00e9el. Donc, si votre service n'ex\u00e9cute pas des t\u00e2ches pendant plus de 2 minutes et ne sauvegarde rien sur le disque, vous pouvez utiliser des instances spot sans perte de donn\u00e9es.<\/p>\n

<\/p>\n

Concernant le disque \u2014 AWS a r\u00e9cemment rendu<\/a><\/noindex> possible l'utilisation du Elastic File System (EFS) avec ECS, avec ce sch\u00e9ma m\u00eame le disque ne repr\u00e9sente pas un obstacle, mais nous ne l'avons pas essay\u00e9, car en principe, nous n'avons pas besoin de disque pour stocker l'\u00e9tat. Par d\u00e9faut, apr\u00e8s avoir re\u00e7u un SIGINT (envoy\u00e9 au moment du changement de statut de la t\u00e2che \u00e0 Draining), toutes les t\u00e2ches en cours seront arr\u00eat\u00e9es apr\u00e8s 30 secondes, m\u00eame si elles n'ont pas eu le temps de s'ex\u00e9cuter ; ce temps peut \u00eatre modifi\u00e9 avec le param\u00e8tre ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. L'essentiel est de ne pas le r\u00e9gler \u00e0 plus de 2 minutes pour les machines spot.<\/p>\n

<\/p>\n

Cr\u00e9ation du service<\/h2>\n

<\/p>\n

Passons directement \u00e0 la cr\u00e9ation du service d\u00e9crit. Au cours du processus, je vais d\u00e9crire quelques points utiles suppl\u00e9mentaires qui n'ont pas \u00e9t\u00e9 abord\u00e9s pr\u00e9c\u00e9demment. Dans l'ensemble, il s'agit d'un guide \u00e9tape par \u00e9tape, mais je ne vais pas aborder des cas tr\u00e8s basiques ou tr\u00e8s sp\u00e9cifiques. Toutes les actions s'effectuent dans la console visuelle AWS, mais elles peuvent \u00eatre reproduites de mani\u00e8re programmatique avec CloudFormation ou Terraform. Chez Adapty, nous utilisons Terraform.<\/p>\n

<\/p>\n

Template de lancement EC2<\/strong><\/h3>\n

<\/p>\n

Dans ce service, une configuration des machines qui seront utilis\u00e9es est cr\u00e9\u00e9e. La gestion des mod\u00e8les se d\u00e9roule dans la section EC2 -> Instances -> Templates de lancement.<\/p>\n

<\/p>\n

Image machine Amazon (AMI)<\/strong> \u2014 nous indiquons l'image de disque avec laquelle toutes les instances seront lanc\u00e9es. Pour ECS, dans la plupart des cas, il est conseill\u00e9 d'utiliser l'image optimis\u00e9e par Amazon. Elle est r\u00e9guli\u00e8rement mise \u00e0 jour et contient tout le n\u00e9cessaire pour le fonctionnement d'ECS. Pour conna\u00eetre l'ID de l'image actuel, nous visitons la page Images AMI optimis\u00e9es pour Amazon ECS<\/a><\/noindex>, choisissons la r\u00e9gion utilis\u00e9e et copions l'ID AMI pour celle-ci. Par exemple, pour la r\u00e9gion us-east-1, l'ID actuel au moment de la r\u00e9daction de cet article est ami-00c7c1cf5bdc913ed<\/em>. Cet ID doit \u00eatre ins\u00e9r\u00e9 dans le champ Sp\u00e9cifier une valeur personnalis\u00e9e.<\/p>\n

<\/p>\n

Type d'instance<\/strong> \u2014 indiquez le type d'instance. Choisissez celui qui convient le mieux \u00e0 votre t\u00e2che.<\/p>\n

<\/p>\n

Cl\u00e9 de paire (connexion)<\/strong> \u2014 indiquez le certificat permettant de se connecter \u00e0 l'instance via SSH, si n\u00e9cessaire.<\/p>\n

<\/p>\n

Param\u00e8tres r\u00e9seau<\/strong> \u2014 indiquez les param\u00e8tres de r\u00e9seau. Plateforme r\u00e9seau<\/strong> dans la plupart des cas, cela devrait \u00eatre un Virtual Private Cloud (VPC). Groupes de s\u00e9curit\u00e9<\/strong> \u2014 groupes de s\u00e9curit\u00e9 pour vos instances. Comme nous allons utiliser un \u00e9quilibreur de charge devant les instances, je recommande d'indiquer ici un groupe qui autorise les connexions entrantes uniquement depuis l'\u00e9quilibreur de charge. Cela signifie que vous aurez 2 groupes de s\u00e9curit\u00e9, un pour l'\u00e9quilibreur de charge qui autorise les connexions entrantes (inbound) de partout sur les ports 80 (http) et 443 (https), et un deuxi\u00e8me pour les machines, qui autorise les connexions entrantes sur n'importe quel port depuis le groupe de l'\u00e9quilibreur de charge. Les connexions sortantes (outbound) dans les deux groupes doivent \u00eatre ouvertes selon le protocole TCP sur tous les ports vers toutes les adresses. Il est possible de restreindre les ports et adresses pour les connexions sortantes, mais il faudra alors surveiller en permanence que vous ne tentez pas d'acc\u00e9der \u00e0 un port ferm\u00e9.<\/p>\n

<\/p>\n

Stockage (volumes)<\/strong> \u2014 indiquez les param\u00e8tres des disques pour les machines. Le volume du disque ne peut pas \u00eatre inf\u00e9rieur \u00e0 celui sp\u00e9cifi\u00e9 dans l'AMI, pour ECS Optimized \u2014 30 GiB.<\/p>\n

<\/p>\n

D\u00e9tails avanc\u00e9s<\/strong> \u2014 indiquez des param\u00e8tres suppl\u00e9mentaires.<\/p>\n

<\/p>\n

Option d'achat<\/strong> \u2014 voulons-nous acheter des instances spot. Nous voulons, mais nous ne cocherons pas cette case ici, nous le configurerons dans le groupe d'auto-scaling, o\u00f9 il y a plus d'options.<\/p>\n

<\/p>\n

Profil d'instance IAM<\/strong> \u2014 indiquez le r\u00f4le sous lequel les instances seront lanc\u00e9es. Pour que les instances fonctionnent dans ECS, elles ont besoin de droits qui sont g\u00e9n\u00e9ralement associ\u00e9s au r\u00f4le ecsInstanceRole<\/em>. Dans certains cas, celui-ci peut \u00eatre cr\u00e9\u00e9, s'il n'existe pas, alors ici l'instruction<\/a><\/noindex> des instructions sur la fa\u00e7on de le faire. Apr\u00e8s sa cr\u00e9ation, nous l'indiquerons dans le mod\u00e8le.
\nEnsuite, il y a beaucoup de param\u00e8tres, dans l'ensemble, il est possible de laisser les valeurs par d\u00e9faut, mais chacun d'eux poss\u00e8de une description claire. J'active toujours les param\u00e8tres d'instance optimis\u00e9e EBS et T2\/T3 Unlimited, si des instances burstable.<\/a><\/noindex> Donn\u00e9es utilisateur<\/p>\n

<\/p>\n

Donn\u00e9es utilisateur<\/strong> \u2014 indiquez les donn\u00e9es utilisateur. Nous allons modifier le fichier \/etc\/ecs\/ecs.config<\/code>, qui contient la configuration de l'agent ECS.
\nVoici un exemple de ce \u00e0 quoi pourraient ressembler les donn\u00e9es utilisateur :<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 ce param\u00e8tre indique que l'instance appartient \u00e0 un cluster avec le nom sp\u00e9cifi\u00e9, c'est-\u00e0-dire que ce cluster pourra ex\u00e9cuter ses t\u00e2ches sur ce serveur. Nous n'avons pas encore cr\u00e9\u00e9 de cluster, mais lors de sa cr\u00e9ation, nous utiliserons ce nom.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 ce param\u00e8tre indique que lors de la r\u00e9ception d'un signal d'arr\u00eat d'une instance spot, toutes les t\u00e2ches sur celle-ci doivent passer au statut Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 ce param\u00e8tre indique qu'apr\u00e8s r\u00e9ception du signal SIGINT, toutes les t\u00e2ches ont 1 minute avant d'\u00eatre arr\u00eat\u00e9es.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 ce param\u00e8tre indique que le m\u00e9canisme d'authentification utilise le sch\u00e9ma docker.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 param\u00e8tres de connexion \u00e0 un registre de conteneur priv\u00e9, o\u00f9 sont stock\u00e9es vos images Docker. S'il est public, il n'est pas n\u00e9cessaire d'indiquer quoi que ce soit.<\/p>\n
<\/p>\n
Dans cet article, j'utiliserai une image publique de Docker Hub, donc il n'est pas n\u00e9cessaire d'indiquer les param\u00e8tres. ECS_ENGINE_AUTH_TYPE<\/code> et ECS_ENGINE_AUTH_DATA<\/code> aucun besoin.<\/p>\n
<\/p>\n
Bon \u00e0 savoir<\/strong>: il est recommand\u00e9 de mettre \u00e0 jour r\u00e9guli\u00e8rement l'AMI, car dans les nouvelles versions, les versions de Docker, Linux, de l'agent ECS, etc. sont mises \u00e0 jour. Pour ne pas l'oublier, vous pouvez configurer des notifications<\/a><\/noindex> sur la sortie de nouvelles versions. Vous pouvez recevoir des notifications par email et mettre \u00e0 jour manuellement, ou vous pouvez \u00e9crire une fonction Lambda qui cr\u00e9era automatiquement une nouvelle version de la Launch Template avec l'AMI mis \u00e0 jour.<\/p>\n
<\/p>\n
Groupe de mise \u00e0 l'\u00e9chelle EC2<\/strong><\/h3>\n
<\/p>\n
Le groupe de mise \u00e0 l'\u00e9chelle est responsable du lancement et de la mise \u00e0 l'\u00e9chelle des instances. La gestion des groupes se fait dans la section EC2 -> Auto Scaling -> Groupes de mise \u00e0 l'\u00e9chelle.<\/p>\n
<\/p>\n
Template de lancement<\/strong> \u2014 on choisit le mod\u00e8le cr\u00e9\u00e9 lors de l'\u00e9tape pr\u00e9c\u00e9dente. Nous laissons la version par d\u00e9faut.<\/p>\n
<\/p>\n
Options d'achat et types d'instance<\/strong> \u2014 on sp\u00e9cifie les types d'instances pour le cluster. Adhere to launch template utilise le type d'instance du mod\u00e8le de lancement. Combine purchase options and instance types permet de configurer les types d'instances de mani\u00e8re flexible. Nous allons l'utiliser.<\/p>\n
<\/p>\n
Base on-demand optionnelle<\/strong> \u2014 le nombre d'instances normales, non-spot, qui seront toujours en cours d'ex\u00e9cution.<\/p>\n
<\/p>\n
Pourcentage on-demand au-dessus de la base<\/strong> \u2014 le rapport entre les instances normales et spot, 50-50 les r\u00e9partit \u00e9galement, 20-80 signifiera qu'il y aura 4 instances spot pour chaque instance normale. Dans cet exemple, je vais sp\u00e9cifier 50-50, mais dans la r\u00e9alit\u00e9, nous faisons souvent 20-80, et parfois 0-100.<\/p>\n
<\/p>\n
Types d'instance<\/strong> \u2014 ici, vous pouvez sp\u00e9cifier des types suppl\u00e9mentaires d'instances qui seront utilis\u00e9s dans le cluster. Nous ne l'avons jamais utilis\u00e9, car je ne comprends pas tr\u00e8s bien le sens de cette histoire. Peut-\u00eatre est-ce li\u00e9 aux limites sur des types sp\u00e9cifiques d'instances, mais elles peuvent \u00eatre facilement augment\u00e9es gr\u00e2ce au support. Si vous connaissez une application, je serais ravi de lire vos commentaires)<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
R\u00e9seau<\/strong> \u2014 param\u00e8tres r\u00e9seau, vous choisissez le VPC et les sous-r\u00e9seaux pour les machines, dans la plupart des cas, il convient de choisir tous les sous-r\u00e9seaux disponibles.<\/p>\n
<\/p>\n
\u00c9quilibrage de charge<\/strong> \u2014 param\u00e8tres de l'\u00e9quilibreur, mais nous le ferons s\u00e9par\u00e9ment, ici nous ne touchons \u00e0 rien. Contr\u00f4les de sant\u00e9<\/strong> seront \u00e9galement configur\u00e9s plus tard.<\/p>\n
<\/p>\n
Taille du groupe<\/strong> \u2014 nous sp\u00e9cifions les limites pour le nombre de machines dans le cluster et le nombre souhait\u00e9 de machines au d\u00e9marrage. Le nombre de machines dans le cluster ne sera jamais inf\u00e9rieur au minimum sp\u00e9cifi\u00e9 ni sup\u00e9rieur au maximum, m\u00eame si les m\u00e9triques indiquent qu'une mise \u00e0 l'\u00e9chelle devrait se produire.<\/p>\n
<\/p>\n
Politiques de mise \u00e0 l'\u00e9chelle<\/strong> \u2014 param\u00e8tres de mise \u00e0 l'\u00e9chelle, mais nous allons nous baser sur les t\u00e2ches ECS en cours, donc nous configurerons la mise \u00e0 l'\u00e9chelle plus tard.<\/p>\n
<\/p>\n
Protection contre la r\u00e9duction d'instance<\/strong> \u2014 protection des instances contre la suppression lors de la mise \u00e0 l'\u00e9chelle vers le bas. Nous l'activons pour que l'ASG ne supprime pas la machine sur laquelle des t\u00e2ches fonctionnent. La protection pour les instances sans t\u00e2ches sera d\u00e9sactiv\u00e9e par le fournisseur de capacit\u00e9 ECS.<\/p>\n
<\/p>\n
Ajouter des balises<\/strong> \u2014 vous pouvez sp\u00e9cifier des balises pour les instances (pour cela, la case \u00e0 cocher Tag new instances doit \u00eatre activ\u00e9e). Je recommande d'indiquer la balise Name, alors toutes les instances lanc\u00e9es dans le groupe auront le m\u00eame nom, ce qui les rendra faciles \u00e0 visualiser dans la console.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Apr\u00e8s la cr\u00e9ation du groupe, ouvrez-le et allez dans la section Configurations avanc\u00e9es, car lors de la cr\u00e9ation, toutes les options ne sont pas visibles dans la console.<\/p>\n
<\/p>\n
Politiques de termination<\/strong> \u2014 r\u00e8gles pris en compte lors de la suppression d'instances. Elles s'appliquent dans l'ordre. Nous utilisons g\u00e9n\u00e9ralement celles montr\u00e9es sur l'image ci-dessous. D'abord, les instances avec le mod\u00e8le de lancement le plus ancien sont supprim\u00e9es (par exemple, si nous avons mis \u00e0 jour l'AMI, une nouvelle version a \u00e9t\u00e9 cr\u00e9\u00e9e, mais toutes les instances ont r\u00e9ussi \u00e0 y passer). Ensuite, les instances les plus proches du prochain moment de facturation sont choisies. Puis, les plus anciennes en date de lancement sont s\u00e9lectionn\u00e9es.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Bon \u00e0 savoir<\/strong>: pour la mise \u00e0 jour de toutes les machines dans le cluster, il est pratique d'utiliser Actualisation des instances<\/a><\/noindex>. Si vous combinez cela avec une fonction Lambda de l'\u00e9tape pr\u00e9c\u00e9dente, vous disposerez d'un syst\u00e8me de mise \u00e0 jour des instances enti\u00e8rement automatis\u00e9. Avant de mettre \u00e0 jour toutes les machines, il est n\u00e9cessaire de d\u00e9sactiver la protection contre la r\u00e9duction de l'\u00e9chelle des instances pour toutes les instances du groupe. Ce n'est pas la configuration du groupe, mais plut\u00f4t la protection des machines elles-m\u00eames, qui se fait dans l'onglet Gestion des instances.<\/p>\n
<\/p>\n
Application Load Balancer et EC2 Target Group<\/h3>\n
<\/p>\n
Le r\u00e9partiteur est cr\u00e9\u00e9 dans la section EC2 \u2192 Load Balancing \u2192 Load Balancers. Nous allons utiliser un Application Load Balancer, pour comparer les diff\u00e9rents types de r\u00e9partiteurs, vous pouvez consulter la page du service<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u2014 il est logique de cr\u00e9er les ports 80 et 443, et de rediriger le port 80 vers le 443 \u00e0 l'aide de r\u00e8gles du r\u00e9partiteur.<\/p>\n
<\/p>\n
Zones de disponibilit\u00e9<\/strong> \u2014 dans la plupart des cas, nous choisissons toutes les zones de disponibilit\u00e9.<\/p>\n
<\/p>\n
Configurer les param\u00e8tres de s\u00e9curit\u00e9<\/strong> \u2014 ici, le certificat SSL pour le r\u00e9partiteur est sp\u00e9cifi\u00e9, la solution la plus pratique est de cr\u00e9er un certificat<\/a><\/noindex> dans ACM. Vous pouvez lire sur les diff\u00e9rences de Politique de s\u00e9curit\u00e9<\/strong> dans documentation<\/a><\/noindex>, vous pouvez laisser le choix par d\u00e9faut ELBSecurityPolicy-2016-08<\/code>. Apr\u00e8s la cr\u00e9ation du r\u00e9partiteur, vous verrez son nom DNS<\/strong>, pour lequel vous devez configurer un CNAME pour votre domaine. Par exemple, c'est ainsi que cela appara\u00eet dans Cloudflare.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Groupe de S\u00e9curit\u00e9<\/strong> \u2014 nous cr\u00e9ons ou choisissons un groupe de s\u00e9curit\u00e9 pour le r\u00e9partiteur, dont j'ai parl\u00e9 plus haut dans la section Mod\u00e8le de lancement EC2 \u2192 Param\u00e8tres r\u00e9seau.<\/p>\n
<\/p>\n
Groupe cible<\/strong> \u2014 nous cr\u00e9ons un groupe qui se charge de router les requ\u00eates du r\u00e9partiteur vers les machines et v\u00e9rifie leur disponibilit\u00e9 afin de remplacer en cas de probl\u00e8me. Le type de cible<\/strong> doit \u00eatre Instance, Protocole<\/strong> et Port<\/strong> tous, si vous utilisez HTTPS pour communiquer entre le r\u00e9partiteur et les instances, vous devez y t\u00e9l\u00e9charger le certificat. Dans cet exemple, nous ne le ferons pas, nous laisserons simplement le port 80.<\/p>\n
<\/p>\n
Contr\u00f4les de sant\u00e9<\/strong> \u2014 param\u00e8tres de v\u00e9rification de la disponibilit\u00e9 du service. Dans un vrai service, cela devrait \u00eatre une requ\u00eate distincte, qui impl\u00e9mente les parties importantes de la logique m\u00e9tier, dans cet exemple, je laisserai les param\u00e8tres par d\u00e9faut. Ensuite, vous pouvez choisir l'intervalle des requ\u00eates, le d\u00e9lai d'attente, les codes de r\u00e9ponses r\u00e9ussies, etc. Dans notre exemple, indiquons les codes de succ\u00e8s 200-399, car l'image Docker qui sera utilis\u00e9e renvoie le code 304.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Enregistrer les cibles<\/strong> \u2014 ici, nous s\u00e9lectionnons les machines pour le groupe, mais dans notre cas, cela sera g\u00e9r\u00e9 par ECS, donc nous passons simplement cette \u00e9tape.<\/p>\n
<\/p>\n
Bon \u00e0 savoir<\/strong>: au niveau du r\u00e9partiteur, nous pouvons activer les journaux, qui seront enregistr\u00e9s dans S3 \u00e0 un emplacement sp\u00e9cifique. au format<\/a><\/noindex>. Vous pouvez les exporter vers des services externes pour l'analyse, ou effectuer des requ\u00eates SQL directement sur les donn\u00e9es dans S3 avec Athena<\/a><\/noindex>. C'est pratique et cela fonctionne sans code suppl\u00e9mentaire. Je recommande \u00e9galement de configurer la suppression des logs du bucket S3 apr\u00e8s une p\u00e9riode de temps d\u00e9termin\u00e9e.<\/p>\n
<\/p>\n
D\u00e9finition de la t\u00e2che ECS<\/h3>\n
<\/p>\n
Lors des \u00e9tapes pr\u00e9c\u00e9dentes, nous avons cr\u00e9\u00e9 tout ce qui concerne l'infrastructure du service, maintenant nous allons d\u00e9crire les conteneurs que nous allons ex\u00e9cuter. Cela se fait dans la section ECS \u2192 D\u00e9definitions des t\u00e2ches.<\/p>\n
<\/p>\n
Compatibilit\u00e9 du type de lancement<\/strong> \u2014 nous choisissons EC2.<\/p>\n
<\/p>\n
R\u00f4le IAM d'ex\u00e9cution de la t\u00e2che<\/strong> \u2014 nous choisissons ecsTaskExecutionRole<\/code>. Il permet d'\u00e9crire des logs, d'acc\u00e9der aux variables secr\u00e8tes, etc.<\/p>\n
<\/p>\n
Dans la section D\u00e9finitions du conteneur, cliquez sur Ajouter un conteneur.<\/p>\n
<\/p>\n
Image<\/strong> \u2014 l'URL de l'image avec le code du projet, dans cet exemple je vais utiliser une image publique de Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Limites de m\u00e9moire<\/strong> \u2014 limites de m\u00e9moire pour le conteneur. Limite stricte<\/strong> \u2014 limite stricte, si le conteneur d\u00e9passe cette valeur, la commande docker kill sera ex\u00e9cut\u00e9e, le conteneur mourra imm\u00e9diatement. Limite souple<\/strong> \u2014 limite souple, le conteneur peut d\u00e9passer cette valeur, mais lors du placement des t\u00e2ches sur les machines, ce param\u00e8tre sera pris en compte. Par exemple, si une machine dispose de 4 GiB de RAM, et que la limite souple du conteneur est de 2048 MiB, alors un maximum de 2 t\u00e2ches avec ce conteneur peut \u00eatre ex\u00e9cut\u00e9 sur cette machine. En r\u00e9alit\u00e9, 4 GiB de RAM c'est l\u00e9g\u00e8rement moins que 4096 MiB, ce que vous pouvez voir dans l'onglet Instances ECS du cluster. La limite souple ne peut pas \u00eatre sup\u00e9rieure \u00e0 la limite stricte. Il est important de comprendre que si une t\u00e2che a plusieurs conteneurs, leurs limites s'additionnent.<\/p>\n
<\/p>\n
Mapping des ports<\/strong> \u2014 dans Port h\u00f4te<\/strong> nous indiquons 0, cela signifie que le port sera attribu\u00e9 dynamiquement et sera suivi par le groupe cible. Port du conteneur<\/strong> \u2014 le port sur lequel votre application fonctionne, souvent sp\u00e9cifi\u00e9 dans la commande d'ex\u00e9cution, ou attribu\u00e9 dans le code de votre application, Dockerfile, etc. Pour notre exemple, nous utilisons 3000, car il est mentionn\u00e9 dans Dockerfile<\/a><\/noindex> l'image utilis\u00e9e.<\/p>\n
<\/p>\n
V\u00e9rification de l'\u00e9tat<\/strong> \u2014 param\u00e8tres de v\u00e9rification de la disponibilit\u00e9 du conteneur, \u00e0 ne pas confondre avec celui configur\u00e9 dans le groupe cible.<\/p>\n
<\/p>\n
Environnement<\/strong> \u2014 param\u00e8tres d'environnement. Unit\u00e9s CPU<\/strong> \u2014 ressemble \u00e0 Memory limits, mais pour le processeur. Chaque c\u0153ur de processeur \u00e9quivaut \u00e0 1024 unit\u00e9s, donc si le serveur a un processeur dual-core et que le conteneur a une valeur de 512, alors quatre t\u00e2ches avec ce conteneur peuvent \u00eatre ex\u00e9cut\u00e9es sur un serveur. Les unit\u00e9s CPU correspondent toujours au nombre de c\u0153urs, il ne peut pas y en avoir un peu moins comme c'est le cas avec la m\u00e9moire.<\/p>\n
<\/p>\n
Commande<\/strong> \u2014 commande pour lancer un service \u00e0 l'int\u00e9rieur du conteneur, tous les param\u00e8tres sont indiqu\u00e9s par virgule. Cela peut \u00eatre gunicorn, npm, etc. Si non sp\u00e9cifi\u00e9, la directive CMD du Dockerfile sera utilis\u00e9e. Nous indiquons npm,start<\/code>.<\/p>\n
<\/p>\n
Variables d'environnement<\/strong> \u2014 variables d'environnement du conteneur. Cela peut \u00eatre \u00e0 la fois des donn\u00e9es textuelles simples et des variables secr\u00e8tes de Secrets Manager<\/a><\/noindex> ou Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Stockage et journalisation<\/strong> \u2014 ici nous configurerons la journalisation dans CloudWatch Logs (service de logs d'AWS). Pour cela, il suffit de cocher la case Auto-configure CloudWatch Logs. Apr\u00e8s la cr\u00e9ation de la d\u00e9finition de t\u00e2che, un groupe de logs sera automatiquement cr\u00e9\u00e9 dans CloudWatch. Par d\u00e9faut, les logs y sont conserv\u00e9s ind\u00e9finiment, je recommande de modifier la p\u00e9riode de conservation de Never Expire \u00e0 la dur\u00e9e requise. Cela se fait dans les groupes de logs CloudWatch, il faut cliquer sur la p\u00e9riode actuelle et choisir une nouvelle.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
ECS Cluster et ECS Capacity Provider<\/h3>\n
<\/p>\n
Allons dans la section ECS \u2192 Clusters pour cr\u00e9er un cluster. En tant que mod\u00e8le, choisissons EC2 Linux + Networking.<\/p>\n
<\/p>\n
Nom du cluster<\/strong> \u2014 tr\u00e8s important, donnez ici le m\u00eame nom que celui indiqu\u00e9 dans le Launch Template dans le param\u00e8tre ECS_CLUSTER<\/code>, dans notre cas \u2014 DemoApiClusterProd<\/code>. Cochez la case Create an empty cluster. Optionnellement, vous pouvez activer Container Insights pour voir les m\u00e9triques des services dans CloudWatch. Si vous avez tout fait correctement, vous verrez dans la section ECS Instances les machines qui ont \u00e9t\u00e9 cr\u00e9\u00e9es dans le groupe Auto Scaling.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Acc\u00e9dez \u00e0 l'onglet Capacity Providers<\/strong> et cr\u00e9ons un nouveau. Rappelons que cela est n\u00e9cessaire pour g\u00e9rer la cr\u00e9ation et l'arr\u00eat des machines en fonction du nombre de t\u00e2ches ECS en cours. Il est important de noter que le fournisseur ne peut \u00eatre li\u00e9 qu'\u00e0 un seul groupe.<\/p>\n
<\/p>\n
Auto Scaling group<\/strong> \u2014 choisissons le groupe cr\u00e9\u00e9 pr\u00e9c\u00e9demment.<\/p>\n
<\/p>\n
Mise \u00e0 l'\u00e9chelle g\u00e9r\u00e9e<\/strong> \u2014 activez-le pour que le fournisseur puisse mettre \u00e0 l'\u00e9chelle le service.<\/p>\n
<\/p>\n
Capacit\u00e9 cibl\u00e9e %<\/strong> \u2014 quel pourcentage d'occupation des machines par des t\u00e2ches est n\u00e9cessaire. Si vous sp\u00e9cifiez 100%, toutes les machines seront toujours occup\u00e9es par des t\u00e2ches en cours. Si vous sp\u00e9cifiez 50%, la moiti\u00e9 des machines seront toujours libres. Dans ce cas, si un pic de charge se produit, les nouvelles t\u00e2ches iront imm\u00e9diatement vers les machines libres, sans attendre le d\u00e9ploiement d'instances.<\/p>\n
<\/p>\n
Protection de terminaison g\u00e9r\u00e9e<\/strong> \u2014 si activ\u00e9, ce param\u00e8tre permet au fournisseur de supprimer la protection des instances contre la suppression. Cela se produit lorsque la machine n'a pas de t\u00e2ches actives et permet de g\u00e9rer la capacit\u00e9 cible %.<\/p>\n
<\/p>\n
Service ECS et configuration de la mise \u00e0 l'\u00e9chelle<\/h3>\n
<\/p>\n
Derni\u00e8re \u00e9tape :) Pour cr\u00e9er un service, il faut acc\u00e9der au cluster cr\u00e9\u00e9 pr\u00e9c\u00e9demment dans l'onglet Services.<\/p>\n
<\/p>\n
Type de lancement<\/strong> \u2014 il suffit de cliquer sur Passer \u00e0 la strat\u00e9gie de fournisseur de capacit\u00e9 et de s\u00e9lectionner le fournisseur cr\u00e9\u00e9 pr\u00e9c\u00e9demment.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
D\u00e9finition de la t\u00e2che<\/strong> \u2014 s\u00e9lectionnez la d\u00e9finition de t\u00e2che cr\u00e9\u00e9e pr\u00e9c\u00e9demment et sa r\u00e9vision.<\/p>\n
<\/p>\n
Nom du service<\/strong> \u2014 pour \u00e9viter toute confusion, nous indiquons toujours le m\u00eame nom que la d\u00e9finition de t\u00e2che.<\/p>\n
<\/p>\n
Type de service<\/strong> \u2014 toujours R\u00e9plica.<\/p>\n
<\/p>\n
Nombre de t\u00e2ches<\/strong> \u2014 nombre souhait\u00e9 de t\u00e2ches actives dans le service. Ce param\u00e8tre est g\u00e9r\u00e9 par la mise \u00e0 l'\u00e9chelle, mais doit quand m\u00eame \u00eatre indiqu\u00e9.<\/p>\n
<\/p>\n
Pourcentage minimum de sant\u00e9<\/strong> et Pourcentage maximum<\/strong> \u2014 d\u00e9finissent le comportement des t\u00e2ches lors du d\u00e9ploiement. Les valeurs par d\u00e9faut sont 100 et 200, ce qui signifie qu'au moment du d\u00e9ploiement, le nombre de t\u00e2ches augmentera plusieurs fois, puis retournera au souhait\u00e9. Si vous avez 1 t\u00e2che, min=0 et max=100, alors lors du d\u00e9ploiement, elle sera tu\u00e9e, et ensuite une nouvelle sera lanc\u00e9e, ce qui entra\u00eenera un temps d'arr\u00eat. Si une t\u00e2che est en cours d'ex\u00e9cution, min=50 et max=150, le d\u00e9ploiement ne se produira pas du tout, car une t\u00e2che ne peut pas \u00eatre partag\u00e9e ou augment\u00e9e par un facteur de 1,5.<\/p>\n
<\/p>\n
Type de d\u00e9ploiement<\/strong> \u2014 nous choisissons Mise \u00e0 jour progressive.<\/p>\n
<\/p>\n
Mod\u00e8les de placement<\/strong> \u2014 r\u00e8gles de placement des t\u00e2ches sur les machines. Par d\u00e9faut, la strat\u00e9gie est AZ Balanced Spread, ce qui signifie que chaque nouvelle t\u00e2che sera plac\u00e9e sur une nouvelle instance jusqu'\u00e0 ce que des machines soient cr\u00e9\u00e9es dans toutes les zones de disponibilit\u00e9. Nous pr\u00e9f\u00e9rons g\u00e9n\u00e9ralement BinPack \u2014 CPU et Spread \u2014 AZ, avec cette politique, les t\u00e2ches sont optimis\u00e9es pour occuper autant que possible une seule machine par rapport au CPU. Si une nouvelle machine doit \u00eatre cr\u00e9\u00e9e, elle est cr\u00e9\u00e9e dans une nouvelle zone de disponibilit\u00e9.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Type de charge balanc\u00e9e<\/strong> \u2014 nous choisissons le Load Balancer d'application.<\/p>\n
<\/p>\n
R\u00f4le IAM du service<\/strong> \u2014 nous choisissons ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Nom du chargeur d'\u00e9quilibre<\/strong> \u2014 nous choisissons le chargeur d'\u00e9quilibre cr\u00e9\u00e9 pr\u00e9c\u00e9demment.<\/p>\n
<\/p>\n
P\u00e9riode de gr\u00e2ce de v\u00e9rification de sant\u00e9<\/strong> \u2014 pause avant l'ex\u00e9cution des v\u00e9rifications de viabilit\u00e9 apr\u00e8s le d\u00e9ploiement d'une nouvelle t\u00e2che, nous mettons g\u00e9n\u00e9ralement 60 secondes.<\/p>\n
<\/p>\n
Conteneur \u00e0 \u00e9quilibrer<\/strong> \u2014 dans le champ Nom du groupe cible, s\u00e9lectionnez le groupe cr\u00e9\u00e9 pr\u00e9c\u00e9demment, et tout se remplira automatiquement.<\/p>\n
<\/p>\n
\"Cr\u00e9ation<\/p>\n
<\/p>\n
Mise \u00e0 l'\u00e9chelle automatique du service<\/strong> \u2014 param\u00e8tres de mise \u00e0 l'\u00e9chelle du service. Nous choisissons Configurer la mise \u00e0 l'\u00e9chelle automatique du service pour ajuster le nombre souhait\u00e9 du service. D\u00e9finissons le nombre minimum et maximum de t\u00e2ches lors de la mise \u00e0 l'\u00e9chelle.<\/p>\n
<\/p>\n
R\u00f4le IAM pour la mise \u00e0 l'\u00e9chelle automatique du service<\/strong> \u2014 nous choisissons AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Politiques de mise \u00e0 l'\u00e9chelle automatique des t\u00e2ches<\/strong> \u2014 r\u00e8gles de mise \u00e0 l'\u00e9chelle. Il existe 2 types :<\/p>\n
<\/p>\n
    \n
  1. Suivi de cible<\/strong> \u2014 suivi d'une m\u00e9trique cible (utilisation du CPU\/RAM ou nombre de requ\u00eates pour chaque t\u00e2che). Par exemple, nous souhaitons que la charge moyenne du processeur soit de 85 %, lorsqu'elle d\u00e9passe ce seuil, de nouvelles t\u00e2ches seront ajout\u00e9es jusqu'\u00e0 ce qu'elle atteigne la valeur cible. Si la charge est inf\u00e9rieure, les t\u00e2ches seront r\u00e9duites, sauf si la protection contre la mise \u00e0 l\u2019\u00e9chelle descendante est activ\u00e9e (D\u00e9sactiver la mise \u00e0 l'\u00e9chelle descendante<\/strong>).<\/li>\n
  2. Mise \u00e0 l'\u00e9chelle par \u00e9tape<\/strong> \u2014 r\u00e9action \u00e0 un \u00e9v\u00e9nement arbitraire. Ici, il est possible de configurer la r\u00e9ponse \u00e0 tout \u00e9v\u00e9nement (Alarme CloudWatch) lorsqu'il se produit, vous pouvez ajouter ou retirer un certain nombre de t\u00e2ches, ou indiquer un nombre exact de t\u00e2ches.<\/li>\n<\/ol>\n
    <\/p>\n
    Le service peut avoir plusieurs r\u00e8gles de mise \u00e0 l'\u00e9chelle, ce qui peut \u00eatre utile, il est important de s'assurer qu'elles ne se contredisent pas.<\/p>\n
    <\/p>\n
    Conclusion<\/h2>\n
    <\/p>\n
    Si vous avez suivi les instructions et utilis\u00e9 la m\u00eame image Docker, votre service devrait renvoyer cette page.<\/p>\n
    <\/p>\n
    \"Cr\u00e9ation<\/p>\n
    <\/p>\n
      \n
    1. Nous avons cr\u00e9\u00e9 un mod\u00e8le selon lequel toutes les machines dans le service sont lanc\u00e9es. Nous avons \u00e9galement appris \u00e0 mettre \u00e0 jour les machines lors de la modification du mod\u00e8le.<\/li>\n
    2. Nous avons configur\u00e9 le traitement du signal d'arr\u00eat d'une instance spot, donc dans la minute suivant sa r\u00e9ception, toutes les t\u00e2ches en cours sont supprim\u00e9es de la machine, ainsi rien n'est perdu et aucune interruption ne se produit.<\/li>\n
    3. Nous avons mis en place un \u00e9quilibreur pour r\u00e9partir uniform\u00e9ment la charge entre les machines.<\/li>\n
    4. Nous avons cr\u00e9\u00e9 un service qui fonctionne sur des instances spot, ce qui r\u00e9duit les co\u00fbts des machines d'environ 3 fois.<\/li>\n
    5. Nous avons configur\u00e9 l'auto-scaling dans les deux sens, afin de g\u00e9rer l'augmentation des charges, tout en \u00e9vitant de payer pour des temps d'inactivit\u00e9.<\/li>\n
    6. Nous utilisons le Capacity Provider pour que l'application g\u00e8re l'infrastructure (machines), et non l'inverse.<\/li>\n
    7. Nous avons bien travaill\u00e9.<\/li>\n<\/ol>\n
      <\/p>\n
      Si vous avez des pics de charge pr\u00e9visibles, par exemple, si vous faites de la publicit\u00e9 dans une grande campagne email, vous pouvez configurer la mise \u00e0 l'\u00e9chelle selon un calendrier<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Il est \u00e9galement possible de faire de la mise \u00e0 l'\u00e9chelle bas\u00e9e sur des donn\u00e9es provenant de diff\u00e9rentes parties de votre syst\u00e8me. Par exemple, nous avons une fonctionnalit\u00e9 d'envoi d'offres promotionnelles personnalis\u00e9es<\/a><\/noindex> aux utilisateurs de l'application mobile. Parfois, une campagne est envoy\u00e9e \u00e0 plus de 1 million de personnes. Apr\u00e8s un tel envoi, nous constatons toujours une forte augmentation des requ\u00eates \u00e0 l'API, car de nombreux utilisateurs se connectent simultan\u00e9ment \u00e0 l'application. Donc, si nous voyons que la file d'attente pour l'envoi de notifications promotionnelles a augment\u00e9 de mani\u00e8re significative par rapport aux indicateurs standards, nous pouvons imm\u00e9diatement lancer plusieurs machines suppl\u00e9mentaires et t\u00e2ches pour \u00eatre pr\u00eats \u00e0 faire face \u00e0 la charge.<\/p>\n
      <\/p>\n
      Je serais ravi si vous partagiez dans les commentaires des cas int\u00e9ressants d'utilisation des instances spot et de l'ECS, ou des \u00e9l\u00e9ments sur le dimensionnement.<\/p>\n
      <\/p>\n
      Bient\u00f4t, nous publierons des articles sur comment nous traitons des milliers d'\u00e9v\u00e9nements analytiques par seconde sur une architecture majoritairement serverless (avec des fonds) et sur la mani\u00e8re dont nous d\u00e9ployons des services \u00e0 l'aide de GitLab CI et Terraform Cloud.<\/p>\n
      <\/p>\n
      Suivez-nous, ce sera int\u00e9ressant !<\/p>\n
      Seuls les utilisateurs enregistr\u00e9s peuvent participer au sondage. Connectez-vous<\/a><\/noindex>, s'il vous pla\u00eet.<\/p>\n
      Utilisez-vous des instances spot en production ?<\/h2>\n