AWS Lambda या Cloud Run Functions: सस्ती दर अस्थिरता नहीं छिपाती

भारत में समान सर्वररहित कार्यभार के लिए AWS Lambda और Cloud Run functions में चुनाव केवल प्रति अनुरोध दर से तय नहीं होता। कम यातायात वाले काम में दोनों के मुफ्त उपयोग का लाभ मिल सकता है, लेकिन शिखर पर निष्पादन समय, आवंटित संसाधन और प्रतिक्रिया समय का फैलाव अधिक मायने रखते हैं।

सीधा उत्तर कार्यभार पर निर्भर है। जब एक समय में बहुत से अलग निष्पादन चाहिए और देरी का अनुमान महत्वपूर्ण है, Lambda Event Functions से हिसाब शुरू करना उचित है। जब कोड एक ही उदाहरण में कई अनुरोध कुशलता से सँभाल सकता है, Cloud Run functions का साझा CPU और स्मृति उपयोग खर्च घटा सकता है। पुराने Google फ़ंक्शन पर हुआ स्वतंत्र परीक्षण स्थिरता का संकेत देता है, वर्तमान सेवा के लिए निश्चित परिणाम नहीं।

अनुरोध दर पूरे बिल का छोटा हिस्सा है

AWS Lambda की मूल्य सूची के अनुसार Event Functions में अनुरोधों के साथ निष्पादन अवधि का शुल्क लगता है; अवधि आवंटित स्मृति के अनुपात में जीबी-सेकंड में गिनी जाती है। मासिक मुफ्त स्तर में दस लाख अनुरोध और 400,000 जीबी-सेकंड हैं। स्मृति बढ़ाने से उपलब्ध CPU भी अनुपात में बढ़ता है। इसीलिए अधिक स्मृति की प्रति सेकंड लागत बढ़ने पर भी CPU प्रधान काम जल्दी समाप्त हो तो उसके कुल जीबी-सेकंड घट सकते हैं। यह संभावना है, हर काम के लिए तय बचत नहीं।

Cloud Run की मूल्य सूची में अनुरोध आधारित बिलिंग के लिए अनुरोध, आवंटित vCPU का समय और स्मृति का समय अलग मद हैं। मासिक मुफ्त स्तर बीस लाख अनुरोध, 180,000 vCPU-सेकंड और 360,000 गीबीबाइट-सेकंड के अमेरिकी आधार मूल्य पर लागू होता है; यह बिलिंग खाते की परियोजनाओं में साझा छूट है। बिल योग्य उदाहरण समय में अनुरोध सँभालने के साथ उदाहरण का शुरू और बंद होना भी शामिल है। Cloud Run functions इसी सेवा की तरह बिल होती हैं; Cloud Build, Artifact Registry, Eventarc और बाहर भेजे गए डेटा का शुल्क अलग जुड़ सकता है।

भारत के लिए पहले दोनों सेवाओं का मुंबई क्षेत्र चुनें, फिर वहाँ की प्रकाशित दर और एक ही मुद्रा में तुलना करें। Lambda में अनुरोधों के अलावा वास्तुकला, स्मृति और कुल निष्पादन सेकंड चाहिए। Cloud Run में अनुरोधों के अलावा vCPU, स्मृति, बिल योग्य उदाहरण सेकंड और चुनी हुई समवर्तिता चाहिए। Google की मुफ्त छूट अमेरिकी आधार मूल्य पर आधारित होने के कारण मुंबई के उपयोग से सीधे उतने ही सेकंड घटाकर शेष पर दर लगाना सटीक बिल नहीं देगा।

तीन भारतीय कार्यभारों में गणना कैसे बदलती है

ये काल्पनिक मासिक इनपुट हैं, वास्तविक उपयोग या प्रदाताओं के बिल नहीं। Lambda के लिए अनुरोध × प्रति अनुरोध अवधि × आवंटित जीबी से जीबी-सेकंड निकालें। Cloud Run के लिए बिल योग्य उदाहरण सेकंड को आवंटित vCPU और गीबीबाइट से अलग-अलग गुणा करें। हर मद पर मुंबई की दर लगाने के बाद खाते में बची मुफ्त छूट और अन्य सेवाओं का खर्च जोड़ने या घटाने से अनुमान बनेगा।

