Railway détaille une panne sur GCP et décide de quitter Google Cloud

 (blog.railway.app)
1 points par GN⁺ 2023-12-04 | 1 commentaires | Partager sur WhatsApp
  • Railway a subi un incident sur sa plateforme opérée sur Google Cloud où certaines machines de us-west se sont arrêtées les unes après les autres et où le basculement automatique a échoué, nécessitant une intervention manuelle pour restaurer les workloads utilisateurs
  • Chaque instance individuelle est restée hors ligne environ 10 minutes selon un schéma roulant, l'incident ayant commencé à 16:40 UTC et l'ensemble des basculements de workloads et de la restauration du service ayant été achevé à 20:53 UTC
  • Au cours des 18 derniers mois, Railway a rencontré une instabilité réseau, une réduction des quotas d'Artifact Registry et des problèmes de réponse du support, ce qui l'a conduit à construire sa propre stack réseau et son propre registre
  • Lors de l'enquête, Railway a observé un CPU soft lockup ainsi que des stack traces kvm_wait et __pv_queued_spin_lock_slowpath, et estime qu'une interaction entre les invités GCP et l'hyperviseur est la cause la plus probable
  • Railway a décidé d'arrêter les services Google Cloud et de migrer vers ses propres instances bare metal ; la première est déjà en production et la migration complète est prévue pour 2024

Panne roulante sur us-west

  • Railway exploitait sa plateforme de développement d'applications sur des produits Google Cloud Platform comme Google Compute Engine
  • À partir du 1er décembre 2023 à 16:40 UTC, certaines machines de la flotte us-west sont devenues indisponibles une par une
    • Chaque instance est restée hors ligne environ 10 minutes
    • La panne s'est propagée de manière roulante
    • Le basculement automatique n'a pas fonctionné, ce qui a nécessité un basculement manuel
  • À 20:53 UTC, tous les basculements de workloads avaient réussi et le service était rétabli
  • D'après son enquête, Railway estime qu'une interaction liée au transfert mémoire de l'espace utilisateur vers le noyau sur les invités GCP peut, dans de rares situations de pression sur les ressources, provoquer un soft lock

18 mois de problèmes accumulés avec Google Cloud

  • Railway dit avoir subi plusieurs problèmes d'exploitation liés à Google Cloud au cours des 18 derniers mois

  • Instabilité réseau

    • En 2022, des coupures réseau persistantes se sont produites sur des produits cloud de Google
    • Après plusieurs escalades auprès de Google, Railway a construit sa propre stack réseau
    • Cette stack repose sur un réseau Wireguard eBPF/IPv6 résilient et fait aujourd'hui tourner tous les déploiements
    • Depuis, les problèmes réseau ont disparu

  • Quotas d'Artifact Registry

    • En 2023, Railway affirme que Google a arbitrairement réduit les quotas d'Artifact Registry à un niveau proche de zéro en pratique
    • Le débit de déploiement des images a fortement chuté, ce qui a retardé les builds
    • Railway a ensuite créé son propre produit de registry, et les problèmes de débit du registre ont disparu

Réponse du support et décision de migrer vers du bare metal

  • Railway estime que, malgré des paiements annuels de plusieurs millions de dollars à Google Cloud, il n'a pas reçu une réponse suffisante dans des situations où des actions de Google affectaient les workloads de Railway et d'autres clients
  • Après qu'un fondateur a publié des messages sur le sujet sur X, Google a pris contact, et Railway a discuté des causes du problème avec des VP de Google
  • Selon Railway, un ingénieur Google pouvait modifier arbitrairement les quotas GCP
    • Les VP de Google auraient reconnu que cette situation était inacceptable
    • Depuis juin, Railway dit continuer à demander un post-mortem, une réponse officielle et une politique empêchant les changements arbitraires de quota
  • Dans ce processus, Railway affirme que Google a modifié les ToS sans avertissement préalable, ce qui a augmenté ses coûts de 20 %
    • Google aurait également promis de répondre à ce sujet, mais Railway dit ne toujours pas avoir reçu de réponse
  • Railway a pris la décision interne, au trimestre dernier, d'arrêter tous les services Google Cloud et de passer à ses propres instances bare metal
    • La première instance bare metal a été lancée il y a quelques semaines
    • La migration de l'ensemble des instances est prévue pour 2024

