रैक पर सर्वर रहित

सर्वर रहित सर्वर की भौतिक अनुपस्थिति के बारे में नहीं है। यह कोई कंटेनर किलर या कोई प्रचलित प्रवृत्ति नहीं है। यह क्लाउड में सिस्टम बनाने का एक नया दृष्टिकोण है। आज के लेख में हम सर्वर रहित अनुप्रयोगों की वास्तुकला पर बात करेंगे, आइए देखें कि सर्वर रहित सेवा प्रदाता और ओपन-सोर्स प्रोजेक्ट क्या भूमिका निभाते हैं। अंत में, आइए सर्वर रहित उपयोग के मुद्दों के बारे में बात करें।

मैं किसी एप्लिकेशन (या यहां तक ​​कि एक ऑनलाइन स्टोर) का सर्वर भाग लिखना चाहता हूं। यह एक चैट, एक सामग्री प्रकाशन सेवा या एक लोड बैलेंसर हो सकता है। किसी भी मामले में, बहुत सारे सिरदर्द होंगे: आपको बुनियादी ढांचा तैयार करना होगा, एप्लिकेशन निर्भरता निर्धारित करनी होगी और होस्ट ऑपरेटिंग सिस्टम के बारे में सोचना होगा। फिर आपको छोटे घटकों को अद्यतन करने की आवश्यकता होगी जो शेष मोनोलिथ के संचालन को प्रभावित नहीं करते हैं। खैर, आइए लोड के तहत स्केलिंग के बारे में न भूलें।

क्या होगा यदि हम अल्पकालिक कंटेनर लेते हैं, जिसमें आवश्यक निर्भरताएँ पहले से ही स्थापित हैं, और कंटेनर स्वयं एक दूसरे से और होस्ट ओएस से अलग हैं? हम मोनोलिथ को माइक्रोसर्विसेज में विभाजित करेंगे, जिनमें से प्रत्येक को दूसरों से स्वतंत्र रूप से अपडेट और स्केल किया जा सकता है। ऐसे कंटेनर में कोड रखकर मैं इसे किसी भी इंफ्रास्ट्रक्चर पर चला सकता हूं। पहले से बेहतर.

यदि आप कंटेनरों को कॉन्फ़िगर नहीं करना चाहते तो क्या होगा? मैं एप्लिकेशन को स्केल करने के बारे में नहीं सोचना चाहता। जब सेवा पर भार न्यूनतम हो तो मैं निष्क्रिय चल रहे कंटेनरों के लिए भुगतान नहीं करना चाहता। मैं कोड लिखना चाहता हूँ. व्यावसायिक तर्क पर ध्यान केंद्रित करें और उत्पादों को प्रकाश की गति से बाज़ार में लाएँ।

ऐसे विचारों ने मुझे सर्वर रहित कंप्यूटिंग की ओर प्रेरित किया। इस मामले में सर्वर रहित का मतलब है सर्वरों की भौतिक अनुपस्थिति नहीं, बल्कि बुनियादी ढांचे प्रबंधन सिरदर्द की अनुपस्थिति।

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

आइए देखें कि एप्लिकेशन विकास प्रक्रिया अब कैसी दिखेगी।

डेवलपर की ओर से

पहले हमने एक ऑनलाइन स्टोर के लिए एक एप्लिकेशन के बारे में बात करना शुरू किया था। पारंपरिक दृष्टिकोण में, सिस्टम का मुख्य तर्क एक अखंड अनुप्रयोग द्वारा निष्पादित किया जाता है। और एप्लिकेशन वाला सर्वर लगातार चलता रहता है, भले ही कोई लोड न हो।

सर्वर रहित में जाने के लिए, हम एप्लिकेशन को माइक्रोटास्क में तोड़ देते हैं। हम उनमें से प्रत्येक के लिए अपना स्वयं का फ़ंक्शन लिखते हैं। फ़ंक्शन एक-दूसरे से स्वतंत्र हैं और राज्य की जानकारी (स्टेटलेस) संग्रहीत नहीं करते हैं। इन्हें विभिन्न भाषाओं में भी लिखा जा सकता है। यदि उनमें से एक "गिर जाता है", तो पूरा एप्लिकेशन बंद नहीं होगा। एप्लिकेशन आर्किटेक्चर इस तरह दिखेगा:

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

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

