Railway resume pane no GCP e decisão de deixar o Google Cloud

 (blog.railway.app)
1 pontos por GN⁺ 2023-12-04 | 1 comentários | Compartilhar no WhatsApp
  • A Railway sofreu um incidente ao operar sua plataforma baseada no Google Cloud em que algumas máquinas em us-west pararam sequencialmente, e o failover automático falhou, exigindo intervenção manual para recuperar as cargas de trabalho dos usuários
  • Cada instância individual ficou cerca de 10 minutos offline em um processo gradual; após o início às 16:40 UTC, o failover de todas as cargas de trabalho e a restauração do serviço foram concluídos às 20:53 UTC
  • Nos 18 meses anteriores, a Railway enfrentou instabilidade de rede, redução de cotas do Artifact Registry e problemas de suporte, levando-a a construir sua própria stack de rede e seu próprio registro
  • Durante a investigação, foram identificados CPU soft lockup e stack traces com kvm_wait e __pv_queued_spin_lock_slowpath; a Railway considera a interação entre o guest do GCP e o hypervisor como a causa mais provável
  • A Railway decidiu encerrar o uso dos serviços do Google Cloud e migrar para suas próprias instâncias bare metal; a primeira instância já foi colocada no ar, e a migração completa está planejada para 2024

Falha gradual ocorrida em us-west

  • A Railway vinha operando sua plataforma de desenvolvimento de aplicações sobre produtos da Google Cloud Platform, como o Google Compute Engine
  • A partir de 1º de dezembro de 2023, às 16:40 UTC, algumas máquinas da frota em us-west começaram a ficar sem resposta, uma a uma
    • Cada instância individual ficou cerca de 10 minutos offline
    • A falha prosseguiu de forma gradual
    • Como o failover automático não ocorreu, foi necessário fazer failover manual
  • Às 20:53 UTC, o failover de todas as cargas de trabalho foi concluído com sucesso e o serviço foi restaurado
  • Com base na investigação, a Railway concluiu que uma interação relacionada à transferência de memória de userspace para kernel no guest do GCP pode, em raras situações de pressão de recursos, causar um softlock

Problemas acumulados com o Google Cloud ao longo de 18 meses

  • Nos últimos 18 meses, a Railway enfrentou vários problemas operacionais relacionados ao Google Cloud

  • Instabilidade de rede

    • Em 2022, ocorreram quedas persistentes de rede em produtos de nuvem do Google
    • Após várias escalações ao Google, a Railway construiu sua própria stack de rede
    • Essa stack própria é uma rede resiliente baseada em eBPF/IPv6 Wireguard e atualmente sustenta todos os deployments
    • Depois disso, os problemas de rede desapareceram

  • Cota do Artifact Registry

    • Em 2023, segundo a Railway, o Google reduziu arbitrariamente a cota do Artifact Registry para praticamente zero
    • A vazão de distribuição de imagens caiu muito, atrasando builds
    • Depois disso, a Railway criou seu próprio produto de registry, e os problemas de vazão do registro também desapareceram

Suporte e decisão de migrar para bare metal

  • A Railway pagava milhões de dólares por ano ao Google Cloud, mas considerou que não recebeu uma resposta suficiente em situações em que ações do Google afetaram as cargas de trabalho da Railway e de outros clientes
  • Depois que o fundador publicou sobre os problemas no X, o Google entrou em contato, e a Railway discutiu as causas com VPs do Google
  • Segundo a Railway, um engenheiro do Google conseguia alterar arbitrariamente cotas do GCP
    • Os VPs do Google teriam concordado que esse problema era inaceitável
    • Desde junho, a Railway segue solicitando uma retrospectiva, uma resposta oficial e uma política para impedir alterações arbitrárias de cota
  • Nesse processo, segundo a Railway, o Google alterou os ToS sem aviso prévio, aumentando os custos da Railway em 20%
    • O Google disse que também responderia sobre esse problema, mas a Railway afirma que ainda não recebeu resposta
  • No último trimestre, a Railway decidiu internamente encerrar todos os serviços do Google Cloud e migrar para suas próprias instâncias bare metal
    • A primeira instância bare metal foi colocada no ar há algumas semanas
    • A migração de todas as instâncias está planejada para 2024