Déroulement des incidents des 30 novembre et 1er décembre

  • Le 30 novembre 2023 à 21:41 UTC, Google a redémarré une machine, mettant une box hors ligne
    • Railway dispose de systèmes automatiques pour détecter et résoudre ce type de situation
    • La box concernée a été correctement basculée et aucun pager n'a été déclenché
  • Le 1er décembre 2023 à 16:52 UTC, une box est passée hors ligne et est devenue inaccessible
    • Elle n'est pas revenue normalement après le basculement automatique
    • L'ingénieur principal d'astreinte a été appelé et, pendant l'enquête, d'autres box sont aussi tombées hors ligne sans se rétablir
  • Railway a commencé à basculer les box manuellement
    • Chaque hôte a subi environ 10 minutes d'indisponibilité
    • Rapidement, une douzaine de box ont été touchées, mobilisant près de la moitié de l'entreprise pour suivre les runbooks et répondre à l'incident
  • En raison de motifs dans les logs série similaires à ceux d'une live migration automatique sur Google Cloud, Railway a d'abord pensé à un redémarrage habituel de Google qui se serait mal passé
    • Un e-mail a été envoyé au contact Google côté compte, mais seule une réponse d'absence automatique a été reçue dans l'immédiat

Indices observés dans les logs de console série

  • La première chose vérifiée par Railway a été les logs de console série
    • Ces logs proviennent directement du noyau via un périphérique série virtualisé
  • Les logs montraient un cœur CPU en soft lock ainsi qu'une stack trace du CPU bloqué
    • Parmi les entrées d'exemple figuraient kvm_wait et __pv_queued_spin_lock_slowpath
  • La dernière fois que Railway avait vu ce type de logs et de comportement, c'était lors de redémarrages lancés par Google en décembre de l'année précédente
    • À l'époque, le même schéma était apparu sur trois box
  • Une enquête complémentaire a permis d'identifier des erreurs noyau correspondant à des discussions sur la virtualisation imbriquée du noyau sur GCP et les soft lockups
  • Comme Railway n'utilisait pas sa propre virtualisation sur les hôtes concernés, il interprète les messages liés à kvm et à la paravirtualisation comme des signaux du code noyau invité interagissant avec l'hyperviseur GCP
  • GCP semble avoir classé un problème similaire comme non reproductible, mais Railway estime fortement que l'incident actuel appartient à la même famille

Cause supposée et mesures d'atténuation

  • Railway estime qu'il existe une interaction potentiellement critique dans le transfert mémoire de l'espace utilisateur vers le noyau sur les invités GCP, susceptible de provoquer un soft lock dans de rares situations de pression sur les ressources
  • Plus précisément, Railway pense que la gestion de mémoire paravirtualisée et la manière dont les pages sont mappées et remappées par l'hyperviseur sont liées à certaines situations de pression sur les ressources
  • Le fait que presque tous les signalements similaires proviennent d'utilisateurs GCP est aussi considéré comme un point commun significatif
  • Le fait que Google traite la plupart des commandes MMIO en espace utilisateur va également dans le sens de cette hypothèse
  • Si cette analyse est correcte, une box pourrait entrer en soft lock à cause de limites de débit, seuils ou conditions non publiés, même à des niveaux inférieurs aux limites visibles dans les métriques CPU, mémoire et IOPS
    • Au moment des faits, les machines se situaient à environ 50 % des limites de ressources publiées
  • Après redémarrage manuel, Railway a désactivé certains services internes pour réduire la pression sur les ressources des instances touchées, qui se sont ensuite stabilisées