• छोटा API: मान लें महीने में 100,000 अनुरोध आते हैं और प्रत्येक 0.2 सेकंड चलता है। Lambda को 0.5 जीबी स्मृति देने पर 10,000 जीबी-सेकंड बनते हैं। Cloud Run में एक साथ एक अनुरोध, एक vCPU और 0.5 गीबीबाइट स्मृति मानें तो बिना अतिरिक्त आरंभ समय के 20,000 उदाहरण सेकंड, 20,000 vCPU-सेकंड और 10,000 गीबीबाइट-सेकंड बनेंगे। मुख्य उपयोग दोनों की मुफ्त सीमा से नीचे दिखता है, बशर्ते खाते की साझा छूट पहले खर्च न हुई हो; आरंभ और सहायक सेवाएँ फिर भी अलग देखनी होंगी।
• आकस्मिक बैच: मान लें महीने में 10,000 काम कुछ अचानक आने वाले दौरों में पूरे हों और हर काम दस सेकंड ले। Lambda को दो जीबी स्मृति देने पर 200,000 जीबी-सेकंड बनते हैं। Cloud Run में एक vCPU, दो गीबीबाइट स्मृति और प्रति उदाहरण एक काम मानें तो सक्रिय काम के 100,000 उदाहरण सेकंड से 100,000 vCPU-सेकंड तथा 200,000 गीबीबाइट-सेकंड निकलते हैं। मासिक योग यह नहीं बताता कि एक साथ कितने उदाहरण शुरू होंगे; उनकी शुरुआत का समय और प्रतीक्षा अलग से खर्च तथा देरी बढ़ा सकते हैं।
• अधिक समवर्ती सेवा: मान लें महीने में पचास लाख अनुरोध हों, प्रत्येक 0.4 सेकंड ले और शिखर पर प्रति सेकंड 500 अनुरोध आएँ। Lambda में एक जीबी स्मृति पर बीस लाख जीबी-सेकंड बनेंगे; शिखर पर लगभग 200 साथ चलने वाले निष्पादन चाहिए होंगे। Cloud Run में एक vCPU, एक गीबीबाइट स्मृति और प्रति उदाहरण बीस समवर्ती अनुरोध मानने पर पूर्ण उपयोग की आदर्श गणना 100,000 उदाहरण सेकंड देती है। यह तभी संभव है जब कोड का CPU और उसकी बाहरी सेवाएँ इतनी समवर्तिता पर वही 0.4 सेकंड अवधि बनाए रखें। अधभरे उदाहरण और धीमे अनुरोध बिल योग्य समय बढ़ाएँगे।

अंतिम उदाहरण में अनुरोधों की संख्या दोनों तरफ समान रहती है, लेकिन गणना की अवधि अलग है। Lambda का निष्पादन समय हर अनुरोध से जुड़ता है; Cloud Run में साथ चल रहे अनुरोध एक उदाहरण का आवंटित CPU और स्मृति साझा करते हैं। इसलिए समवर्तिता को केवल विन्यास की ऊपरी सीमा मानें। यदि साझा CPU के कारण अवधि बढ़ती है, तो कम उदाहरणों से मिलने वाला लाभ घट सकता है।

ठंडी शुरुआत और क्षमता की कीमत

AWS की समवर्तिता संबंधी व्याख्या के अनुसार Lambda Event Function में एक साथ चल रहे अनुरोधों के लिए निष्पादन वातावरण बढ़ते हैं। आरक्षित समवर्तिता किसी फ़ंक्शन के लिए क्षमता अलग रखती है, लेकिन वातावरण पहले से शुरू नहीं करती। पहले से तैयार समवर्तिता ठंडी शुरुआत का असर घटाती है और उसका अतिरिक्त शुल्क लगता है। इस कारण मुफ्त निष्पादन सीमा के भीतर दिखने वाला, कम औसत यातायात वाला API भी अचानक उछाल पर अपेक्षित देरी पूरी न कर पाए।

Google की फ़ंक्शन पीढ़ियों की तुलना के अनुसार वर्तमान Cloud Run functions एक Cloud Run सेवा के रूप में चलती हैं और एक उदाहरण कई समवर्ती अनुरोध ले सकता है; पहली पीढ़ी में प्रति उदाहरण एक अनुरोध चलता था। यह अंतर उच्च भार में संभावित बचत समझाता है, लेकिन उदाहरण में अनुरोधों की संख्या बढ़ाने से प्रत्येक को अधिक CPU नहीं मिल जाता। CPU प्रधान कोड, साझा स्मृति या धीमी बाहरी सेवा के कारण प्रतिक्रिया समय बढ़े तो अतिरिक्त उदाहरणों की जरूरत पड़ सकती है।

स्वतंत्र माप की उपयोगी और सीमित सीख

SeBS आधारित स्वतंत्र अध्ययन में जाँचे गए कार्यभारों पर AWS Lambda का प्रतिक्रिया समय उच्च समवर्ती भार में अधिक स्थिर था, जबकि Google के परिणाम अधिक बदलते थे; परीक्षण में Google की पहली पीढ़ी के Cloud Functions, कम स्मृति वाला विन्यास, AWS का फ़्रैंकफ़र्ट क्षेत्र और Google का बेल्जियम क्षेत्र इस्तेमाल हुआ। अध्ययन में देरी बढ़ने का व्यवहार मापा गया था, मुंबई में वर्तमान Cloud Run functions का प्रदर्शन नहीं। इसलिए इसकी स्थिरता संबंधी सीख को मूल्य सूची के साथ रखना उपयोगी है, लेकिन इससे आज की दोनों सेवाओं के लिए निश्चित विजेता या भारतीय प्रतिक्रिया समय नहीं निकलता।

चुनाव में लागत के साथ देरी की सीमा भी मायने रखती है। छोटे API में मुख्य निष्पादन मद मुफ्त छूट में समा सकते हैं; आकस्मिक बैच में नई क्षमता शुरू होने की प्रतीक्षा अधिक महत्वपूर्ण हो सकती है। लगातार अधिक समवर्ती अनुरोधों वाली सेवा में Cloud Run का साझा उदाहरण तभी आर्थिक लाभ देगा जब वह भार के दौरान प्रतिक्रिया समय बनाए रखे। जहाँ देरी का फैलाव महँगा पड़ता है, वहाँ सस्ती दिखने वाली इकाई दर से अधिक वजन शिखर भार पर व्यवहार को मिलना चाहिए।

यह भी पढ़ें:

• Amazon S3 या Google Cloud Storage: भारत में निकासी शुल्क फैसला पलटता है
• Kimi K3 भारत के AWS क्षेत्रों में आया—अनुरोध देश से बाहर जा सकता है
• Google Workspace या Zoho Workplace: सस्ती योजना में फ़ाइल बदलने की कीमत