छह महीने का टाइम बम: जब EFS के बर्स्ट क्रेडिट खत्म हुए

लगभग छह महीने तक सब कुछ बिल्कुल ठीक चलता दिखा। इतनी लंबी शांति ही खतरनाक हिस्सा थी।

एक वेब ऐप साझा स्टोरेज के लिए Amazon Elastic File System (EFS) इस्तेमाल कर रहा था। कई ऐप इंस्टेंस एक ही फ़ाइलें खोल सकते थे, डिप्लॉयमेंट आसान था और आर्किटेक्चर पर सवाल उठाने की कोई स्पष्ट वजह नहीं दिख रही थी।

फिर बिना किसी साफ चेतावनी के वेबसाइट बहुत धीमी हो गई और आखिरकार ऐसा लगा मानो पूरी तरह बंद हो गई हो। सर्वर लोड असामान्य रूप से ऊँचा था, रिक्वेस्ट टाइमआउट हो रही थीं और ऐप की प्रक्रियाएँ जमा होने लगीं।

पहली नज़र में यह कंप्यूट क्षमता की समस्या लगी। ऐसा नहीं था। असली वजह EFS का बर्स्ट-क्रेडिट बैलेंस खत्म होना था।

खराबी CPU की समस्या जैसी क्यों लगी

भ्रम पैदा करने वाला एक लक्षण Linux का ऊँचा लोड एवरेज था। ऊँचे लोड एवरेज का मतलब हमेशा CPU का पूरी तरह व्यस्त होना नहीं होता। इसमें ऐसी प्रक्रियाएँ भी आती हैं जो uninterruptible स्थिति में इंतज़ार कर रही हों; स्टोरेज I/O पर अटकने पर ऐसा अक्सर होता है।

ऐप के वर्कर EFS ऑपरेशन पूरे होने का इंतज़ार कर रहे थे। नई रिक्वेस्ट आती रहीं, और वर्कर अटकते गए तथा रिक्वेस्ट की कतार बढ़ती गई:

EFS का थ्रूपुट सीमित हो गया।
फ़ाइल ऑपरेशन में अधिक समय लगने लगा।
ऐप के वर्कर I/O का इंतज़ार करते हुए व्यस्त रहे।
आने वाली रिक्वेस्ट जमा होती गईं।
सिस्टम का लोड बढ़ गया।
आखिरकार वेबसाइट व्यवहार में लगभग अनुपलब्ध हो गई।

अधिक CPU क्षमता जोड़ने से मूल समस्या हल नहीं होती।

खराबी सामने आने में छह महीने क्यों लगे

EFS फ़ाइल सिस्टम को इस मोड में कॉन्फ़िगर किया गया था: Bursting Throughput । इस मोड में लंबे समय तक मिलने वाला बेसलाइन थ्रूपुट EFS Standard स्टोरेज क्लास में रखे डेटा की मात्रा से जुड़ा होता है। वर्कलोड बेसलाइन से नीचे रहे तो फ़ाइल सिस्टम बर्स्ट क्रेडिट जमा करता है। थ्रूपुट बेसलाइन से ऊपर जाए तो वही क्रेडिट खर्च होते हैं।

इससे अपेक्षाकृत छोटे फ़ाइल सिस्टम में भ्रम पैदा हो सकता है:

कम डेटा होने से टिकाऊ बेसलाइन थ्रूपुट कम होता है।
पहले से जमा क्रेडिट कुछ समय के लिए काफी अधिक थ्रूपुट देते हैं।
लंबे समय का वर्कलोड टिकाऊ बेसलाइन से अधिक होने पर भी ऐप सामान्य चलता दिखता है।
क्रेडिट बचे रहने तक असंतुलन छिपा रहता है।
बैलेंस शून्य होते ही प्रदर्शन बहुत गिर जाता है।

इस मामले में जमा क्रेडिट लगभग छह महीने चले। थ्रूपुट के लिहाज़ से आर्किटेक्चर की क्षमता पहले ही कम थी, लेकिन क्रेडिट बैलेंस ने समस्या छिपा रखी थी। यह धीरे-धीरे बढ़ती क्षमता की समस्या थी—छह महीने तक टिक-टिक करता टाइम बम।

अस्थायी बर्स्ट प्रदर्शन को कभी टिकाऊ थ्रूपुट नहीं समझना चाहिए।

EFS का सही थ्रूपुट मोड चुनना

Bursting Throughput

Bursting Throughput तब सही हो सकता है जब रखे गए डेटा के साथ थ्रूपुट की ज़रूरत स्वाभाविक रूप से बढ़े और व्यस्त दौर के बाद शांत समय मिले। इसकी सावधानी से मॉनिटरिंग ज़रूरी है। लगातार गिरता क्रेडिट बैलेंस बताता है कि इस मोड में वर्कलोड लंबे समय तक नहीं चल सकता।

Elastic Throughput

