पिछले हफ्ते की Kagi घटना का पोस्टमॉर्टम विश्लेषण

 (status.kagi.com)
1 पॉइंट द्वारा GN⁺ 2024-01-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Kagi.com सेवा अस्थिरता समस्या का समाधान

  • जांच जारी - डिप्लॉयमेंट के बाद समस्या उत्पन्न हुई और टीम इसे ठीक करने पर काम कर रही थी। (12 जनवरी 16:45 UTC)
  • निगरानी - समस्या का संभावित कारण माने जा रहे configuration change को वापस लिया गया और सेवा के सामान्य होने की लगातार निगरानी की जा रही थी। (12 जनवरी 18:30 UTC)
  • अपडेट - स्थिरता को पूरी तरह बहाल करने के लिए कुछ समय के लिए ट्रैफ़िक रोका जाएगा और उपयोगकर्ताओं को इस पेज पर redirect किया जाएगा। सेवा पर लोड को नियंत्रित तरीके से बहाल करते समय स्थिति के अनुसार अतिरिक्त विवरण साझा किए जाएंगे। (12 जनवरी 20:26 UTC)
  • निगरानी - ट्रैफ़िक बहाल कर दिया गया था और सेवा के पूरी तरह सामान्य होने की निगरानी जारी थी। (12 जनवरी 21:14 UTC)
  • समाधान हो गया - सभी सेवाएं सामान्य रूप से चल रही थीं। समस्या के समाधान की प्रतीक्षा करने वाले उपयोगकर्ताओं का आभार व्यक्त किया गया।

पोस्टमॉर्टम विश्लेषण

  • Kagi के तकनीकी लीड Zac ने पिछले हफ्ते की सेवा बाधा पर विस्तृत पोस्टमॉर्टम साझा किया।
  • इस घटना के जवाब में senior engineer Seth और DevOps engineer Luan ने मिलकर काम किया।
  • कुछ actors सेवा का दुरुपयोग कर रहे थे और infrastructure bottlenecks का फायदा उठा रहे थे; तत्काल mitigation steps लिए गए और code व communication के कई हिस्सों में सुधार का काम चल रहा है।

घटना का क्रम

  • 12 जनवरी को लगभग शाम 5:30 बजे, internal monitoring और उपयोगकर्ताओं की समस्या रिपोर्टों के जरिए infrastructure issue का पता चला।
  • समस्या की प्रकृति ऐसी थी कि अलग-अलग क्षेत्रों के उपयोगकर्ताओं को धीमा loading या page timeout का सामना करना पड़ा।
  • समस्या सुलझाने में काफी समय लगा, और उसके background, progress और आगे की योजना के बारे में बताया गया।

तकनीकी समस्या समाधान प्रक्रिया

  • शुरुआत में संयोग से VM में अतिरिक्त RAM resources upgrade करने के उसी समय यह समस्या हुई।
  • Monitoring ने high latency और application के database connection pool की समस्या की रिपोर्ट की।
  • Connection pool saturation की स्थिति में पहुंच गया था, यानी कुल connections की संख्या configured maximum connection limit से ऊपर चली गई थी।
  • Database की आंतरिक health और query performance का आकलन करते समय, congestion कम करने के असर को जांचने के लिए कुछ instances बदले गए।
  • कुछ instances बदलना मददगार लगता दिखा, इसलिए सभी connection pools को एक बार में पूरी तरह reset करने के लिए user traffic को अस्थायी रूप से रोक दिया गया।
  • Database state की जांच करने पर यह स्पष्ट हुआ कि user table की rows पर high contention ही मूल कारण था।
  • इस contention ने write latency को तेज़ी से बढ़ा दिया, जिससे application के connection pool पर backpressure बना, और अंततः सभी उपलब्ध connections खत्म हो गए।
  • Kagi अब तक GCP पर उपलब्ध सबसे सस्ते single-core database का उपयोग करता रहा था, और इसमें database के आसानी से ठप हो जाने का जोखिम मौजूद था।
  • Bad actors की पहचान कर ली गई, जिनमें 24 घंटे के भीतर बनाए गए accounts और एक ऐसा single user account शामिल था जिसने कम समय में 60,000 से अधिक searches की थीं।
  • उस account की search functionality हटा दी गई और समस्या पैदा करने वाले specific write को disable करने के लिए एक hotfix जारी किया गया।
  • आधी रात तक समस्या पूरी तरह हल हो गई थी, और इन actors के लौटने के संकेतों की लगातार बारीकी से निगरानी की जा रही थी।

