Railway explica la falla de GCP y su decisión de salir de Google Cloud

 (blog.railway.app)
1 puntos por GN⁺ 2023-12-04 | 1 comentarios | Compartir por WhatsApp
  • Railway sufrió un incidente mientras operaba una plataforma basada en Google Cloud: algunas máquinas en us-west se fueron deteniendo de forma secuencial y el failover automático falló, por lo que fue necesaria una intervención manual para recuperar las cargas de trabajo de los usuarios
  • Cada instancia estuvo offline unos 10 minutos en un esquema rolling, y tras comenzar a las 16:40 UTC, el failover de todas las cargas de trabajo y la recuperación del servicio finalizaron a las 20:53 UTC
  • Durante los 18 meses anteriores, Railway enfrentó inestabilidad de networking, reducción de cuotas de Artifact Registry y problemas con la respuesta de soporte, lo que la llevó a construir su propia pila de red y su propio registro
  • En la investigación se detectaron CPU soft lockups y stack traces con kvm_wait y __pv_queued_spin_lock_slowpath; Railway considera que la causa probable fue una interacción entre el guest de GCP y el hipervisor
  • Railway decidió dejar de usar los servicios de Google Cloud y migrar a sus propias instancias bare metal; ya levantó la primera instancia y planea completar la migración durante 2024

Falla rolling ocurrida en us-west

  • Railway venía operando su plataforma de desarrollo de aplicaciones sobre productos de Google Cloud Platform, incluido Google Compute Engine
  • A partir del 1 de diciembre de 2023 a las 16:40 UTC, algunas máquinas del fleet de us-west empezaron a quedar sin respuesta una por una
    • Cada instancia estuvo offline aproximadamente 10 minutos
    • La falla continuó en modalidad rolling
    • Como no hubo failover automático, fue necesario hacer failover manual
  • A las 20:53 UTC, el failover de todas las cargas de trabajo se había completado correctamente y el servicio quedó restaurado
  • Tras investigar, Railway concluyó que una interacción relacionada con la transferencia de memoria de userspace a kernel en el guest de GCP puede provocar, en casos poco frecuentes, un softlock bajo presión de recursos

Problemas acumulados con Google Cloud durante 18 meses

  • Railway tuvo varios problemas operativos relacionados con Google Cloud durante los últimos 18 meses

  • Inestabilidad de networking

    • En 2022, se produjeron cortes persistentes de networking en productos de Google Cloud
    • Después de escalar el problema varias veces con Google, Railway construyó su propia pila de networking
    • Esa pila propia es una red resiliente basada en eBPF/IPv6 WireGuard y actualmente impulsa todos los despliegues
    • Desde entonces, los problemas de networking desaparecieron

  • Cuotas de Artifact Registry

    • Railway afirmó que, en 2023, Google redujo arbitrariamente las cuotas de Artifact Registry a un nivel prácticamente cercano a cero
    • El throughput de despliegue de imágenes cayó de forma considerable y las builds se retrasaron
    • Luego Railway creó su propio producto de registry, y los problemas de throughput del registro también desaparecieron

Respuesta de soporte y decisión de migrar a bare metal

  • Railway pagaba millones de dólares al año a Google Cloud, pero consideró que no recibió una respuesta suficiente ante una situación en la que acciones de Google afectaban las cargas de trabajo de Railway y de otros clientes
  • Después de que el fundador publicara los problemas relacionados en X, Google se puso en contacto, y Railway conversó con VPs de Google sobre la causa de los problemas
  • Según Railway, un ingeniero de Google podía cambiar arbitrariamente las cuotas de GCP
    • Los VPs de Google habrían coincidido en que ese problema era inaceptable
    • Desde junio, Railway sigue solicitando una retrospectiva, una respuesta oficial y una política para evitar cambios arbitrarios de cuotas
  • En ese proceso, Railway afirmó que Google cambió los ToS sin aviso previo, lo que elevó los costos de Railway en 20%
    • Google dijo que también respondería sobre ese tema, pero Railway afirma que todavía no recibió respuesta
  • El trimestre pasado, Railway tomó internamente la decisión de cerrar todos los servicios de Google Cloud y moverse a sus propias instancias bare metal
    • La primera instancia bare metal se levantó hace unas semanas
    • La migración completa de instancias está prevista para 2024

