Я працую ў аўтсорсе, дзе галоўны прынцып можна апісаць фразай "прадавай шмат, рабі хутка". Чым хутчэй зробім, тым больш заробім. І, пажадана, каб усё працавала не на мыліцах і соплях, а з прымальным узроўнем якасці. Я раскажу пра свой досвед, калі за кароткі тэрмін трэба было распрацаваць прома-сэрвіс.
Дадзена: root-рахунак на AWS, адсутнасць абмежаванняў па выбары стэка тэхналогій, адзін бэкендэр, і адзін месяц на распрацоўку.
задача: рэалізаваць прома-сэрвіс, дзе карыстачы людзі загружаюць ад аднаго да чатырох відэа працягласцю ад адной да чатырох секунд, якія потым убудоўваюцца ў арыгінальны відэашэраг.
рашэнне
Пісаць свой веласіпедны сэрвіс у такія сціснутыя тэрміны - так сабе задума. Акрамя таго, каб сэрвіс спраўляўся з нагрузкамі і ўсе ахвочыя атрымалі запаветнае відэа, спатрэбіцца інфраструктура. І пажадана не з цэннікам ад самалёта. Таму адразу арыентуемся на гатовыя рашэнні з мінімальнай кастамізацыяй.
Стандартнае рашэнне для працы з відэа – FFmpeg, кросплатформавая кансольная ўтыліта, якая праз аргументы дазваляе і нарэзаць, і накладваць гук. Справа за малым - напісаць абгортку і выпусціць яе ў жыццё. Пішам прататып, які склейвае два відэа, і… пачынаецца самае цікавае. Бібліятэка на .NET Core 2, павінна круціцца на любой віртуалцы, таму бярэм інстанс AWS EC2 і ўсё запрацуе
Утоены тэкстне, не заробіць
.
FFmpeg хоць і спрашчае задачу, але для рэальна працуючага рашэння трэба стварыць ЕС2 інстанс, спраектаваць для яго сеткавую інфраструктуру, у тым ліку Load Balancer. Простая задача па дэплою з нуля «крыху» ўскладняецца, а інфраструктура пачынае патрабаваць грошы неадкладна – кожную гадзіну з кліенцкага рахунку здымаецца сума за рантайм.
Наш сэрвіс не мяркуе Long-Running працэсаў, не патрабуе вялікай і тоўстай рэляцыйнай базы дадзеных і выдатна ўкладваецца ў падзейную архітэктуру з ланцужком выклікаў мікрасэрвісаў. Рашэнне напрошваецца само сабой - мы можам адмовіцца ад ЕС2 і рэалізаваць true-serverless дадатак, накшталт стандартных Image Resizer на базе AWS Lambda.
Дарэчы, нягледзячы на відавочную нялюбасць распрацоўнікаў AWS да .NET, яны падтрымліваюць .NET Core 2.1 у якасці рантайму, што дае поўны спектр магчымасцяў для распрацоўкі.
І вішанька на торце - AWS падае асобны сэрвіс для працы з відэафайламі - AWS Elemental MediaConvert.
Сутнасць працы неверагодна простая: бярэм S3-спасылку на выходнае відэа, праз AWS Console, .NET SDK ці проста JSON пішам, што жадаем зрабіць з відэа і выкліканы сэрвіс. Ён сам рэалізуе чэргі для апрацоўкі ўваходных запытаў, сам выгружае вынік у S3 і, самае галоўнае, генеруе CloudWatch Event на кожную змену статуту. Гэта дазваляе нам рэалізаваць лямбда-трыгеры на завяршэнне працэсінгу відэа.
Прыкладна так выглядае фінальны варыянт архітэктуры.
Увесь бэкенд размяшчаецца ў двух лямбдах. Яшчэ адна - для ратацыі вертыкальных відэа, паколькі такая праца не можа быць выканана за адзін праход.
Фронт у выглядзе SPA-прыкладанні, напісанага на JS і скампіленага праз pug, размесцім у публічнай S3 кошыку. Для загрузкі саміх відэа нам не патрэбен ніякі серверны код – дастаткова адкрыць REST-эндпоінты, якія нам мяркуе S3. Адзіны момант - не забываем наладзіць палітыкі і CORS.
Падводныя камяні
- AWS MediaConvert па нейкім невядомым чынніку накладвае гук толькі на кожны відэафрагмент па асобнасці, а нам патрэбна забіяцкая песня з застаўкі цалкам.
- вертыкальныя відэа трэба апрацоўваць асобна. AWS не кахае чорныя палосы і кладзе ролікі на 90°.
Ізі катка
Нягледзячы на ўсю прыгажосць Stateless, неабходна адсочваць, што патрабуецца зрабіць з відэа: склеіць ці накласці гук на ўжо гатовы відэашэраг. На шчасце, MediaConvert падтрымлівае перадачу метададзеных праз свае Job, і мы заўсёды можам прымяніць просты сцяг па ўвазе “isMasterSoundJob”, распарсив гэтыя метададзеныя на любым этапе.
Serverless выдатна дазваляе працаваць NoOps – падыходам, які мяркуе непатрэбнасць асобнай каманды, якая адказвае за інфраструктуру праекта. Таму справа была за малым - разгортваем рашэнне на AWS без удзелу сісадмінаў, якім заўсёды і так ёсць чым заняцца.
А каб усё гэта паскорыць, максімальна аўтаматызуем дэплой скрыптам на AWS CloudFormation, якія дазваляюць дэплоіць адной кнопкай прама з VS. У выніку, файл на 200 радкоў кода дазваляе выкаціць гатовае рашэнне, хоць і сінтаксіс CloudFormation з нязвычкі можа агаломшыць.
Разам
Serverless - не панацэя. Але моцна палегчыць жыццё ў сітуацыях з трыма лімітамі: «абмежаваныя рэсурсы-кароткі тэрмін-мала грошай».
Характарыстыкі прыкладанняў, якім падыходзіць Serverless
- без Long-Running працэсаў. Хард ліміт API Gateway - 29 секунд, хард ліміт лямбды - 5 хвілін;
- апісваецца Event-Driven архітэктурай;
- разбіваецца на слабазлучаныя кампаненты па тыпе SOA;
- не патрабуе вялікай працы са сваім станам;
- напісана на .NET Core. Для працы з .NET Framework па-ранейшаму запатрабуецца прынамсі Docker з які адпавядае рантаймам.
Перавагі Serverless-падыходу
- зніжае выдаткі на інфраструктуру;
- зніжае выдаткі на дастаўку рашэння;
- аўтаматычная маштабаванасць;
- распрацоўка на вастрыё тэхнічнага прагрэсу.
Недахопы, на канкрэтным прыкладзе
- Размеркаваны трэйсінг і лагіраванне - часткова вырашаецца праз AWS X-Ray і AWS CloudWatch;
- няёмкая адладка;
- Cold Start пры адсутнасці нагрузкі;
- User-hostile інтэрфейс AWS – універсальная праблема 🙂
Крыніца: habr.com