Railway merangkum gangguan GCP dan memutuskan meninggalkan Google Cloud

 (blog.railway.app)
1 poin oleh GN⁺ 2023-12-04 | 1 komentar | Bagikan ke WhatsApp
  • Railway mengalami insiden saat mengoperasikan platform berbasis Google Cloud, di mana sebagian mesin di us-west berhenti secara bergiliran dan failover otomatis gagal, sehingga pemulihan workload pengguna memerlukan penanganan manual
  • Setiap instance mengalami offline sekitar 10 menit secara rolling, dimulai pada 16:40 UTC dan seluruh failover workload serta pemulihan layanan selesai pada 20:53 UTC
  • Selama 18 bulan sebelumnya, Railway mengalami ketidakstabilan jaringan, pengurangan kuota Artifact Registry, dan masalah respons dukungan, lalu membangun stack jaringan dan registry sendiri
  • Dalam proses investigasi, ditemukan CPU soft lockup serta stack trace kvm_wait dan __pv_queued_spin_lock_slowpath, dan Railway menilai interaksi antara guest GCP dan hypervisor sebagai penyebab yang paling mungkin
  • Railway memutuskan menghentikan penggunaan layanan Google Cloud dan bermigrasi ke instance bare metal miliknya sendiri; instance pertama sudah dijalankan dan migrasi penuh direncanakan pada 2024

Gangguan rolling yang terjadi di us-west

  • Railway telah mengoperasikan platform pengembangan aplikasi di atas produk Google Cloud Platform seperti Google Compute Engine
  • Sejak 1 Desember 2023 pukul 16:40 UTC, sebagian mesin dalam fleet us-west menjadi tidak responsif satu per satu
    • Setiap instance berada dalam kondisi offline sekitar 10 menit
    • Gangguan berlanjut secara rolling
    • Failover otomatis tidak berjalan sehingga diperlukan failover manual
  • Pada 20:53 UTC, seluruh failover workload berhasil dan layanan pulih
  • Berdasarkan hasil investigasi, Railway menilai interaksi terkait transfer memori userspace-to-kernel pada guest GCP dalam kondisi tekanan sumber daya dapat, meski jarang, memicu softlock

Akumulasi masalah Google Cloud selama 18 bulan

  • Selama 18 bulan terakhir, Railway mengalami berbagai masalah operasional terkait Google Cloud

  • Ketidakstabilan jaringan

    • Pada 2022, terjadi putus-sambung jaringan yang berkelanjutan pada produk cloud Google
    • Setelah beberapa kali eskalasi ke Google, Railway membangun stack jaringannya sendiri
    • Stack tersebut adalah jaringan Wireguard eBPF/IPv6 yang tangguh dan kini menjalankan seluruh deployment
    • Setelah itu, masalah jaringan menghilang

  • Kuota Artifact Registry

    • Pada 2023, Railway menyatakan Google secara sepihak menurunkan kuota Artifact Registry hingga praktis mendekati 0
    • Throughput pemrosesan deployment image turun besar sehingga build tertunda
    • Setelah itu Railway membuat produk registry sendiri, dan masalah throughput registry juga hilang

Respons dukungan dan keputusan pindah ke bare metal

  • Railway menilai bahwa meskipun membayar jutaan dolar per tahun kepada Google Cloud, mereka tidak menerima respons yang memadai ketika tindakan Google memengaruhi workload Railway maupun pelanggan lain
  • Setelah pendirinya memposting masalah terkait di X, Google menghubungi Railway, dan Railway membahas akar masalah dengan para VP Google
  • Menurut Railway, seorang engineer Google dapat mengubah kuota GCP secara sepihak
    • Para VP Google disebut setuju bahwa masalah ini tidak dapat diterima
    • Bahkan setelah Juni, Railway masih terus meminta retrospektif, jawaban resmi, dan kebijakan pencegahan perubahan kuota sepihak
  • Dalam proses ini, Railway menyatakan Google mengubah ToS tanpa peringatan sebelumnya sehingga biaya Railway naik 20%
    • Google mengatakan akan menjawab masalah ini juga, tetapi Railway menyebut belum menerima jawaban
  • Pada kuartal lalu, Railway mengambil keputusan internal untuk menghentikan seluruh layanan Google Cloud dan berpindah ke instance bare metal miliknya sendiri
    • Instance bare metal pertama dijalankan beberapa minggu lalu
    • Migrasi seluruh instance dijadwalkan berlangsung pada 2024

