Railway ने GCP आउटेज का विवरण दिया और Google Cloud छोड़ने का फैसला किया

 (blog.railway.app)
1 पॉइंट द्वारा GN⁺ 2023-12-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Railway ने Google Cloud आधारित प्लेटफ़ॉर्म चलाते समय us-west की कुछ मशीनों के क्रमिक रूप से रुकने और automatic failover के विफल होने की घटना झेली, जिसके कारण user workloads को बहाल करने के लिए manual response की ज़रूरत पड़ी
  • अलग-अलग instances लगभग 10 मिनट तक offline रहे, और 16:40 UTC पर शुरू हुई घटना के बाद 20:53 UTC पर सभी workload failover और service recovery पूरी हुई
  • Railway ने पिछले 18 महीनों में networking instability, Artifact Registry quota reduction, और support response से जुड़ी समस्याएँ झेलीं, जिसके बाद उसने अपना networking stack और अपना registry बना लिया
  • जांच के दौरान CPU soft lockup और kvm_wait, __pv_queued_spin_lock_slowpath stack traces दिखे, और Railway ने GCP guest तथा hypervisor interaction को संभावित मुख्य कारण माना
  • Railway ने Google Cloud सेवाएँ बंद कर अपने bare metal instances पर जाने का फैसला किया है; पहला instance पहले ही चालू किया जा चुका है और 2024 में पूरा migration करने की योजना है

us-west में हुई rolling outage

  • Railway, Google Cloud Platform उत्पादों जैसे Google Compute Engine के ऊपर अपना application development platform चलाता रहा है
  • 1 दिसंबर 2023 को 16:40 UTC से us-west fleet की कुछ मशीनें एक-एक करके unresponsive होने लगीं
    • हर instance लगभग 10 मिनट तक offline रहा
    • outage rolling तरीके से जारी रही
    • automatic failover काम नहीं कर पाया, इसलिए manual failover करना पड़ा
  • 20:53 UTC तक सभी workloads का failover सफल हो गया और service बहाल हो गई
  • Railway ने जांच के बाद निष्कर्ष निकाला कि GCP guest के userspace-to-kernel memory transfer से जुड़ा interaction resource pressure की स्थिति में दुर्लभ रूप से softlock पैदा कर सकता है

18 महीनों में जमा हुई Google Cloud की समस्याएँ

  • Railway ने पिछले 18 महीनों में Google Cloud से जुड़ी कई operational समस्याएँ झेलीं

  • networking instability

    • 2022 में Google cloud products में लगातार networking interruptions हुईं
    • Google तक कई बार escalation करने के बाद Railway ने अपना networking stack बना लिया
    • यह stack resilient eBPF/IPv6 Wireguard network है और अभी सभी deployments को चलाता है
    • इसके बाद networking समस्याएँ खत्म हो गईं

  • Artifact Registry quota

    • Railway के अनुसार, 2023 में Google ने Artifact Registry quota को मनमाने ढंग से लगभग 0 के करीब घटा दिया
    • image deployment throughput काफी कम हो गया और builds में देरी हुई
    • इसके बाद Railway ने अपना registry product बनाया और registry throughput की समस्या भी खत्म हो गई

support response और bare metal migration का फैसला

  • Railway का कहना है कि वह Google Cloud को सालाना कई मिलियन डॉलर चुका रहा था, लेकिन ऐसी स्थितियों में जहाँ Google की कार्रवाई Railway और दूसरे ग्राहकों के workloads को प्रभावित कर रही थी, उसे पर्याप्त response नहीं मिला
  • संस्थापक ने संबंधित समस्याएँ X पर पोस्ट करने के बाद Google ने संपर्क किया, और Railway ने Google के VPs के साथ समस्या के कारणों पर चर्चा की
  • Railway के अनुसार, Google का एक engineer GCP quota को मनमाने ढंग से बदल सकता था
    • Railway के अनुसार, Google के VPs ने माना कि यह स्थिति स्वीकार्य नहीं है
    • जून के बाद भी Railway retrospective, official response, और arbitrary quota changes रोकने वाली policy की मांग करता रहा है
  • Railway के अनुसार, इसी दौरान Google ने बिना पूर्व चेतावनी ToS बदल दिया, जिससे Railway की लागत 20% बढ़ गई
    • Google ने कहा था कि वह इस मुद्दे पर भी जवाब देगा, लेकिन Railway का कहना है कि अभी तक जवाब नहीं मिला
  • Railway ने पिछली तिमाही में आंतरिक रूप से फैसला किया कि वह सभी Google Cloud सेवाएँ बंद करके अपने bare metal instances पर जाएगा
    • पहला bare metal instance कुछ हफ्ते पहले चालू हो चुका है
    • सभी instances का migration 2024 में किया जाना है