Elastic Throughput आम तौर पर अनिश्चित या बहुत उतार-चढ़ाव वाले वर्कलोड के लिए बेहतर है। थ्रूपुट माँग के साथ अपने आप बढ़ता-घटता है, इसलिए ऐप सीमित बर्स्ट-क्रेडिट बैलेंस पर निर्भर नहीं रहता। इससे संचालन अधिक भरोसेमंद बनता है, हालाँकि लगातार ऊँचे थ्रूपुट वाले वर्कलोड में उपयोग-आधारित लागत का आकलन करना चाहिए।

Provisioned Throughput

Provisioned Throughput तब उपयोगी है जब ज़रूरी थ्रूपुट पता हो और वह रखे गए डेटा की मात्रा से मिलने वाली क्षमता से अधिक हो। यह फ़ाइल सिस्टम के आकार से अलग, अनुमान लगाने योग्य क्षमता देता है, लेकिन माँग बदलने पर तय क्षमता की समीक्षा करनी होती है।

यह फर्क समझना भी ज़रूरी है कि EFS का थ्रूपुट मोड और उसका परफ़ॉर्मेंस मोडएक ही चीज़ नहीं हैं। थ्रूपुट मोड तय करता है कि थ्रूपुट क्षमता कैसे मिलेगी; परफ़ॉर्मेंस मोड का संबंध लेटेंसी और समानांतर काम जैसी विशेषताओं से है।

किस तरह की मॉनिटरिंग होनी चाहिए थी

Bursting Throughput वाले EFS फ़ाइल सिस्टम का सबसे ज़रूरी CloudWatch मेट्रिक है BurstCreditBalance। मॉनिटरिंग की बुनियादी व्यवस्था में ये भी शामिल होने चाहिए:

BurstCreditBalance क्रेडिट का लगातार घटना पहचानने के लिए
PercentIOLimit यह जानने के लिए कि फ़ाइल सिस्टम अपनी I/O सीमा के पास कब पहुँच रहा है
PermittedThroughput अभी उपलब्ध थ्रूपुट समझने के लिए
MeteredIOBytes और TotalIOBytes I/O की खपत देखने के लिए
ऐप की लेटेंसी, रिक्वेस्ट में लगा समय, टाइमआउट और त्रुटि दर
I/O का इंतज़ार कर रही प्रक्रियाएँ, जिन्हें लोड और वास्तविक CPU उपयोग के साथ मिलाकर देखा जाए

सिर्फ CPU, मेमोरी और HTTP स्टेटस कोड की मॉनिटरिंग काफी नहीं है। साझा स्टोरेज ऐप की महत्वपूर्ण निर्भरता है। इसे केवल इंफ़्रास्ट्रक्चर का हिस्सा नहीं, सेवा का हिस्सा मानकर मॉनिटर करना चाहिए।

क्रेडिट बैलेंस शून्य होने से काफी पहले अलार्म बजना चाहिए। उससे भी ज़रूरी है रुझान देखना। कई हफ्तों तक लगातार गिरता बैलेंस थ्रूपुट की संरचनात्मक कमी दिखाता है, भले ही कुल बचा बैलेंस अभी आरामदायक लगे।

मैं अब क्या अलग करूँगा

डिज़ाइन के समय ही टिकाऊ थ्रूपुट का अनुमान लगाऊँगा।
वास्तविक एक्सेस पैटर्न के आधार पर थ्रूपुट मोड चुनूँगा।
बर्स्ट क्रेडिट को अस्थायी अतिरिक्त गुंजाइश मानूँगा, सामान्य क्षमता नहीं।
क्रेडिट बैलेंस और I/O सीमाओं के लिए CloudWatch अलार्म बनाऊँगा।
क्रेडिट खर्च होने की दर मॉनिटर करूँगा।
लोड टेस्ट में EFS थ्रूपुट और लेटेंसी शामिल करूँगा।
Linux लोड को CPU उपयोग और I/O wait के साथ मिलाकर देखूँगा।
जाँचूँगा कि बार-बार इस्तेमाल होने वाली फ़ाइलों को सचमुच साझा नेटवर्क स्टोरेज चाहिए या नहीं।
स्टोरेज थ्रॉटलिंग और बढ़ी हुई लेटेंसी में ऐप का व्यवहार जाँचूँगा।
थ्रूपुट मोड बदलने की संचालन प्रक्रिया लिखूँगा।

मुख्य सीख

EFS साझा स्टोरेज का बहुत अच्छा समाधान हो सकता है, लेकिन उसका व्यवहार चुने गए थ्रूपुट मोड और वर्कलोड के पैटर्न पर काफी निर्भर करता है।

इस घटना का खतरनाक हिस्सा सिर्फ प्रदर्शन गिरना नहीं था। खतरा यह था कि गिरावट से पहले सिस्टम छह महीने तक ठीक चला। बर्स्ट-क्रेडिट बैलेंस ने खराबी इतनी देर छिपाई कि लंबे समय तक न टिक सकने वाले आर्किटेक्चर पर भरोसा बन गया।

सबसे अच्छा बचाव अधिक क्रेडिट बैलेंस नहीं है। सही थ्रूपुट मोड चुनना, टिकाऊ थ्रूपुट समझना और ऐसे मेट्रिक मॉनिटर करना ज़रूरी है जो उपयोगकर्ताओं को असर दिखने से पहले बढ़ता असंतुलन बता दें।