Evolução das falhas em 30 de novembro e 1º de dezembro

  • Em 30 de novembro de 2023, às 21:41 UTC, uma máquina ficou offline quando o Google reiniciou a máquina
    • A Railway possui sistemas automáticos para detectar e resolver esse tipo de situação
    • A máquina em questão passou por failover corretamente e nenhum page foi gerado
  • Em 1º de dezembro de 2023, às 16:52 UTC, uma máquina ficou offline e inacessível
    • Mesmo após o failover automático, ela não se recuperou normalmente
    • O principal engenheiro de plantão foi acionado e, durante a investigação, outra máquina também ficou offline e não se recuperou
  • A Railway começou a fazer failover manual das máquinas
    • Houve cerca de 10 minutos de downtime por host
    • Em pouco tempo, cerca de 12 máquinas foram afetadas, e aproximadamente metade da equipe da empresa respondeu seguindo o runbook
  • Devido a um padrão de serial log semelhante ao da live migration automática do Google Cloud, inicialmente a Railway julgou que se tratava de uma reinicialização rotineira do Google que havia dado errado
    • Eles enviaram um e-mail ao contato do Google, mas receberam imediatamente uma resposta automática de ausência

Pistas vistas nos logs do serial console

  • A primeira coisa verificada pela Railway foram os logs do serial console
    • Esses logs vêm diretamente do kernel por meio de um serial device virtualizado
  • Os logs mostravam um CPU core em soft lock e o stack trace da CPU bloqueada
    • Exemplos de entradas são kvm_wait e __pv_queued_spin_lock_slowpath
  • A última vez que a Railway tinha visto logs e comportamento semelhantes foi em dezembro do ano anterior, durante reinicializações iniciadas pelo Google
    • Na ocasião, o mesmo padrão ocorreu em três máquinas
  • Em uma investigação adicional, a Railway encontrou erros de kernel que correspondiam a threads relacionados a nested kernel virtualization e soft lockup no GCP
  • Como a Railway não usava virtualização própria nesses hosts, ela interpretou as mensagens relacionadas a kvm e paravirtualization como um sinal de código do kernel guest interagindo com o hypervisor do GCP
  • Embora o GCP pareça ter tratado problemas semelhantes como não reproduzíveis, a Railway avalia fortemente que este incidente pertence à mesma categoria

Causa estimada e medidas de mitigação

  • A Railway considera que há uma interação potencialmente fatal na transferência de memória de userspace para kernel no guest do GCP e que, em raras situações de pressão de recursos, ela causa softlock
  • Mais especificamente, avaliou que isso está relacionado ao gerenciamento de memória paravirtualizado e à forma como páginas são mapeadas e remapeadas pelo hypervisor em determinadas situações de pressão de recursos
  • A Railway também viu como ponto em comum o fato de que quase todos os relatos semelhantes vieram de usuários do GCP
  • O fato de o Google processar a maioria dos comandos MMIO em userspace também se alinha à hipótese da Railway
  • Se essa avaliação estiver correta, uma máquina pode sofrer softlock por limites de velocidade, limiares ou condições não divulgados, mesmo quando as métricas observadas de CPU, memória e IOPS estão abaixo dos limites
    • Naquele momento, as máquinas estavam em torno de 50% dos limites de recursos publicados
  • Após reinicializações manuais, a Railway desativou alguns serviços internos para reduzir a pressão de recursos nas instâncias afetadas e, depois disso, as instâncias se estabilizaram

