Comparaison des coûts : prépayé et à la demande

graphique 3


Rescale propose plusieurs options de prix pour faire fonctionner votre Simulations HPC:À la demande, à faible priorité et prépayé. Cet article présente une analyse de l'utilisation du calcul pour déterminer quand obtenir un forfait prépayé est judicieux du point de vue du coût.

Notre plan tarifaire prépayé propose une réservation à long terme pour les cœurs Rescale au coût horaire le plus bas, en échange du paiement de toutes les heures à l'avance pour la réservation. Les cœurs prépayés sont un excellent moyen de réduire vos coûts matériels SI votre utilisation est suffisamment élevée. Dans ce qui suit, nous répondrons à 2 questions :

  • Quel doit être mon niveau d'utilisation pour un type de base particulier pour que Prepaid me fasse économiser de l'argent ?
  • Compte tenu d'un certain calendrier d'utilisation des cœurs, combien de cœurs prépayés dois-je acheter pour minimiser mes coûts totaux de matériel ?

Économies de coûts prépayés grâce à l'utilisation
La première question est calculée en résolvant cette équation :
Économies de coûts = Utilisation * Nombre total d'heures de réservation * Prix à la demande – Nombre total d'heures de réservation *

Prix ​​prépayé
L'option de prix prépayé propose deux périodes au choix. Les utilisateurs peuvent prépayer les cœurs pendant 1 an ou 3 ans. Ainsi, dans le cas de notre type de noyau Nickel populaire (qui a un coût prépayé sur 3 ans de 0.04 $/noyau/heure), le seuil de rentabilité où les économies de coûts = 0 est :

Utilisation = 0.04 $ par heure prépayée / 0.15 $ par heure sur demande =~ 27 %
Si votre utilisation moyenne d'un noyau Nickel est supérieure 27 %, Prépayé vous fera économiser de l'argent par rapport aux tarifs à la demande. Si votre utilisation moyenne sur un an est de 50%, vous économisez 482 $ par an et par cœur en utilisant l'option Prépayée sur une durée de trois ans, au lieu de l'option Sur demande.

Combien pré-payer pour une prévision de travail donnée ?
Le calcul ci-dessus est simple, mais vous n’avez peut-être pas d’objectif d’utilisation en tête. Au lieu de cela, vous pouvez disposer d'une prévision de toutes les tâches de calcul que vous envisagez d'exécuter, souvent basées sur l'utilisation historique. Comment pouvons-nous prendre un calendrier de travaux et déterminer le nombre optimal de cœurs prépayés à acheter ?
Comme précédemment, nous calculons quelque chose de similaire :

Économies prépayées (x cœurs prépayés) = coût tout à la demande – (coût prépayé (x) + coût résiduel à la demande (x))
Coût Tout à la demande correspond au nombre total d'heures de base pour toutes vos tâches au cours de la période prépayée, multiplié par le prix de base à la demande.
Coût prépayé n'est que le coût prépayé pour x cœurs.

Coût résiduel à la demande est le plus difficile à calculer. Nous devons générer les heures de base supplémentaires à la demande nécessaires, tout en maximisant l'utilisation de nos cœurs prépayés.

Pour calculer les heures de cœur résiduelles, nous devons examiner le nombre de cœurs exécutés par unité de temps, puis considérer uniquement les cœurs qui ne sont pas prépayés. Visuellement, nous regroupons les intervalles de temps d'utilisation des cœurs de bas en haut et découpons les x cœurs inférieurs en fonction des tâches dans le temps (qui utilisent des cœurs prépayés), puis calculons simplement le coût du reste.
cores_uncut
Le graphique ci-dessus ne tient pas compte du fait que les intervalles de temps principaux ne se chevauchent pas toujours entièrement ou ne sont pas toujours disjoints. Les intervalles doivent vraiment être découpés en intervalles disjoints plus petits, puis nous remplissons par le bas avec ces parties d'intervalle.
noyaux_cut
Ensuite, nous comptons simplement les cœurs pour chaque tranche de temps, les tranches manquantes n'ont implicitement aucun cœur.
cores_agrégat
Ici, nous avons entièrement couvert notre période de réservation avec des intervalles disjoints. Ensuite, nous pouvons soustraire le nombre de cœurs prépayés, par exemple si nous avons 2 cœurs prépayés, nous obtenons ces intervalles de cœurs résiduels.
cores_aggregate_prepaid
À partir de ces intervalles, nous additionnons ensuite le produit des longueurs des intervalles et du nombre de cœurs pour obtenir nos heures de cœur résiduelles.
Voyons comment effectuer cette même analyse par programme. Nos entrées sont :

  • Calendrier des tâches de calcul, qui est une liste de tuples se chevauchant partiellement (start_time, end_time, core_count)
  • Début de la période de réservation prépayée
  • Fin de la période de réservation prépayée
  • Nombre de cœurs prépayés
