Railway'nin özetlediği GCP kesintisi ve Google Cloud'dan ayrılma kararı

 (blog.railway.app)
1 puan yazan GN⁺ 2023-12-04 | 1 yorum | WhatsApp'ta paylaş
  • Railway, Google Cloud tabanlı platformunu işletirken us-west'teki bazı makinelerin sırayla durduğu ve otomatik yük devretmenin başarısız olduğu bir olay yaşadı; kullanıcı iş yüklerini geri getirmek için manuel müdahale gerekti
  • Tek tek instance'lar rolling şekilde yaklaşık 10'ar dakika çevrimdışı kaldı; olay 16:40 UTC'de başladı ve 20:53 UTC'de tüm iş yükleri için yük devretme ve hizmet kurtarma tamamlandı
  • Railway, önceki 18 ay boyunca ağ kararsızlığı, Artifact Registry kotasının düşürülmesi ve destek müdahalesi sorunları yaşadığını; bunun üzerine kendi ağ yığınını ve kendi registry'sini kurduğunu söyledi
  • İnceleme sırasında CPU soft lockup ile kvm_wait, __pv_queued_spin_lock_slowpath stack trace'leri görüldü; Railway, olası nedenin GCP guest ile hypervisor etkileşimi olduğunu düşünüyor
  • Railway, Google Cloud hizmetlerini sonlandırıp kendi bare metal instance altyapısına geçme kararı aldı; ilk instance'ı zaten devreye aldı ve 2024 içinde tam geçişi planlıyor

us-west'te yaşanan rolling kesinti

  • Railway, Google Cloud Platform ürünleri üzerinde, Google Compute Engine dahil, bir uygulama geliştirme platformu işletiyordu
  • 1 Aralık 2023 16:40 UTC'den itibaren us-west filosundaki bazı makineler teker teker yanıt veremez hale geldi
    • Her bir instance yaklaşık 10 dakika çevrimdışı kaldı
    • Kesinti rolling biçimde devam etti
    • Otomatik yük devretme çalışmadığı için manuel yük devretme gerekti
  • 20:53 UTC itibarıyla tüm iş yükleri için yük devretme başarıyla tamamlandı ve hizmet geri geldi
  • Railway, inceleme sonucunda GCP guest'teki userspace-to-kernel bellek aktarımı ile ilgili bir etkileşimin, kaynak baskısı altında nadiren softlock'a yol açabileceğini değerlendirdi

18 ay boyunca biriken Google Cloud sorunları

  • Railway, son 18 ayda Google Cloud ile ilgili çeşitli operasyonel sorunlar yaşadığını söyledi

  • Ağ kararsızlığı

    • 2022'de Google bulut ürünlerinde sürekli ağ kopmaları yaşandı
    • Google'a birden çok kez escalation yaptıktan sonra Railway kendi ağ yığınını kurdu
    • Bu özel yığın, dayanıklı bir eBPF/IPv6 Wireguard ağı ve şu anda tüm deployment'ları çalıştırıyor
    • Sonrasında ağ sorunları ortadan kalktı

  • Artifact Registry kotası

    • Railway, 2023'te Google'ın Artifact Registry kotasını fiilen sıfıra yakın bir seviyeye keyfi olarak düşürdüğünü söyledi
    • Image deployment throughput'u ciddi biçimde düştü ve build'ler gecikti
    • Bunun ardından Railway kendi registry ürününü geliştirdi ve registry throughput sorunu da ortadan kalktı

Destek süreci ve bare metal'e geçiş kararı

  • Railway, Google Cloud'a yılda milyonlarca dolar ödediğini ancak Google'ın attığı adımların Railway ve diğer müşterilerin iş yüklerini etkilediği durumlarda yeterli karşılık alamadığını düşünüyor
  • Kurucu ilgili sorunları X'te paylaştıktan sonra Google iletişime geçti ve Railway, Google VP'leriyle sorunun nedenini görüştü
  • Railway'ye göre bir Google mühendisi GCP kotalarını keyfi şekilde değiştirebiliyordu
    • Google VP'lerinin bunun kabul edilemez olduğu konusunda hemfikir olduğu aktarıldı
    • Railway, hazirandan sonra da retrospektif, resmi yanıt ve keyfi kota değişikliklerini önleyecek politika talep etmeyi sürdürdü
  • Railway, bu süreçte Google'ın önceden uyarı yapmadan ToS'u değiştirerek maliyetlerini %20 artırdığını da söyledi
    • Google bu konuya da yanıt vereceğini söyledi ancak Railway hâlâ bir yanıt almadığını belirtti
  • Railway, geçen çeyrekte tüm Google Cloud hizmetlerini sonlandırıp kendi bare metal instance altyapısına geçme yönünde iç karar aldığını açıkladı
    • İlk bare metal instance birkaç hafta önce devreye alındı
    • Tüm instance'ların taşınmasının 2024 içinde yapılması planlanıyor

