Roblox की पिछले साल की 73 घंटे की आउटेज पोस्टमॉर्टम

आउटेज सारांश

• आउटेज 72 घंटे तक हुआ

• मूल कारण 2 थे

  • असामान्य रूप से अधिक read/write लोड की स्थिति में Consul की नई streaming feature को सक्षम करने पर अत्यधिक contention और performance degradation हुआ

  • खास लोड परिस्थितियों में Consul, leader election और data replication के लिए write-ahead-log को मैनेज करने में जिस open source BoltDB का उपयोग करता है, उसमें performance issue उत्पन्न हुआ

• एक single Consul cluster ने इन issues के प्रभाव को और बढ़ा दिया

• Consul implementation में छिपे इन दो दिखने में असंबंधित issues को खोजने में समय लगने के कारण आउटेज लंबा चला

• आउटेज के कारण पर बेहतर visibility देनी चाहिए थी, लेकिन monitoring system भी Consul की तरह प्रभावित होने वाले systems पर निर्भर था, इसलिए कारण ढूंढना और कठिन हो गया

क्लस्टर वातावरण और HashiStack

• Roblox 18,000 servers और 170,000 containers चला रहा है

• यह Nomad, Consul, Vault का उपयोग करता है, जिन्हें आम तौर पर HashiStack कहा जाता है

उस समय Roblox ने streaming feature का उपयोग करने के लिए Consul को 1.9 से 1.10 में upgrade किया।

प्रारंभिक पता लगना (10/28 13:37)

18 अक्टूबर की दोपहर Vault की performance गिरने लगी और एक Consul server पर CPU लोड बढ़ गया।

शुरुआती वर्गीकरण (10/28 13:37 – 10/29 02:00)

• Consul cluster metrics में write latency बढ़ी

• hardware degradation को कारण मानकर Consul cluster nodes में से एक को बदलना शुरू किया गया

• साथ काम करने के लिए HashiCorp के कर्मचारी भी शामिल हुए

• hardware replacement के बाद भी Consul की performance गिरती रही और 16:35 पर खिलाड़ियों की संख्या सामान्य की 50% तक गिर गई

• Consul service discovery के लिए इस्तेमाल हो रहा था और Nomad व Vault भी Consul पर निर्भर थे, इसलिए Consul एक SPoF था।

• इस समय एक नई परिकल्पना बनाई गई कि कारण ट्रैफिक है। माना गया कि अधिक ट्रैफिक के कारण Consul अब लोड संभाल नहीं पा रहा है

• Consul cluster के सभी nodes को अधिक शक्तिशाली systems से बदल दिया गया। (cores 2 गुना बढ़ाए गए, तेज NVME SSD लगाए गए)

• Consul migration लगभग पूरी हो गई, लेकिन cluster सामान्य स्थिति में वापस नहीं आया

सेवा बहाली प्रयास #1 (10/29 02:00 – 04:00)

• आउटेज से पहले के Consul cluster snapshot पर लौटने का निर्णय लिया गया

• यह माना गया कि user data सुरक्षित है और system data का कुछ नुकसान स्वीकार्य होगा

• snapshot restore के बाद Consul से लगातार संचार करने वाले systems के लोड से फिर समस्या न हो, इसलिए iptables से access block किया गया

• snapshot restore के बाद metrics बेहतर दिखे, लेकिन iptables block हटाते ही स्थिति फिर उसी आउटेज अवस्था में लौट गई

सेवा बहाली प्रयास #2 (10/29 04:00 – 10/30 02:00)

• बाहरी ट्रैफिक को block किया गया और non-essential usage हटाया गया, जिससे सैकड़ों instances में चल रही services घटकर single digits तक आ गईं

• फिर से सेवा बहाली की कोशिश की गई, लेकिन Consul फिर असामान्य स्थिति में चला गया

• यह समझ आया कि शुरुआती सोचे गए performance degradation factor के अलावा भी कुछ और है, इसलिए Roblox के नजरिए से Consul को देखने के बजाय Consul के अंदरूनी हिस्से देखने शुरू किए गए

