Tarification d'Amazon sur les incohérences des instances ponctuelles

C'est quelque chose qui sera mieux expliqué par des captures d'écran d'un tableau historique des prix des instances.

Si vous regardez une grande partie des prix des instances pour les instances ponctuelles, vous remarquerez des modèles réguliers de pointes. Vois ici:

Comme vous pouvez le voir, le prix de cette instance de calcul moyen augmente régulièrement au-dessus du prix à la demande .

Une c1.mediuminstance (sur demande) ne coûterait que de l' $0.186heure. Mais pendant quelques semaines, dans la zone B, le prix atteindrait régulièrement 1,20 $. C'est environ 6 fois le prix réel sur demande.

Ce n'est pas non plus isolé. Si vous examinez à nouveau la zone-b pour les petites instances, il y a un pic similaire fréquemment. Ce qui va 4x le prix à la demande.

Est-ce que quelqu'un sait pourquoi cela se produit?

Voici quelques suggestions

• Quelqu'un a entré 1,2 $ au lieu de 0,12 $ (je remettrais cela car cela s'est produit 20 fois en l'espace de 3 semaines).

• Amazon gonfle régulièrement artificiellement ses prix en enchérissant sur ses propres instances pour en avoir le plus pour son argent. (Je remettrais cela en cause car ce serait ridicule et de mauvaises affaires)

• Une entreprise a lancé 1000 serveurs à la fois et veut s'assurer qu'ils démarrent tous. (Je remettrais cela en question car ils les lanceraient vraisemblablement à un prix qui serait inférieur au prix minimum à la demande. Pourquoi paieriez-vous plus cher à la demande pour un seul serveur?).

• C'est un bug dans leur rapport?

Il y a un article rédigé par des gens de l'Institut israélien de technologie qui analyse le marché au comptant. Leur conclusion est que les prix au comptant ne sont pas induits par les enchères mais plutôt générés avec la fonction AR (1). Donc, dans ce cas, cela ne serait pas dû aux offres des autres, mais à l'algorithme utilisé.

http://www.cs.technion.ac.il/~ladypine/spotprice-ieee.pdf

Cependant, je suppose que cela aurait pu changer si le marché au comptant avait vraiment atteint le niveau où ils pouvaient obtenir de bons prix de la demande / offre. Comme Matt le suggère, il est devenu courant de réduire les coûts avec des instances ponctuelles et de nombreux surenchérir sur les prix à la demande pour éviter les temps d'arrêt. À plus long terme, c'était toujours rentable ... mais l'est-il toujours? Le vrai problème est qu'en dehors d'Amazon, personne ne sait vraiment comment les prix sont créés.

Ce n'est pas un bogue, c'est un problème de priorité / disponibilité car les instances à la demande ont priorité sur les instances ponctuelles, quelles que soient les offres ponctuelles. Cela découle de la déclaration d'Amazon EC2 selon laquelle vous " enchérissez sur des instances Amazon EC2 de rechange ".

Ainsi, lorsque la demande d'instances à la demande augmente, il y a moins de pièces de rechange disponibles, et la disponibilité des instances ponctuelles diminue, ce qui fait augmenter les prix au comptant en fonction des offres spot concurrentes.

De nombreux soumissionnaires au comptant n'ont pas compris la priorité plus élevée des instances à la demande et ont soumissionné au-dessus de la tarification à la demande dans le but d'obtenir la priorité sur les demandes d'instance à la demande, mais cela échoue parce que les instances à la demande ont une priorité plus élevée indépendamment de prix de vente au comptant.

En retour, ces offres de tarification au-dessus de la demande se font concurrence, entraînant les prix les plus élevés plusieurs fois plus élevés que la tarification à la demande lorsque la disponibilité des instances ponctuelles est faible.

Bien que les questions suivantes n'aient pas été posées, mes recommandations pour la gestion des instances ponctuelles à moindre coût des charges de travail à long terme sont les suivantes:

1. Concevez votre application en cas d'échecs (sauvegarde / réplication continue) et récupération rapide
2. Définir le prix de l'enchère ponctuelle sur celui de la tarification à la demande
3. Lorsqu'une instance au comptant est terminée, redémarrez-la en tant qu'instance à la demande ou dans une autre région / zone où la tarification au comptant est inférieure.
4. Surveillez les prix au comptant jusqu'à ce qu'ils soient inférieurs aux prix à la demande
5. Arrêtez l'instance à la demande et passez à l'étape 2. ci-dessus

EC2 n'utilise plus le processus AR (1) artificiel pour contrôler le prix minimal. Même lorsqu'ils l'ont fait, ils n'ont modifié que le prix minimal - le processus AR (1) était ancré et n'a jamais fait dépasser les prix au-dessus du prix à la demande. De tels sauts peuvent provenir soit d'utilisateurs spécifiant des prix élevés (peut-être plus que ce qu'ils avaient réellement l'intention de payer), soit d'Amazon souhaitant fermer une partie des instances ponctuelles, comme il semble qu'ils l'aient fait pour m1.small à l'été 2010.

Vous pouvez en lire plus dans la version journal de notre article , dans la dernière section qui est plus mise à jour (la section post-mortem):

Ce n'est pas un bug dans les rapports. Parfois, les prix au comptant augmentent. Dans le passé, ils ont atteint des niveaux énormes. Depuis lors, Amazon a amélioré l'algorithme dans lequel les instances spot sont enchéries et attribuées, mais même quand même, les prix spot augmentent de temps en temps.

En septembre 2011, les prix au comptant de m2.2xlarge dans un AZ us-east-1 ont atteint 999 $ / heure.

La raison est simple: les gens spécifient des prix spot maximaux supérieurs au prix à la demande, et la demande pousse les prix aussi haut.

De nombreuses personnes utilisent des instances ponctuelles pour minimiser le coût des instances EC2 en cours d'exécution. Très souvent, ils spécifieront des prix spot maximum élevés afin de réduire les chances que leur instance spot soit surenchérie et résiliée. C'est un pari qui peut porter ses fruits à long terme, mais qui risque de devenir très cher très rapidement s'il ne fait pas attention.