30 Kasım ve 1 Aralık'taki kesintinin gelişimi

  • 30 Kasım 2023 21:41 UTC'de Google bir makineyi yeniden başlatırken bir kutu çevrimdışı kaldı
    • Railway'nin bu tür durumları algılayıp çözen otomatik sistemi bulunuyor
    • İlgili kutuda yük devretme düzgün şekilde gerçekleşti ve sayfa uyarısı oluşmadı
  • 1 Aralık 2023 16:52 UTC'de bir kutu erişilemez hale gelerek çevrimdışı kaldı
    • Otomatik yük devretmeden sonra da normal şekilde toparlanmadı
    • Birincil nöbetçi mühendis çağrıldı ve inceleme sürerken başka kutular da çevrimdışı olup geri dönmedi
  • Railway kutular için manuel yük devretme başlatmaya başladı
    • Her host'ta yaklaşık 10 dakika kesinti yaşandı
    • Kısa süre içinde yaklaşık 12 kutu etkilendi ve şirket personelinin yaklaşık yarısı runbook'u izleyerek müdahale etti
  • Google Cloud'un otomatik live migration'ına benzer serial log kalıpları nedeniyle, ilk değerlendirme Google'ın rutin yeniden başlatmalarından birinin hatalı çalıştığı yönündeydi
    • Google tarafındaki muhataba e-posta gönderildi ancak hemen otomatik bir izin/dışarıda yanıtı alındı

Serial console log'larında görülen ipuçları

  • Railway'nin ilk baktığı şey serial console log'ları oldu
    • Bu log'lar, sanallaştırılmış bir serial device üzerinden doğrudan kernel'den çıkıyor
  • Log'larda soft-locked CPU core ve kilitlenen CPU'nun stack trace'leri görüldü
    • Örnek girdiler arasında kvm_wait ve __pv_queued_spin_lock_slowpath yer alıyor
  • Railway'nin buna benzer log ve davranışı en son gördüğü zaman, Google'ın önceki yıl aralık ayında başlattığı yeniden başlatmalardı
    • O dönemde de üç kutuda aynı örüntü yaşandı
  • Ek incelemede, GCP'nin nested kernel virtualization ve soft lockup ile ilgili başlıklarıyla örtüşen kernel hataları bulundu
  • Railway, bu host'larda kendi sanallaştırmasını kullanmadığı için kvm ve paravirtualization ile ilgili mesajları, GCP hypervisor'ı ile etkileşen guest kernel kodunun işareti olarak yorumladı
  • GCP benzer sorunları yeniden üretilemedi diye kapatmış görünüyor ancak Railway, bu olayın aynı aileden olduğuna güçlü biçimde inanıyor

Tahmini neden ve hafifletme adımları

  • Railway, GCP guest'teki userspace-to-kernel bellek aktarımında potansiyel olarak kritik bir etkileşim olduğunu ve bunun nadir kaynak baskısı durumlarında softlock'a yol açtığını düşünüyor
  • Daha spesifik olarak, paravirtualized memory management ile hypervisor tarafında sayfaların map/remap edilme biçiminin belirli kaynak baskısı koşullarıyla ilişkili olduğunu değerlendiriyor
  • Benzer raporların neredeyse tamamının GCP kullanıcılarından gelmesi de ortak bir nokta olarak görülüyor
  • Google'ın MMIO komutlarının çoğunu userspace'te işlemesi de Railway'nin tahminiyle örtüşüyor
  • Bu değerlendirme doğruysa, CPU, bellek ve IOPS gözlem metriklerinde sınıra ulaşılmamış görünse bile, açıklanmayan hız sınırları, eşikler veya koşullar nedeniyle kutular softlock yaşayabilir
    • O sırada makineler yayımlanmış kaynak sınırlarının yaklaşık %50 seviyesindeydi
  • Railway, manuel yeniden başlatmadan sonra etkilenen instance'lardaki kaynak baskısını düşürmek için bazı iç servisleri devre dışı bıraktı; ardından instance'lar kararlı hale geldi

