एडब्ल्यूएस सेवाओं का उपयोग कर लंबे समय से चलने वाले कार्यों का निर्धारण

Question

मेरा आवेदन एडब्ल्यूएस सेवाओं पर भारी निर्भर करता है, और मैं उनके आधार पर एक इष्टतम समाधान की तलाश में हूं। वेब एप्लिकेशन एक निर्धारित नौकरी ट्रिगर करता है (अनगिनत बार-बार मानें) जिसके लिए संसाधनों की कुछ मात्रा की आवश्यकता होती है। कार्य के एकल भाग में आमतौर पर अधिकतम 1 मिनट लगेंगे।

वर्तमान विचार क्यूई आकार के आधार पर एसक्यूएस और स्पॉन श्रमिकों के माध्यम से नौकरियों को पारित करना है। (यह हिस्सा कम या ज्यादा स्पष्ट है) लेकिन मैं वास्तव में कुछ अंतराल पर नौकरियों को ट्रिगर करने के लिए एक उचित समाधान खोजने के लिए संघर्ष करता हूं। मान लें कि हम 10000 नौकरियों से निपट रहे हैं। इसलिए एक शेड्यूलर के लिए 10k cronjobs चलाने के लिए (नौकरी स्वयं ही सरल है, बस एसक्यूएस के माध्यम से नौकरी का विवरण पास कर रहा है) एक ही समय में एक पागल विचार की तरह लगता है। तो वास्तविक सवाल यह होगा कि शेड्यूलर को स्वयं कैसे ऑटोस्केल करना है (शेड्यूलर को पुनरारंभ करने पर परिदृश्य दिए गए हैं, नया उदाहरण बनाया गया है आदि)? या शेड्यूलर ऐप के रूप में अनावश्यक है और एडब्ल्यूएस लैम्ब्डा फ़ंक्शंस (या शेड्यूलिंग प्रदान करने वाली अन्य सेवाएं) पर भरोसा करना बुद्धिमान है? लैम्ब्डा फ़ंक्शंस का उपयोग करने में समस्या निश्चित सीमा है और एकल फ़ंक्शन द्वारा प्रदान की गई 128 एमबी की स्मृति वास्तव में बहुत अधिक है (20 एमबी पर्याप्त से अधिक की तरह दिखती है)

वैकल्पिक रूप से, कार्यकर्ता स्वयं कुछ निश्चित समय तक प्रतीक्षा कर सकता है और अधिसूचित कर सकता है शेड्यूलर कि इसे नौकरी को एक और बार ट्रिगर करना चाहिए। मान लीजिए कि अगर आवृत्ति 1 घंटा है करते हैं:

1. Scheduler sends job to worker 1 
2. Worker 1 performs the job and after one hour sends it back to Scheduler 
3. Scheduler sends the job again 

यहां मुद्दा यह है तथापि कि कार्यकर्ता की संभावना में

बॉटम लाइन मैं एक हल्के अनुसूचक जायें जो कि प्राप्त करने के लिए कोशिश कर रहा हूँ बढ़ाया मिल जाएगा। ऑटोस्केलिंग की आवश्यकता नहीं है और नौकरी के विवरण प्रसारित करने के एकमात्र उद्देश्य के साथ एक केंद्र के रूप में कार्य करता है। और निश्चित रूप से सेवा पुनरारंभ पर थ्रॉटल नहीं होना चाहिए।

Answer 1

लैम्बडा इसके लिए बिल्कुल सही है। आपके पास बहुत कम चल रही प्रक्रियाएं हैं (~ 1 मिनट) और लैम्ब्डा छोटी प्रक्रियाओं के लिए है (आजकल पांच मिनट तक)। यह जानना बहुत महत्वपूर्ण है कि सीपीयू की गति रैम रैखिक रूप से रैम के साथ मिलती है। यदि मैं सही ढंग से याद करता हूं तो एक 1 जीबी लैम्ब्डा फ़ंक्शन एक t2.micro उदाहरण के बराबर है, और 1.5 जीबी रैम का अर्थ है 1.5x अधिक CPU गति। इन कार्यों की लागत इतनी कम है कि आप इसे निष्पादित कर सकते हैं। 128 एमबी रैम में सूक्ष्म उदाहरण की 1/8 सीपीयू गति है इसलिए मैं वास्तव में उन लोगों का उपयोग करने की अनुशंसा नहीं करता हूं।

एक क्यूइंग तंत्र के रूप में आप एस 3 का उपयोग कर सकते हैं (हाँ आप इसे सही पढ़ते हैं)। एक बाल्टी बनाएं और जब ऑब्जेक्ट बनाया जाता है तो लैम्ब्डा कार्यकर्ता ट्रिगर करने दें। जब आप नौकरी निर्धारित करना चाहते हैं, तो बाल्टी के अंदर एक फाइल डालें। Lambda तुरंत शुरू होता है और इसे संसाधित करता है।

अब आपको कुछ सीमाओं का सम्मान करना होगा। इस तरह आप एक ही समय में केवल 100 श्रमिक (सक्रिय लैम्ब्डा उदाहरणों की कुल राशि) प्राप्त कर सकते हैं, लेकिन आप इसे बढ़ाने के लिए एडब्ल्यूएस से पूछ सकते हैं।

• 0,005 प्रति 1000 PUT अनुरोध है, तो प्रति मिलियन नौकरी अनुरोध $ 5 (इस SQS से ज्यादा महंगा है):

  लागत इस प्रकार हैं।

• लैम्ब्डा रनटाइम। सामान्य t2.micro CPU गति (1 जीबी रैम) मानते हुए, यह $ 0.0001 प्रति नौकरी (60 सेकंड, पहले 300.000 सेकंड मुफ्त = 5000 नौकरियां)
• लैम्ब्डा अनुरोध। $ 0.20 प्रति मिलियन ट्रिगर्स (पहला मिलियन मुफ्त है)

इस सेटअप को आपके हिस्से पर किसी भी सर्वर की आवश्यकता नहीं है। यह नीचे नहीं जा सकता (केवल अगर एडब्ल्यूएस स्वयं करता है)।