Desarrollo de las fallas del 30 de noviembre y el 1 de diciembre

  • El 30 de noviembre de 2023 a las 21:41 UTC, una máquina quedó offline cuando Google reinició una máquina
    • Railway cuenta con sistemas automáticos para detectar y resolver este tipo de situaciones
    • Esa máquina hizo failover correctamente y no se generó ninguna alerta de pager
  • El 1 de diciembre de 2023 a las 16:52 UTC, una máquina quedó offline en un estado inaccesible
    • Incluso después del failover automático, no se recuperó correctamente
    • Se convocó al ingeniero principal on-call y, durante la investigación, otra máquina también quedó offline y luego no se recuperó
  • Railway empezó a hacer failover manual de las máquinas
    • Se produjo alrededor de 10 minutos de downtime por cada host
    • Poco después, unas 12 máquinas se vieron afectadas y aproximadamente la mitad del personal de la empresa respondió siguiendo los runbooks
  • Debido a patrones en el serial log similares a la live migration automática de Google Cloud, inicialmente se interpretó que se trataba de un reinicio rutinario de Google que había salido mal
    • Enviaron un correo al responsable del lado de Google, pero recibieron de inmediato una respuesta automática de ausencia

Pistas observadas en los logs de la serial console

  • Lo primero que revisó Railway fueron los logs de la serial console
    • Estos logs salen directamente del kernel a través de un dispositivo serial virtualizado
  • En los logs aparecieron cores de CPU en soft lock y stack traces de la CPU bloqueada
    • Algunos ejemplos fueron kvm_wait y __pv_queued_spin_lock_slowpath
  • La última vez que Railway había visto logs y comportamientos similares fue durante los reinicios iniciados por Google en diciembre del año anterior
    • En esa ocasión, tres máquinas mostraron el mismo patrón
  • En una investigación adicional, encontraron errores de kernel que coincidían con hilos relacionados con nested kernel virtualization y soft lockups en GCP
  • Como Railway no usaba virtualización propia en esos hosts, interpretó los mensajes relacionados con kvm y paravirtualization como una señal de código del kernel guest interactuando con el hipervisor de GCP
  • GCP parece haber tratado un problema similar como no reproducible, pero Railway considera firmemente que este incidente pertenece a la misma familia

Causa estimada y medidas de mitigación

  • Railway cree que existe una interacción potencialmente fatal en la transferencia de memoria de userspace a kernel del guest de GCP, que provoca un softlock bajo ciertas condiciones poco frecuentes de presión de recursos
  • Más específicamente, considera que la gestión de memoria paravirtualized y la forma en que las páginas se mapean y remapean en el hipervisor están relacionadas con ciertas condiciones de presión de recursos
  • También ve como punto común que casi todos los reportes similares provienen de usuarios de GCP
  • El hecho de que Google procese la mayor parte de los comandos MMIO en userspace también encaja con la hipótesis de Railway
  • Si esta interpretación es correcta, una máquina podría caer en softlock por límites de velocidad, umbrales o condiciones no publicados, incluso cuando las métricas observables de CPU, memoria e IOPS estén por debajo de los límites
    • En ese momento, las máquinas estaban alrededor del 50% de los límites de recursos publicados
  • Después de reinicios manuales, Railway desactivó algunos servicios internos para reducir la presión de recursos en las instancias afectadas, y luego las instancias se estabilizaron

