एक कामकाजी वीडियो सेवा के तेजी से विकास के लिए सर्वर रहित दृष्टिकोण

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

यह देखते हुए: AWS पर रूट खाता, प्रौद्योगिकी स्टैक की पसंद पर कोई प्रतिबंध नहीं, एक बैक-एंड और विकास के लिए एक महीने।

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

निर्णय

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

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


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

हमारी सेवा में लंबी-चलने वाली प्रक्रियाएं शामिल नहीं हैं, इसके लिए एक बड़े और बोल्ड रिलेशनल डेटाबेस की आवश्यकता नहीं होती है, और पूरी तरह से माइक्रोसर्विस कॉल की एक श्रृंखला के साथ घटना वास्तुकला में फिट बैठता है। समाधान स्वयं सुझाव देता है - हम EC2 को छोड़ सकते हैं और AWS लैम्ब्डा पर आधारित मानक छवि पुनर्विक्रेता की तरह एक सच्चे-सर्वर रहित एप्लिकेशन को लागू कर सकते हैं।

वैसे, .NET के लिए AWS डेवलपर्स के स्पष्ट नापसंद के बावजूद, वे .NET कोर 2.1 को रनटाइम के रूप में समर्थन करते हैं, जो विकास के अवसरों की पूरी श्रृंखला देता है।

और केक पर चेरी - AWS वीडियो फ़ाइलों के साथ काम करने के लिए एक अलग सेवा प्रदान करता है - AWS एलिमेंट मीडियाकॉनवर्ट।

काम का सार अविश्वसनीय रूप से सरल है: हम S3 लिंक को आउटगोइंग वीडियो, AWS कंसोल, .NET SDK या सिर्फ JSON के माध्यम से लिखते हैं जो हम वीडियो के साथ करना चाहते हैं और सेवा को कॉल करते हैं। वह स्वयं आने वाले अनुरोधों को संसाधित करने के लिए कतारों को लागू करता है, वह S3 में परिणाम को अनलोड करता है और सबसे महत्वपूर्ण बात यह है कि प्रत्येक स्थिति परिवर्तन के लिए एक CloudWatch ईवेंट उत्पन्न करता है। यह हमें वीडियो प्रोसेसिंग को पूरा करने के लिए लैम्बडा ट्रिगर्स को लागू करने की अनुमति देता है।


वास्तुकला का अंतिम संस्करण कुछ इस तरह दिखता है

पूरे बैकएंड को दो लैम्ब्डा में रखा गया है। एक और ऊर्ध्वाधर वीडियो को घुमाने के लिए है, क्योंकि इस तरह के काम को एक बार में नहीं किया जा सकता है।

वीडियो रिज़ॉल्यूशन के अनुसार फ्लाई पर एक पारदर्शी छवि प्रदान करके टेक्स्ट ओवरले किया गया था। SixLabors.ImageSharp पुस्तकालय इस उद्देश्य के लिए एकदम सही है, और स्मृति रिसाव की समस्याओं को स्पष्ट रूप से लंबर जीवन चक्र को बायपास करता है।

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

नुकसान

• किसी अज्ञात कारण से AWS MediaConvert व्यक्तिगत रूप से प्रत्येक वीडियो क्लिप पर केवल ध्वनि लगाता है, और हमें पूरे स्क्रीनसेवर से एक उत्कट गीत की आवश्यकता होती है।
• ऊर्ध्वाधर वीडियो को अलग से संसाधित करने की आवश्यकता होती है। AWS को काली धारियां पसंद नहीं हैं और यह 90 ° पर रोलर्स डालता है।

आसान रिंक

स्टेटलेस की सुंदरता के बावजूद, आपको वीडियो के साथ क्या करने की आवश्यकता है, इस पर नज़र रखने की आवश्यकता है: पहले से ही वीडियो अनुक्रम पर गोंद या ओवरले ध्वनि। सौभाग्य से, MediaConvert अपनी नौकरी के माध्यम से मेटाडेटा के हस्तांतरण का समर्थन करता है, और हम हमेशा "isMasterSoundJob" की तरह एक साधारण झंडा लगा सकते हैं, इस मेटाडेटा को किसी भी स्तर पर पार्स कर सकते हैं।

सर्वर रहित NoOps को ठीक बनाता है - एक ऐसा दृष्टिकोण जो प्रोजेक्ट इन्फ्रास्ट्रक्चर के लिए जिम्मेदार एक अलग टीम की आवश्यकता को मानता है। इसलिए, यह एक छोटा मामला था - हम सिस्टम प्रशासक की भागीदारी के बिना AWS पर समाधान को तैनात करते हैं, जिनके पास हमेशा कुछ करने के लिए होता है।
और इसे तेजी से बढ़ाने के लिए, हम तैनाती स्क्रिप्ट को स्वचालित रूप से यथासंभव एडब्ल्यूएस क्लाउडफ़ॉर्मेशन के लिए स्वचालित करते हैं, जिससे आप वीएस से सीधे एक बटन को तैनात कर सकते हैं। नतीजतन, कोड की 200 लाइनों के साथ एक फ़ाइल आपको तैयार-तैयार समाधान को रोल करने की अनुमति देती है, हालांकि क्लाउडफॉर्म सिंटैक्स आदत से बाहर चौंकाने वाला हो सकता है।

कुल मिलाकर

सर्वरहित रामबाण नहीं है। लेकिन यह तीन सीमाओं के साथ स्थितियों में जीवन की सुविधा प्रदान करेगा: "सीमित संसाधन - कम समय - थोड़ा पैसा।"

सर्वर रहित के लिए उपयुक्त अनुप्रयोगों के लक्षण

• लंबे समय से चल रही प्रक्रियाओं के बिना। हार्ड सीमा एपीआई गेटवे - 29 सेकंड, हार्ड सीमा लैम्ब्डा - 15 मिनट;
• घटना-चालित वास्तुकला द्वारा वर्णित;
• एसओए के प्रकार से शिथिल युग्मित घटकों में टूट जाता है;
• उसकी हालत के साथ बहुत काम की आवश्यकता नहीं है;
• .NET Core में लिखा है। .NET फ्रेमवर्क के साथ काम करने के लिए, आपको उचित रनटाइम के साथ कम से कम डॉकटर की आवश्यकता होगी।

एक सर्वर रहित दृष्टिकोण के लाभ

• बुनियादी सुविधाओं की लागत को कम करता है;
• एक समाधान देने की लागत को कम करता है;
• ऑटो स्केलेबिलिटी
• तकनीकी प्रगति में सबसे आगे विकास।

नुकसान, एक ठोस उदाहरण पर

• वितरित अनुरेखण और लॉगिंग - आंशिक रूप से AWS X-Ray और AWS CloudWatch के माध्यम से हल किया गया;
• असुविधाजनक डिबगिंग;
• लोड की अनुपस्थिति में कोल्ड स्टार्ट;
• AWS उपयोगकर्ता-शत्रुतापूर्ण इंटरफ़ेस एक सार्वभौमिक समस्या है :)