30 नवंबर और 1 दिसंबर की outage progression

  • 30 नवंबर 2023 को 21:41 UTC पर Google द्वारा मशीन restart किए जाने के दौरान एक box offline हो गया
    • Railway के पास ऐसी स्थितियों को detect और resolve करने वाला automatic system है
    • उस box का failover सामान्य रूप से हो गया और कोई page नहीं गया
  • 1 दिसंबर 2023 को 16:52 UTC पर एक box inaccessible होकर offline हो गया
    • automatic failover के बाद भी वह सामान्य रूप से recover नहीं हुआ
    • primary on-call engineer को बुलाया गया, और जांच के दौरान दूसरे boxes भी offline होकर वापस नहीं आए
  • Railway ने boxes का manual failover शुरू किया
    • हर host पर लगभग 10 मिनट का downtime हुआ
    • जल्दी ही लगभग 12 boxes प्रभावित हो गए और कंपनी के लगभग आधे लोग runbook के अनुसार response में लग गए
  • Google Cloud की automatic live migration जैसी serial log patterns की वजह से शुरुआत में यह माना गया कि Google का routine restart ही गलत तरीके से हुआ है
    • Google की तरफ़ के प्रभारी को email भेजा गया, लेकिन तुरंत out-of-office auto-reply मिला

serial console logs में दिखे संकेत

  • Railway ने सबसे पहले serial console logs की जांच की
    • ये logs virtualized serial device के जरिए सीधे kernel से निकलते हैं
  • logs में soft-locked CPU core और lock हुए CPU के stack traces दिखे
    • उदाहरण के तौर पर kvm_wait, __pv_queued_spin_lock_slowpath दिखे
  • Railway ने इस तरह के logs और behavior आख़िरी बार पिछले साल दिसंबर में Google द्वारा शुरू किए गए restarts के समय देखे थे
    • उस समय भी तीन boxes में यही पैटर्न दिखा था
  • आगे की जांच में GCP की nested kernel virtualization और soft lockup से जुड़े threads से मेल खाते kernel errors मिले
    • Google ने संबंधित bug को स्वीकार किया था, इसका उदाहरण Railway ने Kubernetes issue comment से दिया
    • दूसरे user complaints के उदाहरण के रूप में Stack Overflow case 1, Stack Overflow case 2 दिए गए
  • Railway ने कहा कि वह उन hosts पर अपनी virtualization का उपयोग नहीं कर रहा था, इसलिए kvm और paravirtualization से जुड़े messages को उसने GCP hypervisor के साथ interaction करने वाले guest kernel code का संकेत माना
  • GCP ने मिलती-जुलती समस्या को reproduce नहीं किया जा सका के रूप में संभाला हुआ लगता है, लेकिन Railway का मानना है कि यह घटना उसी श्रेणी की है

अनुमानित कारण और mitigation steps

  • Railway का मानना है कि GCP guest के userspace-to-kernel memory transfer में एक संभावित गंभीर interaction है, जो resource pressure की दुर्लभ स्थिति में softlock पैदा करता है
  • अधिक विशेष रूप से, उसका मानना है कि paravirtualized memory management और hypervisor में pages के map और remap होने का तरीका कुछ खास resource pressure स्थितियों से जुड़ा है
  • Railway ने यह भी समानता बताई कि लगभग सभी मिलती-जुलती reports GCP users से आई हैं
  • Railway के अनुमान से यह बात भी मेल खाती है कि Google अधिकतर MMIO commands को userspace में handle करता है
  • अगर यह आकलन सही है, तो CPU, memory, और IOPS metrics में सीमा से नीचे होने पर भी, undisclosed rate limits, thresholds, या conditions की वजह से boxes softlock हो सकते हैं
    • उस समय मशीनें प्रकाशित resource limits के लगभग 50% स्तर पर थीं
  • Railway ने manual reboot के बाद प्रभावित instances पर resource pressure घटाने के लिए कुछ internal services disable कीं, और इसके बाद instances स्थिर हो गए

