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 टिप्पणियां
Hacker News की रायें
शुरुआत में VM में RAM जोड़ने वाला इंफ्रास्ट्रक्चर अपग्रेड और आउटेज बिल्कुल उसी समय होना महज संयोग निकला, लेकिन ऐसे “संयोग” वाकई बहुत बार होते हैं और समस्या ट्रैक करते समय उनके अस्तित्व पर ही शक करने लगते हैं
उस हालत में अगर घबराहट हो जाए, तो अंत में आप कोई emergency fix (hotfix) ठेल देते हैं जो किसी और चीज़ को तोड़ देता है, और उसके बाद मामला कहीं ज़्यादा तकलीफ़देह हो जाता है
Murphy’s Law सिस्टम एडमिन और डेवलपर्स के लिए बेरहम है
मेरी एक पसंदीदा बात है: “अगर आपको नहीं पता कि आपने क्यों/कैसे ठीक किया, तो हो सकता है आपने असल में उसे ठीक किया ही न हो”
“खुशकिस्मती से” इसका मेरी query से लेना-देना नहीं था, लेकिन ऐसे दो संयोग साथ आ जाएँ तो सच में डर लगता है
ऐसी चीज़ें काफी बार झेलने के बाद अब ज़्यादा assumptions पर शक करने और जो अभी verify नहीं हुआ है उसे confirmed data के रूप में mark न करने की आदत बन गई है
bias और जल्दबाज़ी में निष्कर्ष निकालना पूरी तरह खत्म तो नहीं हुआ, लेकिन मदद मिली है, और खुले दिमाग़ से बने रहना काफी कठिन काम है
इंजीनियर के लिए अहम क्षमता है outage response changes पर critical reasoning करना, उन्हें debug करना और “isolate करके test” कर पाना। यह दिखने से कहीं ज़्यादा कठिन है और आमतौर पर senior-level skill के करीब है
मैं उन users में से एक था जिसने यह समस्या Discord पर report की थी। मुझे Kagi पसंद है, लेकिन status page का यह दिखाना कि सब कुछ normal है, काफी निराशाजनक था
वास्तविक users को प्रभावित करने वाले outage के दौरान भी status page priority नहीं लग रहा था, यह बेचैन करने वाला था, और उम्मीद है आगे से इसे सही तरह update किया जाएगा
जिन services पर मैं पहले बहुत निर्भर था, जैसे GitHub, वे status page तुरंत update कर देती थीं, इसलिए मुझे यह जानकर राहत मिलती थी कि समस्या मेरे device की तरफ़ नहीं बल्कि service की तरफ़ पहचानी गई समस्या है
इस बार मुझे उस दिन बर्फ़ गिरने से पहले आसपास खुली grocery store ढूँढनी थी, लेकिन अंत में Google पर जाना पड़ा, जिससे थोड़ी निराशा हुई
फिर भी Kagi का इस्तेमाल किए गए 99.9% समय में यह Google से बेहतर रहा है, इसलिए मैं इसे इस्तेमाल करता रहूँगा, और उम्मीद है कि postmortem में जैसा कहा गया है, वे status page code को किसी दूसरी service/platform पर ले जाएँगे
आखिर में status page पर कुछ डालना अपने-आप में एक बातचीत बन जाता है, और वह बातचीत engineers का समय और ध्यान खा जाती है, जिससे outage fix करने में उतनी ही देरी होती है
communication और असली recovery के बीच balance बनाना पड़ता है, लेकिन सही जवाब हमेशा स्पष्ट नहीं होता
अगर लोग पर्याप्त हों तो Technical Incident Manager communication संभाल सकता है और communication side पर और engineers लगा सकते हैं, लेकिन यह हमेशा संभव नहीं होता। कुछ systems specialized होते हैं, documentation कम होती है और instrumentation भी कम होती है
निजी तौर पर मैं समस्या के संकेत दिखते ही “संभावित समस्या की जाँच कर रहे हैं” जैसा बड़ा और vague notice डालना पसंद करता हूँ, फिर बाद में details भरना या उसे वापस लेना। लेकिन जिन कंपनियों में मैंने काम किया, उन्हें यह idea पसंद नहीं था
उस समय मैं Kagi की तरफ़ काफी खिंचा, और कुछ queries के लिए इधर-उधर करके इस्तेमाल भी किया, लेकिन LLM, Perplexity, और Google के search page पर ही सीधे जवाब देने के मामले बढ़ने के साथ Kagi के लिए बची queries बहुत ज़्यादा नहीं रहीं
अगर Kagi किसी तरह Perplexity के साथ मिल जाए, तो यह काफी दिलचस्प होगा
कई बार तो वे अंत तक दिखाते ही नहीं
यह outage इतना जाना-पहचाना लग रहा है कि हैरानी होती है
व्यक्तिगत तौर पर जितनी बार मानना चाहूँ उससे ज़्यादा बार मैंने बिल्कुल इसी तरह की outages handle की हैं, और Kagi team की तरह database connection pool state वाले rabbit hole में फँसकर नई instances डालना या यह मानना कि traffic को “reset” करने से ठीक हो जाएगा जैसी वही mitigations आज़माईं, लेकिन सब बेकार गया
ऐसी outages में database के सामान्य saturation metrics जैसे CPU usage, IOPS वगैरह का ज़्यादा न हिलना भी मदद नहीं करता। query latency ज्यादा दिखती है, लेकिन “CPU और IOPS में तो headroom है…” सोचते-सोचते, हमेशा की तरह, lock contention छिपी हुई है यह छूट जाता है
मेरे अनुभव में DB connection pool की 98% अजीब निशानियाँ DB की ही समस्या से आती हैं। Kagi कौन-सा relational database इस्तेमाल करता है, यह नहीं पता, लेकिन मैं strongly recommend करूँगा कि DB की global I/O wait time (seconds/second), global lock acquisition time (seconds/second), और normalized query-wise execution time (seconds/second) को graph करें
इसमें CPU usage chart भी जोड़ दें तो बड़े performance issues में से अधिकांश को जल्दी identify करने वाला dashboard बन जाता है
अलग से, यह थोड़ा चौंकाने वाला है कि search queries relational database writes trigger करती हैं। मुझे लगा था relational database सिर्फ़ user settings, login management जैसी चीज़ों के लिए इस्तेमाल होता होगा
अगर Kagi usage aggregation, जैसे counter increment, relational database में कर रहा है, तो scale बढ़ने पर फटने वाला यह बहुत typical failure mode है
search results को block करने जैसे मामलों में search की वजह से indirect writes हो सकती हैं, और visit history या analytics भी जाहिर है होंगे
फिर भी यह साफ़ नहीं है कि हर search पर write lock contention पैदा करने वाली चीज़ आखिर क्या हो सकती है
यह ऐसी चीज़ है जिससे हर startup को कभी न कभी गुजरना पड़ता है। मैं भी गुजर चुका हूँ और यह सचमुच तकलीफ़देह होता है
कभी-कभी ऐसे मुद्दों को रोकने की क्षमता बनाने के लिए समय या resources कम पड़ जाते हैं, और कभी किसी खास समस्या के सच में हो सकने की कल्पना तक नहीं की होती, फिर अचानक झटका लगता है
पारदर्शिता भी ज़रूरी है और सीखना भी, लेकिन कभी-कभी मुआवज़ा भी ज़रूरी होता है। Kagi को उस समय के लिए search credits देने पर विचार करना चाहिए जब service इस्तेमाल नहीं की जा सकी
खासकर इसलिए भी, क्योंकि उन्होंने खुद माना है कि real-time response कमज़ोर था
Paid service का outage “जहाँ user ही product होता है” वाली service के outage जैसा नहीं होता
यह internal systems की observability के बारे में काफ़ी कुछ दिखाता है
यह कहना आसान है कि उन्हें जल्दी पता चलना चाहिए था, लेकिन अगर सही Datadog dashboard और Splunk queries होतीं, तो बात कहीं पहले और साफ़ दिख जाती
उम्मीद है वे इसे सीखने का मौका मानेंगे और बेहतर monitoring में निवेश करेंगे
यह घटना 100% learning experience थी, लेकिन observability के बारे में थोड़ा और context दे सकता हूँ
Kagi एक छोटी team है, और ऐसी घटनाओं पर response दे सकने वाले लोग असल में 3 हैं, जो 3 time zones में फैले हैं। मेरे और core developer के लिए यह web career का शुरुआती चरण है, हम ऐसे Silicon Valley veterans नहीं हैं जो यह सब पहले से झेल चुके हों
यह तो तय है कि सीखने को बहुत कुछ है, लेकिन Kagi को शून्य से बनाया है, इसलिए अब तक का सफ़र और आगे की दिशा—दोनों पर हमें गर्व है
Observability को हमने करीब पिछले 6 महीनों से ज्यादा गंभीरता से लेना शुरू किया है। अब हमारे पास कई dashboards हैं, और alerts भी हैं जो सीधे company chat channels में जाकर संबंधित लोगों को बुलाते हैं
DB का मुख्य जिम्मेदार होने के नाते GCP का Query Insights बहुत मददगार है। outage के दौरान भी monitoring ने alert किया और Query Insights ने “culprit” query भी दिखा दी, लेकिन दुनिया की सारी monitoring होने पर भी root cause या सबसे efficient mitigation को समझने का अनुभव कम पड़ सकता है
दूसरे शब्दों में, अगर सावधान न रहें तो हमारे अपने system जो दिखा रहे हैं उससे खुद gaslight न हो जाएँ—यह समझदारी अभी कम है। पीछे मुड़कर देखें तो कह सकता हूँ कि GCP Query Insights 100% सही था और यह application space का bug नहीं था
Growth की वजह से अब हम team को काफ़ी expand कर सकते हैं, पहले भी SRE consulting ली है, और आगे भी full-time या part-time support लेकर लगातार सुधार करना चाहते हैं
क्या एक user ने scraper चलाकर service को 7 घंटे के लिए down कर दिया? मुझे पता है बाहर से “यह तो anticipate करना चाहिए था” कहना आसान है, लेकिन testing के दौरान किसी ने “अगर बहुत ज़्यादा searches होने लगें तो क्या होगा?” नहीं पूछा, यह अजीब लगता है
https://news.ycombinator.com/item?id=39019936
संक्षेप में, हमारे पास core people बहुत कम हैं और team young है, जहाँ हर कोई कई roles एक साथ निभा रहा है। अभी dedicated SRE team नहीं है
“अगर बहुत ज़्यादा searches होने लगें तो क्या होगा?” की बात करें, तो https://kagi.com/stats देखें—हमारे यहाँ पहले से “बहुत सारी searches” हो रही हैं और यह रोज़ करीब 4 लाख तक पहुँच रही हैं। रोज़मर्रा में system पर्याप्त spare capacity के साथ चलता है और कुछ automatic scaling measures भी हैं
समस्या details में थी, जहाँ कुछ users ने एक pathological case का दुरुपयोग किया। अनुभव की कमी के कारण हमें पता नहीं था कि किस natural traffic या pathological traffic को पहले से predict और simulate किया जा सकता था
20,000 concurrent search users का load simulate करना शुरू में करने लायक experiment लगता है, और हमने कुछ मिलता-जुलता किया भी था। लेकिन इस outage को देखते हुए, तब भी यह issue पकड़ा नहीं जाता
अब तक production service पर security scanners चलाने वाले करीब 10 लोग रहे हैं, और उस समय आया traffic इस outage से ज़्यादा था
Features भी बनाने हैं—ऐसे में इस तरह के development का balance रखना बहुत कठिन है, और साफ़ है कि हमें और ज़्यादा करना चाहिए था। जैसा मैंने दूसरी post में कहा, निकट भविष्य में team expand करने की कोशिश है ताकि ऐसे प्रयासों में हम बहुत ज्यादा बिखर न जाएँ
hindsight में कहने को बहुत कुछ है, लेकिन उम्मीद है कि हमने यहाँ तक कैसे पहुँचे, यह थोड़ा और transparent तरीके से बता पाया
खासकर अगर किसी ने पहली बार उस तरीके से hit किया हो, तो और भी
तुलना के लिए, जिन systems को मैं handle करता हूँ वे FAANG scale के नहीं हैं, लेकिन request rate के हिसाब से Kagi से निश्चित रूप से बड़े हैं। Kagi भी जल्दी सीखेगा, और इस बीच ऐसी कुछ और problems आएँ तो भी मुझे लगता है कि कुछ हद तक ठीक है। यह इस बात का संकेत भी है कि वे सही दिशा में आगे बढ़ रहे हैं
Kagi का paid user होने के नाते downtime झेलने के बाद समझ आया कि Google की reliability को मैं कितना taken for granted मानता था
पिछले 20 सालों में Google मेरे लिए लगभग एक बार को छोड़कर कभी down नहीं हुआ। Search engine access खोना काफ़ी serious है
मुझे Kagi सच में पसंद है इसलिए पैसे देता हूँ, लेकिन इस्तेमाल के दूसरे महीने में downtime झेलना काफ़ी असहज लगा। मुझे postmortems पसंद हैं, लेकिन चाहूँगा कि उन्हें पढ़ने की नौबत न आए
फिर भी उम्मीद है कि इस अनुभव से Kagi और resilient व reliable service बनेगा
Search engine email provider या ISP जैसी lock-in effect वाली service नहीं है
मैं वाकई इस बात पर निर्भर हो गया था कि Kagi तेज़ है और हर जगह अच्छे से काम करता है
याद आया जब एक customer के यहाँ हम नए networking tool का proof of concept चला रहे थे। Run करने के लगभग 2 मिनट बाद customer का पूरा network down हो गया
हम isolated sandbox area में थे, इसलिए हमारे product के लिए पूरे network का outage cause करने का कोई तरीका नहीं था, लेकिन दिमाग में चल रहा था: “ऐसा हो ही नहीं सकता, है न… है न?!?!”
“बाद में जिस account को block किया था, उससे संपर्क हुआ। उस account ने दावा किया कि उसने हमारे results को automatically scrape करने के लिए account का इस्तेमाल किया था, जो terms में allowed नहीं है।”
हर संभव input RPC/API/HTTP request, खासकर public requests पर QPS limit लगानी चाहिए
हमारे पास autocomplete feature वाला search function था, और तेज़ी से type करने वाले users को support करने के लिए हमने जानबूझकर उस endpoint की rate limit हटा दी थी
एक दिन सुबह करीब 6 बजे Tennessee में कोई व्यक्ति काम पर आया और अपना wallet keyboard पर रख दिया। wallet ने एक key दबाए रखी और हर keystroke पर API hit करना शुरू कर दिया
स्वाभाविक रूप से, करीब 15 मिनट बाद DB बहुत unstable हो गया, और DB latency इतनी बढ़ गई कि एक web server crash हो गया। फिर cascading failures हुए और पूरा production cluster down हो गया
यह कहने की ज़रूरत नहीं कि उसी दिन rate limit फिर से जोड़ दी गई