आगे की कार्रवाई

  • इस घटना से बहुत कुछ सीखा गया, और system को अधिक मजबूत बनाने तथा incidents के दौरान communication process को बेहतर करने की तत्काल योजनाएं पहले से चल रही हैं।
  • सबसे पहले, यह स्वीकार किया गया कि status page updates पर्याप्त तेज़ नहीं थे।
  • अब एक ऐसे status page platform पर जाने की योजना है जहां automated internal monitoring को उपयोगकर्ताओं के लिए अधिक आसानी से दिखाया जा सके, ताकि वे real time में platform की health समझ सकें।
  • समस्या पैदा करने वाली queries को सीधे mitigate किया जा रहा है, और यह पता लगाने के लिए load testing चल रही है कि क्या ऐसे और भी defects मौजूद हैं।
  • अतिरिक्त monitoring लगाई जाएगी ताकि infrastructure में सही जगह की ओर तेज़ी से संकेत मिल सके और इस बार की तरह गलत signals का पीछा करने में समय बर्बाद न हो।
  • इस तरह के दुरुपयोग का पता लगाने वाले systems को मजबूत किया जा रहा है, और क्योंकि इसका असर सिर्फ performance पर नहीं बल्कि सीधे cost पर भी पड़ता है, इसे लागू करने के लिए automated limits सेट करना ज़रूरी है।
  • नई limits इस पोस्ट के समय तक पहले ही लागू की जा चुकी थीं, और उनके प्रभाव की निगरानी कर आवश्यकता के अनुसार उन्हें आगे भी समायोजित किया जाएगा।
  • यदि किसी को लगता है कि Kagi तक उसकी पहुंच गलती से block हो गई है, तो support@kagi.com पर संपर्क करने का अनुरोध किया गया।

GN⁺ की राय

  • Kagi को user table row contention के कारण write latency की समस्या हुई, जिसने application के connection pool पर backpressure डालकर सेवा बाधित कर दी।
  • यह समस्या उस जोखिम का परिणाम थी जो Kagi द्वारा GCP पर सबसे सस्ते single-core database के उपयोग से पैदा हुआ था।
  • Kagi टीम ने इस घटना से सीख लेते हुए system को मजबूत करने, उपयोगकर्ताओं के साथ communication सुधारने, और दुरुपयोग रोकने के लिए automated limits लागू करने जैसे कदम उठाए, जो सेवा की स्थिरता और transparency बढ़ाने के प्रयास को दिखाते हैं। ये प्रयास उपयोगकर्ताओं को अधिक भरोसेमंद सेवा देने की Kagi की प्रतिबद्धता को दर्शाते हैं।

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