Def Calculate_ResiDual_Core_Hours (Core_USE_Interval start_time, end_time, max (0 , (count - prepaid_core_count))) pour start_time, end_time, count in disjoint_intervals) return sum((end_time - start_time) * count pour start_time, end_time, count in résiduel_core_intervals)

La majeure partie de la complexité ici se cache dans chop_and_aggregate. Regardons une implémentation de ceci. Nous commençons à booking_start et avançons dans le temps, en gardant une trace des intervalles actuellement ouverts. Lorsqu'un intervalle s'ouvre ou se ferme, nous créons un nouvel intervalle disjoint avec le nombre de cœurs actuel entre les 2 dernières limites temporelles.

def chop_and_aggregate(reservation_start, reservation_end, sorted_intervals) : current_time = booking_start open_intervals = Counter() close_intervals = [] pour le début, la fin, le nombre d'intervalles triés : # fermer les intervalles qui se terminent avant le début de l'intervalle suivant si open_intervals : next_end = min(open_intervals.keys ()) while start >= next_end : close_intervals.append((current_time, next_end, sum(open_intervals.values()))) del open_intervals[next_end] current_time = next_end if open_intervals : next_end = min(open_intervals.keys()) else : break # diviser les intervalles ouverts à l'heure de début du nouvel intervalle if open_intervals: close_intervals.append((current_time, start, sum(open_intervals.values()))) # ajouter un nouvel intervalle current_time = start open_intervals[end] += count # close out intervalles ouverts restants pour la fin dans trié(open_intervals.keys()) : end = min(end, booking_end) if open_intervals: close_intervals.append((current_time, end, sum(open_intervals.values()))) del open_intervals[end] retourner les intervalles_fermés

En mettant tout cela ensemble, vous pouvez multiplier les heures de base résiduelles par le prix à la demande et réaliser des économies. Vous pouvez même utiliser calculate_residual_core_hours avec zéro cœur prépayé pour obtenir (de manière inefficace) le coût tout à la demande :

all_on_demand_hours = calcul_residual_core_hours (job_intervals, réservation_start, réservation_end, 0) résiduel_on_demand_hours = calcul_residual_core_hours (job_interval _cores * prepaid_price + résiduel_on_demand_hours * on_demand_price)

À partir de là, vous pouvez effectuer une recherche binaire sur le nombre de prepaid_cores pour trouver vos économies optimales. À titre d'optimisation, les disjoint_intervals ne doivent être calculés qu'une seule fois pour tous les différents calculs de base prépayés.

Détails supplémentaires
L'explication ci-dessus est simplifiée à partir de notre véritable option prépayée :

Différents types de noyaux
Vous pouvez utiliser plusieurs types de noyaux (par exemple Marbre et Nickel) pour les tâches que vous exécutez habituellement. Dans ce cas, vous devez séparer vos tâches par type de cœur et effectuer l'analyse ci-dessus une fois pour chaque lot de type de cœur. Vous obtiendrez le nombre optimal de cœurs prépayés de chaque type. Notez que dans certaines situations, cela peut entraîner un gaspillage de capacité et pourrait finir par être plus coûteux que de fonctionner avec moins de types de cœurs, même si cela signifie que vous utilisez des cœurs plus puissants que ceux nécessaires pour une tâche particulière.

Nous prévoyons de publier prochainement un calculateur de base prépayé qui fera des recommandations basées sur votre utilisation précédente de Rescale, en effectuant l'analyse ci-dessus pour vous !

Auteur

  • Mark Whitney

    Mark Whitney est directeur de l'ingénierie chez Rescale. Ses domaines d'expertise comprennent les architectures de calcul haute performance, la recherche sur l'information quantique et le cloud computing. Il est titulaire d'un doctorat en informatique de l'Université de Californie à Berkeley.