Outsourcingban dolgozom, ahol a fő elvet az „eladni sokat, gyorsan csinálni” kifejezéssel lehet leírni. Minél gyorsabban csináljuk, annál többet fogunk keresni. És kívánatos, hogy minden ne mankón és takonyon működjön, hanem elfogadható minőségben. Elmesélem azt a tapasztalatomat, amikor rövid időn belül szükség volt egy promóciós szolgáltatás kidolgozására.
adott: root fiók az AWS-en, nincs korlátozás a technológiai verem kiválasztására vonatkozóan, egy háttérrendszer és egy hónap a fejlesztésre.
Feladat: olyan promóciós szolgáltatást valósítanak meg, amelyben a felhasználók egy-négy, 1-4 másodperces videót töltenek fel, amelyeket aztán beágyaznak az eredeti videósorozatba.
döntés
Nem jó ötlet ilyen rövid idő alatt saját kerékpárszervizt írni. Ráadásul ahhoz, hogy a szolgáltatás bírja a terhelést, és mindenki megkapja az áhított videót, infrastruktúrára lesz szükség. És lehetőleg ne az árcédulával a repülőről. Ezért azonnal a kész megoldásokra koncentrálunk, minimális testreszabással.
A videóval való munka standard megoldása az FFmpeg, egy többplatformos konzol-segédprogram, amely érveken keresztül lehetővé teszi a hang kivágását és átmásolását. Nincs más hátra, mint megírni egy csomagolóanyagot, és felszabadítani az életben. Írunk egy prototípust, amely összefűz két videót, és... kezdődik a móka. A könyvtár .NET Core 2-re épül, bármilyen virtuális gépen futnia kell, ezért veszünk egy AWS EC2 példányt és minden működni fog
Rejtett szövegnem, nem fog menni
.
Bár az FFmpeg leegyszerűsíti a feladatot, egy igazán működő megoldáshoz létre kell hozni egy EC2 példányt, és meg kell tervezni hozzá a hálózati infrastruktúrát, beleértve a Load Balancert is. A nulláról történő üzembe helyezés egyszerű feladata „kicsit” bonyolultabbá válik, és az infrastruktúra azonnal pénzt követel – óránként levonják a futásidőre szánt összeget az ügyfélszámláról.
Szolgáltatásunk nem tartalmaz hosszú távú folyamatokat, nem igényel nagy és vastag relációs adatbázist, és tökéletesen illeszkedik egy esemény alapú architektúrába mikroszolgáltatási hívások láncolatával. A megoldás önmagát sugallja – elhagyhatjuk az EC2-t, és megvalósíthatunk egy valódi szerver nélküli alkalmazást, mint például az AWS Lambda alapú szabványos Image Resizer.
Egyébként annak ellenére, hogy az AWS-fejlesztők nyilvánvalóan nem szeretik a .NET-et, futásidejűként támogatják a .NET Core 2.1-et, ami a fejlesztési lehetőségek teljes skáláját biztosítja.
És a cseresznye a tortán - az AWS külön szolgáltatást biztosít a videofájlokkal való munkához - AWS Elemental MediaConvert.
A munka lényege hihetetlenül egyszerű: veszünk egy S3 linket a kimenő videóra, megírjuk az AWS Console-on, .NET SDK-n vagy egyszerűen JSON-on keresztül, hogy mit akarunk csinálni a videóval, és felhívjuk a szolgáltatást. Maga is sorokat valósít meg a bejövő kérések feldolgozásához, az eredményt magára az S3-ra tölti fel, és ami a legfontosabb, minden állapotváltozáshoz generál egy CloudWatch eseményt. Ez lehetővé teszi számunkra, hogy lambda triggereket alkalmazzunk a videófeldolgozás befejezéséhez.
Így néz ki a végső architektúra:
A teljes backend két lambdában található. Egy másik a függőleges videók forgatására szolgál, mivel ezt a munkát nem lehet egy menetben elvégezni.
Az előlapot JS-ben írt és mopsz segítségével összeállított SPA alkalmazás formájában egy nyilvános S3 vödörbe helyezzük el. Maguk a videók letöltéséhez nincs szükségünk semmilyen szerverkódra – csak meg kell nyitnunk az S3 által biztosított REST végpontokat. Az egyetlen dolog, hogy ne felejtse el konfigurálni a házirendeket és a CORS-t.
Buktatók
- Az AWS MediaConvert ismeretlen okból csak minden videórészlethez külön-külön alkalmazza a hangot, de kell egy vidám dal a teljes képernyővédőből.
- A függőleges videókat külön kell feldolgozni. Az AWS nem szereti a fekete sávokat, és a görgőket 90°-ra állítja.
Könnyű korcsolyapálya
A Stateless minden szépsége ellenére nyomon kell követnie, hogy mit kell tennie a videóval: ragassza vagy adjon hozzá hangot a kész videósorozathoz. Szerencsére a MediaConvert támogatja a metaadatok átadását a Jobs-on, és mindig használhatunk egy egyszerű „isMasterSoundJob” formátumú jelzőt, amely bármely szakaszban elemzi ezeket a metaadatokat.
A kiszolgáló nélküli megoldás tökéletesen lehetővé teszi a NoOps-szal való munkát – ez a megközelítés feltételezi a projekt infrastruktúrájáért felelős külön csapat szükségtelenségét. Ezért ez apróság volt – a megoldást az AWS-re telepítjük a rendszergazdák részvétele nélkül, akiknek amúgy is mindig van tennivalójuk.
Mindezek felgyorsítása érdekében pedig a lehető legnagyobb mértékben automatizáljuk a telepítési szkriptet az AWS CloudFormation-en, amely lehetővé teszi, hogy egyetlen gombbal telepítse közvetlenül a VS-ről. Ennek eredményeként egy 200 sornyi kódból álló fájl kész megoldást tesz lehetővé, bár a CloudFormation szintaxis sokkoló lehet, ha nem szokott hozzá.
Összességében
A szerver nélküli nem csodaszer. De ez sokkal könnyebbé teszi az életet olyan helyzetekben, ahol három korlát van: „korlátozott erőforrások – rövid távú – kevés pénz”.
A kiszolgáló nélküli alkalmazásokhoz alkalmas alkalmazások jellemzői
- Hosszú távú folyamatok nélkül. Az API Gateway kemény határa 29 másodperc, a lambda kemény korlátja 5 perc;
- eseményvezérelt architektúra írja le;
- lazán összekapcsolt komponensekre bomlik, mint például a SOA;
- nem igényel sok munkát az Ön állapotával;
- .NET Core-ban íródott. A .NET-keretrendszerrel való együttműködéshez legalább a megfelelő futási környezettel rendelkező Docker szükséges.
A szerver nélküli megközelítés előnyei
- csökkenti az infrastruktúra költségeit;
- csökkenti a megoldás szállításának költségeit;
- automatikus skálázhatóság;
- fejlődés a technológiai haladás élvonalában.
Hátrányok, konkrét példával
- Elosztott nyomkövetés és naplózás – részben megoldva az AWS X-Ray és az AWS CloudWatch segítségével;
- kényelmetlen hibakeresés;
- Hidegindítás, ha nincs terhelés;
- Az AWS felhasználói ellenséges felülete univerzális probléma :)
Forrás: will.com