- जिस सुबह Twitter का होम फ़ीड ज़्यादातर समय डाउन रहा, उस दौरान यह देखा गया कि वेब क्लाइंट लगातार content requests दोहराता रहा, मानो खुद ही DDOS ट्रिगर कर रहा हो
- स्क्रीन लोड न होने पर भी retries नहीं रुकीं, और पहले वीडियो में rate limited error तथा कांपता हुआ scrollbar दिखाई देता है
- दूसरे वीडियो में दिखता है कि न पहुँच रहे content को fetch करने की कोशिश में Twitter खुद को प्रति सेकंड लगभग 10 requests भेज रहा है
- हाल ही में लागू की गई बिना लॉग-इन उपयोगकर्ताओं के लिए reading limit को संभावित कारण माना गया, जिसने शायद अनपेक्षित conditions बना दीं
- बाद के वीडियो के Firefox network console में भी requests लगातार आती रहीं, और इसे ऐसी self-DDOS स्थिति के रूप में समझा गया जिसमें उपयोगकर्ता का browser Twitter को बार-बार requests भेजता रहा
Twitter वेब क्लाइंट में दिखीं बार-बार होने वाली requests
- उस सुबह Twitter का होम फ़ीड ज़्यादातर समय डाउन था, और कुछ भी load न होने की स्थिति में भी वेबसाइट ने requests को retry करना बंद नहीं किया
- पहले वीडियो में यह error message दिखता है कि उपयोगकर्ता rate limited स्थिति में है, साथ ही दाईं ओर का scrollbar कांपता हुआ दिखता है
- दूसरा वीडियो बताता है कि scrollbar क्यों कांप रहा था, और उसमें Twitter को content fetch करने की कोशिश में खुद को प्रति सेकंड लगभग 10 requests भेजते हुए देखा जा सकता है
- content के न पहुँचने की पृष्ठभूमि में उस बदलाव को कारण माना गया जिसमें बिना लॉग-इन उपयोगकर्ताओं को Twitter पढ़ने से रोका गया
बाद की पुष्टि और संलग्न सामग्री
- बाद की पोस्ट में Firefox network console की स्क्रीन के जरिए यह अतिरिक्त रूप से दिखाया गया कि network requests लगातार होती रहीं
- यह व्याख्या जोड़ी गई कि deploy किया गया code race condition पैदा कर रहा था, जिसके परिणामस्वरूप उपयोगकर्ताओं से Twitter की ओर DDOS-जैसी requests चलने लगीं
- पोस्ट करने वाले ने बताया कि शुरुआत में उसने connection बंद कर दिया था, लेकिन उसके बाद भी कुछ समय तक Twitter requests को उकसाता रहा
- संलग्न सामग्री:
2 टिप्पणियां
Twitter, अस्थायी रूप से rate-limited mode में स्विच
Hacker News की राय
बेहद कड़वे निजी अनुभव से कहूँ तो, भयानक आइडिया होने का साफ़ पता होने के बावजूद उसे लागू करने के लिए मजबूर किया जाना जितना हिला देने वाला होता है, वैसी चीज़ें बहुत कम होती हैं
ख़ासकर तब, जब आप उस व्यक्ति को यह समझाने की कोशिश करें कि वह आपसे आपके बेहतर निर्णय के ख़िलाफ़ जाने को कह रहा है और आप असफल रहें, और बाद में वही व्यक्ति लिखित सबूत होने के बावजूद ज़ोर से यह कहे कि उसने ऐसा कभी कहा ही नहीं था
पता नहीं अभी Twitter में काम करने वाले लोगों ने हाल की कार्रवाई के ऐसे बड़े साइड इफेक्ट्स की चेतावनी दी थी या नहीं, लेकिन नेतृत्व के काम करने के तरीके को देखकर इसमें ज़रा भी हैरानी नहीं होती
पिछले कुछ महीनों में Twitter जैसा बदला है, वह मुझे बहुत नापसंद है, और अधिग्रहण से पहले भी मुझे इसका short-form format पसंद नहीं था क्योंकि उसमें nuance खो जाता था और कुछ embed करने लायक ट्वीट्स ही लेखों का आधार बन जाते थे, लेकिन ऐसे मैनेजमेंट के तहत काम करने वाले लोगों के लिए सच में अफ़सोस होता है
मेरा अंदाज़ा है कि Elon ने कहा होगा, “site बहुत slow है,” और engineers ने देखा होगा कि home feed requests धीमे हैं, लेकिन वे architecture नहीं समझते थे, उनके पास profiling tools भी नहीं थे, और उन पर अवास्तविक deadline में इसे ठीक करने का दबाव था
इसलिए वे शायद लगभग एक ही चीज़ कर सकते थे: कई parallel requests भेजना और उम्मीद करना कि उनमें से कोई एक तेज़ निकले
game industry में काम करके मुझे समझ आया कि इतना पैसा और समय लगाने के बाद भी ऐसे games क्यों रिलीज़ होते हैं जिनमें basic features तक टूटे होते हैं
इस तरह का चरम schedule pressure उल्टा ऐसा विशाल दलदल बना देता है जहाँ एक चीज़ बदलो तो दस टूट जाती हैं, और अंत में प्रगति रुक जाती है
यह basic error handling है जो कई साल पहले से मौजूद होनी चाहिए थी
403 हो या कुछ भी, ट्वीट्स को ब्लॉक करने वाला response कभी भी कम अंतराल वाले infinite retries शुरू नहीं करना चाहिए
मैंने टीम के vulnerability tickets मैनेज करने का एक tool बनाया, और उसका पहला use case मेरी आपत्ति के बावजूद सभी vulnerability tickets delete करना निकला
इसे चलाने वाले व्यक्ति को असली security सुधार से ज़्यादा इस बात की चिंता है कि कागज़ों में सब अच्छा दिखे
सालों से पता हो, बार-बार सुझाव दिया हो, फिर भी कोशिश की अनुमति न मिले, बल्कि आपको अलग-थलग कर दिया जाए और “वही आदमी” समझा जाए
मैंने ऐसे technical और business approach के साथ काम किया है जो “पुराने तरीके” से किसी तरह चलते तो रहते हैं, लेकिन धीरे-धीरे कंपनी को मारते रहते हैं
लेकिन अगर कोई senior साफ़ तौर पर उस काम की ज़िम्मेदारी ले जो उसे खतरनाक होते हुए भी ज़रूरी लगता है, तो समस्या आने पर उससे निपटने की गुंजाइश कहीं बेहतर होती है और developers को बाद की तंज़भरी बातों का कम सामना करना पड़ता है
हालाँकि, ऐसी चीज़ों को कोसना ज़्यादा आसान होता है
यह भी देखना चाहिए कि अभी holiday weekend है
Elon ने एक बड़ा release ज़बरदस्ती आगे बढ़ाया, और engineers को दफ़्तर आकर पिछले 12 घंटों में बार-बार कई patches लगाने पड़े
programmers की चिंता होती है
और भी चौंकाने वाली बात यह है कि आजकल Twitter engineering कितनी जुगाड़ू लगती है
codebase में गहराई तक जाने की मेहनत किए बिना सबसे आसान और सबसे छोटे fixes चुनने से ही समस्याएँ पैदा होती हैं
इस बिंदु पर employment conditions और manager expectations दोनों ही पूरी तरह साफ़ हैं
जो भी कारण हो, जो लोग अब भी टिके हुए हैं, उनके लिए सहानुभूति महसूस करना मुश्किल है
बहुत कम संभावना है कि यही bug असली कारण हो
server-side rate limiter की लागत कम होती है, और frontend bug तभी trigger होता है जब rate limiting सक्रिय हो
जिन systems को मैं संभालता हूँ, उनमें भी मैंने ऐसे bugs देखे हैं जहाँ network library default setting में बिना किसी सामान्य सीमा के requests retry करना पसंद करती है
लेकिन उन retries ने कभी rate limiter पर खास दबाव नहीं डाला
हाँ, अगर आप ऐसे API को hit कर रहे हों जो कुछ महँगा काम करने के बाद error लौटाता हो, तो वह थोड़ा ज़्यादा परेशान कर सकता है, इसलिए हम सभी public endpoints पर rate limiting रखते हैं
web app शायद Twitter traffic का सबसे छोटा हिस्सा है, और native apps में शायद यह समस्या नहीं होगी
यह हो सकता है कि anonymous access block करने से DDoS हुआ, उससे किसी metric में बड़ा spike आया, और फिर Elon ने निष्कर्ष निकाला कि scraping बढ़ गई है, जिसके बाद scrapers को सज़ा देने के लिए उसने रोज़ 600 tweets की limit लगा दी
लगता है मेरा quota reset हो गया है या policy बदल गई है, क्योंकि अब मैं फिर से site खोल पा रहा हूँ
मैं इस बात से सहमत हूँ कि यह bug पूरी घटना का मूल कारण होने की संभावना कम है
लेकिन मुझे Musk की वह कहानी भी भरोसेमंद नहीं लगती जो वह site को लगभग बंद कर देने की वजह के रूप में बेच रहा है
दोनों बातें सच हो सकती हैं, और इससे आदमी दूसरे संभावित कारणों के बारे में सोचता ही रहता है—पूरा समय बर्बाद होता है, फिर भी यह किसी अजीब मानसिक चारे जैसा लगता है
किताब "Nothing is true and everything is possible" में बताया गया है कि Putin किस तरह misinformation का इस्तेमाल जन-नियंत्रण और लोकतांत्रिक राजनीति को हटाने के लिए करता है, और यहाँ भी वैसा ही लागू होता महसूस होता है
Musk के प्रशंसक वही दोहराएँगे जो वह उनसे कहलवाना चाहता है, लेकिन ज़्यादातर लोग समझते होंगे कि यह सिर्फ़ उसके अपने मतलब की बकवास है
और जो लोग root cause ढूँढना चाहते हैं, वे इस bug जैसी ऐसी narratives में आसानी से बह जाते हैं जो सही लगती तो हैं लेकिन जिनके पीछे कोई supporting data नहीं होता
अगर आप अमेरिका के भविष्य के संभावित रास्ते देखना चाहते हैं, तो मैं इस किताब की ज़ोरदार सिफारिश करता हूँ
https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
मैंने खुद ऐसे degenerate cases देखे हैं और उन्हें कम करने की कोशिश की है जहाँ इस तरह के retries backend पर इतना बोझ डालते हैं कि servers requests को reject करने तक के साथ कदम नहीं मिला पाते
upstream callers की कई layers के retries से हालत इतनी बिगड़ गई थी कि requests application तक पहुँचने से पहले ही TCP buffers/queues में ही practically timeout हो जाती थीं
पता नहीं Twitter homepage backend भी उतने ही scale पर है या नहीं
दिलचस्प स्थिति है
स्क्रीनशॉट को देखें तो बहुत बड़ी मात्रा में
GET /TweetDetailबन रहे हैं, और 429 दिख रहा है, यानी लगता है कोई rate limit trigger हो रही हैअगर यह हाल में सभी API calls के लिए authentication अनिवार्य करने के फ़ैसले की वजह से है, तो असली दोषी दरअसल API gateway या उसके नीचे का कोई मिलता-जुलता component हो सकता है
और यह behavior रुकता हुआ नहीं दिखता, जो exponential backoff retry में अपेक्षित behavior नहीं है
मैं यह दावा नहीं कर रहा कि मैं Twitter में काम करने वाले लोगों से बेहतर engineer हूँ, लेकिन Musk से जुड़ी बातों को अलग रखकर भी production में ऐसा देखना दिलचस्प है
मैंने बहुत बार देखा है कि user requests को low latency के साथ serve करना इतना महत्वपूर्ण माना जाता है कि exponential backoff की बजाय fixed random backoff को तरजीह दी जाती है
मैंने कई design meetings और documents में यह स्पष्ट फ़ैसला होते देखा है कि overload और system recovery के tradeoff को समझते हुए भी exponential backoff का इस्तेमाल नहीं किया जाएगा
backend change, यानी mandatory authentication + rate limiting, शायद frontend और backend को पर्याप्त रूप से साथ test किए बिना deploy कर दिया गया होगा
वही सबसे plausible culprit लगता है
हो सकता है Twitter instances को forcefully terminate किया जा रहा हो
Platformer ने 10 जून को रिपोर्ट किया था कि “Twitter 30 जून की contract renewal date से पहले Google cloud services का bill चुकाने से इनकार कर रहा था”
यह भी कहा गया था कि “Twitter का Google Cloud contract 2018 से चला आ रहा था”
https://www.engadget.com/twitter-has-supposedly-started-payi...
आह, लगता है इससे यह पूरा बवाल समझ में आता है
शायद वह GCP से निकलने की कोशिश में हो, लेकिन सिर्फ़ payment से इनकार करने की वजह से अचानक GCP access खो देने का मामला नहीं रहा होगा
यह एक हफ़्ते पहले का article है
सब कुछ self-hosted है
Gcloud सिर्फ़ batch jobs और data analysis को support करता है
दिलचस्प theory है, लेकिन DDoS anonymous access disable करने के फ़ैसले से पहले ही था
दरअसल वह फ़ैसला चल रहे DDoS mitigation के लिए लिया गया था[0][1]
इसलिए संदिग्ध web frontend retry logic ने स्थिति को और ख़राब किया हो सकता है, लेकिन वह मूल कारण नहीं है
[0] https://twitter.com/elonmusk/status/1674865731136020505
“यह अस्थायी emergency measure है. data looting इतनी ज़्यादा थी कि सामान्य users के लिए service quality गिर रही थी!”
[1] https://twitter.com/elonmusk/status/1674942336583757825
“इसे जल्द हटा दिया जाएगा. पहले की post की तरह, data scraping के अत्यधिक स्तर की वजह से साहसी और त्वरित कार्रवाई ज़रूरी थी.”
“startups से लेकर दुनिया की कुछ सबसे बड़ी कंपनियों तक, AI करने वाली लगभग हर company भारी मात्रा में data scrape कर रही थी.”
“किसी AI startup की बेतुकी valuation में मदद करने के लिए मुझे तुरंत बड़ी संख्या में servers बढ़ाने पड़ें, यह काफ़ी खीझ पैदा करने वाली बात है.”
यह तय है कि उन startups द्वारा इस्तेमाल किए जाने वाले किसी ख़ास date से पहले के सभी tweets का एक विशाल archive कहीं न कहीं पहले से मौजूद होगा
क्या किसी को पता है कि login-only change से पहले भी ऐसे requests थे?
अगर यह विशाल scraping operation दरअसल उनका JavaScript bug निकला, तो वाकई मज़ेदार होगा
अगर “scraping traffic” का ज़्यादातर हिस्सा Twitter की अपनी ही गलती निकले, तो मुझे बिल्कुल हैरानी नहीं होगी
बेवकूफ़ी भरा, लेकिन साफ़ दिखाई देने वाला नतीजा था
rate limit लगने से पहले कुछ ही सेकंड में दर्जनों requests निकल गई होंगी
ऐसे बहुत से छोटे bugs मिलकर किसी DDoS या scraping जैसे लग सकते थे
हो सकता है यह bug न हो
Elon ने कहा कि उसने एक दिन में देखे जा सकने वाले tweets की संख्या 600 तक सीमित कर दी, जो पागलपन भरी limit है
ज़्यादातर लोग सिर्फ़ 5 मिनट scroll करें तो भी शायद उससे आगे निकल जाएँ
मुझे याद है जब Tweetbot दिखाता था कि मेरी feed में 500 से ज़्यादा items हैं, तो 20 मिनट के tram rides के कुछ चक्करों के लिए पढ़ने लायक बकवास काफ़ी होती थी
मुझे शक नहीं कि Twitter ने हाल में traffic में भारी बढ़ोतरी देखी होगी, लेकिन मुझे काफ़ी यक़ीन है कि उसका बड़ा हिस्सा Twitter की खुद की बनाई समस्या है
Elon बस इसे ऐसे ही छोड़ सकता था, लेकिन हाँ, याद आया, 44 बिलियन डॉलर का मामला था
Parag Agrawal और उसकी टीम को ठीक-ठीक पता था कि वे क्या कर रहे थे
बिल्कुल वही कहावत है कि मूर्ख और उसका पैसा जल्दी अलग हो जाते हैं
कि Delaware court द्वारा Elon को Twitter खरीदने के लिए मजबूर किए जाने के बाद, वह पैसे वाले तानाशाहों के पास गया, उनसे 44 बिलियन डॉलर लिया, और उनकी तरफ से Twitter को जलाकर खत्म करने का वादा किया
Twitter न हो तो Arab Spring नहीं, आपदाओं के real-time updates नहीं, और विरोध की आवाज़ों को फैलने से रोकने के लिए इंटरनेट बंद करने की ज़रूरत भी नहीं
बहुत बड़ा मतलब नहीं है, लेकिन rate limit फिर से ढीली की जा रही है
6k/600/300 → 8k/800/400(दोपहर करीब) → 10k/1k/500(शाम 3 बजे करीब)
https://twitter.com/elonmusk/status/1675214274627530754 और उसके अपने replies के आधार पर
“Something went wrong” दिख रहा है
नए login-only rules के तहत, साइट चालू भी होती तो भी शायद पढ़ नहीं पाते
अब Twitter links contaminated links बन गई हैं और व्यवहार में लगभग बेकार हैं
पूरा का पूरा सर्कस है