Comment éviter les câlins de la mort sur l'instance EC2?

J'ai une application iOS sur l'App Store et récemment, j'ai reçu une énorme augmentation du trafic vers ma page de destination hébergée sur EC2 et j'ai eu pour résultat que la page ne répondait pas, heureusement j'ai réussi à la récupérer en redémarrant et en mettant à niveau l'instance vers un t2.medium.

Maintenant, je cherche à embaucher quelqu'un pour mettre en œuvre une technologie pour éviter à nouveau la même mort. Mon expérience ne s'étend que jusque-là, ce qui me permet de comprendre les choses de base sur les devops mais pas assez pour l'équilibreur de charge sur AWS, je veux savoir ce qu'est une implémentation abordable pour mon instance.

Ma page de destination et le backend de l'application iOS sont hébergés sur la même instance.

Si vous voulez quelque chose de rapide pour obtenir ce tri sans beaucoup plus de connaissances, je recommanderais le haricot élastique. Il s'agit d'une autre application AWS qui gérera pour vous la configuration de l'équilibreur de charge et la mise à l'échelle des instances.

Il n'y a pas de coût supplémentaire en plus de l'équilibreur de charge et des instances, vous pouvez donc continuer à utiliser des instances de type t2 mais laissez le beanstalk élastique évoluer autant que vous le souhaitez.

La mise à l'échelle automatique n'est pas instantanée et en période de pic de trafic, il faudra un peu de temps, des minutes normalement, pour pouvoir gérer une pointe, mais ce sera beaucoup mieux que la mise à l'échelle manuelle de la taille de l'instance et il est vraiment facile d'accéder aux poignées avec.

Je recommanderais la mise à l'échelle automatique comme mentionné ci-dessus avec l'ajout de certaines alarmes CloudWatch pour démarrer le processus de mise à l'échelle automatique lorsque des seuils spécifiques commencent à augmenter, pas quand c'est déjà trop loin.

Par exemple; configurez CloudWatch pour surveiller votre serveur, lorsque le processeur est à 50% ou plus pendant une période de 30 secondes ou plus, démarrez le processus de mise à l'échelle automatique.

Cela peut ne pas être complètement sans défaut, mais c'est facile à faire via certains guides en ligne et tous configurables via l'interface graphique.

De plus, si votre page de destination est statique, pourquoi ne pas l'héberger sur un t2.micro de niveau gratuit et utiliser un autre niveau gratuit de t2.micro pour votre application?

J'aimerais vous aider si vous cherchez de l'aide. En fonction de votre page, vous n'aurez peut-être pas du tout besoin d'ec2. Par exemple, si vous proposez quelque chose de statique ou de JavaScript, il peut être servi à partir de s3 avec une distribution cloudfront. Ou nous pourrions éventuellement utiliser un groupe de mise à l'échelle automatique si cela est absolument nécessaire.

Il existe deux stratégies générales pour faire face aux pics de trafic: augmenter la capacité et réduire les coûts.

L'augmentation de la capacité signifie une mise à l'échelle automatique, dont tout le monde était très excité lorsque les clouds publics sont devenus disponibles. Dans son sens le plus élémentaire, cela démarrera plus de serveurs Web pour vous en fonction de la charge et les ajoutera à un équilibreur de charge, mais comme cela peut être difficile à gérer, il existe également des solutions plus automatisées, comme Elastic Beanstalk.

Le problème avec l'extension de capacité automatisée est que son extension de facture est également automatisée - 10x trafic normal signifie 10x serveurs signifie 10x argent que vous devez payer. C'est pourquoi, même si c'est une stratégie utile à garder à l'esprit, je pense que vous devriez toujours commencer par voir combien vous pouvez tricher.

Par triche, je veux dire cache, qui repose sur l'idée que la plupart du temps, vous pouvez donner aux utilisateurs des données légèrement obsolètes et qu'ils ne le remarqueront pas, ce qui peut vous faire gagner énormément de temps. Imaginez que vous avez une page que vous décidez qu'elle est correcte si elle est obsolète de cinq secondes et qu'elle obtient 20 requêtes / s. Sans mise en cache, vous exécutez ce calcul 1200 fois par minute, alors qu'avec la mise en cache, il n'est que de 12. Vous pouvez voir comment cela peut faire une énorme différence.

Il existe bien sûr de nombreux types de mise en cache et un site Web performant en utilisera plusieurs. Mais pour votre cas d'utilisation, il existe deux options assez bonnes et faciles.

La première consiste à rendre le site complètement statique. Cela suppose que vous pouvez le faire, mais si vous le pouvez, alors vous avez juste Nginx servir directement le html, et il peut servir des tonnes de demandes sans sueur.

Si vous avez besoin d'un certain niveau de dynamicité, la mise en cache pleine page est une bonne option. Nginx a une certaine capacité pour le faire, mais j'aime vraiment Varnish en raison de sa flexibilité.

Quelle que soit l'option ou les options que vous choisissez, assurez-vous d'effectuer des tests de charge pour valider que vous l'avez configuré correctement; parfois, la fixation d'un point expose un nouveau goulot d'étranglement.

Je voudrais partager notre expérience avec AWS. Nous avons déployé notre application sur EC2 et sommes confrontés au même problème et également à un coût élevé. Nous avons déployé notre application Amazon EC2 Container Service bien que notre application soit monolithique, mais nous avons atteint

• Disponibilité
• Rentable
• Évolutivité

L'équilibreur de charge d'application gère le trafic et achemine le trafic vers l'instance saine et vous pouvez exécuter plusieurs tâches des mêmes services sans vous soucier de la mise à l'échelle et de l'équilibrage de la charge.

Cette architecture facilite la mise en œuvre de l'isolement des défaillances. Des techniques telles que la vérification de l'état, la mise en cache, les cloisons ou les disjoncteurs vous permettent de réduire le rayon de souffle d'un composant défaillant et d'améliorer la disponibilité globale d'une application donnée.

Cela dépend beaucoup de l'architecture spécifique, mais par exemple:

• Chargez votre site Web avec CloudFront pour réduire la charge sur l'hôte
• Utilisez le service d'hébergement côté client dans quelque chose comme S3 pour l'évolutivité
• Elastic Load Balancer avec un groupe de mise à l'échelle automatique