हम प्रत्येक फ़ंक्शन के लिए एक ईवेंट निर्दिष्ट करते हैं। एक घटना एक कार्रवाई के लिए एक ट्रिगर है:

घटना
वह क्रिया जो फ़ंक्शन करता है

एक उत्पाद छवि रिपॉजिटरी पर अपलोड कर दी गई है।
छवि को संपीड़ित करें और एक निर्देशिका में अपलोड करें

भौतिक स्टोर का पता डेटाबेस में अद्यतन कर दिया गया है
मानचित्रों में नया स्थान लोड करें

ग्राहक माल के लिए भुगतान करता है
भुगतान प्रक्रिया प्रारंभ करें

ईवेंट HTTP अनुरोध, स्ट्रीमिंग डेटा, संदेश कतार इत्यादि हो सकते हैं। इवेंट स्रोत डेटा में परिवर्तन या घटनाएँ हैं। इसके अलावा, फ़ंक्शन को टाइमर द्वारा ट्रिगर किया जा सकता है।

आर्किटेक्चर पर काम किया गया और एप्लिकेशन लगभग सर्वर रहित हो गया। इसके बाद हम सेवा प्रदाता के पास जाते हैं।

प्रदाता की ओर से

आमतौर पर, सर्वर रहित कंप्यूटिंग क्लाउड सेवा प्रदाताओं द्वारा पेश की जाती है। उन्हें अलग तरह से कहा जाता है: Azure फ़ंक्शंस, AWS लैम्ब्डा, Google क्लाउड फ़ंक्शंस, IBM क्लाउड फ़ंक्शंस।

हम प्रदाता के कंसोल या व्यक्तिगत खाते के माध्यम से सेवा का उपयोग करेंगे। फ़ंक्शन कोड को निम्नलिखित में से किसी एक तरीके से डाउनलोड किया जा सकता है:

• वेब कंसोल के माध्यम से अंतर्निर्मित संपादकों में कोड लिखें,
• कोड के साथ पुरालेख डाउनलोड करें,
• सार्वजनिक या निजी गिट रिपॉजिटरी के साथ काम करें।

यहां हम उन इवेंट को सेट करते हैं जो फ़ंक्शन को कॉल करते हैं। अलग-अलग प्रदाताओं के लिए इवेंट के सेट अलग-अलग हो सकते हैं.

प्रदाता ने अपने बुनियादी ढांचे पर एक सेवा के रूप में कार्य (एफएएएस) प्रणाली का निर्माण और स्वचालित किया:

1. फ़ंक्शन कोड प्रदाता की ओर भंडारण में समाप्त होता है।
2. जब कोई घटना घटती है, तो तैयार वातावरण वाले कंटेनर स्वचालित रूप से सर्वर पर तैनात हो जाते हैं। प्रत्येक फ़ंक्शन इंस्टेंस का अपना पृथक कंटेनर होता है।
3. भंडारण से, फ़ंक्शन कंटेनर में भेजा जाता है, गणना की जाती है, और परिणाम लौटाता है।
4. समानांतर घटनाओं की संख्या बढ़ रही है - कंटेनरों की संख्या बढ़ रही है। सिस्टम स्वचालित रूप से स्केल करता है। यदि उपयोगकर्ता फ़ंक्शन तक नहीं पहुंचते हैं, तो यह निष्क्रिय हो जाएगा।
5. प्रदाता कंटेनरों के लिए निष्क्रिय समय निर्धारित करता है - यदि इस समय के दौरान कंटेनर में फ़ंक्शन दिखाई नहीं देते हैं, तो यह नष्ट हो जाता है।

इस तरह हम सर्वरलेस को बॉक्स से बाहर निकाल देते हैं। हम सेवा के लिए पे-एज़-यू-गो मॉडल का उपयोग करके भुगतान करेंगे और केवल उन कार्यों के लिए जिनका उपयोग किया जाता है, और केवल उस समय के लिए जब उनका उपयोग किया गया था।