Impact sur les utilisateurs

  • Pendant les basculements manuels, chaque machine a subi 10 minutes d'indisponibilité par hôte
  • Comme plusieurs utilisateurs exécutaient des workloads multi-services, l'indisponibilité successive des box a pu provoquer plusieurs interruptions cumulées
  • Railway a présenté ses excuses aux utilisateurs et indiqué qu'il migrait vers son propre bare metal pour offrir une meilleure fiabilité

À lire aussi

1 commentaires

 
GN⁺ 2023-12-04
Avis sur Hacker News

  • Nous sommes une petite entreprise logicielle de deux personnes, et nous avons nous aussi eu beaucoup de problèmes avec Google pendant des années à cause de Google Adwords. Par exemple :
    https://successfulsoftware.net/2015/03/04/google-bans-hyperl...
    https://successfulsoftware.net/2016/12/05/google-cpa-bidding...
    https://successfulsoftware.net/2020/08/21/google-ads-can-cha...
    https://successfulsoftware.net/2021/05/04/wtf-google-ads/
    Si Google n’a même pas la volonté d’offrir un support correct à l’auteur du billet original, qui lui verse pourtant des sommes importantes, quel espoir reste-t-il à des petites entreprises comme la nôtre ?

  • De manière générale, je pense que GCP a perdu sa direction au cours des dernières années. Il y a encore quelques années, c’était une alternative nettement meilleure qu’AWS en rapport performance/prix sur le calcul, le stockage et la bande passante, et nous l’avions vérifié avec des tests de performance détaillés et une modélisation des coûts pour nos workloads
    À l’époque, le support était aussi excellent. Un ticket initialement ouvert pour un problème réseau ambigu avait été rapidement escaladé, repris par des ingénieurs de plusieurs régions, puis finalement résolu par un rollback d’un changement côté GCP. Le commercial nous avait aussi rapidement mis en relation avec des ressources internes, ce qui laissait une impression très positive de l’ensemble de l’expérience
    Aujourd’hui, AWS a clairement rattrapé son retard en performance/prix, et reste encore en avance de plusieurs années sur de nombreux services managés. En parallèle, le support GCP s’est fortement dégradé et semble désormais passer en grande partie par des prestataires externes, qui ne paraissent pas avoir beaucoup plus de visibilité que nous sur l’infrastructure GCP réelle
    L’expérience commerciale est aussi bien pire, et notre interlocuteur actuel est clairement un point négatif. Nous avons beaucoup investi dans GCP, mais comme aucun signe d’amélioration n’apparaît, nous travaillons activement à réduire nos dépenses GCP. J’étais autrefois un défenseur de GCP, mais aujourd’hui il m’est difficile de recommander de lancer de nouveaux projets dessus

  • Tous les fournisseurs cloud ont des problèmes, c’est vrai. Au cours des deux dernières années, j’ai identifié et signalé au travail plusieurs problèmes liés à Keyspaces, Amazon Aurora et App Runner ; tous ont entraîné des dégradations de performance, et le support AWS nous a fait perdre du temps en nous poussant à creuser au mauvais endroit
    Ce n’est qu’après plusieurs semaines d’escalade que les responsables des projets ont reconnu les problèmes ; certains étaient même déjà connus, ce qui signifie que l’équipe support nous a fait perdre notre temps. Pour l’instant, nous sommes coincés avec Keyspaces, mais désormais j’essaie de ne plus utiliser que les services de base comme EC2, EBS et S3. Dès qu’on s’en éloigne, ça devient risqué

    • C’est vraiment ça. On a l’impression que la moitié des services AWS sont soit mal conçus, soit mal exploités, soit les deux. CloudWatch est particulièrement buggé et lent, au point de ressembler à un véritable piège pour débutants
      Quand je vois une entreprise utiliser CloudWatch pour tous ses logs, j’en déduis qu’elle manque surtout d’expérience et ne connaît pas les nombreuses alternatives. Cela dit, les services de calcul restent fiables

  • C’est ridicule de reprocher à GCP la panne d’une seule instance de calcul. L’auteur original reconnaît lui-même que c’est un événement rare, alors que sur AWS j’ai souvent vu des instances être arrêtées de force ou carrément disparaître. 99.95% de durabilité et 99.999% sont deux choses très différentes
    Si la même architecture avait été déployée sur AWS, d’après mon expérience elle aurait subi des pannes en continu. D’après la documentation AWS et mon expérience, les composants de base d’AWS sont bien moins stables que ceux de GCP

    • Le billet ne semble pas vraiment parler d’AWS. Le problème principal ne paraît pas être la panne d’une seule instance, mais le manque de communication et de support, même pour un grand partenaire entreprise
      Ils semblent vouloir migrer vers du bare metal, ce qui a l’avantage évident de pouvoir dire directement à l’ingénieur d’astreinte de réparer le problème d’une manière ou d’une autre
    • Les SLA de EC2 et de GCP Compute sont exactement de 99.99% tous les deux ; en dessous, c’est 10% de remboursement, et en dessous de 95%, 100% de remboursement
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Mon expérience est complètement différente. En plusieurs années sur AWS, je n’ai vu qu’une seule fois une instance s’arrêter à cause d’une étrange tâche de fond AWS sans lien avec l’application, et je n’ai jamais vécu — ni même l’impression d’avoir entendu parler — d’une instance qui disparaît tout simplement
    • Dans le cloud, en règle générale, comme quelqu’un l’a dit, il faut concevoir l’architecture en partant du principe que tout échoue en permanence

  • J’ai eu beaucoup d’interactions avec Google Cloud Support, en particulier autour des services managés, et honnêtement ça ne m’a pas vraiment impressionné, surtout comparé à mes expériences de support AWS, qui ont toujours été excellentes dans des environnements d’usage de taille comparable
    Cela dit, si quelqu’un chez Google Cloud vous aide vraiment bien, il vaut mieux le féliciter ouvertement. Comme c’est rare, ce n’est pas un grand effort de faire en sorte que cela soit récompensé par un fort feedback positif. J’ai moi-même eu quatre expériences vraiment excellentes, et j’ai à chaque fois immédiatement envoyé un message au TAM. J’espère que ces personnes seront récompensées et promues

    • Oui. Ce type de discussion dérive facilement comme les débats vi/emacs, et la première page de HN fait généralement surtout remonter des plaintes
      J’utilise GCP de façon intermittente sur des projets depuis une dizaine d’années, et j’ai aussi construit plusieurs entreprises qui ont bien réussi dessus. Ce n’était pas parfait, mais dans l’ensemble j’en suis satisfait
      À l’inverse, j’ai beaucoup utilisé AWS dans l’équipe qui construisait la première version hébergée de Cloud Foundry, et je n’ai aucune envie d’y revenir. C’était un chaos sans fin

  • Il est déjà arrivé qu’une fonctionnalité très « enterprise » de GCP casse, et il est alors devenu évident qu’elle n’avait en réalité jamais vraiment fonctionné correctement jusque-là. En essayant de la corriger discrètement, ils ont même provoqué du downtime, et les interlocuteurs GCP ont passé l’appel censé expliquer la cause à rappeler sans cesse que tout le monde était couvert par un NDA
    Admettre ce fait aurait été un cauchemar pour les secteurs réglementés

    • Je me demande toujours si un NDA peut vraiment empêcher de parler à un régulateur, à la police, à un procureur, ou à une véritable autorité d’État, ou d’agir en lanceur d’alerte. J’aimerais croire qu’on doit toujours pouvoir signaler un crime

  • « Le 1er décembre à 8:52 PST, une box est passée hors ligne et est devenue inaccessible. Elle aurait dû revenir automatiquement après le basculement, mais ce n’est pas arrivé. Pendant que l’ingénieur d’astreinte principal recevait l’alerte et enquêtait, une autre box est passée hors ligne et n’est pas revenue non plus »
    Ça n’a aucun sens. Une machine redémarre et ça provoque une panne catastrophique ? Les VM redémarrent parfois. Si tout le système a été conçu pour s’effondrer de lui-même dans ce scénario, je n’aimerais pas davantage ça, qu’ils migrent vers AWS ou même qu’ils utilisent leur propre colocation

    • Il faut lire l’article plus attentivement. Même dans le passage cité, il n’est pas dit que la machine a « redémarré », mais qu’après un crash elle n’est pas revenue en ligne
      Et nulle part l’article ne dit qu’il s’agissait d’une « panne catastrophique ». Railway tout entier n’est pas tombé, mais Railway est une société de déploiement qui revend des ressources de calcul pour déployer les applications de ses clients. Donc si une VM tombe et que le failover automatique ne fonctionne pas, cela devient du downtime pour les clients précis qui faisaient tourner des services sur cette machine
      L’article dit aussi : « Pendant le basculement manuel de ces machines, il y a eu 10 minutes de downtime par hôte. Comme beaucoup d’utilisateurs exécutent des charges de travail multiservices, ce downtime peut se multiplier à mesure que les boxes passent hors ligne les unes après les autres. Nous présentons nos plus sincères excuses à tous les utilisateurs »

  • Fait intéressant, j’ai l’impression que GCP a assez souvent des seuils non documentés
    J’ai vécu quelque chose de similaire avec Cloud Run. Il y avait des événements de scaling qui ne s’expliquaient ni par l’utilisation CPU ni par le nombre de requêtes simultanées, contrairement à ce que la documentation présente comme critères de scaling
    Après de longs échanges avec le support payant, j’ai fini par apprendre qu’il existait un critère supplémentaire lié à la durée des requêtes, mais évidemment personne n’a pu l’expliquer en détail

  • Ça a l’air d’avoir été une expérience vraiment frustrante. Cela dit, puisqu’ils n’utilisent pas de virtualisation à l’intérieur de la VM, je vois mal le lien entre la virtualisation imbriquée et ce problème. Un soft lockup est en général un signal très général indiquant qu’il n’y a plus de progression
    Le commentaire sur les instructions MMIO me laisse de la même façon perplexe. S’il s’agit d’émulation d’instructions, je ne vois pas pourquoi l’endroit où cela se produit aurait de l’importance. De toute façon, ce sera lent et confiné à l’espace utilisateur ; si ça doit être rapide, il devrait déjà y avoir très peu de sorties du guest, et encore moins d’émulation
    On a l’impression que l’auteur est tellement frustré qu’il s’accroche à tout ce qu’il peut pour chercher une cause plausible à l’incident récent

  • « En 2022, nous avons subi des micro-coupures réseau persistantes sur les produits cloud de Google. Après de multiples escalades auprès de Google, nous nous sommes épuisés et avons construit notre propre pile réseau, à savoir un réseau eBPF/IPv6 Wireguard résilient qui fait tourner tous nos déploiements. Et soudain, les problèmes réseau ont disparu »
    Si je comprends bien, le réseau pour les VM repose sur des VLAN programmés via les switches, et quand on crée un VPC cela doit probablement créer un VLAN ; si le réseau sous-jacent est instable, je me demande comment une surcouche UDP/WireGuard pourrait être plus stable
    Au passage, si seulement un dixième de ce problème était arrivé sur AWS à un client comme celui-ci, une armée de solution architects aurait occupé une salle de réunion une semaine sur deux, revu l’architecture et mis des ingénieurs support sur les appels

    • Il ne s’agit pas de programmer des switches pour créer des VLAN, tout passe par un réseau overlay
      C’est ancien, mais ça aide à se faire une idée : https://www.usenix.org/conference/nsdi18/presentation/dalton
    • À vue de nez, il est possible que les optimisations réseau sophistiquées de Google aient interagi de manière défavorable avec leur trafic
      En construisant leur propre pile réseau, ils ont contourné ces optimisations, et WireGuard, fondé par nature sur de l’UDP non fiable, gérait peut-être mieux les pannes intermittentes