users पर प्रभाव

  • manual failover के दौरान हर मशीन पर प्रति host 10 मिनट का downtime हुआ
  • कई users multi-service workloads चला रहे थे, इसलिए boxes के लगातार offline होने से downtime कई बार जुड़ सकता था
  • Railway ने users से माफ़ी मांगी और कहा कि बेहतर reliability के लिए वह अपने bare metal पर migrate कर रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-04
Hacker News की राय

  • हम 2 लोगों की छोटी software company हैं, और हमें भी कई सालों से Google Adwords की वजह से Google के साथ काफी समस्याएँ रही हैं। उदाहरण के लिए:
    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 को बड़ी रकम चुकाता है, ठीक-ठाक support देने के इच्छुक नहीं हैं, तो हमारे जैसे छोटे business के लिए क्या उम्मीद बचती है?

  • कुल मिलाकर, मुझे लगता है कि पिछले कुछ सालों में GCP ने दिशा खो दी है। कुछ साल पहले तक compute, storage और bandwidth के price-performance के मामले में यह AWS से सार्थक रूप से बेहतर विकल्प था, और हमने अपने workloads के लिए detailed performance tests और cost modeling करके इसकी पुष्टि भी की थी
    उस समय support भी बेहतरीन था। शुरुआत में खोला गया एक अस्पष्ट network issue ticket जल्दी escalate हुआ, अलग-अलग regions के engineers ने उसे handoff करके solve किया, और आखिरकार GCP की तरफ का change rollback किया गया। sales representative ने भी internal resources से जल्दी connect कराया, जिससे पूरा अनुभव सकारात्मक रहा
    अब AWS ने price-performance में साफ तौर पर बराबरी कर ली है, और कई managed services में वह अब भी कई साल आगे है। दूसरी तरफ GCP support काफी खराब हो गया है; ज्यादातर cases शायद outsourced support providers के पास जाते हैं, और उन्हें असली GCP infra की visibility हमसे खास बेहतर लगती भी नहीं
    sales experience भी बहुत खराब हो गया है और हमारा मौजूदा rep साफ तौर पर net negative है। हमने GCP में बड़ा investment किया है, लेकिन सुधार के संकेत नहीं दिख रहे, इसलिए हम GCP spend घटाने का काम सक्रिय रूप से कर रहे हैं। पहले मैं GCP advocate था, लेकिन अब किसी नए project को GCP पर डालने की सलाह देना मुश्किल है

  • यह सच है कि सभी cloud providers में समस्याएँ होती हैं। पिछले 2 सालों में काम के दौरान मैंने Keyspaces, Amazon Aurora, और App Runner से जुड़ी कई समस्याएँ खोजकर report कीं; सभी से performance degradation हुआ और AWS support ने गलत जगह खुदवाकर समय बर्बाद कराया
    कई हफ्तों तक escalation के बाद ही project owners ने समस्याएँ मानीं, और उनमें से कुछ तो पहले से known issues थीं, फिर भी support team ने हमारा समय खराब करवाया। फिलहाल हम Keyspaces में बंधे हुए हैं, लेकिन अब EC2, EBS, S3 जैसी core services के अलावा कुछ इस्तेमाल नहीं करना चाहते। उससे बाहर जाना risky है

    • बिल्कुल सही। AWS services की लगभग आधी संख्या या तो खराब design की हुई लगती है, या खराब operate होती है, या दोनों। CloudWatch खास तौर पर बहुत buggy और slow है; सच कहें तो यह beginners trap जैसा दिखता है
      जब कोई company सभी logs के लिए CloudWatch इस्तेमाल करती दिखती है, तो लगता है कि शायद अनुभव की कमी के कारण उन्हें कई alternatives का पता नहीं है। फिर भी compute services भरोसेमंद हैं

  • GCP में एक compute instance नीचे चला गया, इस पर दोष देना हास्यास्पद है। मूल लेखक ने भी माना कि यह दुर्लभ घटना थी, लेकिन AWS में मैंने instances को force stop होते या पूरी तरह गायब होते अक्सर देखा है। 99.95% durability और 99.999% में बड़ा फर्क है
    अगर वही architecture AWS पर चलाया होता, तो मेरे अनुभव के हिसाब से लगातार outages होते। AWS docs और मेरे अनुभव के अनुसार AWS के basic building blocks GCP की तुलना में बहुत कम stable हैं

    • लगता नहीं कि लेख में AWS को खास तौर पर discuss किया गया है। मुख्य समस्या भी एक instance के नीचे जाने की नहीं, बल्कि बड़े enterprise partner तक के लिए communication और support की कमी की दिखती है
      वे शायद bare metal पर जाने की सोच रहे हैं, जिसका साफ फायदा यह है कि on-call engineer से सीधे कह सकते हैं कि किसी तरह इसे ठीक करो
    • EC2 और GCP Compute की SLA दोनों ठीक 99.99% हैं, और इससे नीचे जाने पर 10% refund, 95% से नीचे गिरने पर 100% refund मिलता है
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • मेरा अनुभव इससे बहुत अलग है। AWS कई साल इस्तेमाल करने में application से असंबंधित किसी अजीब AWS background task की वजह से instance बंद हुआ, ऐसा सिर्फ एक बार हुआ; और instance बस गायब हो गया, ऐसा न मैंने अनुभव किया है न शायद सुना है
    • cloud में आम तौर पर, जैसा किसी ने कहा था, architecture इस assumption पर बनाना चाहिए कि हर चीज हमेशा fail होती है

  • Google Cloud Support के साथ, खासकर managed services के मामले में, मेरा काफी interaction रहा है, और समान scale के AWS usage में support experience हमेशा शानदार रहा, उसकी तुलना में ईमानदारी से कहूँ तो यह बहुत प्रभावशाली नहीं था
    हालांकि Google Cloud में अगर किसी ने सचमुच अच्छी मदद की हो, तो उसकी खूब तारीफ करना अच्छा है। ऐसी चीजें जितनी दुर्लभ हैं, strong positive feedback देकर उन्हें reward दिलाने में कोई बड़ा बोझ भी नहीं है। मेरे साथ भी चार वाकई शानदार experiences हुए, और मैंने हर बार तुरंत TAM को message भेजा। उम्मीद है ऐसे लोगों को reward और promotion मिले

    • सही है। ऐसी discussions आसानी से vi/emacs debate जैसी बन जाती हैं, और HN के front page पर आम तौर पर complaints ही आती हैं
      मैंने करीब 10 साल तक projects में GCP को बीच-बीच में इस्तेमाल किया है, और उस पर कई सफल businesses भी बनाए हैं। perfect नहीं था, लेकिन कुल मिलाकर मैं संतुष्ट हूँ
      इसके उलट, Cloud Foundry का शुरुआती hosted version बनाने वाली team में AWS काफी इस्तेमाल किया था, और वहाँ वापस नहीं जाना चाहूँगा। वह endless chaos था

  • GCP में एक बहुत ही enterprise जैसा फीचर कभी टूट गया था, और यह साफ़ सामने आया कि वह फीचर उस समय तक कभी ठीक से काम ही नहीं कर पाया था। चुपचाप ठीक करने की कोशिश में downtime भी हो गया, और GCP के प्रतिनिधि कारण समझाने वाली call में बस बार-बार यही याद दिलाते रहे कि सब लोग NDA के तहत हैं
    ऊपर की बात मान लेते तो regulated industries के लिए यह एक nightmare बन जाता

    • मुझे हमेशा यह जिज्ञासा रही है कि क्या NDA regulator, पुलिस, prosecutor, या असली सरकारी एजency को बताने या whistleblowing करने तक को रोक सकता है। मेरा मानना है कि अपराध की report कभी भी की जा सकनी चाहिए

  • “1 दिसंबर सुबह 8:52 PST पर एक box offline हो गया और accessible नहीं रहा। और failover के बाद उसे अपने-आप वापस आना चाहिए था, लेकिन नहीं आया। primary on-call engineer को alert मिला और वह investigate कर रहा था, तभी एक और box offline हो गया और वापस नहीं आया”
    यह बात समझ में नहीं आती। Machine restart हुई और catastrophic failure हो गया? VM कभी-कभी reboot होते हैं। लेकिन अगर उस scenario में पूरा configuration अपने-आप ढह जाने के लिए design किया गया था, तो AWS पर shift करें या फिर अपना colocation इस्तेमाल करें, मुझे तो पसंद नहीं आएगा

    • लेख को और ध्यान से पढ़ना चाहिए। जिस हिस्से को quote किया है उसमें भी नहीं कहा गया कि machine “restart” हुई, बल्कि लिखा है कि crash के बाद फिर से online नहीं लौटी
      और लेख में कहीं भी नहीं कहा गया कि यह “catastrophic failure” था। पूरा Railway down नहीं हुआ था, लेकिन Railway एक deployment company है, इसलिए वह customer applications deploy करने के लिए compute resources resell करता है। इसलिए अगर एक VM down हो जाए और automatic failover न हो, तो उस machine पर service चला रहे खास customers के लिए downtime हो जाता है
      लेख में भी लिखा है, “इन machines का manual failover करते समय प्रति host 10 मिनट का downtime हुआ। कई users multi-service workloads चलाते हैं, इसलिए boxes के एक-एक करके offline होने से यह downtime कई गुना बढ़ सकता है। सभी users से गहरी माफी”

  • दिलचस्प बात है कि मुझे लगने लगा है कि GCP में undocumented thresholds काफी आम लगते हैं
    Cloud Run में भी मैंने ऐसा ही कुछ अनुभव किया। Documentation में scaling को control करने वाली CPU usage और concurrent requests की criteria से explain न होने वाले scaling events हुए थे
    paid support के साथ काफी लंबी बातचीत के बाद पता चला कि request duration से जुड़ा एक अतिरिक्त criterion है, लेकिन जाहिर है, कोई भी उसे detail में explain नहीं कर पाया

    • हमने भी Cloud Run में एक undocumented limit झेली थी। यह प्रति instance प्रति second maximum network packets से जुड़ा एक अस्पष्ट quota था, और root cause trace करने में 6 महीने लग गए, जिससे वाकई गुस्सा आया
      लगता है अब यह यहाँ documented है: https://cloud.google.com/run/quotas#cloud_run_bandwidth_limi...
    • बिना announcement के changes भी होते हैं। 2022 में GCP की वजह से Firefox outage हुआ था:
      https://hacks.mozilla.org/2022/02/retrospective-and-technica...

  • यह वाकई बहुत frustrating experience लगता है। हालांकि जब VM के अंदर virtualization इस्तेमाल नहीं हो रही है, तो nested virtualization का इस issue से क्या संबंध है, यह थोड़ा confusing है। soft lock आम तौर पर progress न होने का एक broad signal होता है
    MMIO instructions से जुड़ी comment भी इसी तरह उलझाने वाली है। अगर बात instruction emulation की है, तो यह कहाँ हो रही है, यह क्यों महत्वपूर्ण है, समझ नहीं आता। वैसे भी यह slow होगी और user space से बंधी होगी; अगर इसे fast चलना है, तो guest से बाहर निकलना ही बहुत कम होना चाहिए, और emulation तो और भी कम
    लगता है author frustrate होकर हाल की घटना के बारे में अपनी समझ की सीमा में जो भी पकड़ में आ रहा है, उससे cause ढूँढने की कोशिश कर रहे हैं

  • “2022 में हमने Google cloud product में लगातार network transient failures झेले। Google को कई बार escalate करने के बाद थककर हमने अपना networking stack बनाया—यानी सभी deployments को चलाने वाला resilient eBPF/IPv6 Wireguard network। इसके बाद अचानक network problems गायब हो गईं”
    मेरी समझ से VM के लिए network switch में program किए जाने वाले VLAN होते हैं, और VPC बनाते समय शायद VLAN ही बनता होगा; ऐसे में अगर underlying network unstable है, तो overlay UDP/WireGuard कैसे ज़्यादा stable हो सकता है, यह जानने की curiosity है
    साथ ही, ऐसे customer के लिए अगर AWS पर इस problem का 1/10 भी हुआ होता, तो solution architects की फौज हर दो हफ्ते conference room में बैठकर architecture review करती और support engineer को call पर जोड़ती

    • switch को program करके VLAN बनाने की बात नहीं है; सब कुछ overlay network से handle होता है
      material पुराना है, लेकिन अंदाज़ा लगाने में मदद करता है: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • अनुमान लगाऊँ तो शायद Google की clever network optimizations इनके traffic से conflict कर रही थीं
      अपना network stack बनाते समय उन्होंने ऐसी optimizations को bypass किया, और WireGuard मूल रूप से unreliable UDP के ऊपर बना है, इसलिए शायद intermittent failures को बेहतर handle कर पाया