नया ECR कंटेनर इमेज डिप्लॉय के बाद AWS Lambda टाइमआउट क्यों होता है

नया ECR इमेज पुश के बाद AWS Lambda में 300s टाइमआउट? कारण: कोल्ड‑स्टार्ट और इमेज पुल/बूटस्ट्रैप देरी. समाधान: हल्का इमेज, स्टार्टअप सरल, टाइमआउट समायोजित.

जब कंटेनर-आधारित AWS Lambda नए ECR इमेज को पुश करने के तुरंत बाद अचानक टाइमआउट होने लगता है, तो मन करता है कि वजह कॉन्फ़िगरेशन या कोड रिग्रेशन को माना जाए। जबकि जड़ कारण अक्सर ज्यादा साधारण होता है: प्लेटफ़ॉर्म आपका नया इमेज खींचने (pull) और उसे बूटस्ट्रैप करने में लगा होता है, और इसी बीच आपकी इनवोकेशन का समय खत्म हो जाता है।

यह विफलता कैसी दिखती है

नीचे दिया गया इनवोकेशन ट्रेस देखें। फ़ंक्शन का टाइमआउट 300 सेकंड है, और प्लेटफ़ॉर्म रन को खत्म करने से पहले एप्लिकेशन लॉग में कुछ भी नहीं दिखता।

2025-07-14T08:51:28.206+09:00 START RequestId: 24e982ca-5161-4f02-82d7-0bd94d289fc5 Version: $LATEST

2025-07-14T08:56:28.255+09:00 2025-07-13T23:56:28.254Z 24e982ca-5161-4f02-82d7-0bd94d289fc5 Task timed out after 300.05 seconds

2025-07-14T08:56:28.255+09:00 END RequestId: 24e982ca-5161-4f02-82d7-0bd94d289fc5

2025-07-14T08:56:28.255+09:00 REPORT RequestId: 24e982ca-5161-4f02-82d7-0bd94d289fc5 Duration: 300048.73 ms Billed Duration: 301192 ms Memory Size: 128 MB Max Memory Used: 119 MB Init Duration: 1191.06 ms

त्रुटि टाइमआउट की ओर इशारा करती है, मेमोरी खत्म होने की नहीं। डिफ़ॉल्ट Lambda टाइमआउट 3 सेकंड है, इसलिए यहाँ कॉन्फ़िगरेशन पहले ही बढ़ाकर 300 सेकंड किया गया है।

नया ECR इमेज डिप्लॉय करने के बाद ऐसा क्यों होता है

कंटेनर इमेज अपडेट होते ही पिछला कोड अमान्य हो जाता है। अगली इनवोकेशन आने पर Lambda सेवा आपके फ़ंक्शन को प्लेटफ़ॉर्म के किसी भी होस्ट पर शेड्यूल करती है। उस होस्ट को आपके अभी‑अभी पुश किए गए इमेज के बारे में कुछ पता नहीं होता, इसलिए उसे बिना किसी लेयर कैश के पूरा इमेज ECR से खींचना पड़ता है। डाउनलोड पूरा होने के बाद ही रनटाइम आपका इमेज लॉन्च करता है। अगर आपका इमेज या एप्लिकेशन भारी स्टार्टअप काम करता है—जैसे डिपेंडेंसीज़ लाना या JVM इनिशियलाइज़ करना—तो ये सब आपके हैंडलर तक इवेंट पहुँचने से पहले चलता है। फ़ंक्शन तभी तैयार होता है जब यह सब पूरा हो जाए।

पहली Lambda इंस्टेंस चलने तक आने वाली सभी इनवोकेशंस को कोल्ड‑स्टार्ट व्यवहार के कारण देरी होगी।