Impacto nos usuários

  • Durante o failover manual, cada máquina teve 10 minutos por host de downtime
  • Como vários usuários executavam cargas de trabalho com múltiplos serviços, o downtime pôde se acumular várias vezes à medida que as máquinas ficavam offline em sequência
  • A Railway pediu desculpas aos usuários e afirmou que está migrando para sua própria infraestrutura bare metal para alcançar maior confiabilidade

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-04
Opiniões no Hacker News

  • Somos uma pequena empresa de software com 2 pessoas, e também tivemos muitos problemas com o Google ao longo dos anos por causa do Google Adwords. Por exemplo:
    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/
    Se eles não têm disposição para oferecer suporte adequado ao autor do texto original, que paga grandes quantias ao Google, que esperança haveria para pequenos negócios como nós?

  • No geral, acho que o GCP perdeu o rumo nos últimos anos. Até alguns anos atrás, ele era uma opção significativamente melhor que a AWS em custo-benefício para computação, armazenamento e largura de banda, e tínhamos confirmado isso com testes detalhados de desempenho e modelagem de custos para nossas cargas de trabalho
    O suporte na época também era excelente. Um chamado inicial sobre um problema de rede ambíguo foi escalado rapidamente, engenheiros de várias regiões assumiram em sequência para resolvê-lo e, no fim, uma alteração do lado do GCP foi revertida. O representante de vendas também conectou rapidamente recursos internos, então a experiência como um todo foi positiva
    Hoje, a AWS claramente alcançou o GCP em custo-benefício e, em vários serviços gerenciados, ainda está anos à frente. Por outro lado, o suporte do GCP piorou bastante e parece ir, na maior parte, para empresas terceirizadas de suporte, que não parecem ter muito mais visibilidade sobre a infraestrutura real do GCP do que nós
    A experiência com vendas também ficou muito pior, e o representante atual é claramente um ponto negativo. Fizemos um grande investimento no GCP, mas não vemos sinais de melhora, então estamos trabalhando ativamente para reduzir os gastos com GCP; antes eu era defensor do GCP, mas agora é difícil recomendar que novos projetos sejam colocados no GCP

  • É verdade que todos os provedores de nuvem têm problemas. Nos últimos 2 anos, no trabalho, encontrei e reportei vários problemas relacionados a Keyspaces, Amazon Aurora e App Runner, todos resultando em degradação de desempenho, e o suporte da AWS nos fez perder tempo investigando os lugares errados
    Só depois de semanas de escalonamento os responsáveis pelos projetos reconheceram os problemas, e alguns deles eram problemas que já conheciam, mesmo assim a equipe de suporte acabou nos fazendo perder tempo. Por enquanto estamos presos ao Keyspaces, mas agora não quero usar nada além de serviços centrais como EC2, EBS e S3. Fora disso, é arriscado

    • É bem isso. Parece que cerca de metade dos serviços da AWS é mal projetada, mal operada, ou as duas coisas. O CloudWatch em especial é cheio de bugs e lento, praticamente uma armadilha para iniciantes
      Quando vejo uma empresa usando CloudWatch para todos os logs, presumo que seja por falta de experiência e por não conhecer várias alternativas. Ainda assim, os serviços de computação são confiáveis

  • É engraçado culpar o GCP porque uma instância de computação caiu. O próprio autor do texto original reconheceu que foi um evento raro, enquanto na AWS já passei frequentemente por instâncias sendo interrompidas à força ou simplesmente desaparecendo. 99,95% de durabilidade e 99,999% são coisas bem diferentes
    Se a mesma arquitetura tivesse sido colocada na AWS, pela minha experiência ela teria ficado com falhas constantes. Pela documentação da AWS e pela minha experiência, os componentes básicos da AWS são muito menos estáveis que os do GCP

    • O texto não parece tratar especificamente da AWS. O problema central também não parece ser uma única instância ter caído, mas sim a falta de comunicação e suporte, mesmo para uma grande empresa parceira
      Eles parecem querer migrar para bare metal, o que tem a vantagem clara de poder falar diretamente com o engenheiro de plantão para que ele dê um jeito de corrigir
    • Os SLAs de EC2 e GCP Compute são ambos exatamente 99,99%; se ficarem abaixo disso, há reembolso de 10%, e se caírem abaixo de 95%, reembolso de 100%
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Minha experiência é bem diferente. Usando AWS por anos, só tive uma instância interrompida uma vez por causa de alguma tarefa estranha em segundo plano da AWS, sem relação com a aplicação, e acho que nunca vi nem ouvi falar de uma instância simplesmente desaparecer
    • Na nuvem, em geral, como alguém disse, é preciso arquitetar com a suposição de que tudo falha o tempo todo

  • Interagi bastante com o Google Cloud Support, especialmente em relação a serviços gerenciados, e, para ser sincero, não fiquei muito impressionado em comparação com experiências de suporte que sempre foram excelentes em ambientes de uso da AWS de porte semelhante
    Dito isso, se alguém no Google Cloud realmente ajudou bem, é bom elogiar bastante. Como isso é raro, não custa muito garantir que a pessoa seja recompensada com um feedback positivo forte. Eu também tive quatro experiências realmente excelentes e sempre mandei mensagem imediatamente ao TAM. Espero que essas pessoas sejam recompensadas e promovidas

    • Sim. Esse tipo de discussão tende a virar um debate vi/emacs, e normalmente só reclamações chegam à primeira página do HN
      Usei GCP de forma intermitente em projetos por cerca de 10 anos e construí vários negócios bem-sucedidos em cima dele. Não foi perfeito, mas no geral fiquei satisfeito
      Em contraste, usei bastante a AWS em uma equipe que estava criando uma das primeiras versões hospedadas do Cloud Foundry, e não quero voltar. Era uma confusão sem fim

  • Houve uma vez, no GCP, um recurso bem corporativo que quebrou, e ficou claro que ele nunca tinha funcionado corretamente até aquele momento. Ao tentar corrigir silenciosamente, eles também causaram downtime, e os responsáveis do GCP, numa ligação em que deveriam explicar a causa, apenas repetiam que todos estavam sob NDA
    Admitir esse fato teria sido um pesadelo para setores regulados

    • Sempre me perguntei se um NDA pode impedir alguém de falar com órgãos reguladores, polícia, promotores ou uma instituição estatal de verdade, ou até de fazer uma denúncia interna. Quero acreditar que crimes sempre devem poder ser denunciados

  • “Às 8h52 PST de 1º de dezembro, uma máquina ficou offline e inacessível. E, depois do failover, deveria ter voltado automaticamente, mas não voltou. Enquanto o engenheiro principal de plantão recebia o alerta e investigava, outra máquina ficou offline e também não voltou”
    Isso não faz sentido. Uma máquina reiniciou e isso causou uma falha catastrófica? VMs reiniciam de vez em quando. Mas, se a configuração inteira foi projetada para desmoronar sozinha nesse cenário, eu não ficaria satisfeito, seja mudando para AWS ou até usando colocação própria

    • É preciso ler o texto com mais atenção. Mesmo no trecho citado, não diz que a máquina “reiniciou”, mas sim que não voltou a ficar online depois de um crash
      E em nenhum lugar do texto se diz que isso foi uma “falha catastrófica”. A Railway inteira não caiu, mas a Railway é uma empresa de deploy e revende recursos de computação para hospedar aplicações de clientes. Portanto, se uma VM cai e o failover automático não acontece, isso vira downtime para clientes específicos que rodavam serviços naquela máquina
      O texto também diz: “Durante o failover manual dessas máquinas, houve 10 minutos de downtime por host. Como muitos usuários executam workloads com vários serviços, esse downtime pode se multiplicar à medida que as máquinas ficam offline uma após a outra. Pedimos sinceras desculpas a todos os usuários”

  • Curiosamente, comecei a pensar que limiares não documentados parecem ser bastante comuns no GCP
    Passei por algo parecido no Cloud Run. Houve eventos de escalonamento que não eram explicados pelos critérios documentados de uso de CPU e número de requisições simultâneas que, segundo a documentação, controlam o scaling
    Depois de muito vai e vem com o suporte pago, descobri que havia um critério adicional relacionado à duração das requisições, mas, naturalmente, ninguém conseguiu explicar os detalhes

  • Parece uma experiência realmente frustrante. Dito isso, acho meio confuso que relação virtualização aninhada tem com esse problema, já que eles não estão usando virtualização dentro da VM. Soft lock geralmente é um sinal genérico de que não há progresso
    O comentário sobre instruções MMIO também é igualmente confuso. Se a questão é emulação de instruções, não sei por que importa onde ela acontece. De qualquer forma, será lenta e presa ao espaço de usuário; se precisa rodar rápido, o ideal é quase nunca sair do guest, e emulação menos ainda
    Dá a impressão de que o autor, frustrado, está tentando encontrar uma causa para eventos recentes agarrando-se a qualquer coisa que pareça compreensível

  • “Em 2022, enfrentamos falhas momentâneas persistentes de rede em produtos do Google Cloud. Depois de escalar várias vezes com o Google e ficarmos exaustos, criamos nossa própria stack de rede: uma rede WireGuard eBPF/IPv6 elástica que alimenta todos os deploys. Então, de repente, os problemas de rede desapareceram”
    Pelo que entendo, a rede para VMs é uma VLAN programada nos switches, e, ao criar uma VPC, provavelmente se cria uma VLAN; então fico curioso como um overlay UDP/WireGuard poderia ser mais estável se a rede subjacente é instável
    Além disso, se apenas 1/10 desse problema tivesse acontecido na AWS com um cliente assim, um exército de solution architects estaria de plantão numa sala de reunião semana sim, semana não revisando a arquitetura e colocando engenheiros de suporte nas chamadas

    • Não é que os switches sejam programados para criar VLANs; tudo é tratado como uma rede overlay
      É um material antigo, mas ajuda a ter uma noção: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • Se eu tivesse que chutar, é possível que as otimizações inteligentes de rede do Google estivessem conflitando com o tráfego deles
      Ao criar a própria stack de rede, eles contornaram essas otimizações, e talvez o WireGuard, por ser essencialmente construído sobre UDP não confiável, tenha conseguido lidar melhor com falhas intermitentes