क्लाउड / सिस्टम
Amazon EFS की समस्या दिखने से बहुत पहले मौजूद हो सकती है। छोटा फ़ाइल सिस्टम सीमित burst credits खर्च करते हुए कई हफ्तों या महीनों तक वर्कलोड ठीक चला सकता है। एप्लिकेशन स्वस्थ दिखता है, डैशबोर्ड हरे रहते हैं और आर्किटेक्चर पर भरोसा बन जाता है। फिर जमा क्रेडिट शून्य हो जाते हैं और उसी वर्कलोड के सामने लगातार उपलब्ध throughput की कहीं कम सीमा आ जाती है।
इस देरी से समस्या अचानक आई लगती है। संचालन के नजरिए से वह बिल्कुल अचानक नहीं होती।
छिपा हुआ असंतुलन
Bursting Throughput में baseline throughput, EFS Standard storage class में रखे डेटा की मात्रा के साथ बढ़ती है। AWS के दस्तावेज़ों में baseline दर 50 KiB/s प्रति GiB है और हर फ़ाइल सिस्टम को कम से कम 1 MiB/s metered throughput मिलती है। Baseline से कम काम करने पर credits जमा होते हैं; उससे ज्यादा पर खर्च होते हैं।
खतरा ऐसे वर्कलोड में है जिसकी लंबे समय की औसत मांग baseline से थोड़ी ज्यादा हो। तुरंत घटना नहीं होती, क्योंकि पहले जमा credits अंतर पूरा करते रहते हैं। लेकिन बैलेंस हर दिन घटता जाता है।
लक्षण गलत दिशा में क्यों ले जाते हैं
Storage calls धीमी हों तो application workers इंतजार करते हैं। Linux में ऐसे processes जो uninterruptible I/O wait में रुके हैं, load average में गिने जाते हैं। इसलिए storage bottleneck, compute क्षमता की समस्या जैसा दिख सकता है। अनुरोध कतार में लगते हैं, worker pools भरते हैं और पूरे सिस्टम में timeouts फैलते हैं, जबकि CPU इस्तेमाल असली वजह नहीं होता।
और instances जोड़ने से स्थिति बिगड़ सकती है, अगर हर नया worker उसी सीमित shared file system पर और अनुरोध भेजे। Bottleneck साझा है और बढ़ी हुई concurrency उसी पर दबाव बढ़ाती है।
छह अच्छे महीने भी बहुत कम क्यों साबित करते हैं
लंबे समय तक विफलता न होना सिर्फ उस अवधि की मांग, baseline throughput और बचे credits के मेल को सही साबित करता है। यह नहीं साबित करता कि credits खत्म होने के बाद भी वर्कलोड टिकाऊ रहेगा। लगातार घटता BurstCreditBalance इसलिए सिर्फ क्षमता का आंकड़ा नहीं, भरोसेमंदी के लिए शुरुआती चेतावनी है।
Load testing में स्थिर लंबे समय की स्थिति भी देखनी चाहिए, सिर्फ छोटा peak test नहीं। दस मिनट का test दिखा सकता है कि burst सीमा पर्याप्त ऊंची है। वह हजारों घंटों में जमा होते घाटे के बारे में ज्यादा नहीं बताता।
जांच का बेहतर क्रम
- CPU utilization की तुलना load average और I/O wait से करें।
- EFS की जांच करें
BurstCreditBalanceकई हफ्तों या महीनों की अवधि में। - तुलना करें
MeteredIOBytesइसके साथPermittedThroughput. - Storage की सीमाओं को application latency और भरे हुए worker pools से जोड़कर देखें।
- देखें कि Standard storage class में वास्तव में कितना डेटा है, क्योंकि Bursting baseline उसी से तय होती है।
- तय करें कि वर्कलोड के लिए Bursting, Elastic या Provisioned throughput सही है।
इंजीनियरिंग की सीख
Burst capacity एक बफ़र है, क्षमता की योजना नहीं। Credits पर चलने वाली हर सेवा को उसके बैलेंस की दिशा और घटने की दर से परखना चाहिए, सिर्फ यह देखकर नहीं कि संख्या शून्य से ऊपर है। इस श्रृंखला का पिछला लेख असली घटना के पैटर्न को विस्तार से समझाता है; अगला लेख इसी सीख को CloudWatch मॉनिटरिंग डिज़ाइन में बदलता है।