न ली गई छूट - Spot और Graviton सस्ते क्यों हैं

AWS का बिल लगातार दो महीने बजट से एक अंकों वाले प्रतिशत से ऊपर निकल गया। रकम के लिहाज़ से बड़ा नहीं था, पर दिशा ऊपर की थी। कहां और कम करूं सोचकर संसाधन एक-एक करके खंगाले, तो नतीजा उलटा निकला। घटाने लायक संसाधन लगभग बचा ही नहीं था। असली लीवर "कितना इस्तेमाल करते हैं" में नहीं, "कैसे ख़रीदते हैं" में था। इस प्रक्रिया में जो सीखा वह यह था कि बिल के हर आंकड़े की एक वजह होती है, और वह वजह जाने बिना यह तय नहीं हो सकता कि क्या बंद करें और क्या रहने दें।

संसाधन पहले से ही कसे हुए थे

पहले इस्तेमाल की मात्रा देखी। पर यह हिस्सा तो पहले से ही काफ़ी संवारा हुआ था। NAT गेटवे हटाकर पब्लिक सबनेट से डिज़ाइन किया गया था, लॉग सिर्फ़ 7 दिन रखे जाते थे, ट्रेसिंग 1% सैंपलिंग पर थी, और ऑब्ज़र्वेबिलिटी डैशबोर्ड फ़्री टियर के भीतर ही ठूंसा हुआ था। DB और Redis पहले से सस्ते ARM इंस्टेंस पर चल रहे थे, S3 में ऑटो-टियरिंग लगी थी, और बैस्शन ज़रूरत पड़ने पर ही उठाया जाता था। संसाधन के स्तर पर जो निचोड़ा जा सकता था, लगभग सब निचोड़ा जा चुका था।

जून के बिल को आइटम के हिसाब से देखें तो: सबसे बड़ा हिस्सा अकेले DB (RDS) का था - कुल का क़रीब 40%, उसके बाद कंप्यूट (ECS Fargate) क़रीब 17%, फिर लोड बैलेंसर और WAF दोनों क़रीब 10%-10%, और पब्लिक IP, कैश (ElastiCache) व S3 इकाई अंकों वाले प्रतिशत पर सिमटे हुए। यहां इंस्टेंस को और छोटा करना उल्टा कदम होता। DB में एक बार मेमोरी कम पड़ने पर उसे बढ़ाया गया था, और WAF प्रोडक्शन डिप्लॉय से पहले नियमों को जांचने के लिए जान-बूझकर रखा गया था। बचा हुआ लीवर संसाधन नहीं, ख़रीदने का तरीक़ा था - वही संसाधन इस्तेमाल करते हुए, उसे सस्ता ख़रीदने का रास्ता।

Spot सस्ता क्यों है

सबसे पहले जो बात दिखी वह यह थी कि कंप्यूट सिर्फ़ ऑन-डिमांड लिस्ट प्राइस पर ख़रीदा जा रहा था। AWS के पास वही सर्वर कहीं सस्ता बेचने की खिड़की भी है - Fargate Spot। यह ऑन-डिमांड के मुक़ाबले क़रीब 70% सस्ता है।

इतना सस्ता होने की एक वजह है। AWS पीक डिमांड के हिसाब से डेटा सेंटर पहले से बनाकर रखता है। सामान्य समय में सर्वर बचे रह जाते हैं। बची हुई क्षमता को यूं ही खाली छोड़ने पर मुनाफ़ा शून्य रहता है, इसलिए "फ़ुल-प्राइस ग्राहक आए तो 2 मिनट में जगह खाली कर दो" की शर्त लगाकर वह बची हुई क्षमता कौड़ियों के भाव बेच दी जाती है। यह ठीक वैसे ही है जैसे एयरलाइन उड़ान से ठीक पहले खाली सीटें सस्ते में बेच देती है - वैसे भी खाली उड़ी तो कमाई शून्य ही है, तो शर्त लगाकर भी बेच देना फ़ायदे का सौदा है।

अहम सवाल यह है कि क्या उस शर्त - यानी "हटने को कहा जाए तो हट जाना" - को झेला जा सकता है। प्रोडक्शन में यह मुश्किल है। यूज़र जुड़े हों और टास्क 2 मिनट बाद वापस ले लिया जाए तो सेवा पल भर के लिए ही सही, डगमगा जाती है। पर staging अलग है। वहां असली यूज़र नहीं होते, और कुछ मिनट डाउन रहने पर भी बस एक QA को थोड़ी देर असुविधा होती है। इसलिए staging के API को Spot पर ले गए। परफ़ॉर्मेंस ऑन-डिमांड जैसी बिल्कुल एक जैसी है - vCPU और मेमोरी दोनों उसी हार्डवेयर पर चलते हैं। बदलती है सिर्फ़ एक चीज़, "वापस लिया जा सकता है" वाली उपलब्धता की शर्त, और वह शर्त staging ख़ुशी-ख़ुशी झेल सकता था। लागू करने के बाद staging के टास्क Spot पर सामान्य रूप से चलने लगे।

Graviton सस्ता क्यों है

दूसरी बात कंप्यूट की चिप को लेकर थी। DB और Redis पहले से ARM इंस्टेंस पर चल रहे थे, पर ऐप्लिकेशन चलाने वाला Fargate ही x86 पर रह गया था। AWS की अपनी बनाई ARM चिप, Graviton पर जाने से वही परफ़ॉर्मेंस क़रीब 20% सस्ते में मिल जाता है।

