- Google Cloud indique que Cloud Spanner peut désormais coûter moitié moins qu’Amazon DynamoDB pour la plupart des charges de travail, grâce à un débit accru jusqu’à 50 % et une capacité de stockage par nœud multipliée par 2,5, sans changement de prix
- Malgré ces améliorations, Spanner conserve une forte cohérence externe, une latence de l’ordre de quelques millisecondes, une montée en charge quasi illimitée et un SLA de disponibilité de 99,999 %
- La capacité de stockage par nœud passe de 4 To à 10 To, et les utilisateurs continuent de ne payer que pour l’espace de stockage réellement utilisé, indépendamment de la nouvelle limite
- La mise à jour est d’abord disponible sur certaines configurations d’instances régionales et multirégionales, avant d’être étendue aux autres configurations et à la montée de capacité de stockage dans les prochains mois
- Les clients bénéficient de ces améliorations au tarif actuel, sans reprovisionnement, sans interruption et sans action de leur part ; ils peuvent démarrer une instance prête pour la production à partir de 65 $ par mois ou profiter d’un essai gratuit de 90 jours
Amélioration du rapport prix/performance de Cloud Spanner
- Google Cloud augmente le débit jusqu’à 50 % et multiplie par 2,5 la capacité de stockage par nœud de Cloud Spanner, sans modifier son prix
- Selon l’entreprise, cette amélioration permet d’utiliser Spanner à moitié prix d’Amazon DynamoDB pour la plupart des charges de travail
- Spanner combine débit élevé, montée en charge quasi illimitée, latence de l’ordre de quelques millisecondes, SLA de disponibilité de 99,999 % et sémantique de forte cohérence externe
- Le déploiement s’appliquera à tous les clients Spanner dans les prochains mois, sans reprovisionnement, sans interruption et sans action utilisateur
Évolutions côté calcul et stockage
- Côté calcul, le débit progresse de 50 %, améliorant l’efficacité coût pour les charges de travail relationnelles et clé-valeur
- Côté stockage, la capacité qu’un nœud Spanner peut accueillir passe de 4 To à 10 To
- Même avec une limite de capacité plus élevée, les utilisateurs ne paient que pour l’espace de stockage réellement utilisé
- Cela offre davantage de flexibilité pour optimiser les environnements Spanner
- À charge de travail comparable, Spanner offrirait jusqu’à 2 fois plus de débit de lecture par dollar qu’Amazon DynamoDB
Caractéristiques de performance et charges de travail visées
- Spanner fournit une latence de l’ordre de quelques millisecondes prévisible pour les lectures et écritures à forte cohérence, sur plusieurs zones de disponibilité au sein d’une même région
- Avec SQL familier, l’absence d’interruption de maintenance et un SLA de disponibilité de 99,999 %, il convient aussi bien aux données relationnelles qu’aux charges de travail clé-valeur orientées lecture
- En interne, Google utilise Spanner pour des services comme Ads, Gmail et Photos
- Selon le billet de blog Prime Day d’Amazon, DynamoDB traite 126 millions de requêtes par seconde au pic
- Google indique que Spanner traite jusqu’à 3 milliards de requêtes par seconde en pointe et gère plus de 12 exaoctets de données
Témoignages clients et calendrier de disponibilité
- Uber explique que Spanner est un composant essentiel de ses opérations critiques, notamment pour sa scalabilité et ses faibles coûts d’exploitation
- Avant Spanner, son framework de gestion des données nécessitait beaucoup de supervision et d’efforts opérationnels, augmentant complexité et dépenses
- Les solutions de contournement traditionnelles, comme le sharding et la cohérence éventuelle, freinaient la vitesse de développement
- Après l’adoption de Spanner, les coûts d’exploitation ont été simplifiés, la fiabilité s’est améliorée, et l’entreprise obtient un meilleur débit et de meilleures performances au même prix
- CERC améliore son efficacité opérationnelle grâce à l’augmentation du débit et de la capacité de stockage par nœud
- L’amélioration du rapport prix/performance est actuellement disponible sur certaines configurations d’instances régionales et multirégionales, les autres configurations devant suivre
- La montée de capacité de stockage sera déployée au cours des prochains mois
- Les utilisateurs peuvent profiter d’un essai gratuit de 90 jours ou démarrer une instance prête pour la production à partir de 65 $ par mois
1 commentaires
Avis sur Hacker News
Nous avons récemment migré notre infrastructure de GCP vers AWS. Nous avons tout déplacé : clusters Kubernetes, load balancers, stockage, Lambda, jusqu’à KMS.
Google donne l’impression de gérer sa stack technique comme une startup qui cherche à étoffer son CV, avec beaucoup trop d’éléments immatures, de bricolages et de fonctionnalités non documentées. Avec GKE, de nouvelles versions et fonctionnalités sortaient en permanence, et il fallait sans cesse retravailler les contournements critiques intégrés à notre infra à cause de défauts côté Google.
La moitié du temps de l’équipe infra servait à se prémunir contre les problèmes de Google, l’autre moitié aux travaux d’infrastructure initialement prévus, et cela ne s’arrêtait jamais. Après le passage à AWS, pour 3 clusters Kubernetes, la facture est tombée à environ 60 % de ce qu’elle était sur GCP.
Le support AWS a été incroyablement bon, tandis que le support Google a été catastrophique. Un bug signalé en 2020 a récemment été fermé comme stale sans aucune action, au motif que l’API avait tellement changé que cela n’avait plus vraiment de sens. Chaque jour de facturation mensuelle me rappelait que nous payions des développeurs incapables de faire des choses que d’autres entreprises font bien mieux, et cela ne me manque absolument pas.
Je travaille dans le jeu vidéo en Europe, et quand j’étais chez Ubisoft, AWS m’a laissé une très mauvaise impression. Après être passé chez Tencent/Sharkmob, j’ai essayé d’apprécier AWS puisque c’est le standard du secteur, mais la plupart du temps, cela m’a semblé être un fatras incohérent recouvert de fonctions Lambda.
Nous appelions ces pièges bizarres des sujets de 3 heures du matin : des problèmes pour lesquels on n’a pas la capacité mentale de gérer à 3 h du matin. Nous avons donc convaincu le studio de passer à GCP, et je suis encore aujourd’hui très reconnaissant de cette décision.
En revanche, Azure, dont la part de marché est pourtant bien plus importante que celle de GCP, est épouvantable et globalement complètement chaotique. Même en payant le support, il est difficile d’être mis en relation avec les équipes d’ingénierie, tandis qu’AWS est excellent.
Nous utilisons Enterprise Support, donc leurs interlocuteurs sont présents dans nos canaux Slack, et les TAM sont bons aussi. Si nous avons besoin de quelqu’un de l’équipe Route53, un appel est organisé dans la semaine ; pour une demande de fonctionnalité EKS, nous pouvons parler au chef de produit l’après-midi même. Azure est un bazar de fond en comble.
Quand je développais des services AWS, je prenais directement les appels du support client, sans intermédiaire. Les techniciens parlaient directement entre eux, nous faisions parfois des promesses aux clients sur-le-champ, et il arrivait même que les clients pilotent notre travail comme des chefs de projet.
Après en avoir parlé avec GAE, ils ont constaté que le downtime qu’ils observaient était effectivement corrélé au downtime de GAE. Pendant un temps, la disponibilité de GAE s’est améliorée, mais nous utilisons désormais AWS nous aussi.
À l’inverse, le support GCP mérite un F, et on a presque l’impression de devoir supplier pour obtenir le moindre niveau d’aide.
La comparaison selon laquelle « d’après le blog d’Amazon Prime Day, DynamoDB traite 126 millions de requêtes par seconde au pic. À l’inverse, Spanner traite 3 milliards de requêtes par seconde au pic, soit plus de 20 fois plus, et gère plus de 12 exaoctets de données » ne me paraît pas vraiment équitable
Les 126 millions de requêtes par seconde d’Amazon se lisent comme la charge générée sur DynamoDB par les services liés à Amazon qui gèrent Prime Day, pas comme l’ensemble d’AWS
Une comparaison plus juste consisterait à partager la charge de pic générée par les services Google sur Cloud Spanner, et non à additionner tous les services Spanner tournant sur l’ensemble de GCP et sur l’infrastructure interne non-GCP de Google
Dire que Photos, Gmail et Ads dépendent fortement de l’infrastructure GCP serait un signal de confiance fort, mais pour moi ce serait une information nouvelle. En particulier, dans cet article on parle d’habitude de « Cloud Spanner », puis seulement lorsqu’il est question de Gmail, Ads et Photos, on dit « Spanner », ce qui entretient la confusion : utilisent-ils l’infrastructure Cloud Spanner, ou exécutent-ils Spanner sur leur propre infrastructure ?
Chez Amazon, pratiquement tous les services sont construits sur AWS, ce qui ressemble à un vrai vote de confiance, alors que j’avais l’impression que GCP avait historiquement été beaucoup moins utilisé par les services internes de Google
“DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second.”
Amazon l’a indiqué très clairement. Si Google a utilisé ce chiffre sans ce contexte, c’est une comparaison totalement mesquine et malhonnête. La personne qui a écrit cet article semble manquer d’honnêteté
https://www.youtube.com/watch?v=268jdNwH6AM
Le blog dit : “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” Mais le Spanner interne de Google et GCP Spanner sont distincts. Le fait qu’un service Google utilise Spanner ne signifie pas nécessairement qu’il utilise GCP
Cela dit, d’après ce que je comprends, Spanner et GCP Spanner sont bien plus proches l’un de l’autre que Borg et Kubernetes
Même en additionnant toute l’utilisation d’AWS, si l’usage propre d’Amazon pendant Prime Day est de 126 millions de requêtes par seconde, il est assez douteux que DynamoDB dépasse Spanner
Cherchez « Database as a Queue » pour vous faire une idée de l’ambiance. En réalité, il est vraiment difficile d’utiliser une base de données relationnelle chez AWS, au point qu’une équipe doit obtenir une dérogation allant jusqu’à l’approbation du CEO, ce qui montre la robustesse de DDB
Pour beaucoup de projets, Postgres reste moins cher que les deux. J’ai utilisé les deux, mais je préfère de très loin adapter un projet à Postgres/CockroachDB plutôt que d’utiliser Spanner ou DynamoDB
Spanner et DynamoDB comportent bien plus de pièges, ainsi que des flambées de coûts soudaines, du verrouillage fournisseur et d’autres problèmes. AWS, GCP, Azure, Oracle Cloud, jusqu’aux déploiements basés sur des opérateurs Kubernetes, prennent très bien en charge Postgres ; autant utiliser Postgres
Si vous pouvez exploiter correctement Postgres, bien sûr qu’il faut l’utiliser. Si toutes vos données tiennent dans Postgres sur une seule machine, il n’y a aucune raison d’utiliser une base de données de niveau P, scalable mondialement
Si je construis une application de chat avec des millions de messages et presque aucune « relation », je me demande sincèrement s’il faudrait utiliser Postgres ou une famille quelconque de NoSQL
Avec des fonctions distribuées et du code déployé sur Lambda, la gestion des connexions SQL était devenue un cauchemar, et des requêtes se perdaient un peu partout
PostgreSQL est excellent, et même si je travaille chez Google, je suis d’accord à 100 %. Utilisez simplement PG jusqu’à ce que ça ne marche plus. Ce n’est que lorsque vous arrivez dans le domaine de Spanner et DynamoDB que ce genre de discussion prend son sens
Si quelque chose de complètement différent est un peu moins cher, on pourrait dire de « simplement l’utiliser » pour n’importe quoi. Par exemple, stocker des enregistrements sous forme de commits dans un dépôt GitHub est gratuit et suffisamment bon marché pour un petit projet, mais ce n’est pas la même chose
GCP Spanner est « à partir de 65 dollars par mois », tandis que le niveau gratuit d’AWS offre notamment « 25 Go de stockage de données, 2,5 millions de requêtes de lecture de flux »
https://aws.amazon.com/dynamodb/pricing/
Sur le graphique, les courbes finiront bien par se croiser un jour, mais le titre de Google me semble trompeur
Sauf à des fins pédagogiques, il y a très peu de raisons de l’utiliser pour un petit projet, et les clients de Spanner sont par exemple des organisations pour lesquelles même CockroachDB ne suffit pas. Pour une base de données qui n’est pas aussi gigantesque, PostgreSQL suffit
De nos jours, beaucoup d’applications atteignent plus de 100 millions d’utilisateurs en un mois, donc on n’est pas dans un cas à 50 QPS. En plus, ils ont aussi omis la limite en octets de DynamoDB. Si vous dépassez 1 Ko d’un seul octet, deux unités de lecture sont facturées
Dire que « Google devrait aussi proposer une remise d’entrée de gamme » est tout à fait recevable, mais cela ne dit pas si le produit réel est plus cher ou moins cher
J’aimerais essayer Spanner pour un projet personnel ou un side project, mais une instance prête pour la production commence à 65 dollars par mois. DynamoDB, avec une facturation à la requête, peut tourner pour quasiment 0 dollar par mois
Cela dit, la facturation à la requête n’est gratuite que tant que l’on reste dans le niveau gratuit. Il faut vérifier les limites, et si on les dépasse, ce n’est plus gratuit
L’architecture de CRDB est, par nature, assez proche de Spanner en interne
https://www.cockroachlabs.com/get-started-cockroachdb/
Avant, j’aimais plutôt bien les produits Google, donc je suis partagé. Je suis assez lié à Gmail, et je fais déjà tourner plusieurs choses sur GCP
Mais j’ai aussi de plus en plus l’impression de m’être brûlé avec les fermetures soudaines de services par Google. J’avais tous mes domaines chez Google Domains et j’en étais satisfait, puis récemment ils ont été vendus sans prévenir à Squarespace, une entreprise avec laquelle je ne veux pas faire affaire
J’utilise un Google Pixel et j’utilisais aussi l’application Google Podcasts, mais j’ai entendu dire qu’elle allait aussi être arrêtée et migrée vers YouTube Music. J’ai essayé YouTube Music, mais je déteste vraiment ça, donc il va falloir que je trouve une alternative
À long terme, ce sont peut-être de petits services, mais je ne suis pas rassuré à l’idée de confier de nouveau des services importants à Google. Avant d’y consacrer du temps, je me demande : « Et si, un jour, Google vendait ou arrêtait Cloud Spanner ? Est-ce que je me retrouverais en difficulté ? »
L’enregistrement de domaines peut être un champ de mines en matière de réglementation et de réputation, mais d’autres produits cloud, y compris la distribution de contenu, le sont aussi. Je ne dirais pas encore que cela révèle une grande tendance d’arrêt de services Google Cloud, mais au moins le feu est passé à l’orange
Les abandons de produits Google sont agaçants, mais ils n’ont rien à voir avec les produits et services Google Cloud. Google Cloud a des clients payants, donc je ne les vois pas annoncer soudainement l’arrêt de produits ou services
Google Domains est un produit Google, et l’équivalent côté Google pour les clients Google Cloud est Google Cloud Domains
« Les organisations de toutes tailles et de tous secteurs cherchent de plus en plus à accélérer leur transformation numérique et à stimuler l’innovation fondée sur l’IA » : comment Google en est-il arrivé là ?
Sans version à la demande de Spanner facturée à l’unité de travail plutôt qu’au nœud, il est difficile de le comparer à DynamoDB pour de nombreux cas d’usage
Le débit moyen étant bien inférieur au pic, je doute qu’on puisse réellement constater des économies avec Spanner
Cela dit, le développement me semble beaucoup plus simple avec Spanner qu’avec DynamoDB
Google a déjà fortement augmenté le coût de certains services. Le vendor lock-in est dangereux
Je me demande si c’est aussi arrivé sur d’autres services. Pour un service de cloud d’entreprise qui est loin derrière AWS, en deuxième ou troisième position, cela me paraît beaucoup moins probable
Même si c’est un vieil exemple, je connais aussi un cas où ils ont baissé les coûts : https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
À ma connaissance, AWS, par exemple, n’a fait que baisser les prix de ses services
Si vous installez une base Postgres sur un Droplet, ça ne coûte presque rien et les performances sont plutôt bonnes
Pour 65 dollars par mois, on peut aussi obtenir un serveur très puissant chez Hetzner. Il faut se frayer un chemin dans la jungle délirante des offres cloud, et après y avoir jeté un œil, je me suis dit qu’il valait mieux apprendre une bonne fois les bases de l’administration Linux et s’en servir toute sa vie
Comparer Postgres et Spanner, c’est un peu comme comparer une camionnette de livraison et un train. Un train a toujours des coûts fixes plus élevés
L’administration Linux est une compétence utile, mais mes capacités en administration Linux ne peuvent pas rivaliser avec la fiabilité, la disponibilité et la scalabilité de systèmes cloud comme Dynamo, S3 ou Spanner
Une trop grande partie du temps est consacrée à de la configuration et du dépannage propres à chaque service, qui n’ont pas beaucoup de valeur ailleurs
Avec 1 Go de stockage, des éléments de 1 Ko, 100 000 écritures et 100 000 lectures sur un mois, cela revient à 0,39 dollar en mode à la demande DynamoDB. Même en passant à 1 million d’écritures et 1 million de lectures chacun, cela fait 1,63 dollar. Avec des lectures fortement cohérentes, on arrive à 1,75 dollar, et avec des écritures transactionnelles en plus, à 3,00 dollars