Kullanıcılara etkisi

  • Manuel yük devretme sırasında her makinede host başına 10 dakika kesinti yaşandı
  • Birçok kullanıcı çok hizmetli iş yükleri çalıştırdığı için, kutuların art arda çevrimdışı olması kesintinin birkaç kez birikmesine yol açmış olabilir
  • Railway, kullanıcılardan özür dileyerek daha yüksek güvenilirlik için kendi bare metal altyapısına geçtiğini belirtti

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-04
Hacker News görüşleri

  • 2 kişilik küçük bir yazılım şirketiyiz ve biz de yıllardır Google Adwords yüzünden Google ile çok sorun yaşadık. Örneğin:
    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/
    Google'a büyük meblağlar ödeyen yazının yazarına bile düzgün destek vermeye niyetleri yoksa, bizim gibi küçük işletmeler için ne umut kalıyor diye düşünüyorum

  • Genel olarak son birkaç yılda GCP'nin yönünü kaybettiğini düşünüyorum. Birkaç yıl önce bile bilgi işlem, depolama ve bant genişliğinde fiyat/performans açısından AWS'den anlamlı biçimde daha iyi bir seçenekti; bunu kendi iş yüklerimiz için ayrıntılı performans testleri ve maliyet modellemesi yaparak doğrulamıştık
    O dönemde destek de harikaydı. Başta açtığımız belirsiz bir ağ sorunu bileti hızla eskale edildi, farklı bölgelerdeki mühendisler devralarak çözdü ve sonunda GCP tarafındaki bir değişiklik geri alındı. Satış temsilcisi de iç kaynakları hızla devreye sokuyordu; genel deneyim olumluydu
    Şimdi ise AWS fiyat/performansta açıkça yetişti ve birçok yönetilen hizmette hâlâ birkaç yıl önde. Buna karşılık GCP desteği ciddi biçimde kötüleşti; çoğu şey dış destek sağlayıcılarına gidiyor gibi duruyor ve onların gerçek GCP altyapısına görünürlüğü bizden pek daha iyi değil gibi
    Satış deneyimi de çok daha kötüleşti ve mevcut temsilci açıkça eksi yazıyor. GCP'ye büyük yatırım yaptık ama iyileşme belirtisi görmediğimiz için GCP harcamalarını azaltma çalışmalarını aktif biçimde yürütüyoruz; eskiden GCP savunucusuydum ama artık yeni projeleri GCP'ye koymayı önermek zor

  • Tüm bulut sağlayıcılarında sorunlar olduğu doğru. Son 2 yılda işte Keyspaces, Amazon Aurora ve App Runner ile ilgili birçok sorun bulup raporladım; hepsi performans düşüşüne yol açtı ve AWS desteği bizi alakasız yerlere bakmaya zorlayarak zaman kaybettirdi
    Haftalar süren eskalasyonlardan sonra ancak proje sahipleri sorunları kabul etti; bunların bazılarının zaten bilinen problemler olduğu ortaya çıktı ama destek ekibi yine de zamanımızı boşa harcattı. Şimdilik Keyspaces'e bağlıyız ama artık EC2, EBS ve S3 gibi çekirdek hizmetler dışında kullanmamaya çalışıyorum. Onların dışına çıkınca risk başlıyor

    • Kesinlikle öyle. AWS hizmetlerinin yaklaşık yarısı ya kötü tasarlanmış ya kötü işletiliyor ya da ikisi birden gibi geliyor. CloudWatch özellikle çok hatalı ve yavaş; neredeyse acemiler için bir tuzak gibi görünüyor
      Bir şirketin tüm loglar için CloudWatch kullandığını görünce, bunun muhtemelen diğer seçenekleri bilmeyen deneyimsizlikten kaynaklandığını varsayıyorum. Yine de bilgi işlem hizmetleri güvenilir

  • GCP'de tek bir bilgi işlem örneğinin düşmesini eleştirmek komik. Yazının yazarı da bunun nadir bir olay olduğunu kabul ediyor ama ben AWS'de örneklerin zorla durdurulmasına ya da tamamen ortadan kaybolmasına sık sık rastladım. 99.95% dayanıklılık ile 99.999% arasında büyük fark var
    Aynı mimariyi AWS üzerinde kursalardı, tecrübeme göre sürekli kesintiler yaşarlardı. AWS dokümantasyonu ve kendi deneyimime göre AWS'nin temel bileşenleri GCP'den çok daha az kararlı

    • Yazı aslında AWS'yi özellikle ele almıyor gibi. Esas sorun da tek bir örneğin düşmesi değil, büyük bir kurumsal ortak için bile iletişim ve desteğin yetersiz olması gibi görünüyor
      Bunlar bare metal'e geçmeyi düşünüyor gibi; orada nöbetçi mühendise doğrudan "bunu bir şekilde düzelt" diyebilmenin bariz bir avantajı var
    • EC2 ve GCP Compute için SLA her ikisinde de tam olarak 99.99%; bunun altına düşerse %10 geri ödeme, %95'in altına düşerse %100 geri ödeme var
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Benim deneyimim ise çok farklı. AWS'yi yıllardır kullanıyorum; uygulamayla ilgisiz tuhaf AWS arka plan işleri yüzünden bir örneğin durdurulduğunu sadece bir kez gördüm, bir örneğin kendiliğinden yok olduğunu ise ne yaşadım ne de duyduğumu hatırlıyorum
    • Bulutta genel olarak, birinin dediği gibi, her şeyin her zaman başarısız olacağını varsayarak mimari kurmak gerekir

  • Google Cloud Support ile, özellikle yönetilen hizmetler konusunda, çok etkileşimim oldu; benzer ölçekte AWS kullandığım ortamlarda destek deneyimi hep harikayken, açıkçası burası pek etkileyici değildi
    Yine de Google Cloud'da biri gerçekten çok yardımcı olduysa bunu güçlü biçimde takdir etmek iyi olur. Bu kadar nadir yaşandığı için, güçlü olumlu geri bildirimle ödüllendirilmelerini sağlamak büyük bir külfet değil. Benim de gerçekten harika geçen dört deneyimim oldu ve her seferinde hemen TAM'e mesaj attım. Umarım bu insanlar ödüllendirilir ve terfi eder

    • Evet. Bu tür tartışmalar kolayca vi/emacs çekişmesine dönüşebiliyor ve HN ana sayfasına genelde yalnızca şikâyetler çıkıyor
      GCP'yi yaklaşık 10 yıldır projelerde aralıklı olarak kullanıyorum ve üzerinde başarılı birçok iş de kurdum. Kusursuz değildi ama genel olarak memnunum
      Buna karşılık Cloud Foundry'nin ilk barındırılan sürümünü yapan ekipte AWS'yi yoğun kullanmıştım; geri dönmek istemem. Bitmek bilmeyen bir hengâmeydi

  • GCP’de oldukça kurumsal sayılabilecek bir özelliğin bozulduğu bir durum olmuştu; üstelik o özelliğin o ana kadar aslında hiç düzgün çalışmadığı açıkça ortaya çıktı. Bunu sessizce düzeltmeye çalışırken bir de kesinti yaşattılar ve GCP yetkilileri, nedeni açıklamaları gereken görüşmede herkesin NDA kapsamında olduğunu hatırlatıp durdu.
    Bunu kabul etmek düzenlemeye tabi sektörler için bir kâbus olurdu.

    • NDA’nın düzenleyici kurumlara, polise, savcılara veya gerçek devlet kurumlarına konuşmayı ya da içeriden ihbar yapmayı engelleyip engelleyemeyeceğini hep merak etmişimdir. Suçların her durumda bildirilebilmesi gerektiğini düşünmek istiyorum.

  • “1 Aralık saat 08:52 PST’de bir kutu çevrimdışı oldu ve erişilemez hale geldi. Ardından failover sonrasında otomatik olarak geri gelmesi gerekirken gelmedi. Birincil on-call mühendis uyarıyı alıp incelerken başka bir kutu daha çevrimdışı oldu ve o da geri gelmedi.”
    Bu kulağa mantıklı gelmiyor. Makine yeniden başladı diye felaket düzeyinde bir arıza mı yaşandı? VM’ler zaman zaman yeniden başlar. Ama o senaryoda tüm yapının kendi kendine çökmesine yol açacak şekilde tasarlandıysa, AWS’ye taşınsalar da hatta kendi colocation altyapılarını kullansalar da hoşuma gitmez.

    • Yazıyı daha dikkatli okumak lazım. Alıntıladığınız bölümde bile makinenin “yeniden başladığı” söylenmiyor; çöktükten sonra tekrar çevrimiçi dönmediği söyleniyor.
      Ayrıca yazının hiçbir yerinde bunun “felaket düzeyinde bir arıza” olduğu da söylenmiyor. Railway’nin tamamı gitmedi, ancak Railway bir deployment şirketi olarak müşterilerin uygulamalarını dağıtmak için işlem kaynaklarını yeniden satıyor. Bu yüzden bir VM düşer ve otomatik failover çalışmazsa, o makinede servis çalıştıran belirli müşteriler için bu kesinti anlamına gelir.
      Yazıda ayrıca şöyle deniyor: “Bu makineleri manuel failover ile taşırken host başına 10 dakikalık kesinti yaşandı. Birçok kullanıcı çok servisli iş yükleri çalıştırdığından, kutular sırayla çevrimdışı oldukça bu kesinti katlanabilir. Tüm kullanıcılarımızdan içtenlikle özür dileriz.”

  • İlginç şekilde, GCP’de dokümante edilmemiş eşiklerin epey yaygın olmaya başladığını düşünmeye başladım.
    Cloud Run’da da benzer bir şey yaşadım. Belgelerde ölçeklemeyi belirlediği söylenen CPU kullanımı ve eşzamanlı istek sayısı ile açıklanamayan ölçekleme olayları vardı.
    Ücretli destekle uzun bir yazışma trafiğinden sonra, istek süresiyle ilgili ek bir kriter daha olduğunu öğrendim; ama doğal olarak kimse bunu ayrıntılı biçimde açıklayamadı.

  • Gerçekten sinir bozucu bir deneyim gibi geliyor. Ama VM içinde sanallaştırma kullanılmıyorsa nested virtualization ile bunun nasıl bağlantılı olduğu biraz kafa karıştırıcı. Soft lockup genelde ilerlemenin durduğunu gösteren genel bir işarettir.
    MMIO komutlarıyla ilgili yorum da benzer şekilde kafamı karıştırıyor. Eğer kastedilen komut emülasyonuysa, bunun nerede gerçekleştiğinin neden önemli olduğunu anlamıyorum. Sonuçta zaten yavaş olacak ve kullanıcı alanına taşınacak; hızlı çalışması gerekiyorsa misafir sistemden çıkışın neredeyse hiç olmaması, hele emülasyonun hiç olmaması gerekir.
    Yazarın büyük hayal kırıklığı yaşayıp son olayla ilgili anlayabildiği her şeye tutunarak kök nedeni bulmaya çalıştığı hissi veriyor.

  • “2022’de Google bulut ürünlerinde sürekli kısa süreli ağ kesintileri yaşadık. Google’a defalarca escalation yaptıktan sonra bıktık ve kendi ağ yığınımızı, yani tüm deployment’ları çalıştıran esnek bir eBPF/IPv6 Wireguard ağını kurduk. Sonra birden ağ sorunları ortadan kayboldu.”
    Benim anladığım kadarıyla VM ağı, switch’lere programlanan VLAN’lardan oluşuyor ve VPC oluşturduğunuzda muhtemelen bir VLAN oluşturuluyor; o yüzden alttaki ağ kararsızsa, üstteki UDP/WireGuard overlay’inin nasıl daha kararlı olabildiğini merak ediyorum.
    Ayrıca şunu da ekleyeyim: AWS’de bu müşterinin yaşadıklarının onda biri bile olsa, çözüm mimarlarından oluşan bir ekip iki haftada bir toplantı odasına yerleşir, mimariyi gözden geçirir ve destek mühendislerini görüşmelere dahil ederdi.

    • Switch’leri programlayıp VLAN oluşturmak söz konusu değil; her şey overlay network olarak ele alınıyor.
      Eski bir kaynak ama fikir vermeye yardımcı olabilir: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • Tahminimce Google’ın akıllı ağ optimizasyonları onların trafiğiyle çakışmış olabilir.
      Kendi ağ yığınlarını kurunca bu optimizasyonları baypas ettiler ve WireGuard da doğası gereği güvenilmez UDP üzerine kurulduğundan, aralıklı kesintileri daha iyi tolere etmiş olabilir.