डेवलपर्स को सेवा से परिचित कराने के लिए, प्रदाता 12 महीने तक निःशुल्क परीक्षण की पेशकश करते हैं, लेकिन कुल गणना समय, प्रति माह अनुरोधों की संख्या, धन या बिजली की खपत को सीमित करते हैं।

किसी प्रदाता के साथ काम करने का मुख्य लाभ बुनियादी ढांचे (सर्वर, वर्चुअल मशीन, कंटेनर) के बारे में चिंता न करने की क्षमता है। अपनी ओर से, प्रदाता अपने स्वयं के विकास और ओपन-सोर्स टूल का उपयोग करके FaaS को लागू कर सकता है। आइए उनके बारे में आगे बात करते हैं।

खुले स्रोत की ओर से

ओपन-सोर्स समुदाय पिछले कुछ वर्षों से सर्वर रहित टूल पर सक्रिय रूप से काम कर रहा है। सबसे बड़े बाज़ार खिलाड़ी भी सर्वर रहित प्लेटफ़ॉर्म के विकास में योगदान करते हैं:

• गूगल डेवलपर्स को अपना ओपन-सोर्स टूल प्रदान करता है - चाकू. आईबीएम, रेडहैट, पिवोटल और एसएपी ने इसके विकास में भाग लिया;
• आईबीएम सर्वर रहित प्लेटफॉर्म पर काम किया ओपनव्हिस्क, जो बाद में अपाचे फाउंडेशन का एक प्रोजेक्ट बन गया;
• माइक्रोसॉफ्ट प्लेटफ़ॉर्म कोड आंशिक रूप से खोला गया एज़्योर फ़ंक्शंस.

सर्वर रहित ढांचे की दिशा में भी विकास चल रहा है। कुबेलेस и विखंडन पहले से तैयार कुबेरनेट क्लस्टर के अंदर तैनात किया गया, ओपनएफएएस कुबेरनेट्स और डॉकर स्वार्म दोनों के साथ काम करता है। फ्रेमवर्क एक प्रकार के नियंत्रक के रूप में कार्य करता है - अनुरोध पर, यह क्लस्टर के अंदर एक रनटाइम वातावरण तैयार करता है, फिर वहां एक फ़ंक्शन लॉन्च करता है।

फ़्रेमवर्क आपकी आवश्यकताओं के अनुरूप टूल को कॉन्फ़िगर करने के लिए जगह छोड़ते हैं। तो, क्यूबलेस में, एक डेवलपर फ़ंक्शन निष्पादन टाइमआउट को कॉन्फ़िगर कर सकता है (डिफ़ॉल्ट मान 180 सेकंड है)। विखंडन, कोल्ड स्टार्ट समस्या को हल करने के प्रयास में, कुछ कंटेनरों को हर समय चालू रखने का सुझाव देता है (हालांकि इसमें संसाधन डाउनटाइम लागत शामिल होती है)। और OpenFaaS हर स्वाद और रंग के लिए ट्रिगर्स का एक सेट प्रदान करता है: HTTP, काफ्का, Redis, MQTT, Cron, AWS SQS, NATs और अन्य।

आरंभ करने के निर्देश फ़्रेमवर्क के आधिकारिक दस्तावेज़ में पाए जा सकते हैं। उनके साथ काम करने के लिए प्रदाता के साथ काम करने की तुलना में थोड़ा अधिक कौशल की आवश्यकता होती है - यह कम से कम सीएलआई के माध्यम से कुबेरनेट्स क्लस्टर लॉन्च करने की क्षमता है। अधिक से अधिक, अन्य ओपन-सोर्स टूल (उदाहरण के लिए, काफ्का कतार प्रबंधक) शामिल करें।

भले ही हम सर्वरलेस के साथ कैसे भी काम करें - एक प्रदाता के माध्यम से या ओपन-सोर्स का उपयोग करके, हमें सर्वरलेस दृष्टिकोण के कई फायदे और नुकसान प्राप्त होंगे।

फायदे और नुकसान की दृष्टि से

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

सर्वर रहित विकास समय को और भी कम कर देता है, डेवलपर को केवल एप्लिकेशन के व्यावसायिक तर्क और कोडिंग पर ध्यान केंद्रित करने की अनुमति देता है। परिणामस्वरूप, विकास के विपणन का समय कम हो गया है।

