Comparaison d'instances cloud

Le même gabarit sur trois clouds, et pourquoi ce n'est pas la même affaire

Choisir une instance de base commence en général par un gabarit — tant de vCPU, tant de mémoire — et se termine sur le nom le moins cher au-dessus de ce plancher dans la liste du fournisseur. Cet outil fait cette recherche simultanément sur AWS RDS, Google Cloud SQL et Azure Flexible Server, et ajoute le chiffre que ces listes omettent : combien de connexions chacun vous laissera réellement ouvrir.

Comment ça marche

• Prend un minimum de vCPU et un minimum de mémoire et trouve, par cloud, la plus petite instance satisfaisant les deux.
• Affiche deux options plus grandes à côté, pour voir ce que coûte le palier suivant en ressources.
• Indique la limite de connexions de chaque instance à côté de son gabarit, calculée selon la règle du fournisseur.
• Marque explicitement la plus petite correspondance, car la première ligne d'un tableau fournisseur est rarement celle qu'on veut.

plus petite correspondance = minimum des instances ou
    vcpu >= votre_minimum  ET  memoire >= votre_minimum
  triees par vcpu, puis par memoire

les connexions viennent de la regle publiee par chaque
fournisseur, pas d'un standard commun au secteur

Exemple chiffré

Un service exigeant au moins 8 vCPU et 32 Gio, chiffré sur les trois clouds.

1. AWS : db.m5.2xlarge — 8 vCPU, 32 Gio, environ 3 324 connexions
2. Azure : B8ms — 8 vCPU, 32 Gio, 3 437 connexions
3. Google Cloud SQL : db-custom-8-53248 — 8 vCPU, 52 Gio, 600 connexions
4. les gabarits coïncident presque sur deux clouds ; les limites de connexions pas du tout

AWS et Azure aboutissent à un matériel pratiquement identique avec un plafond de connexions pratiquement identique. Cloud SQL vous donne 20 Gio de mémoire en plus et environ un cinquième des connexions. Si votre service est gourmand en connexions plutôt qu'en mémoire, la décision est déjà prise.

Lire le résultat

• Cloud SQL accepte des gabarits personnalisés arbitraires : la plus petite correspondance affichée pour Google est donc la plus petite de ce catalogue, pas la plus petite existante. Un gabarit à exactement 8 vCPU et 32 Gio y est disponible ; la colonne le signale, et le chiffre Google doit se lire comme un échantillon.
• La plus petite correspondance est parfois burstable, et burstable n'équivaut pas. La série B d'Azure et la classe t d'AWS accumulent des crédits CPU au repos puis bridant une fois les crédits épuisés — acceptable pour une base de développement ou un outil interne irrégulier, médiocre pour toute charge de fond soutenue.
• Les nombres de vCPU ne se comparent pas d'un cloud à l'autre sans précaution. Les instances AWS Graviton comptent des cœurs physiques quand les classes x86 comptent des hyperthreads : 8 vCPU Graviton et 8 vCPU x86 ne sont pas la même puissance. Comparez avec confiance au sein d'un cloud, grossièrement entre clouds.
• On compare ici gabarit et plafond de connexions, pas le prix. Capacité réservée, remises d'engagement et plans d'économies déplacent le coût réel d'un facteur important, et différemment selon le cloud : une comparaison de gabarits amorce une décision, elle ne la conclut pas.
• Pour la plupart des bases, la mémoire compte plus que les vCPU : elle détermine à la fois le cache qui évite le disque et, chez AWS et Azure, le plafond de connexions lui-même. Dans le doute sur le plancher à relever, relevez la mémoire.

Questions fréquentes

Pourquoi Google affiche-t-il plus de mémoire que demandé ?

Parce que le catalogue échantillonne les gabarits Cloud SQL courants au lieu de tous les énumérer, et que le gabarit échantillonné le plus proche au-dessus de votre plancher peut le dépasser. Cloud SQL prend en charge les gabarits personnalisés : vous pouvez généralement demander la mémoire exacte souhaitée — la colonne Google est indicative.

La plus petite correspondance est-elle toujours le bon choix ?

C'est la moins chère au-dessus de votre plancher, ce qui n'est juste que si le plancher l'est. Fixez-le à partir de l'usage mesuré plus une marge pour la croissance et le basculement, pas du pic actuel : une instance calibrée exactement sur le pic d'aujourd'hui n'a pas de place pour celui de demain.

Pourquoi les limites de connexions diffèrent-elles autant à mémoire égale ?

Parce qu'elles procèdent de règles différentes avec des intentions différentes. AWS et Azure dérivent la limite de la mémoire et arrivent dans la même plage. Google la fixe par paliers de mémoire à des valeurs bien plus basses, en supposant qu'une charge à nombreuses connexions passe par un pooler. Aucune des trois n'a tort ; elles s'appliquent différemment, et c'est ce qui vous concerne.