जब लमदा फ़ंक्शन को पूरा करने के लिए 30 सेकंड से अधिक की आवश्यकता होती है, तो एपीआई गेटवे टाइमआउट को संभालें
आपकी मदद की जरूरत हैं! एपीआई गेटवे से, मैं एक लैम्बडा फ़ंक्शन को ट्रिगर करने की कोशिश कर रहा हूं। यह लैम्ब्डा फ़ंक्शन क्लाउडफ़ॉर्मेशन स्टैक बनाने जा रहा है और स्टैक एक ईसी 2-उदाहरण को तैनात करने वाला है। नीचे उस कोड का हिस्सा है जो स्टैक क्रिएशन को आरंभ करता है और स्टैक क्रिएशन की स्थिति का इंतजार करता है ताकि वह प्रतिक्रिया वापस कर सके। बात एपीआई गेटवे की 30 सेकंड की हार्ड-कोडेड टाइमआउट मूल्य है और स्टैक निर्माण 30 सेकंड से पहले पूरा नहीं होता है। इस परिदृश्य में, API अनुरोध केवल आंतरिक सर्वर त्रुटि को वापस करते हुए। इससे मैं कैसे निपटूं?
# Create the CloudFormation Stack
StackID = cf_client.create_stack(
StackName=stackname,
TemplateURL='https://s3-bucket/template1.template',
Capabilities=['CAPABILITY_NAMED_IAM']
)
waiter = cf_client.get_waiter('stack_create_complete')
waiter.wait(
StackName=stackname,
WaiterConfig={
'Delay' : 5,
'MaxAttempts' : 50
}
)
जवाब
शायद लैम्ब्डा के बजाय सीधे CloudFormation स्टैक बनाने के कारण यह एक स्टेप फंक्शन को पूरी तरह से CloudFormation स्टैक बनाने के लिए ट्रिगर कर सकता है । मूल फ़ंक्शन निष्पादन आईडी को तब लौटा सकता है जब वह start_execution फ़ंक्शन चलाने के बाद वापस लौटता है।
यह 2 लाभ प्रदान करता है, पहला यह है कि यह बहुत तेज होगा (एक बार चरण फ़ंक्शन निष्पादन शुरू हो जाने के बाद एसडीके द्वारा एक प्रतिक्रिया वापस कर दी जाती है ताकि यह जल्दी हो जाए), साथ ही विफलता के लिए लचीला होने के कारण (आपके पास विकल्प है त्रुटियों पर पुन: प्रयास करें या सूचित करें)।
वैकल्पिक रूप से, यदि आप चाहते हैं कि क्लाइंट से HTTP अनुरोध के भीतर ही ऐसा करने का अनुरोध किया जाए, तो आपको एपीआई गेटवे (जिसमें अधिकतम कटऑफ है) के बजाय अपने लैम्बडा को यातायात की सेवा करने वाले ALB को देखना होगा । एक ALB 4000 सेकंड तक के लंबे समय तक का समर्थन कर सकता है ।