बोनस के रूप में, हमें लोड के लिए स्वचालित स्केलिंग मिलती है, और हम केवल उपयोग किए गए संसाधनों के लिए भुगतान करते हैं और केवल उस समय जब उनका उपयोग किया जाता है।

किसी भी तकनीक की तरह, सर्वरलेस के भी नुकसान हैं।

उदाहरण के लिए, ऐसा नुकसान कोल्ड स्टार्ट टाइम (जावास्क्रिप्ट, पायथन, गो, जावा, रूबी जैसी भाषाओं के लिए औसतन 1 सेकंड तक) हो सकता है।

एक ओर, वास्तव में, कोल्ड स्टार्ट का समय कई चर पर निर्भर करता है: वह भाषा जिसमें फ़ंक्शन लिखा जाता है, पुस्तकालयों की संख्या, कोड की मात्रा, अतिरिक्त संसाधनों के साथ संचार (समान डेटाबेस या प्रमाणीकरण सर्वर)। चूंकि डेवलपर इन वेरिएबल्स को नियंत्रित करता है, वह स्टार्टअप समय को कम कर सकता है। लेकिन दूसरी ओर, डेवलपर कंटेनर के स्टार्टअप समय को नियंत्रित नहीं कर सकता - यह सब प्रदाता पर निर्भर करता है।

जब कोई फ़ंक्शन पिछले ईवेंट द्वारा लॉन्च किए गए कंटेनर का पुन: उपयोग करता है तो एक ठंडी शुरुआत एक गर्म शुरुआत में बदल सकती है। यह स्थिति तीन मामलों में उत्पन्न होगी:

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

कई अनुप्रयोगों के लिए, कोल्ड स्टार्ट कोई समस्या नहीं है। यहां आपको सेवा के प्रकार और कार्यों पर निर्माण करने की आवश्यकता है। व्यावसायिक अनुप्रयोग के लिए एक सेकंड की शुरुआत में देरी हमेशा महत्वपूर्ण नहीं होती है, लेकिन यह चिकित्सा सेवाओं के लिए महत्वपूर्ण हो सकती है। इस मामले में, सर्वर रहित दृष्टिकोण संभवतः अब उपयुक्त नहीं होगा।

सर्वरलेस का अगला नुकसान किसी फ़ंक्शन का छोटा जीवनकाल (टाइमआउट जिसके दौरान फ़ंक्शन को निष्पादित किया जाना चाहिए) है।

लेकिन, यदि आपको लंबे समय तक चलने वाले कार्यों के साथ काम करना है, तो आप हाइब्रिड आर्किटेक्चर का उपयोग कर सकते हैं - सर्वरलेस को किसी अन्य तकनीक के साथ जोड़ सकते हैं।

सभी सिस्टम सर्वर रहित योजना का उपयोग करके काम करने में सक्षम नहीं होंगे।

कुछ एप्लिकेशन निष्पादन के दौरान अभी भी डेटा और स्थिति संग्रहीत करेंगे। कुछ वास्तुकलाएं अखंड रहेंगी और कुछ विशेषताएं लंबे समय तक जीवित रहेंगी। हालाँकि (क्लाउड प्रौद्योगिकियों और फिर कंटेनरों की तरह), सर्वरलेस एक महान भविष्य वाली तकनीक है।

इस नस में, मैं सर्वर रहित दृष्टिकोण का उपयोग करने के मुद्दे पर आसानी से आगे बढ़ना चाहूंगा।

आवेदन पक्ष से

2018 के लिए, सर्वर रहित उपयोग का प्रतिशत डेढ़ गुना बढ़ गया. जिन कंपनियों ने पहले ही अपनी सेवाओं में प्रौद्योगिकी लागू कर दी है उनमें ट्विटर, पेपाल, नेटफ्लिक्स, टी-मोबाइल, कोका-कोला जैसे बाजार दिग्गज शामिल हैं। साथ ही, आपको यह समझने की आवश्यकता है कि सर्वरलेस कोई रामबाण नहीं है, बल्कि समस्याओं की एक निश्चित श्रृंखला को हल करने के लिए एक उपकरण है:

• संसाधन डाउनटाइम कम करें. जिन सेवाओं पर कम कॉल आती हैं, उनके लिए लगातार वर्चुअल मशीन रखने की आवश्यकता नहीं है।
• तुरंत डेटा प्रोसेस करें. चित्रों को संपीड़ित करें, पृष्ठभूमि को काटें, वीडियो एन्कोडिंग बदलें, IoT सेंसर के साथ काम करें, गणितीय संचालन करें।
• अन्य सेवाओं को एक साथ "गोंद" करें। आंतरिक कार्यक्रमों के साथ गिट रिपॉजिटरी, जिरा और कैलेंडर के साथ स्लैक में चैट बॉट।
• भार को संतुलित करें. आइए यहां करीब से देखें।

मान लीजिए कि एक ऐसी सेवा है जो 50 लोगों को आकर्षित करती है। इसके नीचे कमजोर हार्डवेयर वाली एक वर्चुअल मशीन है। समय-समय पर सेवा पर भार काफी बढ़ जाता है। तब कमजोर हार्डवेयर सामना नहीं कर सकता।

आप सिस्टम में एक बैलेंसर शामिल कर सकते हैं जो लोड को तीन वर्चुअल मशीनों पर वितरित करेगा। इस स्तर पर, हम लोड का सटीक अनुमान नहीं लगा सकते हैं, इसलिए हम संसाधनों की एक निश्चित मात्रा को "रिजर्व में" रखते हैं। और हम डाउनटाइम के लिए अधिक भुगतान करते हैं।

ऐसी स्थिति में, हम हाइब्रिड दृष्टिकोण के माध्यम से सिस्टम को अनुकूलित कर सकते हैं: हम लोड बैलेंसर के पीछे एक वर्चुअल मशीन छोड़ते हैं और फ़ंक्शंस के साथ सर्वर रहित एंडपॉइंट पर एक लिंक डालते हैं। यदि लोड सीमा से अधिक है, तो बैलेंसर फ़ंक्शन इंस्टेंस लॉन्च करता है जो अनुरोध प्रसंस्करण का हिस्सा लेता है।

इस प्रकार, सर्वरलेस का उपयोग वहां किया जा सकता है जहां बड़ी संख्या में अनुरोधों को बहुत बार नहीं, बल्कि गहनता से संसाधित करना आवश्यक होता है। इस मामले में, किसी वर्चुअल मशीन या सर्वर को हर समय बनाए रखने की तुलना में 15 मिनट तक कई फ़ंक्शन चलाना अधिक लाभदायक है।

सर्वर रहित कंप्यूटिंग के सभी फायदों के साथ, कार्यान्वयन से पहले, आपको पहले एप्लिकेशन तर्क का मूल्यांकन करना चाहिए और समझना चाहिए कि सर्वर रहित किसी विशेष मामले में कौन सी समस्याएं हल कर सकता है।

सर्वर रहित और चयनकर्ता

सेलेक्टेल में हम पहले से ही हैं कुबेरनेट्स के साथ सरलीकृत कार्य हमारे नियंत्रण कक्ष के माध्यम से। अब हम अपना स्वयं का FaaS प्लेटफ़ॉर्म बना रहे हैं। हम चाहते हैं कि डेवलपर्स एक सुविधाजनक, लचीले इंटरफ़ेस के माध्यम से सर्वरलेस का उपयोग करके अपनी समस्याओं को हल करने में सक्षम हों।

यदि आपके पास कोई विचार है कि आदर्श FaaS प्लेटफ़ॉर्म क्या होना चाहिए और आप अपनी परियोजनाओं में सर्वरलेस का उपयोग कैसे करना चाहते हैं, तो उन्हें टिप्पणियों में साझा करें। प्लेटफ़ॉर्म विकसित करते समय हम आपकी इच्छाओं को ध्यान में रखेंगे।
 
लेख में प्रयुक्त सामग्री:

• सर्वर रहित उपयोग का प्रतिशत डेढ़ गुना बढ़ गया है (पूर्ण राइटस्केल रिपोर्ट)
• प्रारंभ का समय कितना ठंडा है यह एप्लिकेशन की भाषा पर निर्भर करता है

स्रोत: www.habr.com