contention analysis (10/30 02:00 – 10/30 12:00)

• 10 घंटे के अतिरिक्त analysis के बाद पता चला कि Consul writes लंबे समय तक block हो रही थीं

• contention का कारण पता नहीं था, लेकिन शुरुआती CPU को 64 cores से 128 cores पर बदलने से contention और बढ़ा, ऐसा माना गया

• 64 cores पर वापस जाने का निर्णय लिया गया, लेकिन इससे मदद नहीं मिली

मूल कारण की खोज (10/30 12:00 – 10/30 20:00)

• Consul की streaming feature कई महीनों से सक्षम थी और CPU उपयोग व network bandwidth को कम कर रही थी, इसलिए इसे धीरे-धीरे रोलआउट किया जा रहा था।

• आउटेज से एक दिन पहले, 27 तारीख 14:00 बजे traffic routing backend में यह feature सक्षम की गई।

• एक दिन पहले सक्षम करने के बाद यह ठीक चल रही थी, इसलिए इसे कारण नहीं माना गया

• performance analysis के बाद यह प्रमाण मिला कि streaming code उच्च CPU उपयोग पैदा कर रहा था

• streaming को disable कर deployment पूरा होने के बाद यह पुष्टि हुई कि Consul की KV write latency कम हो गई (आखिरकार!)

• HashiCorp के अनुसार streaming अधिक efficient थी, लेकिन implementation में long polling की जगह कम संख्या के concurrency control elements (Go channels) का उपयोग किया गया -> इससे उच्च लोड पर एक single Go channel में contention बढ़ गया और efficiency घट गई

• एक breakthrough मिला, लेकिन अभी भी बीच-बीच में leader election दिख रहा था और कुछ leaders में पहले जैसी latency problems दिखीं

• यह मानते हुए कि cluster सामान्य रहेगा यदि कुछ विशेष leaders का चुनाव न हो, focus service को सामान्य स्थिति में लौटाने पर रखा गया

• इसके बाद HashiCorp ने मूल कारण की जांच जारी रखी और पाया कि कुछ leaders का धीमा होना BoltDB के कारण था

cache service recovery (10/30 20:00 – 10/31 05:00)

• आउटेज के 54 घंटे बाद service recovery की तैयारी हो गई

• आउटेज के दौरान database ठीक था, लेकिन प्रति सेकंड 1 अरब requests संभालने वाला cache system असामान्य स्थिति में था।

• इस cache को restore कर उसके सामान्य होने की पुष्टि करते-करते आउटेज के 61 घंटे हो गए।

उपयोगकर्ताओं की वापसी (10/31 05:00 – 10/31 16:00)

• 31 तारीख को 5 बजे service restoration की तैयारी शुरू हुई और 10 बजे पूरी हुई।

• DNS के जरिए आने वाले players की संख्या को नियंत्रित करते हुए monitoring के साथ उसे धीरे-धीरे बढ़ाया गया

• 73 घंटे बाद सभी players फिर से access कर सके।

अतिरिक्त विश्लेषण और आउटेज के कारण किए गए बदलाव

• HashiCorp और Roblox ने performance issues को हल करने के लिए एक "compression" process विकसित किया

• telemetry improvement: telemetry system और Consul के बीच circular dependency थी, इसलिए Consul में समस्या होने पर data कम मिल रहा था। circular dependency हटाई गई ताकि telemetry system, जिन systems को वह monitor करता है, उन पर निर्भर न रहे

• availability zones और data centers का विस्तार

• अन्य storage होने के बावजूद Consul में रखे गए या अनावश्यक KV data को साफ किया गया।

• BoltDB के successor bbolt को अपनाने वाले Consul के नए version का परीक्षण चल रहा है

• bootstrap process के कारण recovery धीमी हुई, इसलिए इसे automate करने और नए tools व processes विकसित करने पर काम चल रहा है

[xguru]

अनुवाद के लिए धन्यवाद।

उस स्तर पर 72 घंटे का outage सच में डरावना लगता है।