यह पूरी प्रक्रिया कंटेनर इमेज के लिए क्लासिक कोल्ड स्टार्ट पाथ है। अगर यह आपके कॉन्फ़िगर किए गए टाइमआउट से लंबा खिंच जाए, तो सेवा 300 सेकंड के टाइमआउट त्रुटि के साथ प्रयास समाप्त कर देती है। AWS अपने Lambda रनटाइम वातावरण के दस्तावेज़ों में इस कोल्ड‑स्टार्ट विलंब और उससे जुड़े संदेशों का उल्लेख करता है, और समान परिदृश्यों पर समुदाय के उत्तरों—जैसे यह और यह—में चर्चा मिलती है। कोल्ड‑स्टार्ट विलंब पर आधिकारिक मार्गदर्शन यहाँ उपलब्ध है।

इसका समाधान क्या है

प्रभाव घटाने के कई व्यवहार्य तरीके हैं। अगर आपका वर्कलोड अनुमति देता है तो टाइमआउट बढ़ाएँ। इमेज का आकार छोटा रखें ताकि ECR से पुल जल्दी पूरा हो। इमेज के भीतर स्टार्टअप‑टाइम का काम कम करें—डिपेंडेंसीज़ छाँटें या इनिशियलाइज़ेशन सरल करें। अपनी परिस्थिति में तेजी से शुरू होने वाली भाषा पर भी विचार कर सकते हैं। एक बार इमेज पुल हो जाए और इंस्टेंस वॉर्म हो, तो अगली इनवोकेशंस सामान्य रूप से चलनी चाहिए, और शुरुआती कुछ इनवोकेशंस टाइमआउट होकर रिट्राई हो सकती हैं, जब तक कि इमेज होस्ट पर कैश न हो जाए। आप जैसे ही नया इमेज डिप्लॉय करते हैं, चक्र फिर से दोहरता है क्योंकि पिछला इमेज अमान्य हो जाता है।

एक रिपोर्टेड मामले में, हर 10 मिनट पर फ़ंक्शन को बुलाने से समस्या दोबारा नहीं आई—यह इस विचार से मेल खाता है कि नियमित रूप से चलने वाले फ़ंक्शंस वॉर्म रहते हुए लंबे कोल्ड स्टार्ट से बच जाते हैं।

इंजीनियरिंग टीमों के लिए यह क्यों मायने रखता है

कंटेनर इमेज वाले Lambda आपको पैकेजिंग पर नियंत्रण देते हैं, लेकिन वे रिलीज़ के तुरंत बाद आने वाली शुरुआती इनवोकेशंस पर कुछ कोल्ड‑स्टार्ट लागत डालते हैं। अगर कोई क्रिटिकल पाथ रिलीज़ के तुरंत बाद तत्काल रिस्पॉन्स पर निर्भर है, तो लंबा इमेज पुल या भारी इनिशियलाइज़ेशन उपयोगकर्ता‑दृश्यमान टाइमआउट में बदल सकता है। यह समझना कि प्लेटफ़ॉर्म को इवेंट सँभालने से पहले आपका इमेज डाउनलोड करना और एक‑बार का स्टार्टअप काम चलाना पड़ सकता है, आपको सुरक्षित टाइमआउट, उचित इमेज आकार और स्वीकार्य वॉर्म‑अप व्यवहार की योजना बनाने में मदद करता है।

मुख्य बातें

अगर आप नया कंटेनर इमेज ECR पर प्रकाशित करके Lambda अपडेट करने के तुरंत बाद 300‑सेकंड के टाइमआउट देखते हैं, तो इसे मेमोरी सीमा नहीं बल्कि कोल्ड‑स्टार्ट व्यवहार मानें। टाइमआउट को इमेज पुल और स्टार्टअप कार्य के अनुरूप रखें, कंटेनर और उसके इनिशियलाइज़ेशन को सरल बनाएँ, और यह अपेक्षा रखें कि ताज़ा इमेज पुश के बाद सबसे शुरुआती इनवोकेशंस इमेज के कैश होने तक विलंबित या रिट्राई हो सकती हैं। अगर डिप्लॉय के तुरंत बाद सतत उपलब्धता चाहिए, तो अपनी रिलीज़ और ट्रैफ़िक रणनीतियों में इस विंडो का हिसाब रखें। अधिक पृष्ठभूमि के लिए AWS के कोल्ड‑स्टार्ट विलंब संबंधी दस्तावेज़ और संदर्भित स्पष्टीकरण देखें।