इसके सस्ते होने की वजह Spot से अलग है। सामान्य इंस्टेंस में AWS Intel या AMD से CPU ख़रीदकर इस्तेमाल करता है, इसलिए हमारे भुगतान में चिप बनाने वाली कंपनी का मार्जिन भी जुड़ा रहता है। Graviton AWS की ख़ुद डिज़ाइन की हुई चिप है, इसलिए वह बीच का मार्जिन नहीं है। इसके अलावा ARM आर्किटेक्चर वही काम कम बिजली और कम गर्मी में कर लेता है, जिससे डेटा सेंटर का बिजली और कूलिंग ख़र्च भी कम बैठता है। AWS के लिए लागत कम है, इसलिए 20% सस्ता बेचकर भी मुनाफ़ा बचता है, और साथ ही सस्ता बेचकर ग्राहकों को अपनी चिप के इकोसिस्टम में खींचने की रणनीति भी है।

फ़र्क़ यहां अहम है। Spot की छूट के साथ "वापसी को झेलने" की शर्त जुड़ी होती है, पर Graviton की छूट पर कोई शर्त नहीं। यह बस एक सस्ती चिप है। इसलिए Spot staging तक ही सीमित रह सकता है, जबकि Graviton प्रोडक्शन तक वैसे ही लागू होता है। परफ़ॉर्मेंस को लेकर भी ख़ास चिंता नहीं। Node.js में Graviton पर vCPU के हिसाब से परफ़ॉर्मेंस x86 के बराबर या उससे बेहतर ही है। एकमात्र देखने वाली बात कोल्ड-स्टार्ट है। ऐप पहली बार शुरू होते वक़्त सिंगल-कोर स्पीड पर निर्भर करता है, और यहां Graviton नए x86 से थोड़ा धीमा हो सकता है, जिससे शुरुआत में कुछ सेकंड ज़्यादा लग सकते हैं। पहले staging पर चढ़ाकर स्टार्टअप टाइम नाप लिया, फिर प्रोडक्शन पर प्रमोट किया। इसके लिए बस एक जांच काफ़ी है - नेटिव मॉड्यूल arm64 के लिए बिल्ड होते हैं या नहीं।

दोनों छूटों के स्वभाव को समेटें तो यह बनता है। Spot असुविधा झेलने की क़ीमत के बदले मिलने वाली छूट है, इसलिए शर्त जुड़ी है (इसीलिए staging तक), और Graviton AWS की अपनी चिप की लागत-बढ़त में हिस्सा है, इसलिए कोई शर्त नहीं (इसीलिए प्रोडक्शन तक भी)। परफ़ॉर्मेंस एक जैसी होने पर महंगे x86 लिस्ट प्राइस पर टिके रहने की कोई वजह नहीं थी। दरअसल यह ऑप्टिमाइज़ेशन नया कुछ बचाने से ज़्यादा, जो छूट अब तक नहीं ली जा रही थी, उसे अब लेना शुरू करने के क़रीब है।

कुछ खर्च बंद नहीं करने चाहिए

पर बिल को खंगालते वक़्त उल्टी दिशा का जाल भी मिलता है। जो फ़िज़ूलख़र्ची जैसा दिखता है, असल में बीमा होता है।

RDS Proxy ऐसा ही निकला। हर महीने एक तय रकम ख़र्च हो रही थी, और पहली नज़र में यह बचत का उम्मीदवार लगा। Proxy के कामों में से एक सीक्रेट को बिना रुकावट अपने-आप घुमाना (rotation) है, और वह rotation फ़ीचर फ़िलहाल बंद था। rotation इस्तेमाल ही नहीं हो रहा तो Proxy क्यों रखा है, यही सवाल उठा।

यह ग़लतफ़हमी थी। Proxy का असली मक़सद rotation नहीं, कनेक्शन सर्ज को रोकना था। डिप्लॉय या स्केल-आउट से टास्क अचानक बढ़ें तो DB की ओर जाने वाले कनेक्शन उछल पड़ते हैं, और DB एक साथ जितने कनेक्शन ले सकता है उसकी एक सीमा होती है। Proxy उसके आगे खड़े होकर कनेक्शन को इकट्ठा कर मल्टीप्लेक्स करता है, ताकि वह सीमा पार न हो। संयोग से यही वह DB था जिसमें एक बार मेमोरी कम पड़ने पर उसे बढ़ाया गया था, और हर कनेक्शन मेमोरी खाता है। यानी वह तय ख़र्च फ़िज़ूलख़र्ची नहीं, बल्कि हर डिप्लॉय पर DB को कनेक्शन के उछाल से गिरने से बचाने वाला बीमा प्रीमियम था। इसे बंद करना बचत नहीं, बचाव की दीवार हटाना होता।

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

बिल के हर आंकड़े की एक वजह होती है

क्लाउड ख़र्च घटाने की बात सुनते ही हाथ पहले "क्या बंद करूं" की तरफ़ जाता है। इंस्टेंस घटाओ, फ़ीचर बंद करो, संसाधन मिटाओ। पर इस बार जो सीखा वह इसका उल्टा था। घटाने से पहले जो सवाल पूछना चाहिए वह है - "यह आंकड़ा यहां है क्यों"।

कुछ आंकड़े न ली गई छूट होते हैं। Spot और Graviton जैसे, वही संसाधन सस्ते में ख़रीदने की खिड़की होते हुए भी बस लिस्ट प्राइस पर ख़रीदा जा रहा था। ऐसी हर छूट के सस्ते होने की अपनी वजह होती है, और वह वजह (वापसी झेलनी है या बिना शर्त लागत-बढ़त है) जानने से तय होता है कि इसे कहां सुरक्षित तरीक़े से लागू करें। कुछ आंकड़े उल्टे, बंद न करने वाले बीमे होते हैं। फ़िज़ूलख़र्ची जैसे दिखने पर भी अगर वह कोई हादसा रोक रहा है, तो वह लाइन-आइटम ख़र्च नहीं, बचाव है।

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