უსერვერო მიდგომა სამუშაო ვიდეო სერვისის სწრაფი განვითარებისთვის

მე ვმუშაობ აუთსორსინგში, სადაც მთავარი პრინციპი შეიძლება აიხსნას ფრაზით „იყიდე ბევრი, გააკეთე სწრაფად“. რაც უფრო სწრაფად გავაკეთებთ ამას, მით მეტს მივიღებთ. და, სასურველია, ყველაფერი მუშაობდეს არა ყავარჯნებზე და სნოტზე, არამედ ხარისხის მისაღები დონით. მოგიყვებით ჩემს გამოცდილებაზე, როცა საჭირო იყო მოკლე დროში სარეკლამო სერვისის შემუშავება.

მაისი root ანგარიში AWS-ზე, არანაირი შეზღუდვა ტექნოლოგიის სტეკის არჩევანზე, ერთი backend და ერთი თვე განვითარებისთვის.

Დავალება: განახორციელეთ სარეკლამო სერვისი, სადაც მომხმარებლები ატვირთავენ ერთიდან ოთხამდე ვიდეოს ერთიდან ოთხ წამამდე ხანგრძლივობით, რომლებიც შემდეგ ჩართულია ორიგინალური ვიდეო სერიებში.

გადაწყვეტილება

საკუთარი ველოსიპედის სერვისის დაწერა ასეთ მოკლე დროში არ არის კარგი იდეა. გარდა ამისა, იმისათვის, რომ სერვისმა გაუძლოს დატვირთვას და ყველამ მიიღოს სასურველი ვიდეო, საჭირო იქნება ინფრასტრუქტურა. და სასურველია არა თვითმფრინავის ფასით. ამიტომ, ჩვენ დაუყოვნებლივ ვამახვილებთ ყურადღებას მზა გადაწყვეტილებებზე მინიმალური პერსონალიზებით.

ვიდეოსთან მუშაობის სტანდარტული გადაწყვეტა არის FFmpeg, კროს-პლატფორმული კონსოლის პროგრამა, რომელიც არგუმენტების საშუალებით საშუალებას გაძლევთ ამოჭრათ და გადაიტანოთ აუდიო. დარჩენილია მხოლოდ შეფუთვის დაწერა და სიცოცხლეში გაშვება. ვწერთ პროტოტიპს, რომელიც ორ ვიდეოს აკერებს ერთმანეთს და... გართობა იწყება. ბიბლიოთეკა დაფუძნებულია .NET Core 2-ზე, ის უნდა იმუშაოს ნებისმიერ ვირტუალურ მანქანაზე, ამიტომ ვიღებთ AWS EC2 ინსტანციას და ყველაფერი იმუშავებს

დამალული ტექსტიარა, არ იმუშავებს
.
მიუხედავად იმისა, რომ FFmpeg ამარტივებს ამოცანას, რეალურად მოქმედი გადაწყვეტისთვის თქვენ უნდა შექმნათ EC2 ინსტანცია და შეიმუშავოთ ქსელის ინფრასტრუქტურა მისთვის, Load Balancer-ის ჩათვლით. ნულიდან განლაგების მარტივი ამოცანა ხდება "ცოტა" უფრო რთული და ინფრასტრუქტურა დაუყოვნებლივ იწყებს ფულის მოთხოვნას - ყოველ საათში გაშვებული თანხის ამოღება ხდება კლიენტის ანგარიშიდან.

ჩვენი სერვისი არ მოიცავს ხანგრძლივ პროცესებს, არ საჭიროებს დიდ და მსუყე რელაციურ მონაცემთა ბაზას და იდეალურად ჯდება მოვლენებზე დაფუძნებულ არქიტექტურაში მიკროსერვისის ზარების ჯაჭვით. გამოსავალი თავისთავად გვთავაზობს - ჩვენ შეგვიძლია მივატოვოთ EC2 და განვახორციელოთ ჭეშმარიტი სერვერის პროგრამა, როგორიცაა სტანდარტული Image Resizer, რომელიც დაფუძნებულია AWS Lambda-ზე.

სხვათა შორის, მიუხედავად იმისა, რომ AWS დეველოპერები აშკარად არ მოსწონთ.

და ტორტზე ალუბალი - AWS გთავაზობთ ცალკე სერვისს ვიდეო ფაილებთან მუშაობისთვის - AWS Elemental MediaConvert.

სამუშაოს არსი წარმოუდგენლად მარტივია: ვიღებთ S3 ბმულს გამავალ ვიდეოზე, ვწერთ AWS Console-ის, .NET SDK-ის ან უბრალოდ JSON-ის მეშვეობით, თუ რა გვინდა გავაკეთოთ ვიდეოსთან და მოვუწოდებთ სერვისს. ის თავად ახორციელებს რიგებს შემომავალი მოთხოვნების დასამუშავებლად, ატვირთავს შედეგს თავად S3-ში და, რაც მთავარია, ქმნის CloudWatch Event-ს თითოეული სტატუსის ცვლილებისთვის. ეს საშუალებას გვაძლევს განვახორციელოთ ლამბდა ტრიგერები ვიდეოს დამუშავების დასასრულებლად.

ასე გამოიყურება საბოლოო არქიტექტურა:

მთელი უკანა ნაწილი მოთავსებულია ორ ლამბდაში. კიდევ ერთი არის ვერტიკალური ვიდეოების მბრუნავი, რადგან ასეთი სამუშაო არ შეიძლება გაკეთდეს ერთი პასით.

წინა ნაწილს განვათავსებთ JS-ში დაწერილი SPA აპლიკაციის სახით და შედგენილია pug-ის საშუალებით საჯარო S3 თაიგულში. თავად ვიდეოების ჩამოსატვირთად, ჩვენ არ გვჭირდება სერვერის კოდი - ჩვენ უბრალოდ უნდა გავხსნათ REST ბოლო წერტილები, რომლებსაც S3 გვაწვდის. ერთადერთი ის არის, რომ არ დაგავიწყდეთ პოლიტიკის და CORS-ის კონფიგურაცია.

უარყოფითი მხარეები

• AWS MediaConvert, გაურკვეველი მიზეზის გამო, მხოლოდ თითოეულ ვიდეო ფრაგმენტს ცალ-ცალკე იყენებს ხმას, მაგრამ ჩვენ გვჭირდება მხიარული სიმღერა მთელი ეკრანმზოგისგან.
• ვერტიკალური ვიდეოები ცალკე უნდა დამუშავდეს. AWS-ს არ მოსწონს შავი ზოლები და აყენებს ლილვაკებს 90°-ზე.

მარტივი სასრიალო მოედანი

მიუხედავად მოქალაქეობის არმქონეების მთელი სილამაზისა, თქვენ უნდა თვალყური ადევნოთ იმას, თუ რა უნდა გაკეთდეს ვიდეოს საშუალებით: დააწებოთ ან დაამატოთ აუდიო დასრულებულ ვიდეოს თანმიმდევრობას. საბედნიეროდ, MediaConvert მხარს უჭერს მეტამონაცემების გადაცემას მისი სამუშაოების მეშვეობით და ჩვენ ყოველთვის შეგვიძლია გამოვიყენოთ ფორმის მარტივი დროშა „isMasterSoundJob“, ამ მეტამონაცემების გარჩევა ნებისმიერ ეტაპზე.

სერვერის გარეშე შესანიშნავად იძლევა NoOps-თან მუშაობის საშუალებას - მიდგომა, რომელიც ითვალისწინებს ცალკეული გუნდის არასაჭიროებას, რომელიც პასუხისმგებელია პროექტის ინფრასტრუქტურაზე. მაშასადამე, ეს იყო პატარა საკითხი - ჩვენ AWS-ზე ვაყენებთ გამოსავალს სისტემის ადმინისტრატორების მონაწილეობის გარეშე, რომლებსაც ყოველთვის აქვთ რაიმე გასაკეთებელი.
და ამ ყველაფრის დასაჩქარებლად, ჩვენ მაქსიმალურად ავტომატიზირებთ განლაგების სკრიპტს AWS CloudFormation-ზე, რომელიც საშუალებას გაძლევთ განათავსოთ ერთი ღილაკით პირდაპირ VS-დან. შედეგად, 200 სტრიქონიანი კოდის ფაილი საშუალებას გაძლევთ გამოაქვეყნოთ მზა გადაწყვეტა, თუმცა CloudFormation სინტაქსი შეიძლება შოკისმომგვრელი იყოს, თუ არ ხართ მიჩვეული.

საერთო ჯამში

სერვერის გარეშე არ არის პანაცეა. მაგრამ ეს ბევრად გაადვილებს ცხოვრებას სამი შეზღუდვის მქონე სიტუაციებში: „შეზღუდული რესურსები — მოკლევადიანი — ცოტა ფული“.

აპლიკაციების მახასიათებლები, რომლებიც შესაფერისია სერვერისთვის

• ხანგრძლივი პროცესების გარეშე. API Gateway-ის მყარი ლიმიტი არის 29 წამი, ლამბდა მყარი ლიმიტი არის 5 წუთი;
• აღწერილია Event-Driven არქიტექტურით;
• იშლება თავისუფლად დაწყვილებულ კომპონენტებად, როგორიცაა SOA;
• არ საჭიროებს დიდ მუშაობას თქვენს მდგომარეობასთან დაკავშირებით;
• დაწერილია .NET Core-ში. .NET Framework-თან მუშაობისთვის მაინც დაგჭირდებათ Docker-ი შესაბამისი გაშვების დროით.

სერვერის გარეშე მიდგომის უპირატესობები

• ამცირებს ინფრასტრუქტურის ხარჯებს;
• ამცირებს ხსნარის მიწოდების ღირებულებას;
• ავტომატური მასშტაბირება;
• განვითარება ტექნოლოგიური პროგრესის უახლესი ზღვარზე.

ნაკლოვანებები, კონკრეტული მაგალითით

• განაწილებული მიკვლევა და აღრიცხვა - ნაწილობრივ მოგვარებულია AWS X-Ray და AWS CloudWatch-ის მეშვეობით;
• არასასიამოვნო გამართვა;
• ცივი დაწყება, როდესაც არ არის დატვირთვა;
• AWS მომხმარებლის მტრული ინტერფეისი უნივერსალური პრობლემაა :)

წყარო: www.habr.com