Impacto en los usuarios

  • Durante el failover manual, cada máquina sufrió 10 minutos por host de downtime
  • Como varios usuarios ejecutaban cargas de trabajo con múltiples servicios, el downtime pudo acumularse varias veces a medida que las máquinas quedaban offline en secuencia
  • Railway pidió disculpas a los usuarios y afirmó que está migrando a bare metal propio para lograr mayor confiabilidad

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-04
Opiniones de Hacker News

  • Somos una pequeña empresa de software de 2 personas, y nosotros también tuvimos muchos problemas con Google durante años por Google Adwords. Por ejemplo:
    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 no están dispuestos a darle soporte adecuado al autor original, que le paga enormes sumas a Google, qué esperanza podemos tener los pequeños negocios como nosotros

  • En general, creo que en los últimos años GCP perdió el rumbo. Hace unos años, en términos de precio/rendimiento para cómputo, almacenamiento y ancho de banda, era una opción significativamente mejor que AWS, y lo habíamos confirmado haciendo pruebas detalladas de rendimiento y modelado de costos para nuestras cargas de trabajo
    El soporte en ese entonces también era excelente. Un ticket inicial por un problema de red ambiguo se escaló rápidamente, ingenieros de varias regiones lo fueron tomando hasta resolverlo y, al final, se revirtió un cambio del lado de GCP. El representante de ventas también nos conectó rápido con recursos internos, así que toda la experiencia fue positiva
    Ahora AWS definitivamente ya alcanzó a GCP en precio/rendimiento, y en varios servicios administrados sigue estando varios años adelante. En cambio, el soporte de GCP empeoró mucho; parece que la mayoría va a proveedores de soporte tercerizados, y no parecen tener mucha más visibilidad sobre la infraestructura real de GCP que nosotros
    La experiencia comercial también se volvió mucho peor, y nuestro representante actual es claramente un punto negativo. Hemos invertido mucho en GCP, pero como no vemos señales de mejora, estamos trabajando activamente en reducir el gasto en GCP. Antes era defensor de GCP, pero ahora me cuesta recomendar montar proyectos nuevos ahí

  • Es cierto que todos los proveedores cloud tienen problemas. En los últimos 2 años, en el trabajo detecté y reporté varios problemas relacionados con Keyspaces, Amazon Aurora y App Runner; todos derivaban en degradación de rendimiento, y el soporte de AWS nos hizo perder tiempo llevándonos a investigar por el lado equivocado
    Solo después de semanas de escalamiento los responsables de los proyectos reconocieron los problemas, y algunos de ellos ya eran problemas conocidos, aun así el equipo de soporte nos hizo perder tiempo. Por ahora estamos atados a Keyspaces, pero de ahora en adelante intento no usar nada que no sean servicios centrales como EC2, EBS y S3. Si te sales de eso, es riesgoso

    • Totalmente. Siento que más o menos la mitad de los servicios de AWS están mal diseñados, mal operados, o ambas cosas. CloudWatch en particular tiene muchísimos bugs y es lento; en la práctica parece una trampa para principiantes
      Cuando veo que una empresa usa CloudWatch para todos sus logs, tiendo a pensar que es por falta de experiencia y por no conocer las muchas alternativas. Aun así, los servicios de cómputo sí son confiables

  • Me parece ridículo culpar a GCP porque se cayó una instancia de cómputo. El autor original también reconoce que fue un caso raro, pero en AWS me pasó muchas veces que una instancia se detuviera forzosamente o directamente desapareciera. 99.95% de durabilidad y 99.999% son cosas muy distintas
    Si hubieran montado la misma arquitectura en AWS, por experiencia creo que habrían tenido caídas constantemente. Según la documentación de AWS y mi experiencia, los componentes básicos de AWS son mucho menos estables que los de GCP

    • No parece que el artículo realmente trate sobre AWS. El problema central tampoco parece ser que una sola instancia se haya caído, sino la falta de comunicación y soporte, incluso para un socio corporativo grande
      Parece que quieren moverse a bare metal, lo cual tiene la clara ventaja de poder decirle directamente a un ingeniero de guardia que lo arregle como sea
    • Los SLA de EC2 y GCP Compute son ambos exactamente de 99.99%; si bajan de eso hay un reembolso del 10%, y si caen por debajo del 95% hay un reembolso del 100%
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Mi experiencia es muy distinta. Usé AWS durante años y solo una vez se detuvo una instancia por algún proceso raro de AWS en segundo plano, ajeno a la aplicación. No creo haber vivido ni escuchado que una instancia simplemente desapareciera
    • En la nube, en general, como dijo alguien, hay que diseñar la arquitectura con la suposición de que todo falla todo el tiempo

  • He interactuado bastante con Google Cloud Support, especialmente por servicios administrados, y la verdad no me impresionó demasiado en comparación con la experiencia de soporte que siempre fue excelente en entornos de AWS de tamaño similar
    Dicho eso, si alguien en Google Cloud realmente te ayudó bien, conviene elogiarlo mucho. Como esas ocasiones son raras, no cuesta mucho dar feedback positivo fuerte para que se lo reconozcan. Yo tuve cuatro experiencias realmente excelentes y siempre le mandé un mensaje de inmediato al TAM. Espero que esas personas sean recompensadas y promovidas

    • Sí. Este tipo de discusiones fácilmente se vuelven como el debate vi/emacs, y a la portada de HN normalmente solo llegan las quejas
      He usado GCP de forma intermitente en proyectos durante unos 10 años, y también construí varios negocios exitosos sobre él. No fue perfecto, pero en general quedé satisfecho
      En cambio, usé mucho AWS en el equipo que creó una de las primeras versiones hospedadas de Cloud Foundry, y no quisiera volver. Era un alboroto interminable

  • En GCP hubo una función muy de enterprise que se rompió, y quedó claro que esa función nunca había funcionado correctamente hasta ese momento. Intentaron arreglarla en silencio, pero también provocaron downtime, y las personas responsables de GCP, en la llamada en la que debían explicar la causa, solo repetían que todos estaban bajo NDA
    Admitir ese hecho habría sido una pesadilla para las industrias reguladas

    • Siempre me pregunto si un NDA puede impedir hablar o denunciar ante reguladores, la policía, fiscales o una entidad estatal real. Me gustaría pensar que los delitos siempre deberían poder denunciarse

  • “El 1 de diciembre a las 8:52 a. m. PST, una caja quedó offline y se volvió inaccesible. Y aunque debía volver automáticamente después del failover, no lo hizo. Mientras el ingeniero principal on-call recibía la alerta e investigaba, otra caja quedó offline y tampoco volvió”
    Esto no tiene sentido. ¿Una máquina se reinició y hubo una falla catastrófica? Las VM se reinician de vez en cuando. Pero si diseñaron toda la configuración para que se desmoronara sola en ese escenario, no me gustaría, ya sea que se muden a AWS o incluso que usen su propia colocación

    • Hay que leer el texto con más cuidado. Incluso en la parte citada no dice que la máquina se “reinició”, sino que después de crashear no volvió a estar online
      Y en ninguna parte del texto se dice que esto fuera una “falla catastrófica”. No se cayó todo Railway, pero Railway es una empresa de despliegue y revende recursos de cómputo para desplegar aplicaciones de clientes. Por lo tanto, si una VM se cae y el failover automático no funciona, eso causa downtime para los clientes específicos que ejecutaban servicios en esa máquina
      El texto también dice: “Mientras hacíamos failover manual de estas máquinas, hubo 10 minutos de downtime por host. Como muchos usuarios ejecutan workloads con múltiples servicios, este downtime puede multiplicarse a medida que las cajas se van quedando offline una tras otra. Pedimos profundas disculpas a todos los usuarios”

  • Curiosamente, empiezo a pensar que en GCP parecen ser bastante comunes los umbrales no documentados
    En Cloud Run me pasó algo parecido. Hubo eventos de escalado que no se explicaban con los criterios documentados de uso de CPU y cantidad de solicitudes concurrentes, que supuestamente controlan el escalado
    Después de mucho ir y venir con el soporte pago, me enteré de que había un criterio adicional relacionado con la duración de las solicitudes, pero, por supuesto, nadie pudo explicarlo en detalle

  • Suena como una experiencia realmente frustrante. Dicho eso, me confunde un poco qué tiene que ver la virtualización anidada con este problema si no están usando virtualización dentro de la VM. Un soft lockup suele ser una señal general de que no hay progreso
    El comentario sobre instrucciones MMIO también me resulta igual de confuso. Si se refieren a emulación de instrucciones, no entiendo por qué importa dónde ocurre. De todos modos será lenta y quedará ligada al espacio de usuario; si tiene que funcionar rápido, casi no debería haber exits del guest, y mucho menos emulación
    Da la impresión de que el autor, por frustración, está intentando aferrarse a cualquier cosa comprensible sobre el incidente reciente para encontrar una causa

  • “En 2022 sufrimos fallas breves y persistentes de red en productos de Google Cloud. Después de escalarlo varias veces con Google, nos cansamos y construimos nuestro propio stack de networking: una red WireGuard eBPF/IPv6 elástica que impulsa todos los despliegues. Entonces, de pronto, los problemas de red desaparecieron”
    Según entiendo, la red para VM son VLAN programadas en switches, y cuando se crea una VPC probablemente se crea una VLAN; si la red subyacente es inestable, me pregunto cómo UDP/WireGuard como overlay podría ser más estable
    Además, para un cliente así, si en AWS hubiera ocurrido apenas 1/10 de este problema, una legión de solution architects habría estado ocupando una sala de reuniones cada dos semanas para revisar la arquitectura y sumar ingenieros de soporte a las llamadas

    • No es que se programen switches para crear VLAN; todo se maneja como una red overlay
      Es material viejo, pero sirve para hacerse una idea: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • Especulando, es posible que las optimizaciones inteligentes de red de Google chocaran con el tráfico de ellos
      Al construir su propio stack de red, evitaron esas optimizaciones, y tal vez WireGuard, al estar construido esencialmente sobre UDP no confiable, pudo manejar mejor las fallas intermitentes