1 टिप्पणियां

 
GN⁺ 2024-01-18
Hacker News राय

  • इन्फ्रास्ट्रक्चर upgrade के साथ एक ही समय पर हुई घटना पर राय

    • कहा गया कि VM में अतिरिक्त RAM resources जोड़कर इन्फ्रास्ट्रक्चर upgrade करते समय जो घटना हुई, वह पूरी तरह संयोग थी.
    • यह भी उल्लेख किया गया कि ऐसे "संयोग" अक्सर होते हैं और समस्या सुलझाते समय इंसान को अपने ही अस्तित्व पर शक होने लगता है.
    • चेतावनी दी गई कि अगर troubleshooting के दौरान panic की स्थिति बन जाए, तो ऐसा hotfix लागू किया जा सकता है जो किसी और चीज़ को तोड़ दे, और यह system administrators व developers के लिए Murphy's law का क्रूर रूप बन सकता है.

  • Kagi status page के बारे में उपयोगकर्ता का अनुभव

    • एक उपयोगकर्ता ने कहा कि Kagi की status page पर सब कुछ सामान्य रूप से काम करता हुआ दिख रहा था, जिससे उसे बेचैनी हुई.
    • उसने तुलना करते हुए कहा कि जिन services पर वह पहले निर्भर रहा है, वे status page को तुरंत update कर देती थीं ताकि पता चल सके कि समस्या उसके device में नहीं है.
    • उसने कहा कि वह Kagi का इस्तेमाल जारी रखेगा, लेकिन उम्मीद है कि postmortem में बताए अनुसार status page के code को किसी दूसरी service/platform पर ले जाया जाएगा.

  • व्यक्तिगत अनुभव साझा करने वाली टिप्पणी

    • एक टिप्पणी में साझा किया गया कि उसने व्यक्तिगत रूप से इसी तरह के service outages कई बार देखे हैं और database connection pool की health से जुड़ी समस्या को हल करने की कोशिश की है.
    • यह इंगित किया गया कि database के सामान्य saturation metrics (CPU%, IOPS आदि) ऐसे outages के दौरान बहुत नहीं बदलते, बल्कि lock contention समस्या की वजह हो सकती है.
    • Kagi द्वारा इस्तेमाल किए जा रहे RDBMS के लिए सुझाव दिया गया कि global I/O latency, lock acquisition time, query execution time आदि को graph करना उपयोगी होगा.

  • startup के अनुभव पर टिप्पणी

    • कहा गया कि हर startup किसी न किसी समय ऐसी समस्याओं से गुजरता है.
    • हो सकता है कि ऐसी समस्या रोकने की क्षमता बनाने के लिए पर्याप्त समय या resources न रहे हों, या उन्होंने सोचा ही न हो कि ऐसी खास समस्या होगी.
    • कहा गया कि transparency और learning महत्वपूर्ण हैं, लेकिन कभी-कभी compensation भी अहम होता है, और सुझाव दिया गया कि Kagi को उस समय के लिए search credits देने पर विचार करना चाहिए जब service उपलब्ध नहीं थी.

  • आंतरिक सिस्टम की observability पर टिप्पणी

    • यह कहा गया कि समस्या को इससे जल्दी पहचान लेना चाहिए था, और सही Datadog dashboard व Splunk query से स्थिति बहुत जल्दी स्पष्ट हो जानी चाहिए थी.
    • सलाह दी गई कि बेहतर monitoring में निवेश करके इसे सीखने के अनुभव के रूप में लेना चाहिए.

  • Kagi की reliability पर एक paid user की राय

    • Kagi के downtime का अनुभव करने वाले एक paid user ने कहा कि उसे एहसास हुआ कि वह Google की reliability को हल्के में लेता रहा था.
    • उसने कहा कि search engine तक पहुंच रुक जाना एक बड़ी बाधा हो सकती है, और Kagi से प्यार होने के बावजूद downtime का अनुभव अप्रिय था.
    • उसने उम्मीद जताई कि यह अनुभव Kagi को और मजबूत व भरोसेमंद service बनाएगा.

  • service outage का कारण बने scraper पर टिप्पणी

    • एक उपयोगकर्ता द्वारा चलाए गए scraper की वजह से service 7 घंटे तक बंद रही; इस पर सवाल उठाया गया कि testing के दौरान यह क्यों नहीं पूछा गया: "अगर बहुत सारी searches होने लगें तो क्या होगा?"

  • Kagi इस्तेमाल के अनुभव और postmortem पर टिप्पणी

    • एक व्यक्ति ने साझा किया कि कुछ हफ्तों तक Kagi इस्तेमाल करने के बाद, पिछले हफ्ते जब यह तुरंत load नहीं हुआ, तो उसे समझ नहीं आया कि क्या करना चाहिए.
    • उसने कहा कि postmortem आने से पहले ही वह इस घटना को भूल चुका था, और उस टीम का आभार जताया जिसके बारे में search करते समय सोचना नहीं पड़ता.

  • GCP पर इस्तेमाल किए गए single-core database पर टिप्पणी

    • इस बात पर सकारात्मक प्रतिक्रिया दी गई कि Kagi अब तक GCP पर उपलब्ध सबसे सस्ता single-core database इस्तेमाल करता रहा है.
    • सुझाव दिया गया कि PolyScale जैसी किसी चीज़ पर विचार किया जा सकता है, जो read load में अचानक बढ़ोतरी संभाल सके और performance को और आगे बढ़ा सके.

  • automated scraping पर टिप्पणी

    • कहा गया कि account block किए जाने के बाद संपर्क करने वाले एक उपयोगकर्ता ने दावा किया कि वह results को automatically scrape करने के लिए account का इस्तेमाल कर रहा था.
    • सिफारिश की गई कि सभी incoming RPC / API / HTTP requests, खासकर public वाले, पर QPS (प्रति सेकंड query count) limits सेट करनी चाहिए.