Jeg jobber med outsourcing, hvor hovedprinsippet kan beskrives med uttrykket "selg mye, gjør det raskt." Jo raskere vi gjør det, jo mer vil vi tjene. Og det er ønskelig at alt fungerer ikke på krykker og snørr, men med et akseptabelt kvalitetsnivå. Jeg vil fortelle deg om min erfaring da det var nødvendig å utvikle en salgsfremmende tjeneste på kort tid.
gitt: root-konto på AWS, ingen begrensninger på valg av teknologistabel, én backend og én måned for utvikling.
Mål: implementere en salgsfremmende tjeneste der brukere laster opp fra én til fire videoer som varer fra ett til fire sekunder, som deretter er innebygd i den originale videoserien.
beslutning
Å skrive sin egen sykkeltjeneste på så kort tid er ingen god idé. I tillegg vil det kreves infrastruktur for at tjenesten skal takle belastningen og for at alle skal motta den ettertraktede videoen. Og helst ikke med prislappen fra flyet. Derfor satser vi umiddelbart på ferdige løsninger med minimal tilpasning.
Standardløsningen for å jobbe med video er FFmpeg, et konsollverktøy på tvers av plattformer som, gjennom argumenter, lar deg kutte og overdubbe lyd. Alt som gjenstår å gjøre er å skrive et omslag og slippe det ut i livet. Vi skriver en prototype som syr to videoer sammen, og... moroa begynner. Biblioteket er basert på .NET Core 2, det skal kjøres på hvilken som helst virtuell maskin, så vi tar en AWS EC2-forekomst og alt vil fungere
Skjult tekstnei, det vil ikke fungere
.
Selv om FFmpeg forenkler oppgaven, må du for en virkelig fungerende løsning lage en EC2-forekomst og designe en nettverksinfrastruktur for den, inkludert en Load Balancer. Den enkle oppgaven med å distribuere fra bunnen av blir "litt" mer komplisert, og infrastrukturen begynner å kreve penger umiddelbart - hver time blir beløpet for kjøretid trukket fra klientkontoen.
Tjenesten vår involverer ikke langvarige prosesser, krever ikke en stor og fet relasjonsdatabase, og passer perfekt inn i en hendelsesbasert arkitektur med en kjede av mikrotjenestekall. Løsningen foreslår seg selv - vi kan forlate EC2 og implementere en ekte serverløs applikasjon, som standard Image Resizer basert på AWS Lambda.
Forresten, til tross for den åpenbare motviljen til AWS-utviklere for .NET, støtter de .NET Core 2.1 som kjøretid, som gir en hel rekke utviklingsmuligheter.
Og kirsebæret på kaken - AWS tilbyr en egen tjeneste for arbeid med videofiler - AWS Elemental MediaConvert.
Essensen av arbeidet er utrolig enkelt: vi tar en S3-lenke til den utgående videoen, skriver gjennom AWS Console, .NET SDK eller rett og slett JSON hva vi vil gjøre med videoen og kaller tjenesten. Den implementerer selv køer for å behandle innkommende forespørsler, laster opp resultatet til S3 selv og, viktigst av alt, genererer en CloudWatch Event for hver statusendring. Dette lar oss implementere lambda-utløsere for å fullføre videobehandling.
Slik ser den endelige arkitekturen ut:
Hele backend er plassert i to lambdaer. En annen er for å rotere vertikale videoer, siden slikt arbeid ikke kan gjøres i én omgang.
Vi vil plassere fronten i form av en SPA-applikasjon skrevet i JS og kompilert via pug i en offentlig S3-bøtte. For å laste ned selve videoene trenger vi ingen serverkode - vi trenger bare å åpne REST-endepunktene som S3 gir oss. Det eneste er ikke glem å konfigurere retningslinjer og CORS.
Fallgruver
- AWS MediaConvert, av en eller annen ukjent grunn, bruker kun lyd til hvert videofragment separat, men vi trenger en munter sang fra hele skjermspareren.
- Vertikale videoer må behandles separat. AWS liker ikke svarte striper og setter rullene i 90°.
Enkel skøytebane
Til tross for all skjønnheten til Stateless, må du holde styr på hva som må gjøres med videoen: lim eller legg til lyd til den ferdige videosekvensen. Heldigvis støtter MediaConvert å sende metadata gjennom jobbene sine, og vi kan alltid bruke et enkelt flagg i formen "isMasterSoundJob", og analysere disse metadataene når som helst.
Serverløs tillater perfekt arbeid med NoOps - en tilnærming som forutsetter unødvendigheten av et eget team som er ansvarlig for prosjektinfrastrukturen. Derfor var det en liten sak – vi distribuerer løsningen på AWS uten deltagelse av systemadministratorer, som alltid har noe å gjøre uansett.
Og for å få fart på alt dette, automatiserer vi distribusjonsskriptet så mye som mulig på AWS CloudFormation, som lar deg distribuere med én knapp direkte fra VS. Som et resultat lar en fil på 200 linjer med kode deg rulle ut en ferdig løsning, selv om CloudFormation-syntaksen kan være sjokkerende hvis du ikke er vant til den.
Totalt
Serverløs er ikke et universalmiddel. Men det vil gjøre livet mye enklere i situasjoner med tre grenser: "begrensede ressurser - kortsiktig - lite penger."
Egenskaper for applikasjoner Egnet for serverløse
- uten langvarige prosesser. API Gateway hard grense er 29 sekunder, lambda hard grense er 5 minutter;
- beskrevet av hendelsesdrevet arkitektur;
- brytes ned i løst koblede komponenter som SOA;
- krever ikke mye arbeid med tilstanden din;
- skrevet i .NET Core. For å jobbe med .NET Framework trenger du fortsatt minst Docker med riktig kjøretid.
Fordeler med serverløs tilnærming
- reduserer infrastrukturkostnader;
- reduserer kostnadene ved å levere løsningen;
- automatisk skalerbarhet;
- utvikling i forkant av teknologisk utvikling.
Ulemper, med et spesifikt eksempel
- Distribuert sporing og logging - delvis løst gjennom AWS X-Ray og AWS CloudWatch;
- upraktisk feilsøking;
- Kaldstart når det ikke er last;
- AWS brukerfiendtlig grensesnitt er et universelt problem :)
Kilde: www.habr.com