Perkembangan gangguan pada 30 November dan 1 Desember

  • Pada 30 November 2023 pukul 21:41 UTC, satu box menjadi offline saat Google me-restart mesin
    • Railway memiliki sistem otomatis untuk mendeteksi dan menangani situasi seperti ini
    • Box tersebut berhasil difailover dengan normal dan tidak memicu page
  • Pada 1 Desember 2023 pukul 16:52 UTC, satu box menjadi offline dalam keadaan tidak dapat diakses
    • Setelah failover otomatis, pemulihan normal tetap tidak terjadi
    • Engineer on-call utama dipanggil, dan saat investigasi berlangsung box lain juga menjadi offline lalu gagal pulih
  • Railway mulai melakukan failover box secara manual
    • Terjadi downtime sekitar 10 menit per host
    • Tak lama kemudian sekitar 12 box terdampak, dan sekitar separuh staf perusahaan merespons mengikuti runbook
  • Karena pola serial log-nya mirip live migration otomatis dari Google Cloud, pada awalnya Railway menilai ini sebagai restart rutin Google yang bermasalah
    • Email dikirim ke kontak penanggung jawab di Google, tetapi yang diterima segera hanyalah balasan otomatis sedang tidak di tempat

Petunjuk yang terlihat di log serial console

  • Hal pertama yang diperiksa Railway adalah log serial console
    • Log ini keluar langsung dari kernel melalui serial device yang tervirtualisasi
  • Log menunjukkan CPU core yang soft-locked dan stack trace CPU yang terkunci
    • Contoh entri adalah kvm_wait, __pv_queued_spin_lock_slowpath
  • Terakhir kali Railway melihat log dan perilaku serupa adalah saat restart yang dimulai Google pada Desember tahun sebelumnya
    • Saat itu, pola yang sama juga muncul pada tiga box
  • Dalam investigasi lanjutan, mereka menemukan error kernel yang cocok dengan thread terkait nested kernel virtualization dan soft lockup di GCP
  • Karena Railway tidak menggunakan virtualisasi sendiri pada host tersebut, mereka menafsirkan pesan terkait kvm dan paravirtualization sebagai sinyal dari kode kernel guest yang berinteraksi dengan hypervisor GCP
  • GCP tampaknya menangani masalah serupa sebagai tidak dapat direproduksi, tetapi Railway sangat yakin insiden kali ini berada dalam keluarga yang sama

Dugaan penyebab dan langkah mitigasi

  • Railway menilai ada interaksi yang berpotensi fatal dalam transfer memori userspace-to-kernel pada guest GCP, yang dapat memicu softlock dalam kondisi tekanan sumber daya yang jarang terjadi
  • Lebih spesifik lagi, mereka menilai hal ini terkait dengan paravirtualized memory management dan cara halaman dimapping serta dipetakan ulang di hypervisor dalam kondisi tekanan sumber daya tertentu
  • Mereka juga melihat kesamaan pada fakta bahwa hampir semua laporan serupa datang dari pengguna GCP
  • Fakta bahwa Google memproses sebagian besar perintah MMIO di userspace juga dianggap sejalan dengan dugaan Railway
  • Jika penilaian ini benar, maka box dapat mengalami softlock karena batas laju, ambang, atau kondisi yang tidak dipublikasikan, bahkan ketika metrik observasi CPU, memori, dan IOPS masih berada di bawah batas
    • Saat itu, mesin berada di sekitar 50% dari batas sumber daya yang dipublikasikan
  • Setelah reboot manual, Railway menonaktifkan sebagian layanan internal untuk menurunkan tekanan sumber daya pada instance yang terdampak, dan setelah itu instance menjadi stabil

