Comment vérifier automatiquement les prix au comptant AWS?

J'ai pensé à un travail Jenkins pour vérifier les prix des boîtes d'agent que nous faisons tourner; de temps en temps, les pics de prix et il faudra une heure ou deux avant que quiconque ne remarque qu'aucun nouvel agent n'arrive, puis nous devons entrer manuellement et vérifier le prix au comptant et ajuster en conséquence, ou changer de zone, etc.

Mon premier réflexe était que le meilleur itinéraire est d'avoir un travail Jenkins toutes les heures qui exécute un aws ec2 describe-spot-instance-requestset vérifie les demandes ayant échoué (puis nous relâche en cas d'échec). Mais je me demande s'il existe une méthode plus propre qui implique en fait de comparer les prix durs (et pourrait donc nous dire exactement ce qui ne va pas, et de combien), plutôt que d'examiner les demandes réussies / échouées.

Quelqu'un a créé quelque chose de similaire? Comment as-tu fait ça?

Repéré un outil open source appelé autospotting qui pourrait bien aider à cela:

Une fois activé sur un groupe AutoScaling à la demande existant, il lance une instance ponctuelle EC2 qui est moins chère, au moins aussi grande et configurée de manière identique à vos instances à la demande actuelles. Dès que la nouvelle instance est prête, elle est ajoutée au groupe et une instance à la demande est détachée du groupe et arrêtée.

Nous avons cela dans notre pipeline de tâches, nous pourrons ajouter plus de contexte une fois que nous aurons terminé.

Mise à jour:

Un autre outil récemment présenté lors d'une conférence était mapbox / spotswap

Cela fonctionne légèrement différemment. Il surveille un ASG normal avec des instances à la demande ou réservées, puis, si l'échelle se produit, les offres et les dispositions repèrent les instances d'un niveau de calcul similaire sur un ASG distinct.

Je considérerais personnellement un modèle comme celui-ci:

Timed Lambdas -> Checks spot price -> Push to ElastiCache

Ensuite, lorsque vous avez besoin d'instances:

Timed lambdas -> Pulls spot price from ElastiCache, sets it as environment variable on your Machine where you spin up IaC from -> This is parsed as argument to IaC code and pushes out the spot price

Vous pouvez également définir certaines tolérances au sein des lambdas (c.-à-d. 10, 25, 50% d'augmentation en fonction de l'importance) et un plafond ferme de la demande, par exemple. C'est également un excellent endroit pour construire la logique pour gérer, par exemple, trouver le AZ le moins cher, trouver le prix au comptant ( 2xt2.mediumvs t2.large) relativement le moins cher , etc.

Permettez-moi de vous donner une façon indépendante de l'outil d'essayer de le faire.

de temps en temps les pics de prix et il faudra une heure ou deux avant que quiconque ne remarque qu'aucun nouvel agent n'arrive, puis nous devons entrer manuellement et vérifier le prix au comptant et ajuster en conséquence, ou changer de zone, etc.

Nous avons rencontré le même problème dans l'infrastructure que nous construisons. Nous avons donc eu if-elsedes blocs de style pour définir le prix de l'offre, en fonction du prix à la demande de l'instance.

AWS dispose d'une API pour obtenir le prix à la demande d'une instance. Nous avons utilisé ce wrapper Python à cet effet.

Donc, une fois que nous avons eu la sur demande prix (disons X), nous avons branché en if-elseblocs de style, qui sont 0.4*X, 0.6*X, 0.8*X, X, ce qui signifie que nous essayons pour un prix d'achat de l'ordre de 40%, 60%, 80% du sur -prix à la demande. Si tout échoue, nous retombons dans la création d'instances à la demande.

De plus, comme cela est indépendant des prix spot actuels d'AWS, nous ne payons jamais un prix supérieur au prix à la demande.

Mais, si vous cherchez un moyen de le faire à la volée, la solution de Hashfyre devrait être la voie à suivre.