Dampak terhadap pengguna

  • Selama failover manual, setiap mesin mengalami downtime 10 menit per host
  • Karena banyak pengguna menjalankan workload multi-layanan, downtime dapat terakumulasi beberapa kali ketika box offline secara berurutan
  • Railway meminta maaf kepada pengguna dan menyatakan sedang berpindah ke bare metal miliknya sendiri demi keandalan yang lebih tinggi

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-04
Komentar Hacker News

  • Kami perusahaan software kecil beranggotakan 2 orang, dan selama bertahun-tahun juga sering bermasalah dengan Google karena Google Adwords. Contohnya:
    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/
    Kalau kepada penulis asli yang membayar Google dalam jumlah besar saja mereka tidak punya kemauan memberi dukungan yang layak, rasanya sulit melihat harapan apa yang tersisa bagi pelaku usaha kecil seperti kami

  • Secara keseluruhan, menurut saya selama beberapa tahun terakhir GCP kehilangan arah. Beberapa tahun lalu, GCP adalah pilihan yang secara nyata lebih baik daripada AWS dalam rasio harga terhadap performa untuk komputasi, storage, dan bandwidth, dan kami bahkan memastikannya lewat pengujian performa detail serta pemodelan biaya untuk workload kami
    Dukungan saat itu juga luar biasa. Tiket awal yang kami buat untuk masalah jaringan yang samar cepat dieskalasi, lalu ditangani bergantian oleh engineer di berbagai wilayah sampai akhirnya perubahan di sisi GCP dibatalkan. Perwakilan sales juga cepat menghubungkan kami ke sumber daya internal, jadi pengalaman secara keseluruhan sangat positif
    Sekarang AWS jelas sudah menyusul dalam hal performa per biaya, dan pada banyak managed service masih unggul beberapa tahun. Sebaliknya, dukungan GCP memburuk drastis dan tampaknya kebanyakan dialihkan ke vendor support outsourcing, yang visibilitasnya ke infrastruktur GCP nyata pun tidak terlihat jauh lebih baik daripada kami
    Pengalaman dengan tim sales juga jauh lebih buruk, dan account rep kami sekarang jelas merupakan faktor negatif. Kami sudah berinvestasi besar di GCP, tetapi tidak melihat tanda-tanda perbaikan, jadi kami sekarang aktif menjalankan upaya mengurangi pengeluaran GCP, dan meski dulu saya pendukung GCP, sekarang saya sulit merekomendasikan proyek baru untuk dibangun di atas GCP

  • Memang semua penyedia cloud punya masalah. Dalam 2 tahun terakhir di pekerjaan, saya menemukan dan melaporkan beberapa masalah terkait Keyspaces, Amazon Aurora, dan App Runner, dan semuanya berujung pada degradasi performa, sementara dukungan AWS malah membuat kami menggali ke tempat yang salah dan membuang waktu
    Baru setelah eskalasi selama beberapa minggu para pemilik proyek mengakui masalahnya, dan sebagian dari itu ternyata isu yang sebenarnya sudah mereka ketahui, jadi tim support pada dasarnya membiarkan waktu kami terbuang. Untuk saat ini kami masih terikat pada Keyspaces, tetapi sekarang saya berusaha tidak memakai layanan AWS selain layanan inti seperti EC2, EBS, dan S3. Di luar itu terasa berisiko

    • Memang begitu. Sekitar setengah dari layanan AWS terasa entah dirancang dengan buruk, dioperasikan dengan buruk, atau keduanya. CloudWatch khususnya penuh bug dan lambat, sampai-sampai terlihat seperti jebakan untuk pemula
      Kalau saya melihat perusahaan memakai CloudWatch untuk semua log mereka, saya cenderung menduga itu karena kurang pengalaman dan tidak tahu ada banyak alternatif. Meski begitu, layanan komputasinya tetap bisa diandalkan

  • Menyalahkan GCP karena satu instance komputasi mati terasa lucu. Penulis asli sendiri mengakui itu kejadian langka, sementara di AWS saya sering mengalami instance dipaksa berhenti atau bahkan hilang sama sekali. Daya tahan 99,95% dan 99,999% itu perbedaannya besar
    Kalau arsitektur yang sama dijalankan di AWS, berdasarkan pengalaman saya, kemungkinan besar akan terus mengalami gangguan. Berdasarkan dokumentasi AWS dan pengalaman saya, komponen dasar AWS jauh kurang stabil dibanding GCP

    • Sepertinya tulisan itu tidak benar-benar membahas AWS. Masalah utamanya juga bukan satu instance yang mati, melainkan kurangnya komunikasi dan dukungan bahkan untuk mitra perusahaan besar
      Mereka tampaknya mau pindah ke bare metal, yang punya keunggulan jelas karena Anda bisa langsung menyuruh on-call engineer untuk memperbaikinya bagaimanapun caranya
    • SLA EC2 dan GCP Compute keduanya sama-sama tepat 99.99%, dan jika turun di bawah itu pengembaliannya 10%, lalu jika turun di bawah 95% pengembaliannya 100%
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Pengalaman saya sangat berbeda. Setelah memakai AWS selama bertahun-tahun, hanya sekali saya mengalami instance dihentikan karena pekerjaan latar belakang AWS yang aneh dan tidak ada hubungannya dengan aplikasi, dan saya tidak pernah mengalami atau bahkan rasanya belum pernah mendengar instance yang tiba-tiba hilang begitu saja
    • Di cloud, secara umum, seperti kata seseorang, arsitektur memang harus dirancang dengan asumsi bahwa semua hal selalu gagal

  • Saya sudah cukup sering berinteraksi dengan Google Cloud Support, terutama terkait managed service, dan sejujurnya itu tidak terlalu mengesankan dibanding pengalaman support di lingkungan AWS dengan skala serupa yang selalu sangat baik
    Meski begitu, kalau ada seseorang di Google Cloud yang benar-benar membantu dengan sangat baik, ada baiknya memuji mereka secara besar-besaran. Karena kejadian seperti itu langka, memberi imbalan lewat umpan balik positif yang kuat juga bukan beban besar. Saya sendiri pernah punya empat pengalaman yang benar-benar luar biasa, dan saya selalu langsung mengirim pesan ke TAM. Saya harap orang-orang seperti itu mendapat penghargaan dan promosi

    • Betul. Diskusi seperti ini mudah berubah seperti perang vi/emacs, dan yang naik ke halaman depan HN biasanya hanya keluhan
      Saya sudah memakai GCP secara berkala selama sekitar 10 tahun untuk berbagai proyek, dan juga membangun beberapa bisnis yang sukses di atasnya. Memang tidak sempurna, tetapi secara keseluruhan saya puas
      Sebaliknya, saya pernah banyak memakai AWS di tim yang membangun versi hosting awal Cloud Foundry, dan saya sama sekali tidak ingin kembali ke sana. Rasanya seperti kekacauan tanpa akhir

  • Di GCP pernah ada fitur yang sangat “enterprise” rusak, dan terungkap jelas bahwa fitur itu belum pernah benar-benar berfungsi dengan baik sampai saat itu. Saat mencoba memperbaikinya diam-diam, mereka malah menimbulkan downtime, dan para penanggung jawab GCP dalam panggilan yang seharusnya menjelaskan penyebabnya hanya terus mengingatkan bahwa semuanya berada di bawah NDA
    Jika fakta itu diakui, ini akan menjadi mimpi buruk bagi industri yang diatur regulasi

    • Saya selalu penasaran apakah NDA bisa mencegah orang berbicara kepada regulator, polisi, jaksa, atau lembaga negara sungguhan, atau bahkan melakukan whistleblowing. Saya ingin percaya bahwa kejahatan harus selalu bisa dilaporkan

  • “Pada 1 Desember pukul 8:52 pagi PST, sebuah box offline dan menjadi tidak dapat diakses. Lalu setelah failover seharusnya kembali otomatis, tetapi tidak kembali. Saat engineer on-call utama menerima alert dan menyelidiki, box lain juga offline dan tidak kembali”
    Ini tidak masuk akal. Mesin restart lalu terjadi gangguan besar? VM memang kadang reboot. Tapi jika sistem dirancang sehingga seluruh konfigurasi runtuh sendiri dalam skenario seperti itu, saya tetap tidak akan suka, entah dipindah ke AWS atau bahkan memakai colocation sendiri

    • Perlu membaca artikelnya lebih teliti. Bahkan pada bagian yang dikutip tidak dikatakan mesinnya “restart”, melainkan setelah crash tidak kembali online
      Dan di mana pun dalam tulisan itu tidak dikatakan ini adalah “gangguan besar”. Railway secara keseluruhan tidak down, tetapi Railway adalah perusahaan deployment yang menjual kembali sumber daya komputasi untuk men-deploy aplikasi pelanggan. Jadi jika satu VM mati dan failover otomatis tidak berjalan, itu menjadi downtime bagi pelanggan tertentu yang menjalankan layanan di mesin tersebut
      Di artikelnya juga tertulis, “Selama melakukan failover manual pada mesin-mesin ini, ada downtime 10 menit per host. Karena banyak pengguna menjalankan workload multi-service, downtime ini bisa berlipat ganda saat box-box offline satu per satu. Kami menyampaikan permintaan maaf yang sebesar-besarnya kepada semua pengguna”

  • Menariknya, saya mulai merasa di GCP ambang batas yang tidak terdokumentasi tampaknya cukup umum
    Saya mengalami hal serupa di Cloud Run. Ada event scaling yang tidak bisa dijelaskan oleh penggunaan CPU dan jumlah request bersamaan yang menurut dokumentasi mengendalikan scaling
    Setelah bolak-balik lama dengan dukungan berbayar, saya akhirnya tahu ada kriteria tambahan terkait durasi request, tetapi tentu saja tidak ada yang bisa menjelaskannya secara detail

  • Kedengarannya seperti pengalaman yang sangat membuat frustrasi. Tapi saya agak bingung apa kaitan nested virtualization dengan masalah ini, kalau mereka tidak menjalankan virtualisasi di dalam VM. Soft lockup umumnya hanya sinyal umum bahwa tidak ada progres
    Komentar tentang instruksi MMIO juga sama membingungkannya. Jika yang dibicarakan adalah emulasi instruksi, saya tidak paham kenapa lokasi terjadinya itu penting. Bagaimanapun itu akan lambat dan terikat ke user space; kalau harus berjalan cepat, seharusnya hampir tidak pernah keluar dari guest, dan apalagi sampai melakukan emulasi
    Rasanya penulis sedang frustrasi dan mencoba menangkap apa pun yang bisa dipahami dari insiden terbaru untuk mencari penyebabnya

  • “Pada 2022 kami mengalami gangguan jaringan sesaat yang terus-menerus pada produk Google Cloud. Setelah berkali-kali melakukan eskalasi ke Google, kami lelah dan membangun stack jaringan kami sendiri, yaitu jaringan eBPF/IPv6 Wireguard elastis yang menjalankan semua deployment kami. Setelah itu, tiba-tiba masalah jaringan hilang”
    Sepemahaman saya, jaringan untuk VM adalah VLAN yang diprogram ke switch, dan ketika membuat VPC mungkin itu berarti membuat VLAN; jadi jika jaringan dasarnya tidak stabil, saya penasaran bagaimana UDP/WireGuard sebagai overlay bisa lebih stabil
    Sebagai tambahan, kalau hanya 1/10 dari masalah ini terjadi di AWS pada pelanggan seperti ini, pasukan solution architect kemungkinan akan nongkrong di ruang rapat dua minggu sekali sambil meninjau arsitektur dan menempelkan support engineer ke setiap panggilan

    • Ini bukan memprogram switch untuk membuat VLAN, melainkan semuanya ditangani sebagai overlay network
      Materinya memang lama, tapi cukup membantu untuk mendapat gambaran: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • Dugaan saya, optimisasi jaringan canggih milik Google mungkin bentrok dengan trafik mereka
      Dengan membangun stack jaringan sendiri, mereka melewati optimisasi semacam itu, dan WireGuard pada dasarnya dibangun di atas UDP yang tidak andal, jadi mungkin lebih mampu menangani gangguan yang sesekali terjadi